BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Patterns In The Context of SOA Business Services

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.

No.

ESB Feature

Challenge

1

Intelligent message routing.

“Dynamic routing. Run-time content-based, itinerary-based, or context-based message routing.”

An ESB product  may not only route based on the content and context of the message (which may be no predictable in general) but also engage any additional means and rules unknown to the sender and receiver of the messages. It is believed that the knowledge of how to transfer the message is the prerogative of the ESB product only. This feature is inherited from the Pub/Sub Pattern and MOM systems that assume that the senders do not know about the receivers and the latter may not know who asks for their services.

I would like to learn about such business customers and businesses that are in a deal with each other whilst do not know and do not want to know about each other. There are cases that include ‘a middleman’ but both parties are perfectly aware about it (e.g., a post service) or the middleman becomes a part of the business deal (e.g., a courier service).
My opponents can say that the ESB product is used for integration of technical components and not needed to be aware of the “business rules of engagement”. I agree with this argument and can only add: based on what has been said, the ESB product should not be used to support interactions with business services (which include their technical parts as well) because business consumers and services are aware of each other very well.

2

On-the-fly data transformation.
“Dynamic message transformation and translation. The mapping definition between distinct message structure and semantics is resolved at run time.”
To transform data on-the-fly, the ESB product needs to know the input and output data formats. However, sometimes, especially in real life, the input data is incomplete. It is not a problem – the ESB product can validate data and obtain missed data from somewhere. Nice, but the validation rules can quickly get out of sync with the interaction policies (since ESB is the IT infrastructural construct), especially, when they are under ‘jurisdiction’ of another team.

Again, if an ESB product is a ‘first class citizen’ in the consumer-service interactions with business services, it must carry certain business responsibilities. If the ESB product just translates a format of the exchanged messages, the ESB has to be a trusted translator responsible to both consumer and service and mentioned in the Service Contract. If the ESB product is so advanced enough to enrich the messages, it becomes a partner in the business transaction and must be compliant with all business rules/regulations and security authorization controls.
For example, if the request data is incomplete and additional data source, used by the ESB product, is not mentioned in the Service Contract, the consumer may not be entitled to use this source and the ESB support team gets a problem. From another hand, if this data source is mentioned in the Service Contract, it is unclear why the consumer should choose the ESB product as a data acquirer instead of engaging another service to fulfill its request in the first place.

3

Security interception points and controls.    It is believed that an ESB product is the convenient place for security controls. The security controls can include consumer and service authentication, consumer authorisation/permission for given interaction, information encryption, etc.

I do not know for sure but it seems to me that this feature was added to ESB products by some marketing guys; it could not be done by security professionals because this ‘solution’ violates ‘security 101’. 
Multiple researchers have found that up to 75 to 80 per cent of security breaches happen inside the company, not through the corporate “perimeter”.  If the ESB is the core interaction coordinator, how is it possible even to assume that a malicious call may penetrate into the system core before being checked? Dealing with requester/responder authentication and authorisation controls in the ESB product is too late but... it is very convenient for developers, i.e. code delivery time may be shortened.
This kind of security violation is quite common in IT. Many developers and architects believe that they may retrieve data from the storage on behalf of the user even if the user has no rights to access them. The retrieved data is then filtered in memory and the user does not see the restricted data but the data in the system’s memory is not protected anymore and may be easily intercepted.

4

Endpoint run-time discovery and virtualization.
“The service consumer does not need to be aware of the service provider location and endpoint details; a new or modified service provider can be added to the ESB, without interruptions to the service consumer”
This feature is different from the “Dynamic routing” feature in that the sender and receiver may be aware of each other but do not know their physical communication end-points.

End-point virtualization is a good implementation feature unless it is used to isolate consumers from business services. Web technology has confirmed virtualisation by having only one port known to all Web Site consumers while many internal ports may be configured behind this façade.
As of run-time discovery, I think that whilst we talk about dynamic discovery of internal ports mentioned above, we do not have problems. However, if ‘discovery’ means finding services or providers previously unknown to the consumer, I would not recommend it for the business services unless you ignore the “business rules of engagement”.

5

Loosely coupled service composition.
“The service provider and service consumer do not need to be aware of service interaction style.”

Actually, the explanation of this statement contradicts real implementation from Microsoft: the ESB product can execute different itineraries and, in order to specify particular processing, the core processing engine requires that each message has its instruction or the metadata that defines the processes to be applied to and the tasks to execute on the message content. That is, the service consumer must be very much aware of the processing style but… does not need to be aware of the service as we learnt before.

6

Centralized exception management.
“Exception management framework, services, and infrastructure elements that make it possible to create, repair, resubmit, and compensate fault messages that service consumers or BizTalk components submit”

This is very helpful idea for development of highly centralized systems but that simply does not work in the distributed environment.
Such centralized system requires the ESB product to host an exception management framework exclusively. Plus, it is built based on the assumption that everything – all consumers and services – interact via the ESB only. I call it a ‘desktop mindset in distributed computing’.
To be able to ‘create, repair, resubmit, and compensate fault messages’, the ESB product must be aware of all message details from all consumers and services. Also, it must be aware of all Service Contracts with consumers that regulate the message repair rules and re-submission. Have you seen such ESB ever?

7

Protocol transformation.
“Providing the ability for service provider and service consumer to interact via different protocols including WS-* standards for Web Services.
For example, a service consumer can send an HTTP Web Service request, which will result in sending a message via Message Queuing.”

This statement smells ‘integration’ rather than service orientation.
As we know, all service interfaces and protocols that the consumer may use in the interaction with the SOA service are listed in the Service Contract. If the consumer cannot use specified protocols, why it would sign the Service Contract? However, we can assume that the consumer plans to engage an intermediary – ESB product – to use agreed protocols. This engagement is totally on the consumer’s charge; service does not know and does not care about the ESB. So, engaged ESB product becomes the consumer for the service and, as such, must be compliant with the Service Contract. That is, the consumer and the service always use the protocol agreed in the Service Contract.
Particularly, it is difficult to me to understand given example where the service consumer, sends an HTTP request expecting an immediate response from the service. At the same time, the service is not obliged to respond immediately via messaging interface, it is an asynchronous interface and the response time may not be guaranteed.

8

Quality of service.
“An asynchronous publish/subscribe engine resolves different levels of service availability and provides high availability, scalability, and message traceability for ESB implementations.”

This is the quality of the service provided by the ESB product, which does not necessary relate to the quality of the business service in SOA.

9

Extensibility.
“Provides multiple extensibility points to extend functionality for the endpoint discovery, message routing, and additional BizTalk Server adapters for run time and design time”

An ESB product would be a very limited ‘bus’ without an ability to add more end-points and their discovery. However, given definition addresses only extensibility of the “functionality for the endpoint discovery”. Though it is suggested that new business functionality may be added via adding a new end-point, this is only one of possible ways of adding new business functionality to the service. Anyway, described “extensibility points” are not enough to claim that ESB Pattern and related products provide extensibility to SOA. In SOA, extensibility may be achieved, e.g., via orchestration or via extension of XML Schemas of the exchanged messages.

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.

Rate this Article

Adoption
Style

BT