Cognition 2.0

The SOA platform is still in the process of maturing and hence lacks higher level patterns and best practices that allow adopters and implementers be successful in deploying an Enterprise Service Bus corporate-wide. Although the technology is mature in terms of products being available for deploying services on top, there are few, if any, patters available to guide the way that SOA should be implement to fully leverage and benefit from the architecture.

If we compare the level of maturity of other technologies, such as application servers, servlet containers, among other, there are a great variety of structural patterns and frameworks that can be used. To mention a few in the same context mentioned above, we have Enterprise Java Beans that allow making remote calls to EJBs deployed on other servers. They also come in different "flavours", such as Session Beans, Entity Beans, and Message-driven Beans that provide clean patterns for business logic, data access, and message processing and queuing, respectively. Servlet containers have long been used to deploy web applications that use the Model-View-Controller pattern to provide data presentation and screen manipulation functionality that is independent of the back-office implementation, abstracting everything relating to data access, business rules, and integration to other systems and applications.

To this end, and looking at the variety of issues and flavours of ESB implementations out there in the field, I propose to use and establish a design pattern that simplifies the task of deciding how to deploy a SOA-compliant system. The pattern is called Model-Process-Policy, or MPP for short. The pattern takes the following shape:

The above image is taken from a telecom-specific implementation model that I prepared for TELUS using NetCracker as the Operational Support System (OSS) for resource and service inventory applications. However, the pattern can be extended and applied to any model-driven architecture (MDA) out there, NetCracker being a great example of one.

The pattern starts with the Model. The model is a templated object factory pattern that creates object instances from a template and updates the instance via a change object, or in the case of a telecom application, via a service order. This change object is nothing else but a memento-pattern from the GoF patterns. It provides the advantage of keeping a mirror image of the object during its transformation and can be used as a means to undoing or redoing a specific action or change.

The pattern then flows into the Process. The process is also a templated process model that is directly related and extends the object model from a procedural or transaction point of view. The process is responsible for executing and orchestrating the changes of the model taking it through a series of steps that are pre-determined in the process flow stored within the process template. As soon as a change object is created and committed in the model, a process instance is created in the process engine and the change object is bound to it. There is a 1:1 correspondence between the change object and the process instance, however the process instance can have many sub-processes.

Finally, the Policy is then triggered by the Process. This entails the creation of a process instance, as we mentioned above, and the use of a specific set of policies or business rules that apply to the objects created from the model template. This means that as soon as the process instance starts executing, the process instance looks up a set of policy rules ready to be applied on the model for decision making and model transformation purposes. Hence, out of the hundreds or thousands of potential policies throughout the enterprise, only those that apply to the objects or, better said, object types in the process of being transformed, are the ones filtered out from the inventory of policies and applied to the object instances in the model.

Let's take for example the case of a request to upgrade the bandwidth of a particular internet service on the carrier's network. The request would come as a service order that intends to modify certain parameters of the service, namely the bandwidth or any of its QoS parameters. This would trigger a process instance to be attached to the service order that contains all the steps required for determining the steps needed to change that parameter, namely validating the service location where the customer is located, determining which POP site the service address is served from, and then selecting the equipment in the Central Office that the customer is connected to, down to the port. Once this information is calculated and represented as part of the model, the process instance needs to apply certain policies for determining what business rules need to be applied to transformations of type "change" to objects of type "port". This brings forward policies that specify the maximum amount of used ports that can be allocated on any given equipment, the necessary connections that the equipment bearing the port needs to have to other pieces of equipment to guarantee connectivity and, in our particular case, also bandwidth. There may also be other business rules in effect pertinent to the equipment, time, and so on when the change is to happen. Once the rules have been executed and the process instance finishes, the change object becomes the object instance and the old instance can be kept as history record.

There are other cases where the same pattern can be applied, here is another one to keep the discussion brief and realize the generality of the pattern. An airline ticket reservation system receives an order to book a flight from a specific location to a destination on a given date. Once the necessary parameters are captured through the online screens, the customer submits the request to the reservation system, which in turn creates a process instance that looks up airlines that fly between the departure and destination cities, then it gathers the information about times and dates, and seat inventory information for every flight. At this point the process engine assembles the information in a way, such as to present it back to the customer and potentially to gather more information as to the preferences and other collateral information that is required to make a decision. Once the customer provides the rest of the information, the process engine resumes and start applying any rules and policies applicable to the model at hand and assists the process engine in directing the dialog between the customer and the booking system until a decision is reached and either a match is found or another search is started.

As shown above, the MPP pattern is a generic pattern that provides separation of concerns and a repeatable and sustainable architecture for SOA and Enterprise Service Bus implementations.