Key Learnings:Drawing parallels between Design Patterns and the principles of SOA - Part II

This blog entry attempts to expand on the concepts explored in a prior blog of mine Key Learnings: Drawing parallels between Design Patterns and the principles of SOA that deals the relevance of design patterns in the world of SOA and services. Patterns explored previously were the Facade, Abstract Factory, Builder, Factory and Bridge.

In this blog we look at how infrastructure components like the ESB that are part of the service mediation layer insulate the service consumer from the service provider by offering call-dispatch functions that map out the most efficient call execution path for honoring a consumer business request। Many of the constructs of the service mediation layer provide add-on capabilities which are in fact model driven implementations of common design patterns।


Adapter - modifies an incoming method call to fit the required method signature or definition of the provider without impacting the consumer

Transformer - adapts the parameter and return type or message format (which includes alteration or interpretation of the message content) and enables the insulation of the consumer information from that of the providers'

Decorator - augments the behavior or is a facility to add on to the behavior without altering the interface and breaking the service interface and service contract as new consumers need additions to the base business behavior

Interceptor - provides ancillary behavior, filters out information or calls to the provider, validates the message content for authN credentials, authZ/ entitlements and permissions etc। all of which provide important ancillary behavior to the provider without having the providers' service implementation layer having to be peppered with nonbusiness logic level code।

Finally, the point of this blog is to show that despite vast numbers of changes in technologies and technology based service offerings the basic design principles and design patterns of the object oriented design realm are still applicable। Knowing these and applying these carefully enables one to retain the durability of the service interface and protects the consumers from unexpected or non-deterministic results and exceptions.

Thank you for listening. Your input is invaluable!

- surekha

Business Architecture (Business Design) - some interesting anecdotes

This is in follow-up to Ashok's previous blog on Business Architecture. After publishing the EA 2010 domain model (web cast) the SOA Consortium EA 2010 working group has primarily focused it efforts on explaining (note: not defining) what Business Architecture means to us practitioners. One quick observations from these conversations was that most practitioners where interchangeably using the term Business Design and Business Architecture - basically Business Architecture effort is to come up with Business Design that can adapt to change (more to follow as and when the SOA Consortium get ready to publish this out).

In my opinion - even though the term Business Architecture may not have existed, some large enterprises as well as governments have been defining long-term strategic plans (Business Design) that adapts to change.

Lets take the example of Nokia - if you review their history one would be surprised to learn that Nokia was established in 1865 as a wood-pulp mill. Since then Nokia has been involved in many sectors, producing at one time or another paper products, bicycle and car tires, footwear (including Wellington boots), personal computers, communications cables, televisions, electricity capacitors, aluminium, etc. (Source: Wikipedia)

How did they go through this transformation? I did have an opportunity to partner very closely with Nokia during the dot com days and according to Nokia GAM, Nokia typically establishes a five year plan (Business Design) and executes to it. For example - once they determined that the PC business is going to be a commodity - they sold it and moved on to a new market segment. Looks like they adopted the Business Architecture approach established by the Soviet Union. History demonstrates that it did not work for the Soviet Union, but did work for Nokia. Maybe it had to do more with the market dynamics that the five year plan itself. The economy of India is also based on five year planning (the Soviet Influence) and the entire bureaucracy is measured against achieving this (and as usual the Politicians do interfere :) ).

Yes! it is very useful and great to publish the business design but not necessary for the market place. For example, Oracle which was known as a technology company is now viewed (by the industry) as an acquirer. IBM transformed itself into a Services Company but they still do have hardware and software. In this case the Business Design is essential to help define and explain the role of the hardware and software plays in it's services offerings. If not clearly defined (which includes the monetization aspect) one could land up as a niche players like Sybase and Sun.

These days there are lot of discussions going in various enterprises, forums, consortiums, enterprises and government organizations on topics such as:

• what is business architecture?
• where should it belong? (part of the EA team or business)
• what is the right place for EA? (shouldn't the CEO and the Board be involved in EA?)
• ...etc.

In my opinion - there is no right or wrong answer. Do what you thing is right (or what you can achieve) within your organization. Like my take on our SOA Adoption within BEA-IT, we went about adopting the right enterprise architecture approach which happened to be Services-Oriented Architecture. We did not set out to adopt SOA. As an early adopter of SOA - we saw the benefits which transformed us into it's early advocates.

Hope this was interesting and do drop me line to discuss this further, if interested.

- Yogish Pai