Archive for December, 2008

WCF Extension Points – Dispatcher

Posted: December 28, 2008 in WCF
Tags:

In this post I will be discussing about the various extensibility points of WCF in the server side.I had already discussed in one of my earlier posts (WCF ServiceHost & Channels) about the basic flow of control in the service side but still let me repeat this here once more for a better context setting.The key elements of the service side dispatcher framework are:

  1. ChannelDispatchers – ChannelDispatchers (ChannelDispatcher) accept incoming messages.Each ChannelDispatcher is associated with exactly one ChannelListener.ChannelListener receives the message as mentioned and the message is processed by channels.After the message is processed by the associated channels then ChannelDispatcher passes it on to a suitable EndpointDispatcher.
  2. EndPointDispatchers – EndPointDispatchers are responsible for taking a message out of the channel stack and passing them to the right service operation.
    • One of the key element of the EndpointDispatcher is the DispatchRuntime.DispatchRuntime provides facility to alter default service behaviour using custom classes to provide enhanced functionality related to Service Instancing,Error Handling,Security etc.
    • DispatchRuntime contains the DispatchOperation which is responsible for routing the message to the right operation and providing customizations facilities applicable at the operation level.

I will list down the extension points available in DispatchRuntime and DispatchOperation along with the interfaces required to be implemented in order to develop these extension components.

DispatchRuntime

  1. DispatchRuntime exposes the following two properties which provide facility to customize how ChannelDispatcher accepts or closes a channel.
    • ChannelInitializers – This is a collection of System.ServiceModel.DispatchRuntime.IChannelInitializer interface objects.This interface is for raising notifications when a channel is created.
    • InputSessionShutdownHandlers – This is a collection of System.ServiceModel..DispatchRuntime.IInputSessionShutdown interface objects.This interface is used to define actions for shutdown of an input session.
  2. The following properties are exposed for customizing message processing:
    • MessageInspectors – This is a collection of System.ServiceModel.DispatchRuntime.IDispatchMessageInspector objects.IDispatchMessageInspector defines contract to manipulate the messages
      • after a message is received but before dispatched to the operation
      • after a operation is executed but before reply is sent
    • OperationSelectors – This is a collection of System.ServiceModel.DispatchRuntime.IDispatchOperationSelector objects.IDispatchOperationSelector defines contract to select an operation name based on the message content.
    • Operations – This is a collection of System.ServiceModel.DispatchRuntime.DispatchOperation.We will discuss about the DispatchOperation in the next section.
    • ErrorHandlers – This is a collection of System.ServiceModel.DispatchRuntime.IErrorHandler objects.IErrorHandler defines methods to control the behaviour when an application exception is thrown.
  3. The creation and lifetime of the service instances can be controlled by
    • InstanceContextInitializers – This is a collection of System.ServiceModel.DispatchRuntime.IInstanceContextInitializer objects.IInstanceContextInitialzer defines the contract to manipulate the InstanceContext objects.
    • InstanceProvider – This is an object of type System.ServiceModel.DispatchRuntime.IInstanceProvider and this interface defines methods to customize creation and release of service instances.

DispatchOperation

  1. Formatter – This property of type System.ServiceModel.DispatchRuntime.IDispatchMessageFormatter provides explicit control over message formatting.
  2. CallContextInitializers – This is a collection of System.ServiceModel.Dispatcher.ICallContextInitializer objects.This interface defines methods to add additional state information that is required during execution of the call.
  3. ParameterInspectors – This is a collection of System.ServiceModel.DispatchRuntime.IParameterInspector objects and this interface defines methods to inspect/modify the parameters before and after method call.

So to extend the WCF functionality we need develop a component implementing the required interfaces and then assign it with the appropriate property of DispatchRuntime/DispatchOperation.Now the obvious question is how do we attach the these components to the runtime in declarative or config driven manner?.This is where the WCF behaviours come into picture which I will discuss in my next post.

HTTP Based APIs

Posted: December 14, 2008 in WCF, WebService
Tags: , ,

For the past few years we have seen the growing popularity of blogs,wiki,social networking sites as a part of the Web 2.0 paradigm.Most of these sites are exposing API or services which are accessible over web to enhance the level of collaboration.From technical perspective these APIs are of two types:

  1. Services complying to the WS-* protocols exchanging data as XML based SOAP format.
  2. Simple HTTP APIs exchanging data in POX(Plain Old XML)/JSON(JavaScript Object Notation) format.

The WS-* protocols and SOAP has evolved as part of SOA where the main goal was to achieve a platform/vendor neutral mechanism of distributed computing organizing the architecture around the concept of service.

With advent of Web 2.0 the second category of services I mentioned above are growing in popularity because of their lightweight nature and ease of use.Whenever I discuss about this kind of services with my friends they refer to the term RESTful services.This I feel is not correct.All HTTP based services that does not use SOAP should not be referred to as RESTful.A service is RESTful or not depends upon how you conceptualise the design of the service rather than what technology or data format you use.This is what I would like to substantiate in this post.To make this difference clear and crisp I need to discuss about REST first.

REST

Why we call Intenet as WorldWideWeb?.This is because it is a web of linked resources,we request for a particular resource and what we get is a representation of that resource.This representation may contain a link to another resource and thus we navigate from one resource to another.This is the basic concept of REST.REST is how the WWW actually works.

The term REST (Representation State Transfer) was coined by Roy T Fielding in his PhD dissertation paper entitled “Architectural Styles and the Design of Network-based Software Architecture”. There he described REST as

“Representational State Transfer (REST) architectural style for distributed hypermedia systems, ..”

So REST is the architectural style around which WWW is built.

The key constraints of REST are

  1. Client & Server – This separates the UI from data processing and storage.
  2. Stateless – This implies that each client request must contain all necessary information to process the request.No state is maintained by the server.This improves reliability as state of a request is not preserved and hence no need to recover in case of failure.This improves scalability taking away overhead of state management from server.
  3. Cached – Response for a particular request can be identified as cacheable or non-cacheable.If it is cacheable then client can reuse the response to the same request.This improves efficiency.
  4. Layered – This allows the system to be decomposed into hierarchy of layers where each layer depends on the service provided by the layers below and provides some service to the layers above in the hierarchy.This helps to reduce system complexity but adds to latency which can be balanced by caching.
  5. Uniform Interface – This implies loose coupling between services provided and their implementations so that they can evolve independently of each other.

Resource is the major abstraction in REST.A Resource can be document ,image or a service which is uniquely identified by it’s Uniform Resource Identifier(URI).Each resource has an associated sequence of bytes for it’s Representation and Representation Metadata describing the representation e.g. representation can be a document and it’s representation metadata might be content type of the document.

Now the obvious question how do we achieve the Uniform Interface?.This is provided by the Hypertext Transfer Protocol or HTTP.HTTP is the well established application level protocol for WWW and provides well defined operations and status codes.The listing below shows the HTTP methods and their correspondence with the CRUD operations.

Method Name Description CRUD operation
GET Retrieves representation of a resource READ
POST Submits data to be processed by a resource UPDATE
PUT Creates a new resource or representation CREATE
DELETE Deletes a resource DELETE

RESTful Services

So how do we apply REST in terms of services.REST defines the way we human beings interact with the Web so if we apply the same style in defining the way programs interact over the Web we will be able to design RESTful services.

Let us proceed with the design considering a web application exposing services to maintain personal contacts where list of contacts or a single contact can be retrieved,new contacts can be added,existing can be updated and deleted.

  • Identify the Resources – To identify the resources we need to focus on the entities in the problem domain i.e. Nouns.Here the two entities are
    • Contacts – All contacts
    • Contact  – Individual contact present in the list.This is a part of Contacts itself.
  • Design the URI
  • Map with CRUD operations as per requirement
HTTP Method URI Service Provided
GET www.xyz.com/Contacts View All Contacts
PUT www.xyz.com/Contacts Add new contact
GET www.xyz.com/Contacts/100 Get details of contact with id=100
POST www.xyz.com/Contacts/100 Update contact with id=100
DELETE www.xyz.com/Contacts/100 Delete contact with id=100
  • The content type of the representation of these resources can be POX/JSON.

RPC Style Services

For the same application to design RPC style services the design approach will be different.We will be concentrating on the operations to be provided by the service i.e. actions or Verbs.

Differences Summary

  • RPC focuses on actions/verb while REST focuses on resources/entities/nouns.
  • RPC defines an custom interface with operations and REST defines a resource with URI and actions are defined by uniform interface of HTTP.