Friday, January 29, 2010

Managing SOA—The Control Layer


You should maintain control of your SOA environment by ensuring that all SOA messages in your system comply with a service framework that incorporates a standardized service stub containing necessary control elements for each message.  Whether using a federated ESB or your own canonical approach, you must ensure that every SOA message contains the following elements:
          Versioning. This will enable you to gracefully introduce new versions of services and interfaces. The service routing fabric (often part of the ESB) will be able to use this information to help decide whether to send the service request to one implementation of the service versus another. Clearly, service versioning should be used sparingly and judiciously as it could become a de-facto means of creating new families of services and thus make future control of service implementations more difficult.

          Prioritization. The SOA middleware may be in the position to deliver services under pre-defined level agreements.

          Sequencing/Time-stamping. It’s always a good idea to introduce an ordinal counter for each service request. Ideally, if the response to the service is atomic and can be associated with a request, the response should also incorporate the ordinal number of the request. This type of information can be used for debugging purposes, or even to give the client the ability to associate a response to a request without having to keep state. Time-stamping all services is good way to ensure the potential tracking of performance metrics and the ability to debug message routes.

          Logging level. In principle all service calls should be “log-able”. Once a system has been stabilized, you will probably want to log only a few key service calls. However, given the need, you may want to increase the detail of logging on demand. Setting up a log-level in each service message will enable the middleware to decide whether or not the threshold for logging requires the message to be logged.

          Caching Ability. This setting works in two ways. From a requester’s perspective, the flag may indicate to a caching entity that under no circumstance should there be a cached response to the request.  From a responder’s perspective, the flag might indicate to the caching entity whether or not the response should be cached.
I recommend that you task your architecture group to define the specifics of an Enterprise Service Framework (ESF) to ensure all your applications generate services with the standard headers you’ve defined. The ESF should be instantiated as a common repository of dynamically linked libraries that are a part of your programmers toolkit; one that will have the appropriate headers transparently appended during the service call.
In the end, the establishment of standard headers under an ESF is a foundational practice necessary to support system-wide dashboard monitoring, preventative systems management and proactive performance planning.