Presenter: Rob Daigneau (Chief Architect, SynXis)
Blog: http://www.designpatternsfor.net
Author of an upcoming book on SOA Design Patterns published by Addison Wesley.
This was definitely the most interesting talk of the conference so far. It's pleasing to see an advanced course that really got into some great architectural discussions and provided applicable techniques for solving difficult SOA problems such as maintenance, versioning, forward, and backward compatibility. This session is geared towards the WCF developer who is looking to improve their service oriented design architecture.
There are two typical types of SOA services:
Domain Services
These are the elemental building blocks upon which everthing else is built.
Enterprise Services
Enterprise services are composities of domain services that are pulled together in order to provide more comprehensive, enterprise-level solutions.
Domain Services
Domain services are designed primarily to address a business problem within a particular domain. They encapsulate business logic and data management to abstract the details of the service from consumers of that service. The roles of domain services are also to encapsulate and leverage existing business logic components and classes to allow for re-use of existing components that would be too expensive to re-write. When encapsulating business logic it is performing the role of a mediator. When simplifying the interface to re-used or abstracted objects, it is acting in the role of a facade. A domain service can be thought of as an additional (fourth) layer that exists between the UI and business layers in the application. This does not mean that every application that wishes to communicate with the business tier needs to go through the service. The service layer itself can introduce a performance hit as it may be abstracting the fact that the business logic components are executing on a different machine than the caller. Certain applications may still want to access the business tier directly and this is perfectly acceptable even with an available domain service.
Message Exchange Patterns
Request-Response Pattern
The most basic message exchange pattern is for a request to be issued to the service by the client which then waits for a response from that service. The disadvantage of this pattern is that the client is sitting in an idle state until a response is received from the service. There is no guarantee of how long it might take for the service to respond and hence no way to know how long the client will be locked in the waiting state.
In Only
An example of the "In Only" pattern, also known as Fire and Forget, is a service such as a booking system that takes a request for information and then indicates that a response will be delivered once some process has completed. This might be in the form of an email will be sent to a customer once their original request has been processed. The disadvantage with this system is that the client has to wait an indeterminate amount of time for a response and has to check for that response periodically, i.e. a user checking their Inbox for a confirmation message. This pattern does not work well when both client and service and software programs. Client software polling for a response is a sub-optimal architecture.
Duplex
This message exchange pattern uses asynchronous methods with callbacks to allow a client to continue working after it sends the request. A callback method is sent as part of the request such that the service can invoke that callback method with a response once the work of the service has been complete. However, this requires that the client is still alive and hence able to receive the response once the service is ready to make the callback.
The Duplex (callback) Pattern in Practice
How callback works from the Client
Configuration of the message exchange pattern that will be used can be handled via attributes upon the service definitions. The channel description for the contract is specified in the ServiceContract attribute on the client. In this way, the client can issue a message and continue processing, knowing that the callback will be received once the service has completed its work.
How Callback works from the Service
The implementation of the service can use OperationContext.Current.GetCallbackChannel<> to get a callback channel to the client that issued the request. This gets a specific callback channel that can be used to callback the client with the response. This same mechanism can also be used to implement a publisher subscriber pattern by building a registry of subscribers to callback with the response. In this way, a single request from the Publisher of information can be called back to multiple Subscribers.
Data Transfer Objects
Very similar in definition to the application objects that we use (you DO use objects that are free from business logic to transfer data right?), data transfer objects are used in messages sent to and from the service in order to abstract the definition of an object and avoid having parameters listed in any service contract. This loosens the coupling of the service and client and reduces the service area exposed by the client by reducing all operations involving a particular logical entity to using collections (one item collections for single objects) for all transactions involving a particular entity.
Service Message and Contract Amendments
Better even than passing data transfer objects in service operations, consider using a service message object instead. What is the justification for this? Consider that some additional metadata needs to be transmitted for a particular operation that does not logically fit within the definition of a particular data transfer object. This metadata would classically (in an RPC mindset) be appended to the signature of the operations in the service contract. However, this tightens the coupling and increases the surface area of the service contract. If the service operation simply took a service message as the single parameter, this message could be extended with the metadata without affecting the contract. Even better, consider that a message contains a data transfer object specific extension object that will always contain the additional message metadata and can itself be extended over time. This keeps the definition of the message object itself from changing as new metadata is introduced. This extension object is known as a collection of contract amendments as it literally encapsulates the amendments that have been made to the service contract over time. The amendments property should be declared within the message when it is first developed, despite the fact that it will start it's life as an empty and essentially redundant collection. This allows for the addition of amendments over time without having to modify the message object at any point in its life. This is an extremely desirable stability in the only parameter passed to the operations in a service contract. The final consideration here is that amendment properties must be marked as not required, otherwise existing clients that are unaware of the new amendment will break.
Forward and Backward Compatability
The service should check for the presence of the amendment properties, in the case that the properties are null, it can be determined that an older client is accessing the service. In order to provide appropriate compatability, the service should continue to work even if this extension data is not provided.
The MessageContract Attribute
There is little information out there about the MessageContract attribute for use in classes that define transport-level messages. It gives much greater control that the oft-touted DataContract class.