I’m going to begin a long series of blog articles about a new architecture pattern that will allow creation of more reliable service oriented architectures.  This pattern is based on a set of technologies realized on, but not invented on, the Microsoft Windows platform.  The pattern is primarily based on the realization that certain once arcane techniques are now capable of being used easily, naturally, and in combination with each other.  Enterprise developers can now leverage advanced concepts that were constrained to arcane machines and even more arcane implementations in their day to day operations, and gain great benefit from them.

My goal is to show how, in Windows .Net environments, using the new 3.0 functionality released last November, powerful SOA architectures can be created that have the following non-functional features;

• Robustness -  they are extraordinarily robust, capable of recovering from total failures and resuming operations as if no fault had happened.  In fact, you could take one of these systems, in active operation with partially completed service operations and move it from one machine to another without affecting it.  That means you could stop, move, and restart the entire service architecture without affecting ongoing operations beyond the actually time delays introduced by these actions.
• Scalability - This architecture supports the needs of the enterprise to be scalable and reliable.  In many real world cases, the need to be scalable has to be balanced with the need to be reliable, however in this case, the two goals can be unified.  One artifact of this is that you can easily create sessions and manage transactions without introducing the scalability penalties normally encountered.
• Efficiency -  The architecture is efficient, both in terms of the development effort and in terms of it’s runtime efficiency.  The architecture does not impose a large amount of work on the developers, rather it is a way of looking at existing facilities and combining them to achieve the desired effect.  Run time efficiency comes from the fact that the developed SOA is able to extract maximum benefit from the high performance generalized capabilities it has combined to achieve these results.

Three concepts are central to this architecture.  The first is known as continuations, which is a mechanism where a running program can preserve it’s operating state and return to this state as needed.  The word processor I am using can technically do that simply by saving and reloading a document, however that state is being preserved from an external perspective only.  I can’t see Word’s internal state, and have no way of knowing whether or not it’s internal state is actually being preserved.  Continuations are a means for preserving low level program state, such that it is known for certain that the program is returning to exactly the same internal state it was in earlier.

The second concept involves a change to the request-response mechanism currently assumed in traditional SOA architectures.  The traditional mechanism is based on an earlier generation of technology, where it could be safely assumed that anything capable of providing a service endpoint could be a client (consume other services) but that a client was not necessarily capable of providing an endpoint.  Another way of looking at this is to say that the definition of a service was implied by the creation of an endpoint.  Obviously this isn’t true, but given the earlier technological restrictions, it was in fact an implication of the assumptions.  With the new WCF architecture this is no longer a restriction and its absence allows us to define services in a new way. Any service can be a client and vice versa.

The last concept involves the use of closures, which are a means of declaring bodies of code that are shared between two operating scopes of a program.  Consider the traditional implementation of data access layers (DAL), where there is an obviously generic layer directly on top of the data access functionality, and there is an obviously specialized layer representing the business objects used by the application.  In this style of architecture, a third layer, explicit or implicit, comes into existence to bridge between the business objects and the generic DAL.  In architectures where this activity is formalized, it is usually referred to as the entity layer, and provides the data transport objects (DTO) that move information between the business objects and the DAL.  In essence, closures provide a mechanism whereby this layer can be completely stripped out of the architecture and represented with free floating logical entities passed directly between the business objects and the generic DAL.  In the architecture I’m discussing in these blog entries closures are used for a completely different purpose, but the initial examples will show how closures affect this well known pattern, to make understanding them easier.

These three concepts lead to the rise of several functional features of the architecture.

Symmetry – This comes from the change in the request-response mechanism.  Where traditional SOA architectures are to some degree asymmetric, this architecture is far more symmetric, where clients and services are distinguished by what they actually do, rather than by how they are built.  This isn’t to say that I’m arguing for changing the nature of “true clients”, e.g. the business applications at the edge of the SOA, rather that I want to make the internals of the SOA, where many services are also clients of other services, more uniform.

Agility – The use of continuations makes the SOA more agile with respect to threads, application domains, processes, and threads.  It is truly capable of beginning an operation on one machine and completing the operation on another machine without requiring much effort on the developers or IT support staffs part.

Implementation of this architecture is not necessarily restricted to the Microsoft .Net platform, however a compelling feature of the architecture is that .Net makes the use of these techniques extremely simple, and it ensures that the necessary infrastructure is present.  For these reasons, and because my area of specialty in enterprise software is based on the .Net platform, that is what I will concentrate on.