Friday, 4 February 2011

Known Types in a WCF service

Firstly, this post has been prompted by an MSDN Magazine article by renowned brain-box, Juval Lowy: Data Contract Inheritance. Having recently been forced to resort to the [KnownType] attribute on a WCF data contract, and having been slightly confused as to why (not to mention uncomfortable with having a data contract base class now coupled to its subclasses) the article has proved most illuminating.

For my own benefit here are a few choice bits from the article (my bold).

What’s the problem?

Unlike traditional object orientation or the classic CLR programming model, WCF passes all operation parameters by value, not by reference… The parameters are packaged in the WCF message and transferred to the service, where they are then deserialized to local references for the service operation to work with…

… With multitier applications, marshaling the parameters by value works better than by reference because any layer in the architecture is at liberty to provide its own interpretation to the behavior behind the data contract. Marshaling by value also enables remote calls, interoperability, queued calls and long-running workflows.

If you do pass a subclass reference to a service operation that expects a base class reference, how would WCF know to serialize into the message the derived class portion?

What does [KnownType] do?

When the client passes a data contract that uses a known type declaration, the WCF message formatter tests the type (akin to using the is operator) and sees if it’s the expected known type. If so, it serializes the parameter as the subclass rather than the base class…

The WCF formatter uses reflection to collect all the known types of the data contracts, then examines the provided parameter to see if it’s of any of the known types…

… Because the KnownType attribute may be too broad in scope, WCF also provides ServiceKnownTypeAttribute, which you can apply on a specific operation or on a specific contract.”

.Net 4 to the rescue

To alleviate the problem, in the .NET Framework 4 WCF introduced a way of resolving the known types at run time. This programmatic technique, called data contract resolvers, is the most powerful option because you can extend it to completely automate dealing with the known type issues. In essence, you’re given a chance to intercept the operation’s attempt to serialize and deserialize parameters and resolve the known types at run time both on the client and service sides.

Friday, 4 February 2011

Wednesday, 2 February 2011

Remember Oracle?

OK, it looks like I’m going to have to work with Oracle again after some considerable time working exclusively with MS SQL Server. I’m now so used to T-SQL I thought I’d better spend some time getting up to speed with PL/SQL again. As usual there’s no detail here; this post is just an aide-mémoire.

What is PL/SQL?

The abbreviation PL/SQL refers to Oracle's Procedural Language extension to SQL. In general PL/SQL is executed on the database server but some tools (e.g. SQL Developer) can execute PL/SQL on the client. PL/SQL is a procedural language that also enables you to embed SQL statements within its procedural code.

PL/SQL basics

A PL/SQL Block consists of three sections:

  • The Declaration section
    • Optional
    • Starts with the keyword DECLARE
    • Used to declare any placeholders like variables, constants, records and cursors
  • The Execution section
    • Mandatory
    • Starts with the keyword BEGIN and ends with END
  • The Exception (or Error) Handling section
    • Optional
    • Starts with the keyword EXCEPTION

Basic PL/SQL looks like this:

[DECLARE
     -- Variable declaration here]
BEGIN
     -- Program Execution here
[EXCEPTION
     -- Exception handling here]
END;

For example:

DECLARE
 x   NUMBER;
BEGIN
 x := 123456;
 dbms_output.put_line('x = ');
 dbms_output.put_line(x);
END;
/

The general syntax for declaring a variable is either variable_name:= value; or assigning a value in a SQL statement using the INTO keyword. Note that if the dbms_output.put_line function doesn’t print anything try using SET SERVEROUTPUT ON first. We can select values into a variable like this:

SELECT column_name
INTO variable_name 
FROM table_name 
[WHERE condition]; 
Records

Records are a composite data types (i.e. a combination of different scalar data types like char, varchar, number etc.). Each scalar data type in the record holds a value. A record is therefore somewhat analogous to a row of data.

TYPE record_type_name IS RECORD 
(first_col_name column_datatype, 
second_col_name column_datatype, ...); 

To assign values to elements of a record use the following syntax:

record_name.column_name := value;  

For example:

SELECT col1, col2 
INTO record_name.col_name1, record_name.col_name2 
FROM table_name 
[WHERE clause]; 
Functions

NB: A function must always return a value. Basic function definitions look like this:

CREATE OR REPLACE FUNCTION my_function
 RETURN NUMBER AS
  x   NUMBER;
 BEGIN
  x := 123456;
  RETURN x;
 END;
/

Want to see errors?

SHOW ERRORS;

Execute the function:

SELECT my_function FROM DUAL;
Procedures

NB: A procedure may or may not return a value. A procedure is a PL/SQL Block that is stored and named for reuse. Parameters can be passed to and from a procedure in the following ways:

  • IN-parameters
  • OUT-parameters
  • IN OUT-parameters

The basic syntax for creating a procedure is:

CREATE [OR REPLACE] PROCEDURE proc_name [list of parameters] 
IS    
   Declaration section 
BEGIN    
   Execution section 
EXCEPTION    
  Exception section 
END; 

To execute a procedure use the following syntax. From the SQL prompt.

 EXECUTE [or EXEC] procedure_name; 

Or from within another procedure:

  procedure_name;
The DUAL table

Why select from DUAL? The DUAL table is used in Oracle when you need to run SQL that does not have a table name. It is a special table that has exactly one row and one column (called DUMMY). Because it has one row it is guaranteed to return exactly one row in SQL statements.

Packages

A package is a schema object that groups logically related PL/SQL types, items, and subprograms. Packages usually have two parts, a specification and a body, although sometimes the body is unnecessary. The specification (spec for short) is the interface to your applications; it declares the types, variables, constants, exceptions, cursors, and subprograms available for use. The body fully defines cursors and subprograms, and so implements the spec.” - http://download.oracle.com/docs/cd/B10500_01/appdev.920/a96624/09_packs.htm

See also

http://plsql-tutorial.com/

Wednesday, 2 February 2011

What is Progressive Enhancement?

Progressive Enhancement is a web design strategy that approaches the same problems tackled by Graceful Degradation but from the opposite direction. Rather than a designer creating a compelling experience for the latest browsers and then making it degrade acceptably for older browsers, a designer ensures that basic functionality is available to all browsers and then offers additional functionality to those with a higher specification.
Wikipedia states that Progressive Enhancement consists of the following core principles:
  • basic content should be accessible to all browsers
  • basic functionality should be accessible to all browsers
  • sparse, semantic mark-up contains all content
  • enhanced layout is provided by externally linked CSS
  • enhanced behaviour is provided by unobtrusive, externally linked JavaScript
  • end user browser preferences are respected
This approach has lead to the adoption of related ideas such as Unobtrusive JavaScript (as now supported by Microsoft MVC 3).

References