The Enterprise Service Bus, re-examined

The Enterprise Service Bus re-examinedUpdating concepts and terminology for an evolved technology

Skill Level Intermediate

Greg FlurryDistinguished EngineerIBM Software Group Business Process Optimization

Kim J Clark (kimclarkukibmcom)Consulting IT SpecialistIBM Software Services for WebSphere

18 May 2011

This article clarifies the architectural role of the enterprise service bus (ESB) in aservice-oriented architecture (SOA) and refines terminology associated with the ESBand integration in SOA

Introduction

A series of IBM developerWorks articles titled Exploring the Enterprise Service Buswas introduced in 2007 back when service-oriented architecture and the associatedconcepts and terms were still maturing For example Part 1 of that article series fellinto the (still-common) trap of using the term service in an ambiguous way itpositioned the ESB as an integration layer and suggested the ESB cannot includebusiness logic

Things have changed since that time This article defines a very crisp coherent setof concepts and terms to disambiguate discussions about services and also clarifies(and corrects) the relationship between the ESB and integration in SOA andbetween the ESB and business logic In addition the reality that a service-orientedarchitecture must be implemented is also addressed offering guidance onimplementation approaches with a focus on maintaining the all-important factor ofseparation of concerns

The service in SOA

SOA leverages services to simplify formalize and bring agility to the creation ofbusiness solutions The idealized SOA is shown in Figure 1 where a requesterinteracts with a provider to achieve some business-relevant task

Figure 1 An abstract view of SOA Direct service interaction

Where is the service in Figure 1

Consider these statements

bull We identified the Process Order service as one of the services needed torun our business

bull A service is a repeatable business task

These comments suggest service is not a physical thing but instead an abstractlogical or conceptual thing fundamentally the business task or the businessoutcome resulting from interaction Consistent with that interpretation is The OpenGroup SOA Work Group formal definition of service as a logical representation ofa repeatable activity that has a specified outcome You cannot publish or interactwith this service yet these actions are commonly associated with a serviceUsing this definition you must conclude that the service is not shown but onlyimplied in Figure 1 You might further conclude the service is performed by theprovider

Now consider these statements

bull We will publish the Process Order service in the registry

bull The registry is used to discover services when designing new solutions

Such statements suggest service is more concrete that is a specification ofsomething but still not something with which a requester can interact Using thisdefinition you must conclude that the service is not shown at all in Figure 1 Youmight further conclude that any interaction with the provider is specified by theservice

Finally consider these statements

developerWorksreg ibmcomdeveloperWorks

bull In this use case we invoke the Process Order service

bull My SOA has reusable services that can be called by any application

These statements suggest service is a physical thing with which a requester caninteract Using this definition the interpretation of Figure 1 is that the provider is theservice

So we have at least three very different interpretations for the term service

bull In more formal contexts service refers to the abstract or logicalrepresentation of a business task

bull In more informal contexts service can refer to a concrete description orspecification representation of that business task but more often refers tothe physical implementation or realization of that business task

bull Indeed service in some contexts could refer to all interpretationsperhaps in different phases of the service lifecycle

The above discussion shows that use of the term service without context andqualification can be confusing and even counterproductive It is sometimes possibleto infer the meaning from the context but not always

Rather than use the often ambiguous term service the following specific terms willbe used throughout the remainder of this article in an attempt to be more precise

bull Governed service Refers to a business task made available by theSOA without being particularly precise as to whether you are talkingabout the business task a specification or an implementation or somecombination For example We have a suite of governed services foradministering customers accounts

bull Service specification A formalized set of characteristics related to aservice interaction that includes the business task achieved by aninteraction the technical aspects of how to interact and various qualitiesof service associated with interaction The service specification is a formalrepresentation of a service that is both a concrete and physicalrepresentation The specification is the precise term in the context ofdefining reusable services for the enterprise (logical) or publishingservices in the registry (physical)

bull Service realization Refers to a physical implementation of a servicespecification As it is a physical entity the realization can be invokedThis is an informal yet the most common meaning of service Therealization is the precise term in the context interacting with a service orcalling a service This article will build a picture of the set of things that

ibmcomdeveloperWorks developerWorksreg

might be required for a service realization including clarification on termssuch as mediation integration enterprise service bus and indeedprovider

Widespread use of these more precise terms would go a long way toward reducingambiguity in communication around SOA although its not expected that they willimmediately start to be used in general conversation While it might be more preciseto say Invoke the Process Order service realization or Publish the Process Orderservice specification conversational simplifications will often trump precision

This article is intended to refine terminology to reduce confusion and will try to avoidany ambiguity by using the above terms wherever possible In addition you will alsofind other common term pairings service operation service exposure servicegovernance and service model The normally unambiguous meanings of theseterms will be made clear in the surrounding text

Service versus service operation

Another common point of confusion regarding use of the term service is whether itrefers to a suite of related operations or a single operation

Formal architectural definitions of the term allow multiple operations but do notmandate it Common mechanisms for defining partial service specifications such asWeb Services Definition Language (WSDL) support this view

For example assume you need business tasks that enable add delete find andupdate of a customer business entity You could create a single governed servicedefined by a single service specification with four operations or you could createfour governed services defined by four service specifications each with oneoperation

It is extremely common however that in general conversation the word service isused as shorthand for service operation regardless of whether referring to aservice specification or service realization This too can cause confusion Rememberthe Open Group SOA Work Group definition of service as a representation of arepeatable activity that has a specified outcome This definition itself is anotherexample of loose usage of the term If something performs a single activity then itreally refers to a service operation

The distinction between service and service operation is important when discussingcharacteristics described in the service specification There can be characteristicsthat are common to the service as a whole for example communication transportThere can be characteristics that are specific to a single service operation forexample response time

Thankfully many of the concepts observations and suggestions presented here are

not impacted one way or another by service vs service operation but the preciseterm service operation is used where it makes a difference to the discussion Youare encouraged to do the same where precision matters

Service governance in SOA

You should think of services within an SOA as governed services whichrecognizes that they are defined by service specifications and conform to anorganizations governance policies This helps to differentiate more clearly betweenfunctions that just happen to be exposed in a slightly more usable form (for examplean application that provides an HTTPSOAP-based API) from things that can truly beseen as business-relevant governed services

Lets take a deeper look at what is meant by governed in this context

What is the big difference between SOA and earlier approaches to enterprisearchitecture SOA is about exposing core business-aligned functions as reusableservices Lets deconstruct that into two critically important aspects

bull Governing business alignment of services concerns what businessfunctions are made reusable Put simply the governed services must helpto achieve the goals of the business Governance includes up-frontidentification of the core business functions But an SOA is not static justas a business is not static it slowly matures and evolves as the businessgrows and changes So governance must ensure the continued businessalignment of the governed services (in aggregate the service model) Theoverall SOA not the ESB is responsible for governance of the definitionand evolution of the service model but the ESB does help enforce suchgovernance which leads to the second aspect

bull Governing service exposure focuses on how those business functionsare made reusable For governed services to be reusable (or perhapsmore accurately sharable) the way they are exposed must meet anumber of key criteria that are also governed by the SOA Properexposure includes protocols and transports appropriate quality of serviceobjectives an organizations needs around security monitoring loggingand auditing a versioning strategy and proper ownership These aspectsof governance all relate to how a governed service is exposed and arethings that the ESB must enforce Notice that these are all non-semanticcharacteristics that is they have no effect on the meaning of thebusiness function exposed Architecturally it would make sense toseparate these from any semantic content and well discuss how weretain that separation later

How do you achieve service governance As a way of describing the important

characteristics related to a service interaction the formal service specification playsa key role A logical service specification can in practice be codified to becomephysical to support automated governance processes that ensure compliance withthe business goals of the organization (usually via a service registry and repository)

It is clear that for services to be of value to an enterprise they must be governed inthe ways described above If they are not they are not part of the service model andmust be considered only a part of the implementation of the SOA created for alimited specific usage An SOA therefore consists of governed services and useof this term is encouraged to remind yourself of the difference between these andtraditional interfaces

Two final points on service governance

bull We must accept that in some organizations there will be differing domainsof governance (for example departmental internal to enterprise externalto enterprise and so on) with differing approaches to governance Whatthis means is that just because something is a governed service in onedomain doesnt mean it complies with the governance policies of otherdomains and thus might need further work to be used in another domainThis is as much detail on this broader topic that will be discussed herebut it will no doubt become more prevalent as SOAs evolve and governedenvironments interact more frequently

bull Service governance is just one part of an enterprises overall ITgovernance Service governance which primarily relates to the way thatservices are identified exposed and managed should not be confusedwith other forms of IT governance covering subjects such as codingstandards or implementation technologies These are critically importantparts of the broader IT governance but do not relate specifically toservice governance

The service specification

Given the importance of the service specification discussed earlier lets examine itmore closely Figure 2 shows the service specifications place within a more holisticand mature (but still idealized) SOA emphasizing and facilitating separation ofconcerns between the logical service specification and the physical servicerealization (in this case the provider)

Figure 2 SOA and service specification

Figure 3 shows the various perspectives of a service specification What is theprimary reason for service interaction The service requester interacts with theservice realization to achieve a business task In section (a) of the figure you seethe business task is described by a set of semantic characteristics that include adescription of the business task performed (for example create a purchase orderfrom a shopping cart) and a definition of the business interface in terms oftask-relevant business entities (for example customer account shopping cartpurchase order) You can think of these semantic characteristics as things that areaccomplished in business-relevant terms through interaction with a servicerealization

Figure 3 Aspects of a service specification

Section (b) of the figure shows the syntactic characteristics that refer to themechanisms needed to actually interact with a service realization for examplecommunication protocol message formats and security You can think of thesecharacteristics as the syntax or binding required for successful interaction

Service specification versus other termsUnfortunately we often see and hear different terms used for theconcept we call service specification The most common term wefind is service contract This term has a significant drawback ingeneral use in that a contract implies an agreement between two ormore parties There is really only one party to a specification theservice realization Architecturally a true service contract wouldreference a service realization as one party and define detailedpromises made to the requester party likely related to qualities ofservice

Another common term is service description The drawback hereis that its use in WSDL includes formal support for only a subset ofthe necessary characteristics

Section (c) of the figure refers to operational aspects such as response time

throughput and availability These characteristics recognize that service realizationultimately runs in one or more physical containers with limited resources such asCPU cycles storage memory network bandwidth and so on You can think of theoperational characteristics as qualities of service that are dependent on theappropriate sizing and configuration of the provider container hence itsrepresentation in Figure 3

Separation of concerns mandates that all characteristics in the servicespecification are external and are those exposed by a service realization Thusthese characteristics are independent of the service realization implementation suchthat the implementation can be altered or improved or upgraded without affecting theservice requestors provided those characteristics are not changed This also meansthe service specification is applicable to all users of a realization

Given the definition of service specification in direct service interaction shown inFigures 1 and 2 you can say that since the service provider is the servicerealization

bull The syntactic characteristics offered by the provider must satisfy those inthe service specification and

bull The operational (quality of service) characteristics offered by the providermust satisfy those in the service specification

So in Figures 1 and 2 the service provider implements the semantics of the servicespecification (it performs the business task) and it also exposes the businessrelated semantics by implementing the syntactic and operational characteristics

In some of the discussions that follow it will be convenient to only distinguishcharacteristics relevant to the business task from those that are not relevant In suchdiscussions the syntactic and operational characteristics are grouped together asnon-semantic characteristics and therefore refer only to semantic andnon-semantic characteristics

Use of mediation for service exposure in SOA

The simplistic scenario in Figure 2 where the provider already offers anappropriately governed service is almost never the case in real life Lets look at asituation where the non-semantic characteristics of the provider do not match thegovernance policies including the service specification

With direct service interaction as discussed in relation to Figures 1 and 2 theprovider must satisfy all characteristics described in the service specificationFurther the provider must adhere to all the service governance policies for anorganization This can be difficult or impossible depending on the nature of the

governance within that domain The fact that most providers are not capable ofadhering to well-governed service specifications while maintaining separation ofconcerns is the reason we need mediated service interaction in SOA shown inFigure 4

Figure 4 An abstract view of SOA Mediated service interaction

Transformation versus translationThis article specifically uses the word translation to mean simplychanging the representation of a business entity from one form toanother without changing the core meaning of that object Thustranslation is meant to deal with representation (syntax) rather thanmeaning (semantics)

An example would be mapping ltsurnamegtFlurryltsurnamegt toltsecondNamegtFlurryltsecondNamegt orltDOBgt1960-11-03ltDOBgt to ltDateOfBirthgt3rd November1960ltDateOfBirthgt Notice that even the data itself might changein format but its meaning is the same Translation is typically takingplace when there is only one source of data It would be difficult tochange a single source of data into something with differentmeaning

As an analogy a good language translator could say something inEnglish and French and have it carry the same meaning eventhough the words phrases and even sentence structure might bedifferent The translator is purely mediating between the languagesnot adding new meaning Indeed adding new meaning is beyond alanguage translators role and could at best cause confusion or atworst offense

Transformation on the other hand is used here to denote achange in meaning (semantic) This typically occurs when youtransform (or merge) data from multiple sources which enablesyou to create a new entity with a different meaning

Therefore translation is what you will expect to see in service

exposure where you are not doing semantic work andtransformation is likely to happen in provider creation (describedlater) where new entities are being created

Notice the significant differences between Figure 2 and Figure 4 The first differenceis that a mediation acts as an intermediary between the provider and the requesterA mediation is introduced to enable a requestor to interact with a provider that hasdifferent characteristics -- but different in what way

Part 1 of the earlier article series explained that services hellip implement hellip thesemantics associated with achieving business goals while mediation only modifiessyntax associated with achieving the necessary interconnectivity We should adjustand clarify these statements based on the discussion in the previous sections

That article if interpreted correctly makes it clear that mediation cannot change thesemantic characteristics of the interaction Based on the understanding of theservice specification it is better to say that mediation can manipulate thenon-semantic characteristics of an interaction These include both the syntactic andthe operational (quality of service) characteristics in a service specificationMediations perform a set of actions on the messages that pass through them tomediate the non-semantic characteristics the actions include protocol switchingtranslation encryption and routing

The next difference between Figures 2 and 4 is that the provider alone is no longer aservice realization This reflects that the provider does not comply with awell-governed service specification The provider does supply some set of semanticsyntactic and operational characteristics in the majority of cases however theseare not formally defined by or governed in relation to the service model Todistinguish that ungoverned set of characteristics from a service specification weuse the term provider description

The final difference between Figures 2 and 4 is that the service realization is ineffect a combination of the mediation and the provider You can say that themediation augments the provider by exposing it according to the servicespecification that is it assists the provider in satisfying the characteristics in theservice specification So in this context the mediation is performing serviceexposure which is the act of bringing an ungoverned capability in line with adomain of governance by using a mediation to reconcile the non-semanticcharacteristics

You can now consider that mediations are used within SOA to expose services It isreally more precise to say that a mediation is used to expose a provider according toa service specification the net result is a service realization

Lets now examine the nature of the service specification in mediated serviceinteraction Due to separation of concerns the mediation delegates all responsibility

for semantic characteristics in the service specification to the provider Thus thesemantic characteristics in the provider description (formal or informal) are reflectedin the semantic characteristics of the service specification as shown by the solidarrow in Figure 4

Protocol switch versus conversionDuring service exposure there is often a need to enable onecommunication protocol between the requester and the mediationand another between the mediation and the provider A commonterm used is to switch protocols but sometimes the termconversion is also used We believe switch is the most accurateterm In reality one protocol is used in the interaction with therequester and a second one in the interaction with the providerthere is no conversion

The mediation supplies all the syntactic characteristics of the service specificationsince it is the interaction point for the requester and is wrapping any syntacticcharacteristics of the provider as implied by the lack of any relationship to theprovider description The operational characteristics in the service specification arederived from a combination of the operational characteristics of the provider (in theformal or informal provider description) and those of the mediation itself Forexample characteristics such as response time and throughput are clearly impactedby the operational containers for both the mediation and the provider This is impliedby the dotted arrow in the figure

Lets once again restate our observations on service interaction this time formediated interaction Given the strong emphasis on separation of concerns in SOAthe roles of provider and mediation in performing service exposure arearchitecturally distinct and different

bull The semantic characteristics offered by the provider must satisfy thosein the service specification

bull The syntactic characteristics offered by the provider need not satisfythose in the service specification since the mediation acts as anintermediary

bull The operational quality of service characteristics offered by the providermust exceed those in the service specification since the mediation cantypically only degrade such characteristics There are some subtleexceptions to this such as a mediation that actually improves a providersavailability by routing to an alternate provider under appropriatecircumstances but that is beyond the scope of this article

This distinction between mediation and provider is critical to separation of concernsIf the mediation contributes to the semantic characteristics in a service specificationit would become a provider This would be clear violation of separation of concernsthat can lead to a various issues such as confusion as to where to find the

implementation of the business task when you need to change it and indeed whoowns it from a change control point of view

Service exposure Exposing a provider as a governed serviceThe term service exposure will be used regularly from this point onin the article so it is important to understand that it means toexpose a provider as a governed service We often hear the phraseexpose a service when talking about service exposureUnfortunately this can be misleading as it suggests that a governedservice was already there and you just had to uncover it Youshould interpret service exposure as making a provider availableas a governed service or put even more explicitly expose anexisting ungoverned provider as a governed service according to aservice specification

Based on the above you can state some principles about mediation used for serviceexposure from an architectural perspective

bull Semantic transparency A mediation adds no semantic capabilities Itexposes the provider by satisfying the remaining characteristics in theservice specification

bull Reactive versus proactive A mediation only interacts with a provider asa result of an interaction with that mediation initiated by a requester

bull One-in-one-out Because the provider supplies all the semanticcharacteristics of the service specification for each request for a serviceoperation there will logically be only one invocation of a provider tosatisfy the semantic characteristics of that service operation

bull Stateless The mediation persists no state relating to a request after therequest is satisfied for example after a response is returned to therequester

These principles can be very important for identifying the sometimes subtledistinction between the role of a mediation for service exposure and the role of aprovider

The ESB in SOA

Notice there is no ESB shown in Figure 4 and no mention of the ESB in the relateddiscussion Why Part 1 of the ESB article series identified the ESB as anarchitectural pattern in SOA that is true but not precise That article also suggestedthat an ESB supports mediation flows (mediations) that is both true and preciseWhile it is common now (it was not when that article was written) to say that the ESBexposes services it is more precise to say it is the individual mediations that exposeproviders according to service specifications

This means that from a pure architectural perspective service exposure viamediation supporting the principles in the previous section is the importantarchitectural pattern in SOA Thus it is more precise to say that the ESBarchitectural pattern is support for a collection of individual mediations performingservice exposure In the earlier article the term mediation was intended to alwaysrefer to service exposure However we frequently find the term used to refer to anyuse of capabilities (such as translate and switch) that one finds in the broader topicof integration This is typically a result of confusion over the role of service exposureor use of a product that supports mediation for service exposure and other roles Wewill discuss such confusion in more detail in the next sections

An ESB can thus be considered an architectural container for mediations performingthe role of service exposure as shown in Figure 5 The figure also shows that theESB itself is hosted in one or more operational containers that host mediations usedto expose providers as governed services for an organization and enables theconvenient construction configuration and administration of mediations Thesecontainers are often in the form of products

Figure 5 SOA topology

Service bus vs enterprise service bus

Notice that Figure 5 doesnt actually use the term ESB but instead uses servicebus for the architectural pattern This represents additional terminology evolution toreflect the realities of SOA It has become very common to expose providers as

governed services within a particular domain (for example a departmentapplication or line of business) to assume that all governed services are exposed atthe enterprise level is usually incorrect In such situations a domain uses adomain service bus to expose governed services most of which are used onlywithin the domain but some of which are used across the enterprise Theenterprise service bus exists only logically and service federation (see part 4)supports the sharing of governed services across the enterprise

All that said ESB is an established term so it will be in common use for some timeto come However you should recognize that not all ESBs span the enterpriseDoing so will also diminish the chances of terms such as Enterprise ESB frombecoming common

Service registry and repository

While were considering operational containers where would service specificationsbe contained As they represent governed entities service specifications ideallybelong in a service registry and repository that supports fully governed servicelifecycle management including the service model the resulting servicespecifications and associated metadata In some ways then the service registryand repository becomes a container for service specifications (Figure 5) It isimportant to understand that the existence of a service bus does not define theservice model or mandate service specifications or the existence of the serviceregistry and repository governance provides the motivation

Integration in the context of SOA

This section examines the nature of an integration layer in the context of SOA andrelates it to the role of mediation and the service bus The earlier article positionedthe ESB as an integration layer This assertion needs significant clarification toreduce confusion and to align with the prescriptive concepts and terms in this paper

Integration layer and integration are both very ambiguous terms and theirdefinitions are open to interpretation depending on the context In nearly all contexts(even SOA) the definition of integration derives from enterprise applicationintegration (EAI) and the definition is whatever it takes to allow one application tointeract with another application In EAI integration certainly deals with thenon-semantic mismatches between applications but in EAI it commonly also dealswith the semantic mismatches between applications

Semantic mismatches arise where the expected task or outcome of the callingapplication is not matched by any single interaction with another application The keypoint is that no single interaction achieves the meaning of the required serviceoperation A clear cut example might be for a bookTripItineray() operation whichmight need to do the following takePayment() reserveAccomodation() bookFlight()

updateItineraryStatus() and so on No individual back end operation performs therequired semantics of booking a trip So something somewhere has to understandthe meaning of those different interactions and tie them together Thus in EAIintegration includes both semantic and non-semantic actions and an integrationlayer can perform both

Do we need integration of this sort in SOA Absolutely You saw above that existingproviders sometimes offer the semantic characteristics required by a servicespecification but do not comply with the non-semantics characteristics Mediationwas introduced to deal with such non-semantic mismatches to expose governedservices In SOA as well as EAI you must recognize that existing providers cannotalways offer even the semantic characteristics required by the service specificationsIndeed early in an SOAs maturity cycle organizations spend most of their timedefining and implementing integrations in order to build out the service model fromexisting provider assets So in fact integration is just as important in SOA as in EAI

How do you achieve integration in SOA In reality much the same way as in EAIbut with some significant differences in emphasis EAI is about letting individualapplications interact one-on-one with other applications whereas SOA is about anorganization-wide shared reusable service model used by all applications In SOAas in mature EAI separation of concerns is key and thus an integration layer inSOA might perform both semantic and non-semantic actions but must keep themseparate architecturally

We clarified above that a mediation used for service exposure can only manipulatethe non-semantic characteristics of an interaction Thus the service bus can provideonly a non-semantic sub-layer in an integration layer in SOA Other parts of theintegration layer must manipulate the semantics if the existing providers are unableto satisfy the demands of the semantic characteristics of the service specificationsThus it should be very clear that a service bus is not an entire integration layer atleast not an integration layer as defined by most It should also be clear howeverthat a service bus since it performs non-semantic service exposure included inintegration is part of an integration layer and that mediation for service exposure isa form of integration For completeness we should note that in the rare case whereexisting providers match exactly the semantics of the service model the service buscan be considered a limited integration layer

Lets use Figure 6 to elaborate The top service realization in the figure is identical tothat described in Figure 4 A mediation when used for service exposure andthereby part of the service bus handles the non-semantic mismatches between theservice specification and an existing provider that matches the semantics implied bythe service specification Thus the service bus provides a service exposure layerencapsulated by a more functional integration layer

Figure 6 Integration layer mediation and creation

Now look at the bottom service realization in Figure 6 In this case there is noexisting provider that matches the semantics implied by the service specificationTypically this arises where the granularity of the business task is larger than anyone provider interaction offers Creating a larger-grained business task that matchesthe semantics requires a sequence of interactions often with intervening logic(including the creation of business entities and complex error handling) This is avery different set of capabilities than you expect from mediation used for serviceexposure

You need an architecturally separate layer to do this semantic work In a generalsense this additional layer creates larger-grained business tasks fromsmaller-grained business tasks In some contexts this is called service creationroughly the act of creating a business task that was not present before ndash in otherwords implementing new semantic characteristics A more precise description isthat this additional layer performs provider creation as the new semantics mustmean an existing provider is not present and even the new provider need not (oreven cannot) offer the non-semantic characteristics in the service specification

Figure 6 shows the relationship of the encompassing integration layer to the serviceexposure layer the provider creation layer existing providers service specificationsand service realizations The figure emphasizes that mediation (for serviceexposure) and provider creation contribute to service realization but they arearchitecturally distinct due to separation of concerns It is important to note thatarchitecturally the service bus supplies only the service exposure layer

Lets briefly examine two scenarios that demonstrate the differences betweenservice exposure and provider creation

In the first scenario shown in Figure 7 assume an existing provider that doesexactly what is required by a service specification for the service operation (businesstask business and technical interface protocolformat and so on) with theexception of the need for every request to the provider to be secured via HTTPS

Figure 7 Service exposure in an integration layer

The addition of encryption is a perfect example of a non-semantic contribution to theservice specification The provider implements the business task and in this casethe majority (but not all) of the non-semantic characteristics The mediation enablesHTTPS without any change to the provider It is very clear that the mediation addsabsolutely nothing to the semantics in this scenario As above mediation for serviceexposure exists only in the service bus

In the second scenario shown in Figure 8 there is no existing provider that evenremotely delivers the semantic characteristics in the service specification for theservice operation It becomes necessary to interact with several providers usuallywith additional intervening logic to satisfy the semantic characteristics of thespecification Mediation capability is often leveraged simply to support interaction

with the existing providers not for service exposure In effect we are turning acollection of finer-grained business tasks into a single coarser-grained business taskconsistent with the service specification for the service operation

A concrete example might be retrieving a customer account whereby you needaccount information from one system and customer information from anotherNeither provider holds the complete semantic characteristics so it is quite clear thatsemantic activity must be present to meaningfully merge these different entities thisis well beyond service exposure and into the realm of provider creation Separationof concerns ensures that the mediation performing the non-semantic serviceexposure is implemented independently of the composition

Figure 8 Provider creation and mediation in an integration layer

In summary you see that an integration layer in SOA architecturally contains apurely non-semantic service exposure sub-layer that is fulfilled by the service buspattern and richer semantic functionality in a provider creation sub-layer The formeris always present and the latter is almost always present Thus a service bus (alsoknown as an ESB) itself is generally not sufficient to be an integration layer in SOA

Business logic versus integration logic

Next lets investigate the terms integration logic and business logic used in one

of the earlier articles in the context of the integration layer and the service bus asdescribed in this article We show in this section that both terms are ambiguous andnot helpful in describing the nature of the service bus or the integration layer Wealso suggest more meaningful and helpful alternatives

The earlier article stated that business logic [deals with] the semantics associatedwith achieving business goals while integration logic only modifies syntaxassociated with achieving the necessary interconnectivity Based on the abovedescriptions of the integration layer and the service bus you recognize conflicts forexample business logic is a form of integration logic The problem isover-simplification and lack of precise terminology The comparison should not bebusiness logic versus integration logic but instead about logic categorized byimpact and ownership

Logic impact relates to the characteristics in a service specification

bull Semantic impact implies contribution only to the semanticcharacteristics

bull Non-semantic impact implies contribution only to the non-semanticcharacteristics

Logic ownership relates to the role or group that defines and changes the logic Inthe integration layer there are two distinct ownership roles that matter

bull Business defines all business goals (the why) whether semantic ornon-semantic Business can define and change any logic with semanticor non-semantic impact to achieve business goals

bull IT implements the infrastructure to help achieve business goals (thehow) IT can define and change only logic with non-semantic impact toachieve business goals

Figure 9 shows the three valid logic categories that result business-owned semanticlogic business-owned non-semantic logic and IT-owned non-semantic logicIT-owned semantic logic is by definition invalid semantics are about the meaning ofthe business task

Figure 9 Logic in the integration layer

It is obvious that business-owned semantic logic exists in the provider creationsub-layer Indeed that is the purpose of the sub-layer to introduce new semantics

It is also obvious that IT-owned non-semantic logic exists in the mediationserviceexposure sub-layer This would include IT-owned policies or rules that could alsoimpact routing based on operational considerations like provider health We assertIT-owned non-semantic logic exists in the provider creation sub-layer as well WhyOne example is when a new provider needs to interact with an existing providerusing a different message format IT should own the non-semantic logic needed totranslate messages to enable the interaction This maintains separation of concerns

A less obvious type is business-owned non-semantic logic which exists in theprovider creation sub-layer and in the service exposure layer Such logic would notchange fundamental semantics but for example only change parameter valuesinvolved in the fundamental semantics For the service exposure layer an examplewould be routing between providers the routing decision could be based onbusiness-owned policies or rules to give better qualities of service to requestsfrom premium customers These are business-owned policies but they have nothingto do with satisfying the semantic meaning of the request

You can now be more precise in statements about logic in an integration layer inSOA Mediation in the service exposure layer can contain only non-semantic logicThat logic is usually IT-owned but can be business-owned Thus it is fair to say thatmediation (and thus the service bus) can contain business logic but only if it isnon-semantic The provider creation layer can contain business-owned semanticlogic and both types of non-semantic logic

You care about the distinction between the different types of logic because it isimportant to implement them independently they will need to be updated by differentroles in differing change cycles often using different tools and different governancendash- in effect maintaining separation of concerns This is reasonably obvious betweenIT-owned and business-owned logic but what we are also introducing here is that

there should be a clear separation between the two types of business-owned logicsince they will likely be owned and changed by different business owners

Architecture versus implementation

The discussion here as throughout the earlier article series is about architecturearchitectural layers architectural roles and architectural principles such asseparation of concerns Architecture alone however cannot provide business valuethe architecture must be implemented using appropriate technologies or productsNext well discuss the pragmatics of architecting and implementing an SOA theintegration layer in particular

Separation of concerns is critical in SOA and you need to define the necessaryarchitectural layers to achieve a clean separation of concerns That is the reason forthe integration layer itself and for the mediationservice exposure and providercreation sub-layers in the integration layer A common cause of failed SOAimplementations is failure to define a layered architecture that promotes separationof concerns leading to an implementation that is inflexible and difficult to maintainFor example some enterprises fail to appreciate the difference between anintegration layer and a service bus thus mixing service exposure and providercreation in effect inappropriately mixing the responsibilities of business and IT

This does not mean however that an idealized layered architecture must beimplemented with no compromises Indeed compromises almost always have to bemade for reasons of performance cost technology limitations and so on Forexample it is possible to use clean logical layering rather than physical layering toimprove performance The question is not whether to compromise but what andwhere are the fewest possible compromises that retain the architectural intent andthus maximum separation of concerns

Obviously to implement the architecture you must choose an implementationtechnology for each of the architectural layers In SOA there are often products thattarget a particular layer Such a product will be very good for developmentmaintenance and run time aspects of that layer but not ideal for other layers Thetechnology choice for a layer might however be based on criteria in addition to thetargeted architectural layers the criteria can include skills existing productinventory development cost (tooling significantly impacts such costs) qualities ofservice total cost of ownership or a combination of these It is perfectly valid toleverage a technology for a layer it does not target if other criteria are moreimportant The important consideration is not so much matching products to layersbut that the separation of concerns is preserved as much as possible by ensuringthe separate architectural layers defined are still easily identified in the final solution

Figure 10 shows a very common situation with integration products includingproducts that target the service bus (ESB) pattern ESB products focus on

capabilities that target non-semantic capabilities like adaptation translation routingand so on plus the ability to sequence those primitive capabilities Of course thesecapabilities are leveraged to produce the mediations in the service exposure layer

Figure 10 Architecture and integration products

Those same capabilities can be used in the provider creation layer as well Howeverservice bus mediation flow capability is not designed for the complex decision logicexception handling and state management required by the interaction scenarios youfind in provider creation On the other hand other business process orientedproducts (for example a BPEL engine) focus on complex flow capabilities intendedfor dealing with compositional and exception logic an ability to hold and representin-process state for longer running processes The provider creation layer oftenrequires such capabilities As discussed above the service exposure layer mightuse sophisticated capabilities that contribute to greater agility (such as rules) whenthere is no impact on semantics

An example might help Consider the provider creation scenario in Figure 8 Assumean environment that contains IBM WebSpherereg Process Server targeting businessprocesses WebSphere Process Server includes IBM WebSphere ESB which is aproduct targeting mediation The most optimal solution leveraging targeteddevelopment and run time capabilities would implement mediation using mediationtechnology in WebSphere ESB WebSphere Process Server technology would be

the best choice for new provider creation as it provides sophisticated tooling and runtime capabilities suited to new provider creation However depending on thecomplexity of the new provider and the skills of the development team it is possibleto use WebSphere ESB technology for provider creation as well Again theimportant goal is retention of separation of concerns

To summarize for a successful SOA you must architect layers with cleanseparation of concerns then implement the layers retaining separation of concernsas much as possible You can use any technology to implement a layer whether thetechnology targets that layer or not as long as compromises are understood andany impact on separation of concerns is minimized Good governance during themodel and assemble lifecycle phases goes a long way towards ensuring appropriateseparation of concerns

Conclusion

This article attempted to bring precision and clarity to a broad range of topics andterminology around the SOA architectural pattern enterprise service bus In fact weshowed that the term enterprise service bus is often inappropriate and that a betterterm is simply service bus without more knowledge of the organization it servesthat said we also acknowledged the term ESB is unlikely to be deprecated

We showed the term service without context and qualification can be confusingand even counterproductive and strongly suggest the purely logical governedservice as a more precise but still slightly ambiguous alternative Even moreprecision comes from using service specification to refer to a formal representationof the external semantic syntactic and operational characteristics of a governedservice and service realization to refer to a physical implementation of a servicespecification

We showed that the term service bus in reality is logically a representation of (andphysically a container for) a collection of mediations that perform semanticallytransparent service exposure that is exposing providers according to servicespecifications We showed that the service registry and repository provides theneeded governance of (and can be considered a container for) servicespecifications

We showed that service bus is not a complete integration layer at least not anEAI-style integration layer that performs both semantic and non-semantic actionsWe showed that mediation is a form of integration and that the service bus providesa non-semantic service exposure sub-layer that is part of an integration layer inSOA that includes a provider creation sub-layer responsible for providinglarge-grained providers from one or more small-grained providers

We showed how to be more precise in statements about logic in an integration

layer in SOA We showed that business logic and integration logic are terms that cancause confusion and identified business-owned semantic logic business-ownednon-semantic logic and IT-owned non-semantic logic as more precise terms Wefurther showed the service exposure layer can contain only non-semantic logic butthat includes business-owned non-semantic logic thus allowing business logic in theservice bus (ESB)

We showed that for a successful SOA you should first architect the required layersthat guarantee separation of concerns and then choose an implementationtechnology for the each of those layers comprising only as much as necessary thusretaining separation of concerns We also showed that a product targeting onearchitectural layer can be used for other layers as well assuming preservation ofseparation of concerns

Acknowledgements

The authors would like to thank the following for their contributions to and reviews ofthis article Andy Garratt Guy Hochstetler Andy Humphreys Brian Petrini RachelReinitz Marc-Thomas Schmidt Andre Tost

Resources

bull Exploring the Enterprise Service Bus Part 1 Discover how an ESB can helpyou meet the requirements for your SOA solution

bull The Open Group SOA Work Group

bull The Open Group SOA Ontology

bull The Open Group SOA Governance

bull Exploring the Enterprise Service Bus Part 4 Federated connectivity in theenterprise

bull Designing an ESB Gateway

bull Patterns Implementing an SOA using an Enterprise Service Bus

bull Understand Enterprise Service Bus scenarios and solutions in Service-OrientedArchitecture Part 1

bull IBM developerWorks WebSphere

About the authors

Greg FlurryGreg Flurry is a Distinguished Engineer in IBMs Business Process and ServiceOptimization group His responsibilities include working with clients on serviceoriented solutions and advancing IBMs service oriented product portfolio

Kim J ClarkKim Clark is an IT Specialist from the United Kingdom working in IBM SoftwareServices for WebSphere (ISSW) Alongside providing guidance to customers hewrites and presents regularly on SOA design He has been working in the IT industrysince 1993 spanning object oriented programming enterprise application integration(EAI) and SOA He pioneered many of the early projects using SOA FoundationSuite products Kim holds a degree in Physics from the University of LondonEngland

Table of Contents
Introduction
The service in SOA
The ESB in SOA
Conclusion
Acknowledgements
Resources
About the authors

Page 2: The Enterprise Service Bus, re-examined

The service in SOA

SOA leverages services to simplify formalize and bring agility to the creation ofbusiness solutions The idealized SOA is shown in Figure 1 where a requesterinteracts with a provider to achieve some business-relevant task

Figure 1 An abstract view of SOA Direct service interaction

Where is the service in Figure 1

Consider these statements

bull We identified the Process Order service as one of the services needed torun our business

bull A service is a repeatable business task

These comments suggest service is not a physical thing but instead an abstractlogical or conceptual thing fundamentally the business task or the businessoutcome resulting from interaction Consistent with that interpretation is The OpenGroup SOA Work Group formal definition of service as a logical representation ofa repeatable activity that has a specified outcome You cannot publish or interactwith this service yet these actions are commonly associated with a serviceUsing this definition you must conclude that the service is not shown but onlyimplied in Figure 1 You might further conclude the service is performed by theprovider

Now consider these statements

bull We will publish the Process Order service in the registry

bull The registry is used to discover services when designing new solutions

Such statements suggest service is more concrete that is a specification ofsomething but still not something with which a requester can interact Using thisdefinition you must conclude that the service is not shown at all in Figure 1 Youmight further conclude that any interaction with the provider is specified by theservice

Finally consider these statements