Patterns In The Context of SOA Business Services

Introduction

Along the evolutionary path through centuries, the Mankind  has found that we need some things stable, immutable, and even ‘untouchable’ to grasp the other constantly changing things. The examples of such immutable things include religion postulate, mathematical axioms and the Earth shape.  Nonetheless, sometimes, the knowledge acquired in the evolution pushed us to change even the immutable ones. Such things have happened, e.g., with mathematical axioms, particularly, with the Euclid’s geometry and the understanding of the Earth shape. Heraclitus said: “There is nothing permanent except change” and I am going to follow his wisdom.

Some people simply prefer to believe into immutable things, it is easy, and some other people dare to touch the immutable things from time to time - to be sure they are really immutable... This article has been facilitated by a multi-hour debate between people from two aforementioned categories; the discussion was about pros and cons of a couple of design patterns when the context of the pattern applicability changed.

Here is a topic up for debate; we know two frequently referred patterns – Façade Pattern and Mediator Pattern ; what would  happen with them if the context where the patterns are supposed to be used changes from programming to an application and to enterprise technical levels,  and; finally, crosses into the Business? Why this topic is interesting? I think it is because of:

1. the technology products materialise these patterns, and
2. these products are pushed by the vendors to the corporate IT departments and  affect our work a great deal.

An example of such products is an Enterprise Service Bus (ESB) that all-of-a-sudden has become a “must have” for the implementation of the service-oriented (SO) architecture with no justifiable explanations of why is it so. A dominant majority of existing “explanations” talk about what we can do with the ESB product but the consequences of doing so remain in the shadow.

As our daily practice teaches, we have to start with setting the definitions and ‘common’ language for this article. Here you are. When I mention SOA, I mean OASIS SOA standards like Reference Model and standard-draft Reference Architecture Foundation for SOA. For the term ‘business service’, I consider a combination of manual and automated elements of service in the meaning of OASIS SOA, the service that realises particular business function or feature and provides access to this business capability. The business service realisation may be done in absolutely different ways including an implementation via the business processes. The latter are understood as the ordered sequences of business manual and/or automated activities.

Talking about patterns, I follow the definition of a Pattern given in the GoF book. Sometimes a Pattern and a product implementing this pattern have the same name and we have to clearly state which one is meant.

Everybody means something different talking about Façade

To warm-up, let’s start with the Façade Pattern. Since 1681, word Façade means the front of a building. In Technology, I can start with the Façade Pattern defined in the GoF book as a frontal interface shielding other interfaces defined in the object-oriented (OO) design. It is assumed that the implementation of the Façade Pattern is capable of splitting the messages coming from the sender through the coarse-grained frontal interface into the series of messages to the finer-grained target interfaces. This frees the sender from special knowledge about multiple target interfaces. Simultaneously, the receiver situated behind the Façade interface plays a role of a mediator because it knows how to split the input message and where to direct each part of it to.

Java represents an EJB Façade Pattern. This component façade has a little difference from its OO ancestor. The EJB Façade Pattern serves by 1) receiving a coarse-grained aggregated request compiled out of requests to several other EJB, 2) splitting the request and invoking appropriate EJB components. In this case, the Façade Pattern has survived the change in the context from the object orientation to the component orientation. But this is its last lack.

Probably, the Façade Pattern has appeared so attractive that everybody started to re-define it for personal needs in the new context of the service orientation (SO). Below, there are three different definitions of the Service Façade Pattern and each of them has its own ‘nuances’ in the SO context.

Let’s start with IBM that states:

“This pattern helps to provide loose coupling between a service requester and functionality that is provided by an application or capability that is not service-enabled. The loose coupling conceals the complexities of the provider and presents a standard Web service interface. ...A Service Facade pattern also introduces a mediation point for the application of standard functions such as logging”.

Then IBM adds:

“Legacy applications do not fit naturally into a service-oriented architecture (SOA) environment and changes to such systems are expensive and require scarce skills. ...This pattern is appropriate when an enterprise wants to present a service interface to requesting clients as part of an SOA environment, but provider applications cannot easily be upgraded to provide service interfaces.”

The IBM’s objectives and the approach are clear – if a resource cannot be easily accessed as a service, the façade helps with it.

At the same time, the book “.NET Patterns: Architecture, Design, Processes” characterises the Service Facade is as a delimiter between a Web Service, promoted to the rank of ‘controller’, and the actual service (once again confirming how clumsy the name ‘Web Service’ is):

“To provide a Web Service controller class as an entrance point to a business logic façade object, which may be reused from other contexts than Web Service, e.g., from within CORBA based applications”.

The next definition is quoted from the Thomas Erl’s book ‘SOA Design Patterns’:

“How can a service accommodate changes to its contract or implementation while allowing the core service logic to evolve independently? The coupling of the core service logic to contracts and implementation resources can inhibit its evolution and negatively impact service consumers.”

So, the concern here is about mistaken exposure of the service implementation via its interface. That is,

“A service facade component is used to abstract a part of the service architecture with negative coupling potential. Facade logic is placed in between the contract and the core service logic. This allows the core service logic to remain decoupled from the contract.”

As you can see, the referred .NET Service Façade is just a mediator between externally accessed Web Service interface and the real interface of the class/object implementing the service functionality. To my understanding, the Web Service interface has to be a service façade but, instead, the .NET Service Façade has moved behind the Web Service creating a façade to façade. This means that either the Web Service interface is incorrect or the implementation of the service - the classes with real functionality – improperly designed for the Web Service interface.

For IBM, Service Façade shields original interface of the “non-service enabled resources”.  Well, if this façade is a service, I have no questions. Otherwise, I am getting very suspicious with IBM’s definition because if Service Façade is just an interface it sounds like IBM enables service by just adding a ‘magic’ façade-interface to a non-service. To me it seems that we deal here with a classical semantic problem: playing with words we are taking what is desirable for reality. Particularly, by adding a façade or a connector, we can only enable new connectivity but it is impossible to change the nature, the essence of the things (e.g., creating serviceability), by just adding whatever interface. If you put a transparent glass lid instead of a metal one on your saucepan where you boil eggs, they will not change into pizza; what do you think?   

The Service Façade Pattern explained in the “SOA Design Patterns” book is something totally different from the MS .NET and IBM interpretations. This explanation, quoted above, raises a question: is the Service Façade Pattern an architectural pattern (as claimed by Thomas Erl) or is it an implementation pattern not really visible in the SO architecture?

The first thing, which has jumped into my eyes in the Erl’s explanation, is a term “service contract”: this thing does not comply with the OASIS SOA standards. Based on the mentioned quote, we can only guess that “service contract” stands for “service interface” (though the word ‘contract’ carries richer semantic than the word ‘interface’ and, thus, misleads developers) . With this guess, the initial question in the quote sounds like: “How can a service accommodate changes to its” interface “or implementation while allowing the core service logic to evolve independently”? A straightforward conclusion that may be done on the basis of this question is that the interface changes somehow, the core service logic evolves independently somehow else and the service body/implementation moves on its own change track... If this is not an absurd then this is a chaos or semantic mess. Does this mean that the Service Façade “placed in between the contract and the core service logic” is here to cover the mess instead of fixing it? If the answer is ‘Yes’, it is not what GoF defined as a Pattern, at least.

The second problem the Erl’s explanation apparently concerns is the coupling of service interface implementation details with the service interface, i.e. having the service interface driven by service implementation details. Well, the service interface must be motivated by the means of access to the business functionality realised by the service. If this rule has been violated and somebody has generated the interface from particular internal implementation (as many irresponsible vendors advised in early days of Web Service adoption), it is better to beg the consumers for a pardon, fully discard such a service interface, and create/distribute the new properly designed one. It is much more safely and fair than to hide the mistake behind the façade and leave the consumers with the wrong interface. To avoid such mistakes in the future, the mistakes have to be paid rather than smoothed.

Anyway, an idea of separating service’s interface from the service’s body by using a façade seems to me extremely artificial, error-prone and political.  Such separation promotes an idea that an interface may exist on its own, with no business value (attributed to the service itself). Such interfaces confuse designers who already try to construct a layer of interfaces into nowhere. In the business world, such interfaces look as agley as a front door into to the building that is demolished behind the door but is still claimed headquarter of the firm. Functional business does understand a stand-alone interface/façade or a service without an interface; the interface and the service are the one united thing in the business services realm.

So, we have seen that the meaning of Façade Pattern in the service-oriented context has been changed. It has been reinterpreted by several leading vendors for the sake and benefits of the Web Service technology over the notion of ‘service’. In each observed case, the Façade Pattern, i.e. the Service Façade Pattern, had different semantic, which, unfortunately, set us closer to the Babylon construction than to the IT construction.

ESB Phenomenon

When David Chappell (that time from Progress Software) coined the term and released the first Enterprise Service Bus product, I lived in Boston, MA, and had friends working in Progress. To us, this ESB announcement sounded not more than another marketing dress for the old messaging system married with Web Services. From the Patterns perspective, ESB appeared as a composition of Mediator and Pub/Sub Patterns and started to play as an Adapter Pattern, all together.  I did not put much attention on it and now it seems I was not right. The ESB product’s feature of mediation, if you allow it to occupy the sphere of interactions between business consumers and business services, is a “time bomb” for your IT. The ESB product sucks all business interaction logic (drop by drop) into itself and becomes the inevitable part of any service-oriented development; it ties all services together and holds on to them. Is this what we want in our organisations? The ESB product’s importance is not attributed to a business need or value but based on that everything in the our SO environment becomes dependent on it. What more a product vendor can dream of?

The phenomenon of ESB product is in the classical realisation of the saying: “The road to hell is paved with good intentions”. The solution that simplifies an integration being in one pair of hands becomes the obstacle for an interaction between two pairs of hands. Though, let’s follow the evolution and see how this had happened.

The history of the Mediator Pattern is very similar to the history of the Façade Pattern. The Mediator Pattern was defined in the GoF book to help developers to organise logical interactions between objects and resolve a spaghetti-like design of interactions/interdependencies. I like this pattern and used it a lot. I have mentioned already that implementation of the Façade Pattern frequently utilised the Mediation Pattern when it needed to decide where to re-direct messages received through the façade. Not many changes in the Mediator Pattern we saw when the context of its usage changed to the managing interactions between components.

Introduction of Web Services did not change the use of the Mediation Pattern much. The standard-based Web Service interface, being a façade itself, needed the real ‘worker’ to decide what to do with the received messages. In this way, the service was able to realise the Mediator Pattern internally. The same developer (one pair of hands) controlled both parties participating in the interaction – consumer and service – with no problems.

I think that this development experience contributed to the creating of Enterprise Service Bus Pattern as a combination of the Façade, Mediator, Adapter and Pub/Sub Messaging Patterns at least. Corresponding ESB products did not wait long to conquer the market aiming technical services. However, functional mediation within the context of Business, i.e. SOA business services, is associated with the new responsibilities that have been unknown in technology, in the world of programming objects and components.

According to the OASIS draft of Reference Architecture Foundation for SOA, the latter is positioned in between Business and Technology, on both sides of the fence simultaneously. This means that all elements of the SOA environment that relate to the business logic are automatically get elevated into the ‘business’ status and linked with some business responsibilities. This, nonetheless, does not mean they are released from their technical duties; they become dual and it is the new aspect of modern IT, which aspires to agility with Business.

Following this line of logic, I can conclude that if the ESB product implements business logic of interactions between the business service consumer and the business service itself, the ESB becomes a business concern (like an ERP system). Since your eyebrows moving up, I have to make one step back and recall that we are talking about the SOA business services that encapsulate Business and Technology via a combination of human operational activities and automated procedures, and that the Service Contracts – the agreed documents between the service consumers and service providers – regulate the consumer-service relationships and interactions.  

I can blame the murky ESB Pattern, which we will discuss later on the in the article, for the confuses with the ESB products but it does not help much in our daily work. To illustrate my concerns about the ESB product, let me briefly challenge some of its mostly common features of to see what risks they camouflage. (We need this observation because we do not have a standard, which would define what an enterprise service bus is or should be. We still have each ESB product unique and... barely compatible with another ESB).

So, an ESB product usually consists of several engines accessible to requesters and receivers of the messages transmitted via the Web Service interfaces (I do not exclude that some ESB products have other interaction interfaces). The features of ESB products will be demonstrated based on the ESB Toolkit For Biztalk from Microsoft and listed in the Table 1.

Table 1.

One ESB product feature is more accurate in the service oriented context, another feature is less; all of them are just details. Nevertheless, what qualifies ESB product to the risk of a ‘time-bomb’ is, in my opinion, the feature of mediation between business consumers and business services. I have identified three major aspects of the business-centric SO environment that dont fit in with OO mediation.

The first aspect is a distribution of authorities. Such distribution had not been ever considered when the Mediation Pattern was used in OO design. The use of the Mediation Pattern always assumed that the developer just simplifies cross-relationships between objects having a full authority and control over all of them. However, in SOA, the single authority is not always the granted fact even in the same enterprise. For example, we have two business services A and B that contain technical services α and β respectively, and the services have to interact in a ‘consumer-service’ manner. The business ownership and authority of A and B are different because the services belong to different business departments. This means that the rights of the developers who have to organise interactions A-B / α-β may be limited and driven by different business policies. For instance, the business owners of A and B know that ESB product is under total control of IT department. The owner of the A service is OK with this while the owner of B service might not want making its B/β service dependent on the ‘uncontrolled by business’ infrastructure. Due to this business situation, the IT developers cannot (may not) modify β to set the ESB’s end-points, i.e. the services cannot (may not) interact.

The second aspect is the mandatory Service Contracts between the SOA service provider and the consumers. The Service Contract defines, among other things, the service interfaces (including protocols) and policies that should be accessed and applied respectively during the interactions with the SOA service. Let’s count our options for the ESB product with regard to the Service Contract: 1) the ESB is under its own independent management and authority; 2) the ESB is a part of the consumer realm; 3) the ESB is a part of the service realm.

In the case one, the ESB product might not be used because a use of it violates the Service Contract: no ESB end-points, communication protocols and ESB’s policies are mentioned in the Service Contract. In the case two, the ESB product can be used by the consumer but the ESB product must appear as the consumer (with its identity and compliant with the service interfaces/protocols listed in the Service Contract). Does any ESB product do it? Finally, in the case three, the service providers can announce the ESB’s service interfaces and policies as the SOA service’s interfaces and policies in the Service Description document and refer to them in the related Service Contract documents. Thus, the consumers may have no idea that they deal with the ESB product.

It seems that the case three sets a direction toward how an ESB product may be assimilated in the business-centric service oriented environment. But do not rush, please. Have you seen a precedent where a service provider agreed to incorporate the ESB into its service realm including related SLA and other business responsibilities? Also, who do you think owns the ESB itineraries associated with the authorities of different business owners – the ESB or the SOA service? This is not a trivial question.

The third aspect is the role of an intermediary in business interactions. If an intermediary is engaged in the interaction between consumers and the business service, it must carry certain business responsibilities as a part of the business transaction. If the intermediary fails, it has to accept business penalties. So, what business responsibilities and what accountability may be considered with regard to the technological infrastructure that occupies the position of the intermediary in the business transaction? If we do not find such responsibilities then, sooner or later, this infrastructure starts to drive the business.

Let’s analyse following hypothetical example. We have a Factory A and a Supplier X. The Factory hires a driver and instructs him/her to deliver some parts from the Supplier in any possible way. The diver is smart – he/she finds the proper rout and delivers the parts. Then the Factory A gets another Supplier Y and now asks the driver to deliver the parts from X or Y based on his/her decision. So far, so good. Now, the Factory A opens a sister-Factory B and hires the same driver for A and B on the same ground – the driver should decide the best way of how to obtain the parts and how to deliver. As a result, the Factory A appears without parts since the driver prefers making deliveries to the Factory B most of the time because… it is closer to the driver’s home. Such situation becomes possible because the driver is not involved into the business process and has no business liability.

Unfortunately, the described case is not a total fantasy – Microsoft consultants advice using the ESB as the only interaction infrastructure for SOA services in the enterprise. That is, they should face all three aspects of mismatch between the ESB product/pattern and the enterprise SOA business services.

One of the major business values of SOA is composability – flexibility in adopting business changes via re-aggregation/orchestration of existing business services. This means that the business services must be maximally ‘mobile’ to move into different orchestrations.  If IT starts using the ESB product for connecting consumers with business services, it might look OK at the beginning but the more complex interactions between services should be (the more orchestrations the services participate in), the more chances the ESB, which holds all interactions, becomes an operational bottleneck and the single point of failure for the corporate business. Moreover, several vendors are known for producing frequent mandatory or non-backward compatible updates to their products including the ESB. If the ESB product is the core of the business service system, such updates become very costly and time consuming for the organisations. And, guess, who is in the fault again? You right, it is your IT, not your vendor.

The Way to Go

Nowadays, some IT leaders have understood that the progress and success of many businesses in Banking and in Finance in general, in Telecommunication, in Media, in Healthcare and other non-manufacturing industries with massive consumers and clients require a harmony between the corporate business and its IT team. The fact of publicly proclaimed need for IT agility with Business witnesses the problem between them “because the IT organization itself is becoming increasingly more detached from how the business wants to use their technology”.

In my opinion, the ESB Pattern carries internal contradictions that become much more obvious when it realised via ESB products. The first confusion comes from the definition of the Enterprise Service Bus Pattern from the SOAPatterns.org; based on “SOA Design Patterns” book the definition of the pattern does say more than “An enterprise service bus represents an environment designed to foster sophisticated interconnectivity between services. It establishes an intermediate layer of processing that can help overcome common problems associated with reliability, scalability, and communications disparity.” This Pattern is just a list of technologies rather than a receipt on how to use them and which cases do not use them. Thomas Rischbeck says: “The ESB pattern is about performing integration tasks and adding value to client-service communication in an SOA – all completely transparent to the participants”. I would welcome this transparency if it were not based on intelligent routing and data enrichment having its own policies on the interaction between the participant. In SOA, we have a mechanism that regulates the interactions – Service Contract – and it is not seemed to be considered by the ESB at all.

At the same time, as we mentioned already, ESB Pattern is a combination of Patterns. It is nice to have a Pattern that allows multiple different views but these views must be cohesive – instead, we have a Mediator Pattern, which helps to handle the interaction logic of parties that know about each other very well, joined with a Pub/Sub Pattern that suggests the interacting parties should not know about each other.

I am afraid that the ESB Pattern helps only to distance the business service from the consumers. Even if Pub/Sub is not applied, the existence of the ESB product outside of the business control (being an infrastructure) separates business consumers from the business services. So, knowing all what I said above, does an ESB product have any positive business value?

Actually, it does. And this value, believe it or not, comes from another pattern acquired by the ESB – it is the Adaptor Pattern. This value is a rich set of adaptors to multiple platforms and communication protocols. Messaging systems had to realise physical connections to the heterogeneous systems of old days just to work. Inheriting this adaptor layer, an ESB product can connect consumers to the business services at the technical integration level. Yes, I said ‘connect’, not ‘take over’ the business logic of the connection; the ESB product may ‘connect’ strictly in accordance with the Service Contracts.

Thus, the business value of the ESB Pattern and product does not relate to SOA but to the investments made into the IT infrastructure in the past, the investments into adaptors. In SOA, in the business service realm, the ESB product transparency may be achieved only if it becomes a part of a business consumer or a business service, i.e. controlled by the business entity that becomes responsible in business terms for the ESB actions.

Conclusion – The Take away Thoughts

We have discussed a non-obvious effect of changing usability of the Façade Pattern  and the ESB Pattern depending on the context of their application. For the Façade Pattern, we have found that the pattern semantics consecutively changes when the pattern is applied to objects, to components and to services. More accurately, in the service-oriented environment, the façade merges with the service interface and the Façade Pattern melts into the aggregate service.

More difficult and dangerous situation exists roots combination of the Mediation Pattern with the Pub/Sub Pattern incorporated by the ESB Pattern. Since this pattern is implemented by the ESB products, the latter inherit the pattern’s contradictions when applied to the business services. Particularly, if mediation in the ESB starts to play an independent role and acquires the business logic of interaction in addition to the basic routing responsibilities, it can break the fundamental business concept of Service Contract between the service consumer and the service provider. Straight, mechanical lifting of the Mediation-Pub/Sub combination into the business consumer-provider relationship is impossible unless the mediating intermediary takes certain business responsibilities similarly to a regular business entity. Since the ESB products do not accept business responsibilities, such product should become invisible for the business services, i.e. they must become either a part of the service consumer or a part of the service. Only in this way the ESB product can be incorporated into the business service interactions.

Additionally, the ESB product may not take on the data transformation during the interactions between business consumers and services without their awareness documented explicitly in the Service Contracts. With regard to the security controls, the ESB product is expected to be secured by itself but if it is used as a point of interception of service interactions for the purposes of the authentication and authorisation of the interacting participants, this is considered as a violation of basis security rule (unauthorised request may not penetrate into the core system’s routing environment; they must be blocked before it).

Finally, the article concludes that rich adapter layer, usually provided by the ESB products, enables technical integration between consumer’s and service’s technologies. This is the most useful ESB feature in the service-oriented environment unless it starts performing an ‘intelligent’ routing based on business uncontrolled riles and policies.

I can formulate the main conclusion of this article by rephrasing the famous saying: when in the world of business services do as the business does. Whatever technical solutions IT comes with for the business services, it may not alter business ‘rules of engagement’. If a technical solution does alter these rules, you have to inevitably expect a serious crack between Business and IT; if not now then in the close future.

Dr. Michael Poulin has worked in the financial industry as enterprise-level solution architect for the last 10 years. He holds architect certification in Java, TOGAF, and SOA, and he was included in the IT catalogue of International Who's Who in 2001. He's been a member of the OASIS SOA Reference Model TC since 2007, and co-authored the first and second Public Review Daft of the OASIS Reference Architecture for SOA. He is the author of the book ‘Ladder to SOE: How to Create Resourceful and Efficient Solutions for Market Changes within Business and Technology’ and works as a Head of Business and Technical Architecture for the consulting company BuTechCon Ltd.