Service oriented architectures: approaches, …...service-oriented computing paradigm. xSOA serves...

The VLDB Journal (2007) 16:389–415DOI 10.1007/s00778-007-0044-3

REGULAR PAPER

Service oriented architectures: approaches, technologiesand research issues

Mike P. Papazoglou · Willem-Jan van den Heuvel

Received: 6 June 2005 / Accepted: 1 August 2005 / Published online: 3 March 2007© Springer-Verlag 2007

Abstract Service-oriented architectures (SOA) is anemerging approach that addresses the requirements ofloosely coupled, standards-based, and protocol-independent distributed computing. Typically businessoperations running in an SOA comprise a number ofinvocations of these different components, often in anevent-driven or asynchronous fashion that reflects theunderlying business process needs. To build an SOAa highly distributable communications and integrationbackbone is required. This functionality is provided bythe Enterprise Service Bus (ESB) that is an integrationplatform that utilizes Web services standards to supporta wide variety of communications patterns over multipletransport protocols and deliver value-added capabilitiesfor SOA applications. This paper reviews technologiesand approaches that unify the principles and conceptsof SOA with those of event-based programing. Thepaper also focuses on the ESB and describes a range offunctions that are designed to offer a manageable, stan-dards-based SOA backbone that extends middlewarefunctionality throughout by connecting heterogeneouscomponents and systems and offers integration services.Finally, the paper proposes an approach to extend theconventional SOA to cater for essential ESB require-ments that include capabilities such as service orches-tration, “intelligent” routing, provisioning, integrity andsecurity of message as well as service management. Thelayers in this extended SOA, in short xSOA, are used toclassify research issues and current research activities.

M. P. Papazoglou (B) · W.-J. van den HeuvelINFOLAB, Tilburg University, PO Box 90500,5000 LE, Tilburg, The Netherlandse-mail: [email protected]

Keywords Service oriented architecture ·Asynchronous and event-driven processing ·Application and service integration · Enterprise bus ·Web services

1 Introduction

Modern enterprises need to respond effectively andquickly to opportunities in today’s ever more competi-tive and global markets. To accommodate business agil-ity, enterprises are supposed to streamline (existing)business processes while exposing the various packagedand home-grown applications found spread throughoutthe enterprise in a highly standardized manner. A con-temporary approach for addressing these critical issuesis embodied by (Web) services that can be easily assem-bled to form a collection of autonomous and looselycoupled business processes.

The emergence of Web services developments andstandards in support of automated business integrationhas driven major technological advances in the integra-tion software space, most notably, the service-orientedarchitecture (SOA) ([15,18]). The purpose of this archi-tecture is to address the requirements of loosely coupled,standards-based, and protocol-independent distributedcomputing, mapping enterprise information systems(EIS) appropriately to the overall business process flow.

In an SOA, software resources are packaged as “ser-vices”, which are well defined, self-contained modulesthat provide standard business functionality and areindependent of the state or context of other services.Services are described in a standard definition language,have a published interface, and communicate with each

390 M. P. Papazoglou, W.-J. van den Heuvel

other requesting execution of their operations in orderto collectively support a common business task or pro-cess [41]. Services that utilize Web services standards,e.g., Web Services Description Language (WSDL), Sim-ple Object Access Protocol (SOAP), and UniversalDescription, Discovery and Integration registry (UDDI),are the most popular type of services available today.

An SOA is designed to allow developers to over-come many distributed enterprise computing challengesincluding application integration, transaction manage-ment, security policies, while allowing multiple plat-forms and protocols and leveraging numerous accessdevices and legacy systems [1]. The driving goal of SOAis to eliminate these barriers so that applications inte-grate and run seamlessly. In this way an SOA can deliverthe flexibility and agility that business users require,defining coarse grained services, which may be aggre-gated and reused to facilitate ongoing and changingneeds of business, as the key building blocks of enter-prises.

In contrast to conventional software architectures pri-marily delineating the organization of a system in its(sub)systems and their interrelationships, the SOA cap-tures a logical way of designing a software system toprovide services to either end-user applications or otherservices distributed in a network through published anddiscoverable interfaces. SOA is focused on creating adesign style, technology, and process framework that willallow enterprises to develop, interconnect, and maintainenterprise applications and services efficiently and cost-effectively. While this objective is definitely not new [66],SOA seeks to eclipse previous efforts such as modularprograming, code reuse, and object-oriented softwaredevelopment techniques.

The SOA as a design philosophy is independent of anyspecific technology, e.g., Web-services or J2EE enter-prise beans. This is achieved by limiting the number ofimplementation restrictions to the level of the serviceinterface. SOA requires that functions, or services, aredefined by a description language (WSDL [30] in thecase of Web services) and have interfaces that performuseful business processes. The fundamental intent of aservice in an SOA is to represent a reusable unit of busi-ness-complete work. A service in SOA is an exposedpiece of functionality with three essential properties.Firstly, an SOA-based service is self-contained, i.e., theservice maintains its own state. Secondly, services areplatform independent, implying that the interface con-tract to the service is limited to platform independentassertions. Lastly, the SOA assumes that services can bedynamically located, invoked and (re-)combined.

Logically, a service in an SOA is a bound pair of aservice interface and a service implementation. Service

interface defines the identity of a service and its invo-cation logistics. Service implementation implements thework that the service is designated to do. Because inter-faces are platform independent, a client from any com-munication device using any computational platform,operating system and any programing language can usethe service. These two facets of the service are designedand maintained as distinct items, though their existenceis highly interrelated.

An SOA provides a flexible architecture that unifiesbusiness processes by modularizing large applicationsinto services. A client from any device, using any oper-ating system, in any programing language, can accessan SOA service to create a new business process. AnSOA creates a collection of services that can commu-nicate with each other using service interfaces to passmessages from one service to another, or coordinatingan activity between one or more services.

Services used in composite applications may be brandnew service implementations, they may be fragmentsof old applications that were adapted and wrapped,or they may be combinations of the above. Often thedesigners for the client of the service do not have directaccess to the service implementation, other than indi-rectly through its interface. External Internet-based ser-vice providers and SOA packaged applications simplyoffer the interfaces without revealing the inner work-ings of their environment. Thus, with SOA, an enter-prise can create, deploy and integrate multiple servicesand choreograph new business functions by combiningnew and existing application assets into a logical flow.Accordingly, for well defined and semantically unam-biguous applications an SOA can serve as an enablerof just-in-time integration and interoperability of legacyapplications; a key consideration for enterprises that areseeking to deploy demand driven computing environ-ments.

Services in an SOA exhibit the following main char-acteristics [47]:

− All functions in an SOA are defined as services[7]. This includes pure business functions, businesstransactions composed of lower-level functions, andsystem service functions as well.

− All services are autonomous. Their operation is per-ceived as opaque by external components. Serviceopaqueness guarantees that external componentsneither know nor care how services perform theirfunction, they merely anticipate that they return theexpected result. The implementation and executionspace of the application providing the desired func-tionality is encapsulated behind the service inter-face.

Service oriented architectures 391

− In the most general sense, the interfaces are invo-cable. This implies that it is irrelevant whether ser-vices are local or remote, the interconnect schemeor protocol to effect the invocation, nor which infra-structure components are required to establish theconnection.

The SOA’s loose-coupling principle—especially theclean separation of service interfaces from internalimplementations—to guide planning, development,integration, and management of their network applica-tion platforms make them indispensable for enterprise-wide and cross-enterprise applications [7].

Web services seem to become the preferred imple-mentation technology for realizing the SOA promiseof maximum service sharing, reuse, and interoperabil-ity [56]. Web services and SOA reduce complexity ofenterprise application eco-systems by encapsulation andminimizing the requirements for shared understandingby defining service interfaces in an unambiguous andtransparent manner. Also Web services enable just-in-time integration and interoperability of legacy appli-cations. Based on open and pervasive standards, Webservices seem poised for success, as these are only builton top of existing, ubiquitous infrastructure like HTTP,SOAP, and XML.

In this article, we survey the underpinnings of SOA,assessing methodologies and technologies that serve asthe enabling springboard for business integration pro-jects and deliver a flexible and adaptable environment.This survey is unique in that it unifies the principles,concepts and developments in the area of applicationintegration, middleware, and integration brokers, SOA,event-driven computing, and adapters, and explains howthey operate as part of an emerging distributed com-puting technology named the Enterprise Service Bus(ESB). Moreover, this paper develops and explores anextension to conventional SOAs, entitled the eXtendedSOA (xSOA). xSOA is an attempt to streamline, grouptogether, and logically structure the functional require-ments of complex applications that make use of theservice-oriented computing paradigm. xSOA serves asthe reference for reviewing available technologies, andassessing open research issues.

2 Service roles in SOA

The SOAs and Web services solutions support two keyroles: a service requestor (client) and service provider,which communicate via service requests. A role thusreflects a type of a participant in an SOA ([18,55]).

Service requests are messages formatted according tothe Simple Object Access Protocol (SOAP) [16]. SOAPentails a light-weighted protocol allowing RPC-like callsover the Internet using a variety of transport protocolsincluding HTTP, HTTP/S and SMTP. In principle, SOAPmessages may be conveyed using any protocol as longas a binding is defined. The SOAP request is receivedby a run-time service (a SOAP “listener”) that acceptsthe SOAP message, extracts the XML message body,transforms the XML message into a native protocol,and delegates the request to the actual business processwithin an enterprise.

Requested operations of Web services are implemen-ted using one or more Web service components [103].Web service components may be hosted within a Webservices container [36], serving as an interface betweenbusiness services and low-level, infrastructure services.In particular, Web service containers are similar to J2EEcontainers [2] providing facilities such as location,routing, service invocation, and management. In par-ticular, a service container is the physical manifestationof the abstract service endpoint, and provides the imple-mentation of the service interface. In addition, servicecontainers provide facilities for lifecycle managementsuch as start up, shutdown, and resource cleanup. A ser-vice container can host multiple services, even if they arenot part of the same distributed process. Thread poolingallows multiple instances of a service to be attached tomultiple listeners within a single container [27]. Finally,the response that the provider sends back to the clienttakes again the form of a SOAP envelope carrying anXML message.

SOAP is by nature a platform-neutral and vendor-neutral standard. These characteristics allow for a looselycoupled relationship between requester and provider,which is especially important over the Internet wheretwo parties may reside in different organizations orenterprises. However, SOA does not require the usageof SOAP. Prior to SOAP, for example, some companiesused IBM’s WebSphere MQ to exchange XML docu-ments between them [99]. While this type of infrastruc-ture clearly does not support Web services because theycommunicate using SOAP, they are another exampleof service invocation in an SOA. Currently WebSphereMQ is, of course, equipped with direct support for SOAP.

While SOA services are visible to the service client,their underlying Web components are transparent. Theservice consumer does not have to be concerned with theimplementation of the service, as long as it supports therequired functionality, while offering the desired qual-ity of service. For the service provider, the design ofcomponents, their service exposure and managementreflect key architecture and design decisions that enable


Servicerequester

ServiceProvider

ServiceProvider

ServiceProvider

ServiceProvider

Provider RequesterProvider RequesterService

requesterService

requester

ServiceProvider

ServiceProvider

ServiceProvider

ServiceProvider

ServiceProvider

ServiceProvider

ServiceProvider

ServiceProvider

Provider RequesterProvider Requester

Aggregator

Fig. 1 The role of service aggregator

services in SOA. The provider view offers a perspec-tive on how to design the realization of the componentthat offers the services; its architectural decisions anddesigns.

The process of a service requester having to directlyinteract with a service provider exposes service request-ers to the potential complexity of discovering, exploring,negotiating, and reserving services between differentservice providers. An alternative approach is for anorganization to provide this combined functionalitydirectly to the service requester. This service role com-bines the role of service requester and provider, andis labeled as a service aggregator [73]. The serviceaggregator thus performs a dual role. First, it acts asan application service provider as it offers a complete“service” solution by creating composite, higher-levelservices, which it provides to the service client. Ser-vice aggregators can accomplish this composition usingspecialized composition languages like BPEL [4] andBPML [5]. Second, it acts as a service requester as itmay need to request and reserve services from otherservice providers. This process is shown in Fig. 1.

While service aggregation may offer direct benefitsto the requester, it is a form of service brokering thatoffers a convenience function—all the required servicesare grouped “under one roof”. However, an impor-tant question that needs to be addressed is how doesa service requester determine which one out of a num-ber of potential application service providers, should beselected for their service offerings? The servicerequester could retain the right to select an applicationservice provider based on those that can be discoveredfrom a registry service, such as the UDDI [94]. SOAtechnologies, such as UDDI, and security and privacystandards such as SAML [39] and WS-Trust [3], intro-duce another role which addresses these issues, called aservice broker [31].

Service brokers are trusted parties that force serviceproviders to adhere to information practices that comply

ServiceProvider

ServiceProvider

ServiceClient

ServiceClient

ServiceBroker

ServiceBroker

ServiceProviderService

ProviderServiceClient

ServiceClient

ServiceBrokerServiceBroker

Fig. 2 Service brokering

with privacy laws and regulations, or in the absence ofsuch laws, industry best practices. In this way, broker-sanctioned service providers are guaranteed to offer ser-vices that are in compliance with local regulations andcreate a more trusted relationship with customers andpartners. A service broker maintains an index of avail-able service providers. The service broker is able to “addvalue” to its registry of application service providers byproviding additional information about their services.This may include differences about the reliability, trust-worthiness, the quality of the service, service level agree-ments, and possible compensation routes to name a few.

Figure 2 shows an SOA where a service broker servesas an intermediary that is interposed between servicerequesters and service providers. Figure 2 falls underthis category with the service registry (UDDI operator)being a specialized instance of a service broker. Underthis configuration, the UDDI registry serves as a bro-ker where the service providers publish the definitionsof the services they offer using WSDL and where theservice requestors find information about the servicesavailable.

3 Enterprise service bus

Essentially, Web services denote an important technol-ogy for implementing SOAs; however, other moreconventional programing languages or middleware plat-forms may be adopted as well [91]. In particular, all tech-nologies that directly implement service interfaces withWSDL, and communicate with XML messages, can beinvolved in SOA. As indicated earlier, other technolo-gies such as, for instance, established middleware tech-nologies like J2EE, CORBA, and IBM’s WebSphereMQ, can now also participate in an SOA, using newfeatures that work with WSDL.


Fig. 3 Enterprise service busconnecting diverseapplications and technologies

Service orchestration

Custom applications

Distributed query engine

Adapters Web Services

MQ gateway

JMS/J2EE

Portals

Reliable Asynchronous Secure Messaging

service interfaceservice interface


Custom applications

Distributed query engine

Adapters Web Services

MQ gateway

JMS/J2EE

Portals




Custom applications

Custom applications

Distributed query engineDistributed

query engineAdapters

WebSphere, .NETapps

Java apps

Web Services

MQ gateway

Mainframe & legacy

apps

JMS/J2EE

Data sources Enterpriseapplications

Multi-platformsupport

Portals


service interfaceservice interface

Fundamentally, there are only two options for solvingtechnology and information model mismatches:

1. Build the client module to conform exactly to thecharacteristics of every server module that it willinvoke.

2. Insert a layer of communication and integrationlogic between the client and server modules.

The first approach requires to “develop an interface”for each connection, resulting in a point-to-point topol-ogy. This topology has long been known to be hard tomanage and maintain as it introduces a tighter formof coupling to harmonize transport protocols, documentformats, interaction styles, etc. [61]. This makes it harderto change either of the two systems involved in an inter-change without impacting other systems. In addition,point-to-point integration is not scalable and very com-plex as the number of integration points increases as thenumber of systems increases and can quickly becomeunmanageable. Hence, the broad use of EnterpriseApplication Integration middleware supporting a vari-ety of hub-and-spoke integration patterns [74]. Thisleaves the second approach as the most viable alter-native.

The second approach introduces an integration layerthat must support interoperability among, and coex-ist with deployed infrastructure and applications. Therequirements to provide an appropriately capable andmanageable integration infrastructure for Web servicesand SOA are coalescing into the concept of the ESB([27,82]). The ESB exhibits two prominent features [52].Firstly, it promotes loose coupling of the systems tak-ing part in an integration. Secondly, the ESB can breakup the integration logic into distinct easily manageablepieces.

The ESB is an open, standards-based message busdesigned to enable the implementation, deployment,

and management of SOA-based solutions with a focuson assembling, deploying, and managing distributedSOA. The ESB provides the distributed processing, stan-dards-based integration, and enterprise-class backbonerequired by the extended enterprise [52]. The ESB isdesigned to provide interoperability between large-grained applications and other components via stan-dards-based adapters and interfaces. The bus functionsas both transport and transformation facilitator to allowdistribution of these services over disparate systems andcomputing environments.

Conceptually, the ESB has evolved from the store-and-forward mechanism found in middleware products,e.g., Message Oriented Middleware, and combines con-ventional EAI technologies with Web services, XSLT[98], orchestration, and choreography technologies, e.g.,BPEL, WS-CDL, and ebXML BPSS. Physically, an ESBprovides an implementation backbone for an SOA. Itestablishes proper control of messaging as well as appliesthe needs of security, policy, reliability, and accounting,in an SOA architecture. The ESB, is responsible for theproper control, flow, and translations of all messagesbetween services, using any number of possible messag-ing protocols. An ESB pulls together applications anddiscrete integration components to create assemblies ofservices to form composite business processes, which inturn automate business functions in an enterprise.

Figure 3 depicts a simplified architecture of an ESBthat integrates a J2EE application using JMS, a .NETapplication using a C# client, an MQ application thatinterfaces with legacy applications, as well as externalapplications and data sources using Web services. AnESB, as portrayed in Fig. 3, enables the more efficientvalue-added integration of a number of differentapplication components, by positioning them behind aservice-oriented facade and by applying Web servicestechnology. In this figure, a distributed query engine,which is normally based on XQuery [14] or SQL, enablesthe creation of data services to abstract the complexity


of underlying data sources. A portal in Fig. 3 is a user-facing aggregation point of a variety resources repre-sented as services, e.g., retail, divisional, corporateemployee, and business partner portals.

Endpoints in the ESB, depicted in Fig. 3, provideabstraction of physical destination and connection infor-mation (like TCP/IP hostname and port number) tran-scending plumbing level integration capabilities oftraditional, tightly coupled, distributed software compo-nents. Endpoints allow services to communicate usinglogical connection names, which an ESB will map toactual physical network destinations at runtime. Thisdestination independence offers the services that areconnected to the ESB, the ability to be upgraded, moved,or replaced without having to modify code and disruptexisting ESB applications. For instance, an existing ESBinvoicing service could be easily upgraded by a new ser-vice, without disrupting the execution of other applica-tions. Additionally, duplicate processes can be set up tohandle fail-over if a service is not available. Endpointsalso provide the asynchronous and highly reliable com-munication between service containers. The endpointscan be configured to use several levels of quality of ser-vice, which guarantee communication despite networkfailures and outages [27].

To successfully build and deploy a distributed SOA,there are four primary aspects that need to be addressed:

1. Service enablement Each discrete application needsto be exposed as a service.

2. Service orchestration Distributed services need tobe configured and orchestrated in a unified andclearly defined distributed process.

3. Deployment Emphasis should be shifted from testto the production environment, addressing security,reliability, and scalability concerns.

4. Management Services must be audited, maintainedand reconfigured. The latter requirements requiresthat corresponding changes in processes must bemade without rewriting the services or underlyingapplication.

Services can be programed using application devel-opment tools (like Microsoft .NET, Borland JBuilder, orBEA WebLogic Workshop), which allow new or existingdistributed applications to be exposed as Web services.Technologies like J2EE Connector Architecture (JCA)may also be used to create services by integrating pack-aged applications (like ERP systems), which would thenbe exposed as services.

To achieve its operational objectives, the ESB drawsfrom traditional EAI broker functionality in that it

provides integration services such as connectivity androuting of messages based on business rules, data trans-formation, and adapters to applications [28]. These capa-bilities are themselves SOA-based in that they are spreadout across the bus in a highly distributed fashion andhosted in separately deployable service containers. Thisis crucial difference from traditional integration brokers,which are usually highly centralized and monolithic innature [74]. The SOA approach allows for the selectivedeployment of integration broker functionality exactlywhere it is needed with no additional over-bloating. Thedistributed nature of the ESB container model allowsindividual event-driven services to plugged into the ESBbackbone on an as needed basis, be highly decentralizedand work together in a highly distributed fashion, whilethey are scaled independently from one another. Thisis illustrated in Fig. 3 where applications running ondifferent platforms are abstractly decoupled from eachother, and can be connected together through the busas logical endpoints that are exposed as event-drivenservices.

3.1 Event-driven SOA

In the enterprise context, business events, e.g., a cus-tomer order, the arrival of a shipment at a loading dock,or the payment of a bill, may affect the normal courseof a business process at any point in time [64]. Thisimplies that business processes cannot be designed a pri-ori assuming that events are predetermined following aparticular flow, but must be defined dynamically, drivenby incoming, parallel and a synchronous event flows.Supporting enterprise applications then must commu-nicate using an event-driven SOA ([27,89]). An event-driven SOA thus denotes an architectural approach onhow enterprises could implement an SOA, respectingthe highly volatile nature of business events. An ESBrequires that applications and event-driven services aretied together in the context of an SOA in a loosely cou-pled fashion. This allows them to operate independentlyfrom each other while still providing value to a broaderbusiness function [28].

In an ESB-enabled event-driven SOA, applicationsand services are treated as abstract service endpoints,which can readily respond to asynchronous events [28].The event-driven SOA provides a means of abstractingaway from the details of underlying service connectivityand protocols.

Services in this SOA variant are not required to under-stand protocol implementations or have any knowledgeon routing of messages to other services. An event sourcetypically sends messages through some middlewareintegration mechanism like an ESB, and then the


Fig. 4 Simplified distributedprocurement process

ReplenishmentReplenishmentserviceservice

Sourcing Sourcing serviceservice

Purchase orderPurchase orderserviceservice

Invoicing Invoicing serviceservice

Supplier orderSupplier orderserviceservice

Sending application

Receiving application


Sourcing Sourcing serviceservice

Purchase orderPurchase orderserviceservice

Invoicing Invoicing serviceservice


Sending application

Receiving application

middleware publishes the messages to the services thathave subscribed to the events. The event itself encap-sulates an activity, constituting a complete descriptionof a specific action. To achieve its functionality, the ESBsupports both the established Web services technologies,including, SOAP, WSDL, and BPEL, as well as emerg-ing standards such as WS-ReliableMessaging [49] andWS-Notification [44].

As we already explained earlier in the previous sec-tion, in a brokered SOA (see Fig. 2) the only depen-dency between the provider and client of a service isthe service contract (described in WSDL), which thethird-party service registry advertises. The dependencybetween the service provider and the service client is arun-time dependency, not a compile-time dependency.The client obtains and uses all the information it needsabout the service at run-time. The service interfaces arediscovered dynamically, and messages are constructeddynamically. The service consumer does not know theformat of the request message or response message orthe location of the service until it needs a particularservice.

Service contracts and other associated meta-data,including meta-data about policies and agreements [33],lay the groundwork for enterprise SOAs that involvemany clients operating with a complex, heterogeneousapplication infrastructure. However, many of today’sSOA implementations are not that elaborate. In manycases, when small or medium enterprises implementSOA, neither service interfaces in WSDL nor UDDIlook-ups tend to be available. This is often either due tothe fact that the SOA in place provides for limited func-tionality or because sufficient security arrangements arenot yet in place. In these cases, an event-driven SOA pro-vides a more lightweight, straightforward set of technol-ogies to build and maintain the service abstraction forclient applications [13].

To achieve a more lightweight arrangement an event-driven SOA requires that two participants in an event

(server and client) be fully decoupled [13], not justloosely coupled. With fully decoupled exchanges thetwo participants in an event need not have any knowl-edge about each other, before engaging in some busi-ness transaction. In this case, there is no need for aservice (WSDL) contract that explicates the behavior ofa server to the client. The only relationship is indirect,through the ESB, to which clients and servers are sub-scribed as subscribers and publishers of events. Despitethe notion of decoupling in event-driven SOA, recip-ients of events require meta-data about those events.The publishers of the events often organize them on thebasis of some (topical) taxonomy, which is a form ofmeta-data. Alternatively, meta-data is available aboutthe event, including its size, format, etc. In contrast toservice interfaces, however, meta-data that is associatedwith events is generated on an ad hoc basis, instead ofbeing static and predefined. In particular, ad hoc meta-data describe published events that consumers can sub-scribe to, the interfaces that service clients and providersexhibit as well as the messages they exchange, and eventhe agreed format and context of those meta-data, with-out falling into the formal service contracts themselves.

To effectively orchestrate the behavior of services ina distributed process, the ESB infrastructure includes adistributed processing framework and XML-based ser-vices. To exemplify these features, a simplified distrib-uted procurement business process as shown in Fig. 4,will be configured and deployed using an ESB. The fig-ure shows that when an automated inventory systemtriggers a replenishment signal, an automated procure-ment process flow is triggered and a series of logicalsteps need to be performed. First the sourcing servicequeries the enterprise’s supplier reference database todetermine the list of possible suppliers, who could be pri-oritized on the basis of existing contracts and suppliermetrics. A supplier is then chosen based on some crite-rion and the purchase order is automatically generatedin an ERP purchasing module and is sent the vendor of


Fig. 5 Enterprise service busconnecting remote services

Enterprise Service Bus


OrderOrderapplicationapplication

rPurchase OrderPurchase Orderserviceservice

ERPERP


J2EEJ2EEapplicationapplication

SOAP/HTTP

XML/JMS

SOAP/JMS

Legacy ccLegacy ccapplicationapplication

InvoiceInvoiceapplicationapplication

XML/JMS

ProcurementProcurement

SupplierSupplierFinanceFinance

InventoryInventory

JCAJCAconnectorconnector

InvoicingInvoicingserviceservice

Credit check Credit check serviceservice

Enterprise Service Bus


OrderOrderapplicationapplication

rPurchase OrderPurchase Orderserviceservice

ERPERP







SOAP/HTTP

XML/JMS

SOAP/JMS

Legacy ccLegacy ccapplicationapplication

InvoiceInvoiceapplicationapplication

XML/JMS

ProcurementProcurement

SupplierSupplierFinanceFinance

InventoryInventory

JCAJCAconnectorconnector

InvoicingInvoicingserviceservice

Credit check Credit check serviceservice

choice. Finally, this vendor uses an invoicing service tobill the customer.

The ESB distributed processing infrastructure isaware of applications and services and uses content-based routing facilities to make informed decisionsabout how to communicate with them. The services thatare part of the distributed procurement business processdepicted in Fig. 4 can be seen in use in Fig. 5. For thisexample, the inventory is assumed to be out of stock, andthe replenishment message is routed to a supplier orderservice. Although this figure shows only a single supplierorder service as part of the inventory, in reality a pleth-ora of supplier services may exist. The supplier orderservice, which executes a remote Web service at a cho-sen supplier to fulfil the order, generates its output in anXML message format that is not understood by the pur-chase order service. To avoid heterogeneity problems,the message from the supplier order service leveragesthe ESB’s transformation service to convert the XMLinto a format that is acceptable by the purchase orderservice. Fig. 5 also shows that JCA is used within theESB to allow legacy applications, such as credit checkservice, to be placed onto the ESB through JCA resourceadapters.

Once services that are part of the distributed pro-curement business process depicted in Fig. 4 have beenchained together, it is essential to provide a way to man-age and reconfigure them to react to changes in busi-ness processes. Ideally, this could be achieved througha sophisticated graphical business process managementtool that can be used to configure, deploy, and manage

services and endpoints. This allows the free movementand reconfiguration of services without requiring re-writing or modifying the services themselves.

3.2 Key capabilities

In order to implement an SOA, both applications andinfrastructure must support SOA principles (see Sect. 1).Enabling an application for SOA involves the creationof service interfaces to existing or new functions, eitherdirectly or through the use of adaptors. Enabling theinfrastructure, at the most basic level, involves provisionof the capabilities to route and deliver service requeststo the correct service provider. However, it is also vitalthat the infrastructure supports safe substitution of oneservice implementation by another, without any effect tothe clients of that service. This requires not only that theservice interfaces be specified according to SOA princi-ples, but also that the infrastructure allows client codeto invoke services irrespectively of the service locationand the communication protocol involved. Such servicerouting and substitution are among the many capabil-ities of the ESB. Additional capabilities can be foundin the following list that describes detailed functionalrequirements for an ESB.

We consider the following ESB capabilities list to benecessary to support the functions of a useful and mean-ingful ESB. Some of the ESB functional requirementsdescribed in the list below have also been discussed byother authors such as ([23,27,47,79]).


− Leveraging existing assets Legacy applications aretechnically obsolete mission critical elements of anorganization’s infrastructure—as they form the coreof larger enterprise’s business processes—but aretoo frail to modify and too important to discard andthus must be reused. Strategically, the objective isto build a new architecture that will yield all thevalue hoped for, but tactically, legacy assets must beleveraged and integrated with modern technologiesand applications.

− Service communication capabilities A critical abilityof the ESB is to route service interactions through avariety of protocols, and to transform from one pro-tocol to another where necessary. Another impor-tant aspect of an ESB implementation is the capacityto support service messaging models consistent withthe SOA interfaces, as well as the ability of transmit-ting the required interaction context, such as secu-rity, transaction, or message correlation information.

− Dynamic connectivity capabilities Dynamic connec-tivity pertains to the ability to connect to Web ser-vices dynamically without using a separate staticAPI or proxy for each service. Most enterprise appli-cations today operate on a static connectivity mode,requiring some static piece of code for each service.Dynamic service connectivity is the key capabilityfor a successful ESB implementation. The dynamicconnectivity API is the same regardless of the ser-vice implementation protocol (Web services, JMS,EJB/RMI, etc.).

− Topic/content-based routing capabilities The ESBshould be equipped with routing mechanisms tofacilitate not only topic-based routing but also, moresophisticated, content-based routing. Topic-basedrouting assumes that messages can be grouped intofixed, topical classes, so that subscribers can expli-cate interest in a topic and as a consequence receivemessages associated with that topic [71]. Content-based routing on the other hand allows subscrip-tions on constraints of actual properties (attributes)of business events. The content of the message thusdetermines their routing to different endpoints inthe ESB infrastructure. For example, if a manu-facturer provides a wide variety of products to itscustomers, only some of which are made in-house,depending on the product ordered it might be nec-essary to direct the message to an external supplier,or route it to be processed by an internal warehousefulfilment service. In a typical application, a messageis routed by opening it up and applying a set of rulesto its content to determine the parties interested inits content. Content-based routing is often depen-dant on the message constructed in XML, and will

usually be built on top of Message Oriented Mid-dleware, or JMS based messaging. Such ESB capa-bilities could be based on emerging standard effortssuch as WS-Notification.WS-Notification defines a general, topic-based Webservice system for publish and subscribe interac-tions, which relies on the WS-Resource framework[43]. WS-Notification [44] is a family of related spec-ifications that define a standard Web servicesapproach to notification using a topic-based pub-lish/subscribe pattern. The WS-Notification speci-fication defines standard message exchanges to beimplemented by service providers that wish to par-ticipate in notifications and standard messageexchanges—allowing publication of messages fromentities that are not themselves service providers.It also allows expressing operational requirementsexpected of service providers and requesters thatparticipate in notifications. WS-Notification allowsnotification messages to be attached to WSDL Port-Types. The current WS-Notification specificationprovides support for both brokered as well as peer-to-peer publish/subscribe.

− Endpoint discovery with multiple quality of servicecapabilities The ESB should support the fundamen-tal SOA need to discover, locate, and bind to ser-vices. Increasingly these capabilities will be basedaround Web services standards such as WSDL,SOAP, UDDI, and WS-PolicyFramework. As manynetwork endpoints can implement the same servicecontract, the ESB should support service interac-tions with different values to the business. Severalscenarios make it desirable for the client to selectthe best endpoint at run-time, rather than hard-coding endpoints at build time. The ESB shouldtherefore be capable of supporting various quali-ties of service. Clients can query a Web service, suchas an organizational UDDI service, to discover thebest instance with which to interact based on QoSproperties. Ideally, these capabilities should be con-trolled by declarative policies associated with theservices involved using a policy standard such as theWS-PolicyFramework [9].

− Integration capabilities To support SOA in a heter-ogeneous environment, the ESB needs to integratewith a variety of systems that do not directly supportservice-style interactions. These may include legacysystems, packaged applications, COTS components,etc. When assessing the integration requirements forESB, several types or “styles” of integration mustbe considered. Due their importance ESB integra-tion styles are discussed in some detail later in thisarticle.


− Transformation capabilities The various compo-nents hooked into the ESB have their own expec-tations of messaging models and data formats, andthese might differ from other components. A majorsource of value in an ESB is that it shields any indi-vidual component from any knowledge of the imple-mentation details of any other component. The ESBtransformation services make it possible to ensurethat messages and data received by any componentis in the format it expects, thereby removing theburden to make changes. The ESB plays a majorrole in transformations between different, heterog-enous data and messaging models, whether betweenlegacy data formats (e.g., a COBOL/VSAM applica-tion, running on an OS/390 host) and XML, betweenbasic XML formats, and Web services messages, orbetween different XML formats (e.g., transformingan industry standard XML message to a proprietaryor custom XML format).

− Reliable messaging capabilities Reliable messag-ing refers to the ability to queue service requestmessages and ensure guaranteed delivery of thesemessages to the destination. It also includes theability to respond, if necessary, back to the requestorwith response messages. Reliable messaging sup-ports asynchronous store-and-forward delivery aswell as guaranteed delivery capabilities. Primarilyused for handling events, this capability is crucialfor responding to clients in an asynchronous man-ner, and for a successful ESB implementation.

− Security capabilities Generically handling andenforcing security is a key success factor for ESBimplementations. The ESB needs to both providea security model to service consumers and inte-grate with the (potentially varied) security modelsof service providers. Both point-to-point (e.g., SSLencryption) and end-to-end security capabilities willbe required. These end-to-end security capabilitiesinclude federated authentication, which interceptsservice requests and adds the appropriate usernameand credentials; validation of each service requestand authorization to make sure that the sender hasthe appropriate privilege to access the service; and,lastly, encryption/decryption of XML content at theelement level for both message requests and res-ponses. To address these intricate security require-ments trust models, WS-Security [8] and othersecurity related standards have been developed.

− Long running process and transaction capabilitiesService-orientation, as opposed to distributed objectarchitectures such as .NET or J2EE, make it possi-ble to more closely reflect real-world processes andrelationships. It is believed that SOA represents a

much more natural way to model and build softwarethat solves real-world business processing needs [7].Accordingly, the ESB should provide the ability tosupport business processes and long running ser-vices—services that tend to run for long duration,exchanging message (conversation) as they progress.Typical examples are an online reservation system,which interacts with the user as well as variousservice providers (airline ticketing, car reservation,hotel reservation, etc.).In addition, it is of vital importance that the ESBprovides certain transactional guarantees. More spe-cifically, the ESB needs to be able to provide a meansfor various applications to interact and message witheach other and to recover should some form of tech-nical or process failure occur. The challenge at handis to ensure that complex transactions are handled ina highly reliable manner and if failure should occur,transactions should be capable of rolling back pro-cessing to the original, pre-request state.

− Management and monitoring capabilities In an SOAenvironment, applications cross system (and evenorganizational) boundaries, they overlap, and theycan change over time. Managing these applicationsis a serious challenge [6]. Examples include dynamicload balancing, fail-over when primary systems godown, and achieving topological or geographic affin-ity between the client and the service instance, andso on. Effective systems and application manage-ment in an ESB require a management frameworkthat is consistent across an increasingly heteroge-neous set of participating component systems, whilesupporting complex aggregate (cross-component)management use cases, like dynamic resource pro-visioning and demand-based routing, service-levelagreement enforcement in conjunction with policy-based behavior. The latter implies the ability toselect service providers dynamically based on thequality of service they offer compared to the busi-ness value of individual transactions.An additional requirement for a successful ESBimplementation is the ability to monitor the health,capacity, and performance of services. Monitoring isthe ability to track service activities that take placevia the bus and accommodate visibility into variousmetrics and statistics. Of particular significance isthe ability to be able to spot problems and excep-tions in the business processes and move towardresolving them as soon as they occur. Process moni-toring capabilities are currently provided by toolsetsin platforms for developing, deploying and manag-ing service applications, such as, for instance, Web-Logic Workshop.


− Scalability capabilities With a widely distributedSOA, there will be the need to scale some of the ser-vices or the entire infrastructure to meet integrationdemands. For example, transformation services aretypically very resource intensive and may requiremultiple instances across two or more computingnodes. At the same time, it is necessary to createan infrastructure that can support the large nodespresent in a global service network. The loose cou-pled nature of an SOA requires that the ESB uses adecentralized model to provide a cost effective solu-tion that promotes flexibility in scaling any aspect ofthe integration network. A decentralized architec-ture enables independent scalability of individualservices as well as the communications infrastruc-ture itself.

As ESB integration capabilities in the above list arecentral in understanding the material that follows anda key element of the ESB when performing service-oriented integration, we shall consider them in somedetail in the remainder of this section.

3.3 Integration solutions

ESBs employ a service-oriented integration solutionthat leverages among other issues open standards, loosecoupling, and the dynamic description and discoverycapabilities of Web services to reduce the complexity,cost, and risk of integration. Other salient characteris-tics of the ESB architectural integration style are thatit is technology agnostic and can reuse functionality inexisting applications to support new application devel-opment. There is a series of important technical require-ments that need to be addressed by a service-orientedintegration solution ([47,52]). These include:

Integration at the presentation-tier Integration at thepresentation-tier is concerned with how the completeset of applications and services a given user accessesare fabricating a highly distributed yet unified portalframework that provides a usable, efficient, uniform,and consistent presentation-tier. In this way, the ESBcan provide one face to the users resulting in consis-tent user experience, with unified information deliverywhile allowing underlying applications remain distrib-uted. Two complementary industry standards that areemerging in the portal space can assist with these efforts[57]:

1. JSR 168 This is an industry standard that defines astandard way to develop portlets. It allows portletsto be interoperable across portal vendors. For exam-

ple, portlets developed for BEA WebLogic Portalcan be interoperable with IBM Portal. This allowsorganizations to have a lower dependency on theportal product vendor.

2. WSRP (Web Service for Remote Portals) This isan industry standard that allows remote portlets tobe developed and consumed in a standard mannerand facilitates federated portals. WSRP combinesthe power of Web services and portal technologiesand is fast becoming the major enabling technologyfor distributed portals in an enterprise.

JSR 168 complements WSRP by dealing with localrather than distributed portlets. A portal page may havecertain local portlets which are JSR 168 compliant andsome remote, distributed portlets that are executed ina remote container. With JSR 168 and WSRP matur-ing, the possibility of a true ESB federated portal canbecome a reality.

Application connectivity Application connectivity isan integration style concerned with all types of con-nectivity that the ESB integration layer must support.At the infrastructure level, this means concerns such assynchronous and asynchronous communications, rout-ing, transformation, high speed distribution of data, andgateways and protocol converters. On the processinglevel, application connectivity also relates to the visual-ization of input and output, or sources and sinks.

Visualization signifies the fact that input is receivedand passed to applications in the ESB in a source-neutral way. Special purpose front-end device andprotocol handlers should make that possible. For con-nectivity, an ESB can utilize J2EE components such asthe Java Message Service for MOM connectivity, andJ2EE Connector Architecture for connecting to appli-cation adapters. An ESB can also integrate easily withapplications built with .NET, COM, C#, C++ and C. Inaddition, an ESB can integrate easily with any applica-tion that supports SOAP and Web services.

Application integration Application integration isconcerned with building and evolving an integrationbackbone capability that enables fast assembly and dis-assembly of business software components. Applicationintegration is an integral part of the assembly processthat facilitates strategies which combine legacy appli-cations, acquired packages, external application sub-scriptions and newly built components. The ESB shouldfocus on a service-based application integration stylethat enables better-structured integration solutions thatdeliver:

− Applications comprised interchangeable parts thatare designed to be adaptable to business and tech-nology change.


− Evolutionary application portfolios that protectinvestment and can respond rapidly to new require-ments and business processes

− Integration of various platform and componenttechnologies.

Process integration Process integration is concernedwith the development of automated processes that mapto and provide solutions for business processes, inte-gration of existing applications into business processes,and integrating processes with other processes. Process-level integration at the level of ESB generally includesthe integration of business processes and applicationswithin the enterprise (viz. EAI solutions). It may alsoinvolve the integration of whole processes, not simplyindividual services, from external sources, such as supplychain management or financial services that span multi-ple institutions (viz. e-Business integration solutions).

Data integration Information integration [76] is theprocess of providing a consistent access to all the data inthe enterprise, by all the applications that require it, inwhatever form they need it, without being restricted bythe format, source, or location of the data. This require-ment, when implemented, might involve adapters andtransformation facilities, aggregation services to mergeand reconcile disparate data, e.g., merging two customerprofiles, and validation to ensure data consistency, e.g.,minimum income should be equal to or exceed a certainthreshold. Data should be transformed irrespectively ofthe formats under which they exist, the operating systemthat manages the data, and the location where the dataare stored.

Integration design and development methodologyOne of the requirements for the application develop-ment environment must be that it takes into accountall the styles and levels of integration that could beimplemented within the enterprise, and provide for theirdevelopment and deployment. To be truly robust, thedevelopment environment must rely on a methodologythat clearly prescribes how services and components aredesigned and built in order to facilitate reuse, eliminateredundancy, and simplify integration, testing, deploy-ment, and maintenance.

All of the styles of integration listed above will havesome form of incarnation within any enterprise, eventhough in some cases they might be simplified or notclearly defined. It is important to note that all integra-tion styles must be considered when embarking on anESB implementation.

3.4 Enabling technologies

In this section, we will review the technological under-pinnings of ESBs in some more detail. Fundamentally,

ESBs fuse the following four types of technologies: inte-gration brokers, application servers, business processmanagement, and adapters.

3.4.1 Integration brokers

A prominent technology to interconnect disparate busi-ness applications, many of which are home-grown, ERPsystems or legacy systems, constitutes integration bro-kers. Integration brokers come in many manifestations,ranging from early application-to-application brokers tomore sophisticated broker topologies managing transac-tions, security, (resource) adapters and application pro-tocols [22]. Some examples of commercially availableintegration brokers include IBM’s WebSphere Integra-tion Broker, PeopleSoft’s AppConnect, and Sun ONEIntegration Server.

Figure 6 presents a high-level view of the typical archi-tecture for implementing integration broker. In particu-lar, this figure illustrates the use of an integration brokerto integrate functions and information from a variety ofback-end EIS. To effectively illustrate the workings ofthe integration broker, we use the simplified distributedprocurement process shown in Fig. 4. Figure 6 exempli-fies that when an automated inventory system triggersa replenishment signal, an automated procurement pro-cess flow is triggered and first the enterprise’s supplierreference database is queried to determine the list ofpossible suppliers, who could be prioritized on the basisof existing contracts and supplier metrics. A supplier isthen chosen based and the purchase order is automat-ically generated in the ERP purchasing module and issent to the vendor of choice.

The figure illustrates that the integration-broker is thesystem centrepiece. The integration-broker facilitatesinformation movement between two or more resources(source and target applications, indicated by solid lines)in Fig. 6, and accounts for differences in applicationsemantics and heterogeneous platforms. The variousexisting (or component) EIS, such as customer relation-ship management, ERP systems, transaction processingmonitors, legacy systems, and so on, in this configura-tion are connected to the integration broker by meansof resource adapters. This is indicated by the presence ofdotted lines in Fig. 6. A resource adapter is used to pro-vide access to a specific EIS. The purpose of the adaptersis to provide a reliable insulation layer between appli-cation APIs and the messaging infrastructure. Theseadapters enable non-invasive application integration ina loosely coupled configuration.

Integration brokers are able to share informationwith a multitude of systems by using an asynchronous,event-driven mechanism thus they constitute an ideal


Fig. 6 Integration broker integrating disparate back-end systems

support framework for asynchronous business processes.Integration brokers, as realized in enterprise applica-tion integration suites, have historically been used forthe integration of packaged applications via specific andoften heavily customized adapters. Nowadays, this typeof middleware is responsible for brokering messagesexchanged between multiple applications, providing theability to transform, store, and route messages, also theability to apply business rules and respond to events.

The integration broker architecture presents severaladvantages as it tries to reduce the application integra-tion effort by providing pre-built functionality commonto many integration scenarios. The value propositionrests on reuse (in terms of middleware infrastructureand the application integration logic) across multipleapplications and initiatives. Modern integration brokersincorporate integration functionality such as transfor-mation facilities, process integration, business processmanagement and trading partner management function-ality, packaged adapters, and user-driven applicationsthrough front-end capabilities such as Java Server Pages(JSP).

3.4.2 Application servers

Application servers are widely used to develop anddeploy back-end server logic. Application servers enablethe separation of application (or business) logic andinterface processing and also coordinate many resource

connections. The most prominent features of applicationservers include secure transactional execution environ-ment, load balancing, application-level clustering acrossmultiple servers, failover management should one ofthese servers break down [61]. In addition, applicationservers provide application connectivity and thus accessto data and functions associated with EIS applications,such as ERP, CRM, and legacy applications. While appli-cation servers are focused on supporting new applicationdevelopment, they do not natively support integration.

Application servers, such as SUN’s J2EE [85], IBM’sWebSphere [40], and Microsoft’s .NET [62], typicallyprovide Web connectivity for extending existing solu-tions and bring transaction processing mechanisms tothe Web. In essence, an application server is simply acollection of services that support the development, run-time execution, and management of business logic forWeb-enabled applications. The application server mid-dleware enables the functions of handling transactionsand extending back-end business data and applicationsto the Web. Application servers retrieve informationfrom many existing enterprise systems and expose themthrough a single interface, typically a Web browser. Thismakes application servers ideal for portal-based EAIdevelopment. Unlike integration brokers, they do notintegrate back-end systems directly.

Because application servers were created forWeb-based transactions and application developmentand because of their ability to provide component-based integration to back-end applications, they are


Fig. 7 Application serverproviding access to back-endsystems

particularly useful as support framework for integrat-ing business processes.

Figure 7 illustrates the use of an application server fora wholesale application that brings together ERP capa-bilities with sophisticated customer interfaces to openup new models of sales and distribution. The compo-nent wrappers in this figure facilitate point-integrationof component systems, e.g., ERP, CRM, and distributordatabases, as they introduce each of them to the appli-cation server. A component wrapper may be definedas a software layer that encapsulates legacy data andlogic and defines its services in the wrapper API. Thewrapper API mediates between calls from client appli-cation components to the underlying legacy code anddata, by transforming incoming requests into a messageformat that is understandable to the internal code anddata [83,97].

The terms “adapter” and “wrapper” are often usedinterchangeably, as we will also do throughout this arti-cle. Another term that is often adopted in the samecontext of that of wrappers, is the term “connector”. Aconnector refers to the encapsulation of a communica-tion mechanism. This term originates from architecturaldescription languages (ADLs), while the design patternwhich is concerned with the encapsulation of the com-munication between components is called “Mediator”[20]. The prime distinction between a connector andan adapter is that an adapter bridges an interoperability

problem, i.e., without the adapter the components wouldnot be able to work together, while a connector enablesthe communication between two interoperable compo-nents [95].

Simply speaking, a component wrapper contains asoftware layer that encapsulates legacy data and logicand defines its services in the wrapper API. The wrap-per API mediates between calls from client applicationcomponents to the underlying legacy code and data, bytransforming incoming requests into a message formatthat is understandable to the internal code and data.

Execution in this type of architecture occurs amongcomponent wrappers within the application server.These component wrappers wrap back-end resourcessuch as databases, ERP, transaction mainframe systemsand legacy systems so that they can express data andmessages in the standard internal format expected bythe application server. The application server is oblivi-ous to the fact that these components are only the exter-nal facade of existing EIS that do the real processingactivities [63].

The adapter/component wrapper pairs in the archi-tecture illustrated in Fig. 7 are responsible for providinga layer of abstraction between the application server andthe component EIS. This layer allows for EIS compo-nent communications, as if the component EIS were exe-cuted within the application server environment itself.Traditional application servers constitute an ideal


support framework for synchronous business processes.However, newer generation application servers offeralso asynchronous communication.

Web application servers already provide databaseconnectivity, transaction management, EAI-style con-nectors, message queuing, and are gradually evolvinginto business process execution engines. They also facil-itate reliability, scalability, and availability, while at thesame time automating application development tasks.

In concluding, a few words about application serverimplementation. Application servers are principallyJ2EE-based and include support for JMS [45], the Java2 Connector Architecture (J2CA) [50], and even Webservices.

JMS is a transport-level API that enterprises can com-bine with Web service solutions for messaging, data per-sistence, and access to Java-based applications. JMS is avendor agnostic API for enterprise messaging that canbe used with many different MOM vendors. JMS frame-works function in asynchronous mode but also offer thecapability of simulating a synchronous request/responsemode [70]. For application server implementations, JMSprovides access to business logic distributed among het-erogeneous systems. Having a message-based interfaceenables point to point and publish/subscribe mecha-nisms, guaranteed information delivery, and interoper-ability between heterogeneous platforms.

J2EE Connector Architecture is an emerging tech-nology that has been specifically designed to addressthe hardships of integrating applications. J2CA providesa standardized method for integrating disparate appli-cations in J2EE application architectures. It providessupport for resource adaptation, which maps the J2EEsecurity, transaction, and communication pooling to thecorresponding EIS technology. J2CA defines a set offunctionality that application server vendors can use toconnect to back-end EIS, such as ERP, CRM, and legacysystems and applications. Using J2CA to access EIS isakin to using JDBC (Java Database Connectivity) [101]to access a database. When J2CA is used in an ESBimplementation, the ESB could provide a J2CA con-tainer that allows packaged or legacy applications to beplugged into the ESB through J2CA resource adapters.For instance, a process order service uses JCA to talkto a J2EE application that internally fulfils incomingorders. The latest versions of many application serv-ers, including BEA WebLogic and IBM WebSphere,support J2CA adapters for enterprise connectivity. Inaddition, major packaged application vendors have alsoannounced plans to support JCA in future product offer-ings. The ESB uses J2CA to facilitate application inte-gration between existing applications and services.

3.4.3 Business process management

Today enterprises are striving to become electronicallyconnected to their customers, suppliers, and partners.To achieve this, they are integrating a wide range ofdiscrete business processes across application bound-aries of all kinds. Application boundaries may rangefrom simple enquiries about a customer’s order involv-ing two applications, to complex, long-lived transac-tions for processing an insurance claim involving manyapplications and human interactions, to parallel businessevents for advanced planning, production and shippingof goods along the supply chain involving many applica-tions, human interactions and business to business inter-actions. When integrating on such a scale, enterprisesneed a greater latitude of functionality to overcome mul-tiple challenges arising from the existence of proprietaryinterfaces, diverse standards, and approaches targetingthe technical, data, automated business process, processanalysis, and visualization levels. Such challenges areaddressed by the business process management (BPM)technology [96]. BPM is the term used to describe thenew generation of technology that provides end-to-endvisibility and control over all parts of a long-lived, multi-step information request or transaction/process thatspans multiple applications and human actors in oneor more enterprises [60].

Specialized capabilities of BPM software solutions inan ESB setting include workflow-related business pro-cesses, process analysis, and visualization techniques. Inparticular, BPM allows the separation of business pro-cesses from the underlying integration code. Before weexplain further characteristics and typical elements ofBPM, it is useful to distinguish between the concepts ofprocess automation, workflow, and business processesmanagement.

All enterprises have business processes that requireprocess automation. Any process automation toolshould be able to easily control and coordinate activityand provide an easy method to define the business pro-cess and the underlying flows of information betweenapplications. Process automation is distinct from tra-ditional document workflow as it involves integrationbetween computer-based systems and manual steps andtasks. It is implemented for automating the flow of infor-mation between applications to fulfil business processes.Traditional workflow tools focus instead on handlingthe movement of documents between people who arerequired to perform tasks on these documents [59]. Thismay or may not be directly associated with managinga business process. For example, an order may gener-ate a shipping notice. The shipping notice may in turn


generate a monthly invoice that encompasses manyorders for the same customer. This is an example ofa workflow that changes focus several times. It is nottracking the order to completion, but rather, it tracksonly the information generated.

A business process includes both automated and man-ual processes. Business process automation combinesprocess automation together with task-based workflowinto a managed, end-to-end process [59].

Business Process Management codifies value-drivenprocesses and institutionalizes their execution within theenterprise [80]. This implies that BPM tools, such asChordiant,1 Pega 2 and Fuego,3 can help analyze, define,and enforce process standardization. BPM provides amodeling tool to visually construct, analyze, and executecross-functional business processes. Design and mod-eling of business processes is accomplished by meansof sophisticated graphical tools. In the previous exam-ple, BPM would enable the modeling of the broaderorder management process encompassing order receipt,perhaps credit approval, shipping and invoicing. Com-bining BPM with real-time analysis allows business man-agers to not only track where orders are in this process,but also to understand the company’s exposure withregard to orders in total at any given point in time.

Business Process Management is a commitment toexpressing, understanding, representing and managing abusiness (or the portion of business to which it is applied)in terms of a collection of business processes that areresponsive to a business environment of internal orexternal events [67]. The term management of businessprocesses includes process analysis, process definitionand redefinition, resource allocation, scheduling, mea-surement of process quality and efficiency, and processoptimization. Process optimization includes collectionand analysis of both real-time measures (monitoring)and strategic measures (performance management), andtheir correlation as the basis for process improvementand innovation.

Business Process Management is driven primarily bythe common desire to integrate supply chains, as well asinternal enterprise functions, without the need for evenmore custom software development. This means thatthe tools must be suitable for business analysts, requir-ing less (or no) software development. They must reducemaintenance requirements because internally and exter-nally integrated environments routinely require addi-tions and changes to business processes. BPM promisesthe ability to monitor both the state of any single

1 www.chordiant.com.2 www.pega.com.3 www.fuego.com.

process instance and all instances in the aggregate, usingpresent real-time metrics that translate actual processactivity into key performance indicators.

When sophisticated process definitions are called forin an ESB, a process orchestration engine—that sup-ports BPEL [6] or some other process definition lan-guage such as ebXML Business Process SpecificationSchema (BPSS) [21]—may be layered onto the ESB. Theprocess orchestration may support long-running, state-ful processes, just like BPEL. In addition, it may supportparallel execution paths, with branching, and mergingof message flow execution paths based on join condi-tions or transition conditions being met. Sophisticatedprocess orchestration can be combined with stateless,itinerary-based routing to create an SOA that solvescomplex integration problems. An ESB uses the con-cept of itinerary-based routing to provide a messagewith a list of routing instructions. In an ESB, routinginstructions, which represent a business process defini-tion, are carried with the message as it travels throughthe bus across service invocations. The remote ESB ser-vice containers determine where to send the messagenext, making this type of routing a special category ofcontent-based routing.

The ESB can also benefit from products developedby BPM vendors such as IBM’s WebSphere, HP’s HPProcess Manager, BEA’s WebLogic, and Vitria’s Busi-nessWare. Microsoft BizTalk is another good exampleof a BPM integration product, but its use is limitedto Microsoft Windows and .NET servers. CommercialBPM solutions such as, for instance, Vitria’s Business-Ware-4 provide organizations with a number of mecha-nisms for simplifying the deployment and managementof an integration solution. They consist of range of toolsand technologies that allow the organization to model,test, deploy, and refine such a process-driven integrationsolution.

3.5 Adapters

For the most part, business applications in an enterpriseare not designed to communicate with other applica-tions. There is often an interoperability mismatchbetween the technologies used within internal systemsand with external trading partner systems. In order toseamlessly integrate these disparate applications, theremust be a way in which a request for information in oneformat can easily be transformed into a format expectedby the called service. For instance, in Fig. 3 the func-tionality of a J2EE application needs to be exposed tonon-J2EE clients such as .NET applications and otherclients. In doing so, a Web service may have to inte-grate with other instances of EIS in an organization,


Fig. 8 Combining Webservices with resourceadapters

or the J2EE application itself may have to integratewith other EISs. In such scenarios, how the applicationexchanges information to the ESB depends on the appli-cation accessibility options. There are three alternativeways an application can exchange information with theESB include [52]:

1. Application-provided Web service interface Someapplications and legacy application servers haveadopted the open standards philosophy and haveincluded a Web services interface. The WSDLdefines the interface to communicate directly withthe application business logic. Where possible, tak-ing a direct approach is always preferred.

2. Non-Web service interface The application does notexpose business logic via Web services. An appli-cation-specific adapter can be supplied to providea basic intermediary between the application APIand the ESB.

3. Service wrapper as interface to adapter In somecases the adapter may not supply the correct pro-tocol (JMS, for example) that the ESB expects. Inthis case, the adapter would be Web service enabled.

Adapters provide connectivity, semantic disambigu-ation and translation services between applications andcollaborations [84]. An adapter provides servicesbetween the integration broker and the application-specific component, such as an ERP or CRM application.Resource adaptors translate the applications’ messages

to and from a common set of standards—standard dataformats and standard communication protocols. Whenan application sends a message to another application,its adapter first translates the message into a standard-ized form. When the message is received by the targetapplication, another adapter translates the standardizedmessage into the target application’s native format andprotocol.

An adapter can expose either a synchronous andasynchronous mode of communication between the cli-ent application and the EIS. The adapter provides avariety of transformation services including support forcomplex data structures from one data source to another,for example, between COBOL copybooks and XML,complex XML-to-XML vocabularies, IDL, ODL, leg-acy, database systems, and so on. Messages are first trans-formed into an intermediate state (IDL, XML, or JavaInterfaces) before being formatted. An adapter typi-cally provides support for a range of date/time conver-sion functions, EBCDIC/ASCI, binary and characterconversion functions, EDI (via EDI module), and anumber of functions for splitting/combining data fields.Furthermore, it can incorporate a native XML parserand provides support for popular e-Commerce tradingprotocols such as RosettaNet [104], ebXML [38],cXML,4 and xCBL.5

4 http://www.cxml.org.5 http://eco.commerce.net.


Fig. 9 Extended SOA

CompositionComposition

Description & Basic Operations


Mana-gementgement

•Capability•Interface•Behavior•QoS

•Coordination•Conformance•Monitoring•Semantics

•Publication•Discovery•Selection•Binding

Service provider

Service client

performs

publishes

uses

Role actions

becomes

Operations•Assurance•Support

Market•Certification•Rating•SLAs

Service operator

Market maker

Managed services

Composite services

Basic services

Service aggregator

CompositionComposition



Mana-gementgement

•Capability•Interface•Behavior•QoS

•Coordination•Conformance•Monitoring•Semantics

•Publication•Discovery•Selection•Binding

Service provider

Service client

performs

publishes

uses

Role actions

becomes

Operations•Assurance•Support

Market•Certification•Rating•SLAs

Service operator

Market maker

Managed services

Composite services

Basic services

Service aggregator

As complementary technologies in an ESB imple-mentation, (resource) adapters and Web services canwork together to implement complex integration sce-narios involving federated ESBs spanning multiple orga-nizations, see Fig. 8. Data synchronization (in additionto translation services) is one of the primary objectivesof resource adapters. Adapters can thus take on therole of data synchronization and translation services,whereas Web services will enable application functionsto interact with each other. Web services are an idealmechanism for implementing a universally accessibleapplication function (service) that may need to integratewith other applications to fulfil its service contract. Thedrivers of data synchronization and Web services arealso different. Web services will generally be initiatedby a user request/event, whereas data synchronizationis generally initiated by state changes in data objects (forexample, customer, item, order, and so on).

An event to which a Web service reacts could be a userinitiated request such as a purchase order or an onlinebill payment, for example. User events can naturally begenerated by applications such as an order managementapplication requiring a customer status check from anaccounting system. On the other hand, a state change ina data object can be an activity like the addition of a newcustomer record in the customer service application oran update to the customer’s billing address. These statechanges trigger an adapter to add the new customerrecord or update the customer record in all other appli-cations that keep their own copies of customer data.

Routing of events from service requester to serviceproviders may basically occur in two ways, using content-

based or topic (subject)-based routing (see Sect. 3.4.1).Both routing mechanisms run on top of elementaryInternet-technologies for routing, e.g., DNS routing.Currently, routing of events is standardized in WS-Noti-fication.

Reverting to the J2EE to .NET application connec-tivity scenario, a connectivity service in the form of aresource adapter is required. In this implementationstrategy, Web services can become the interface betweenthe company and its customers, partners, and suppli-ers; whereas the resource adapters become integrationcomponents tying up different EISs inside the company.This is just one potential implementation pattern inwhich Web services and resource adapters can coexist.Another potential integration pattern in which Web ser-vices and resource adapters are required to collaborateis in business process integration. Applications that arepart of a specific business process will have to exposethe required processes (functions), and Web servicesare ideal for that purpose. When the applications needto integrate with other EISs to fulfil their part in thebusiness process, they will use resource adapters.

4 Extending the SOA

A basic SOA, i.e., the architecture depicted in Fig. 2,implements concepts such as service registration, dis-covery, load balancing of service requests. The essentialESB requirements, however, suggest that this approachbe extended to support capabilities such as service


orchestration, “intelligent” routing, provisioning, andservice management. It should also guarantee the integ-rity of data and security of messages. Such overarchingconcerns are addressed by the extended SOA (xSOA)[73,75]. The xSOA is an attempt to streamline, grouptogether and logically structure the functional require-ments of complex applications that make use of theservice-oriented computing paradigm. The xSOA is astratified service-based architecture. The architecturallayers in the xSOA, which are depicted in Fig. 9, embracea multi-dimensional, separation of concerns [72] in sucha way that each layer defines a set of constructs, roles,and responsibilities and leans on constructs of its prede-cessor layer to accomplish its mission. The logical sepa-ration of functionality is based on the need to separatebasic service capabilities provided by the conventionalSOA (for example, building simple applications) frommore advanced service functionality needed for com-posing services and the need to distinguish betweenthe functionality for composing services from that ofthe management of services. As shown in Fig. 9, thexSOA utilizes the basic SOA constructs as its founda-tional layer and layers service composition and man-agement on top of it. The ESB middleware capabilitiessuch as communication, routing, translation, discovery,and so on, fall squarely within the xSOA foundationlayer. ESB capabilities that deal with service composi-tion and management can be found in the compositionand management layers of the xSOA. However, theselayers include more advanced functionality than thatfound in ESB settings.

The bottom layer in the xSOA is identical to the basicSOA (see Fig. 2) in that it defines an interaction betweensoftware agents as an exchange of messages betweenservice requesters (clients) and service providers. Theseinteractions involve the publishing, finding and bindingof operations.

In a typical service-based scenario employing thebasic services layer in the xSOA, a service provider hostsa network accessible software module. The service pro-vider defines a service description, and publishes it toa client (or service discovery agency) through which aservice description is advertised and made discoverable.The service client (requestor) discovers a service (end-point) and retrieves the service description directly fromthe service (Metadata Exchange) or from a registry orrepository like UDDI; it uses the service description tobind with the service provider and invoke the service orinteract with the service implementation. Service pro-vider and service client roles are logical constructs and aservice may exhibit characteristics of both. For reasonsof conceptual simplicity in Fig. 9, we assume that serviceclients, providers and aggregators could act as service

brokers or service discovery agencies and publish theservices they deploy. The role actions in this figure alsoindicate that a service aggregator entails a special typeof provider.

The service composition layer in the xSOA encom-passes necessary roles and functionality for the aggrega-tion of multiple services into a single composite service.Resulting composite services may be used by serviceaggregators as basic services in further service compo-sitions or may be utilized as applications/solutions byservice clients. Service aggregators thus become serviceproviders by publishing the service descriptions of thecomposite service they create. As already explained inSect. 2, a service aggregator is a service provider thatgroups services that are provided by other service pro-viders into a distinct value added service. Service aggre-gators develop specifications and/or code that permit thecomposite service to perform functions that are basedon the following facilities (in addition to Web servicesinteroperation support provided by WSI profiles for ser-vice descriptions [10] and security [11]):

− Meta-data, standard terminology and referencemodels Web services need to use meta-data todescribe what other endpoints need to know tointeract with them. Metadata describing a servicetypically contain descriptions of the interfaces ofa service—the kinds of data entities expected andthe names of the operations supported—such itemsas vendor identifier, narrative description of theservice, Internet address for messages, format ofrequest and response messages, and may also containchoreographic descriptions of the order of inter-actions. Such descriptions may range from simpleidentifiers implying a mutually understood proto-col to a complete description of the vocabularies,expected behaviors, and so on. Such meta-data givehigh-level semantic details regarding the structureand contents of the messages received and sent byWeb services, message operations, concrete networkprotocols, and endpoint addresses used by Web ser-vices; it also describes abstractly the capabilities,requirements, and general characteristics of Webservices and how they can interoperate with otherservices. Web service meta-data need to be accom-panied with standard terminology to address busi-ness terminology fluctuations and reference modelssuch as, for instance, RosettaNet PIPS [104], to allowapplications to define data and processes that aremeaningful not only to their own businesses but alsoto their business partners while also maintaininginteroperability (at the semantic level) with other


business applications. The purpose of combiningmeta-data, standard terminology and referencemodels is to enable business processes to captureand convey their intended meaning and exchangerequirements, identifying among other things themeaning, timing, sequence and purpose of each busi-ness collaboration and associated informationexchange.

− Conformance Service conformance ensures theintegrity of a composite service by matching its oper-ations and parameter types with those of its con-stituent component services, imposes constraints onthe component services (e.g., to ensure enforcementof business rules), and performs data fusion activ-ities. Service conformance comprises three parts:typing, behavioral, and semantic conformance. Typ-ing (syntactic) conformance is performed at the datatyping level by using principles such as type-safe-ness, co-variance and contra-variance for signaturematching [95]. Behavioral conformance ensures thecorrectness of logical relationships between com-ponent operations that need to be blended togetherinto higher-level operations. Behavioral confor-mance guarantees that composite operations do notlead to spurious results and that the overall pro-cess behaves in a correct and unambiguous manner.Finally, semantic conformance ensures that servicesand operations are annotated with domain-specificsemantic properties (descriptions) so that they pre-serve their meaning when they are composed andcan be formally validated. Service conformance is atopic still under research scrutiny ([95]). Concretesolutions exist only for typing conformance [24,68]as they are based on conformance techniques forprograming languages such as Eiffel or Java.

− Coordination Controls the execution of the com-ponent services (processes), Web services transac-tions, and manages dataflow as well as control flowamong them and to the output of the componentservice (e.g., by specifying workflow processes andusing a workflow engine for run-time control of ser-vice execution).

− Monitoring Allows monitoring events or informa-tion produced by the component services, monitor-ing instances of business processes, viewing processinstance statistics, including the number of instancesin each state (running, suspended, aborted, or com-pleted), viewing the status, or summary for selectedprocess instances, suspend, and resume or termi-nate selected process instances. Of particular sig-nificance is the ability to be able to spot problemsand exceptions in the business processes and movetoward resolving them as soon as they occur. Process

monitoring capabilities are currently provided bytoolsets in platforms for developing, deploying, andmanaging service applications, such as, for instance,BEA’s WebLogic and Vitria’s BusinessWare.

− Policy enforcement Web service capabilities andrequirements can be expressed in terms of policies.In particular, policies [88] may be applied to man-age a system or organize the interaction betweenWeb-services [1]. For example, knowing that a ser-vice supports a Web services security standard suchas WS-Security is not enough information to enablesuccessful composition. The client needs to knowif the service actually requires WS-Security, whatkind of security tokens it is capable of processing,and which one it prefers. The client must also deter-mine if the service requires signed messages. Andif so, it must determine what token type must beused for the digital signatures. And finally, the cli-ent must determine when to encrypt the messages,which algorithm to use, and how to exchange ashared key with the service. Trying to orchestratewith a service without understanding these detailsmay lead to erroneous results.

Standards such BPEL and WS-Choreography [19]that operate at the service composition layer in xSOAenable the creation of large service collaborations thatgo far beyond allowing two companies to conduct busi-ness in an automated fashion. We also expect to seemuch larger service collaborations spanning entireindustry groups and other complex business relation-ships. These developments necessitate the use of toolsand utilities that provide them insights into the health ofsystems that implement Web services and into the statusand behavior patterns of loosely coupled applications.A consistent management methodology is essential forleveraging a management framework for a production-quality, service-based infrastructure, and applications.The rationale is very similar to the situation in tradi-tional distributed computing environments, where sys-tems administrators rely on programs/tools/utilities tomake certain that a distributed computing environmentoperates reliably and efficiently.

Managing loosely coupled applications in an SOAinherently entails even more challenging requirements.Failure or change of a single application component canbring down numerous interdependent enterprise appli-cations. The addition of new applications or componentscan overload existing components, causing unexpecteddegradation or failure of seemingly unrelated systems.Application performance depends on the combined per-formance of cooperating components and their


interactions. To counter such situations, enterprises needto constantly monitor the health of their applications.The performance should be in tune, at all times andunder all load conditions.

Managing critical Web service based applicationsrequires in-depth administration and managementcapabilities that are consistent across an increasinglyheterogeneous set of participating distributed compo-nent systems, while supporting complex aggregate(cross-component) management use cases, like service-level agreement enforcement and dynamic resource pro-visioning. Such capabilities are provided by the topmostlayer in the xSOA.

We could define Web services management as thefunctionality required for discovering the existence,availability, performance, health, patterns of usage,extensibility, as well as the control and configuration,life-cycle support and maintenance of a Web service orbusiness process within the context of SOAs. Servicemanagement encompasses the control and monitoringof SOA-based applications throughout their life cycle[58]. It spans a range of activities from installation andconfiguration to collecting metrics and tuning to ensureresponsive service execution. The management layer inxSOA requires that a critical characteristic be realized:that services be managed. In fact, the very same well-defined structures and standards that form the basis forWeb services also provide opportunities for use in man-aging and monitoring communications between services,and their underlying resources, across numerous ven-dors, platforms, technologies, and topologies.

Service management includes many interrelated func-tions [26]. The most prominent functions of service man-agement are summarized in the following:

1. Service-level agreement (SLA) management. Thismay include QoS (e.g., sustainable network band-width with priority messaging service) [46]; servicereporting (e.g., acceptable system response time);and service metering.

2. Auditing, monitoring, and troubleshooting. Thismay include providing service performance and uti-lization statistics, measurement of transactionarrival rates and response times, measurement oftransaction loads (number of bytes per incomingand outgoing transaction), load balancing acrossservers, measuring the health of services and trou-bleshooting.

3. Dynamic services (or resources) provisioning. Thismay include provisioning services and resources toauthorized personnel, dynamic allocation/dealloca-tion of hardware, installation/deinstallation of soft-ware “on demand” based changing workloads,

ensuring SLAs, management policies for messagingrouting and security, and reliable SOAP messagingdelivery.

4. Service lifecycle/state management. This mayinclude exposing the current state of a service andpermit lifecycle management including the ability tostart and stop a service, the ability to make specificconfiguration changes to a deployed Web service,support the description of versions of Web servicesand notification of a change or impending change tothe service interface or implementation.

5. Scalability/extensibility. The Web services supportenvironment should be extensible and must permitdiscovery of supported management functionalityin a given instantiation.

To manage critical applications/solutions and collab-orations spanning entire industry groups and other com-plex business relationships, e.g., specific service markets,the xSOA management services are divided in two com-plementary categories ([73,75]):

1. Service operations management that can be used tomanage the service platform, the deployment of ser-vices and the applications and, in particular, monitorthe correctness and overall functionality of aggre-gated/orchestrated services.

2. Service market management that supports typicalintegrated supply chain functions and provides acomprehensive range of services supporting indus-try-trade, including services that provide businesstransaction negotiation and facilitation, financialsettlement, service certification and quality assur-ance, rating services, service metrics, and so on.

The xSOA’s service operations management func-tionality is aimed at supporting critical applications thatrequire enterprises to manage the service platform, thedeployment of services and the applications. xSOA’s ser-vice operations management typically gathers informa-tion about the managed service platform, Web servicesand business processes and managed resource statusand performance, and supporting specific managementtasks (e.g., root cause failure analysis, SLA monitor-ing and reporting, service deployment, and life cyclemanagement and capacity planning). Operations man-agement functionality may provide detailed applicationperformance statistics that support assessment of theapplication effectiveness, permit complete visibility intoindividual business processes and transactions, guaran-tee consistency of service compositions, and deliverapplication status notifications when a particular activityis completed or when a decision condition is reached. We


refer to the role responsible for performing such oper-ation management functions as the service operator.Depending on the application requirements a serviceoperator could be a service client or service aggregator.

Service operations management is a critical functionthat can be used to monitor the correctness and overallfunctionality of aggregated/orchestrated services thusavoiding a severe risk of service errors. Considerationsneed also be made for modeling the context in which agiven service is being leveraged individual, composite,part of a long-running business process, and so on. Inorder to successfully compose Web services processes,one must fully understand the service’s WSDL con-tract along with any additional requirements, capabil-ities, and policies (preferences). In this way one canavoid typical errors that may occur when individual ser-vice-level agreements (SLAs) are not properly matched.Proper management and monitoring provide a strongmitigation of this type of risk, since the operations man-agement level allows business managers to check thecorrectness, consistency, and adequacy of the mappingsbetween the input and output service operations andaggregate services in a service composition.

It is increasingly important for service operators todefine and support active capabilities versus traditionalpassive capabilities [42]. For example, rather than merelyraising an alert when a given Web service is unable tomeet the performance requirements of a given service-level agreement, the management framework should beable to take corrective action. This action could take theform of rerouting requests to a backup service that is lessheavily loaded, or provisioning a new application serverwith an instance of the software providing the service ifno backup is currently running and available.

Finally, service operations management should alsoprovide global visibility of running processes, compara-ble to that provided by BPM tools. Management visibil-ity is expressed in the form of real-time and historicalreports, and in triggered actions. For example, deviationsfrom key performance indicator target values, such asthe percent of requests fulfilled within the limits speci-fied by a service level agreement, might trigger an alertand an escalation procedure.

Another aim of xSOA’s service management layeris to provide support for service markets (aka of openservice marketplaces). Currently, there exist several ver-tical industry marketplaces, such as those for the semi-conductor, automotive, travel, and financial servicesindustries. Service cooperatives operate much in thesame way like vertical marketplaces, however, they areopen. Their purpose is to create opportunities forbuyers and sellers to meet and conduct business elec-tronically, or aggregate service supply/demand by offer-

ing added value services and grouping buying power(just like a co-operative). The scope of such a servicemarket would be limited only by the ability of enter-prises to make their offerings visible to other enterprisesand establish industry specific protocols by which to con-duct business. Service markets typically support supplychain management by providing to their members a uni-fied view of products and services, standard business ter-minology, and detailed business process descriptions. Inaddition, service markets must offer a comprehensiverange of services supporting industry-trade, includingservices that provide business transaction negotiationand facilitation [17], financial settlement, service certi-fication and quality assurance, rating services, servicemetrics such as number of current service requesters,average turn around time, and manage the negotiationand enforcement of SLAs. The xSOA market manage-ment functionality as illustrated in Fig. 9 is aimed tosupport these open service market functions.

Service markets introduce a new role that of a mar-ket maker. A market maker is a third trusted partyor consortium of organizations that brings the suppli-ers and vendors together. Essentially, a service marketmaker is a special kind of service aggregator that hasadded responsibilities, such as issuing certificates, main-taining industry standard information and introducingnew standards, endorsing service providers/aggregators,etc. The market maker assumes the responsibility ofthe service market administration and performs main-tenance tasks to ensure the administration is open andfair for business and, in general, provides facilities forthe design and delivery of integrated service offeringsthat meet specific business needs and conform to indus-try standards.

5 Research activities and open issues

This section focuses on ongoing research activities con-ducted on services. Also, it identifies open researchissues. We classify both the research activities and openresearch issues on the basis of the functional layers ofxSOA.

5.1 xSOA basic services layers

Research activities in the basics services layer to datetarget formal service description language(s) for holisticservice definitions addressing, besides functionalaspects, also behavioral as well as non-functional aspectsassociated with services. They also concentrate on open,modular, extensible framework for service discovery,publication and notification mechanisms across distrib-


uted, heterogeneous, dynamic (virtual) organizations aswell as unified discovery interfaces and query languagesfor multiple pathways. In the following, we summa-rize several research activities contribute to these andrelated problems.

In addition to the application-specific functions thatservices provide, services may also support (different)sets of protocols and formats addressing extra-functionalconcerns such as transaction processing and reliablemessaging.

Tai et al. [92] address the problem of transactionalcoordination in service-oriented computing. The authorsof this publication argue for the use of declarative policyassertions to advertise and match support for differenttransaction styles (direct transaction processing, queuedtransaction processing, and compensation-based trans-action processing) and introduce the concept of andsystem support for transaction coupling modes as thepolicy-based contracts guiding transactional businessprocess execution.

An SOA requires that developers discover at devel-opment time service descriptions in (UDDI) repositorysystems and, by reading these descriptions they are ableto code client applications that can (at run time) bind toand interact with services of a specific type (i.e., compli-ant to a certain interface and protocol). Understandingthe execution semantics is a rather cumbersome task.

To address this problem Deora et al. ([34,35]) pro-pose a quality of service management framework basedon user expectations. This framework collects expec-tations as well as ratings from the users of a serviceand then the quality of the service is calculated only atthe time a request for the service is made and only byusing the ratings that have similar expectations. Similarresearch efforts are reported in [78].

The AI and semantic Web community has concen-trated their efforts in giving richer semantic descriptionsof Web services that describe the properties and capabil-ities of Web services in an computer-interpretable form.For this purpose, DAML-S [93] language has been pro-posed to facilitate the automation of Web service tasksincluding better means of Web service discovery, execu-tion, “automatic” composition, verification, and execu-tion monitoring.

In addition, in [77], an approach is described thatbuilds on top of existing Web services technologies andcombines them with some concepts borrowed from theSemantic Web to leverage Web service discoveryand composition. This approach is captured by theMETEOR-S Web Service Annotation Framework(MWSAF). In particular, the MWSAF is designed tosemi-automatically mark up Web service descriptionswith ontologies.

In the basic SOA UDDI provides a simple brows-ing-by-business-category mechanism for developers toreview and select published services. It is generallybelieved that discovery based on keyword-search couldbe improved considerably by introducing more pow-erful matching approaches. In [95], a hybrid matchingapproach is suggested, combining semantic and syntacticcomparison algorithms of WSDL documents. Compara-ble research efforts have been reported in [37,51,100].

In order for SOA to become successful, powerfulmechanisms are needed that allow service requestorsto find service providers that are able to provide the ser-vices they need. Typically, this service trading needs tobe executed in several stages as the offer descriptionsare not completely specified in most cases and differ-ent parameters have to be supplemented by the servicerequestor and provider alternately. Unfortunately, exist-ing service description languages (like DAML-S) treatservice discovery as a one-shot activity rather than asan ongoing process and accordingly do not support thisstepwise refinement.

Klein et al. [53] introduce the concept of partiallyinstantiated service descriptions containing differenttypes of variables which are instantiated successively,thereby mirroring step-by-step progress in a trading pro-cess. The suggested approach is grounded on serviceontologies that were developed in the DIANE project[54].

In [81], a peer-to-peer based framework is investi-gated that allows to advertise and find services usingkeyword-based search, ontology-based search andbehavior-based search in a highly decentralized anddynamic environment. In addition, the framework pro-vides mechanisms so that users may express and querythe quality of services.

5.2 xSOA composition layer: research activities

Service composition is today largely a static affair. Allservice interactions are anticipated in advance and thereis a perfect match between output and input signa-tures and functionality. More ad hoc and dynamic ser-vice compositions are required very much in the spiritof lightweight and adaptive workflow methodologies.These methodologies will include advanced forms ofco-ordination, less structured process models, and auto-mated planning techniques as part of the integration/composition process. On the transactional front,although standards like WS-Transaction, WS-Coordina-tion, and BTP are a step in the right direction, they fallshort of describing different types of atomicity needsfor e-business and e-government applications. These do


not distinguish between transaction phases and conver-sational sequences, e.g., negotiation. Another area thatis lacking research results is advanced methodologiesin support for the service composition lifecycle. Severalresearch activities contribute to these and related prob-lems.

Yang and Papazoglou [102] present an integratedframework and prototype system that manage the entirelife-cycle of service components ranging from abstractservice component definition, scheduling, and construc-tion to execution. Service compositions are divided inthree categories: fixed, semi-fixed, and explorative com-positions. Fixed service compositions require that theirconstituent services be synthesized in a fixed (pre-specified) manner. Semi-fixed compositions require thatthe entire service composition is specified statically butthe actual service bindings are decided at run time.Finally, explorative compositions are generated on thefly on the basis of a request expressed by a client (appli-cation developer).

In [90], a framework is introduced for enrichingsemantic service descriptions with two compositionalassertions: assumption and commitment that help toreason about service composition and verification. Theframework uses the interval temporal logic (ITL) lan-guage for representing and proving temporal propertiesof systems. This framework is embedded in the Seman-tic Web rule language [48], which combines Horn-likerules with an OWL knowledge base.

Charfi and Mezini [29] propose to modularize Web-service composition adopting two dimensions, one foroutlining the business process flow, using languages suchas BPEL and BPL, and a second dimension comprisingbusiness rules, which may be attached to the businessprocesses and evolve independently.

There has been some work in the area of applyingAI planning techniques to automate the composition ofWeb Services. In [86], the authors describe how an OWLreasoner can be integrated with an AI planner to over-come the problem of closed world semantics of plannersversus open world semantics of OWL.

Many of the existing approaches toward service com-position largely neglect the context in which composi-tion takes place. In [32], a context-aware methodology isintroduced that considers a social specification of a ser-vice composition as the basis for process specificationand verification.

5.3 xSOA management layer

Service management constitutes the foundation of theupper layer of the extended SOA. Traditional manage-

ment applications fail to meet enterprise requirementsin a service-centric world. Conventional systems man-agement approaches and products view the world in avery coarse (mostly applications oriented) manner. Themost recent wave of management product categoriesdoes not have the business awareness that services man-agement will require. The finer grained nature of ser-vices (as opposed to applications) requires evaluatingprocesses and transactions at a more magnified rate andin a more contextually aware manner.

One crucial aspect of management entails monitor-ing. In [12], a dynamic monitoring approach is probedthat is capable of specifying monitoring rules governingthe control of WS-BPEL processes.

Casati et al. [25] concentrate on operations manage-ment. The proposed business oriented management ofWeb services is an attempt to assess the impact of ser-vice execution from a business perspective and, con-versely, to adjust and optimize service executions basedon stated business objectives. This is a crucial issue ascorporations strive to align service functionality withbusiness goals.

In [87] a model-driven trust negotiation frameworkfor Web services management is explored. The frame-work adopts a model for trust negotiation that employsstate machines, which incorporate security policies. Thepolicy model underlying this framework facilitates life-cycle management.

The ability to gauge the quality of a service is criticalif we are to achieve the service oriented computing para-digm. Many techniques have been proposed and most ofthem attempt to calculate the quality of a service by col-lecting quality ratings from the users of the service, andthen combining them in one way or another. Collect-ing quality ratings alone from the users is not sufficientfor deriving a reliable or accurate quality measure for aservice.

In [69], Maximilien extends the usage of the Qualityof Service concept for not only selecting Web-servicesbut also establishing trust between trading partners. Thispaper outlines an agent-oriented approach, including anarchitecture and programing model. The work is vali-dated empirically, based on a series of simulations.

Ideally, services are collaborating in highly distrib-uted environments, naturally cutting across variousenterprise boundaries. This environment demands thatcontracts are set up, stipulating agreements between ser-vices regarding their collaboration, both at the func-tional and non-functional level, in a concise manner.These contracts may serve as the basis for process mon-itoring and adaptation.

Ludwig et al. (IBM) [65] suggest to standardize onagreements between enterprise domains, proposing the


WS-Agreement standard. Their work addresses both thecontract creation and monitoring from the perspectiveof service providers and consumers. Service providersare supported by an infrastructure offering agreementtemplates, and facilities to dynamically check the state ofan agreement. Likewise, service requesters are in needof contract templates and some monitoring capacities.Lastly, the paper presents the creation and monitoring ofagreements (CREMONIA) architecture, implementingWS-Agreements.

6 Summary

Modern enterprises need to align into virtual alliances,while responding effectively and swiftly to competitivechallenges. Therefore, they are required to streamlineboth internal and external business processes by inte-grating the various packaged and home-grown appli-cations found spread throughout an enterprise. Thisrequires an agile approach that allows enterprise busi-ness services (those offered to customers and partners)to be easily assembled from a collection of smaller, morefundamental business services. This challenge in auto-mated business integration has driven major advancesin technology within the integration software space. As aresult the SOA has emerged recently, essentially address-ing the requirements of service requesters, providers andservice brokers, regarding loosely coupled, standards-based, and protocol-independent distributed comput-ing and offering ways to achieve the desired levels ofbusiness integration effectively, mapping IT implemen-tations more closely to the overall business process flow.

Combining the SOA paradigm with event-driven pro-cessing lays the foundation for an emerging technology,that amalgamates various conventional distributed com-puting, middleware, BPM and EAI technologies, andthereby offers a unified backbone on top of which enter-prise services can be advertised, composed, planned,executed, monitored, and decommissioned. This over-arching implementation backbone to SOA is referred toas the ESB.

To cater for essential ESB requirements that includecapabilities such as service orchestration, “intelligent”routing, provisioning, integrity and security of messageas well as service management, the basic service descrip-tion/publication/discovery functions of the conventionalSOA need to be extended into the extended SOA(xSOA). Particularly, the xSOA incorporates a servicecomposition tier to offer necessary roles and function-ality for the consolidation of multiple services into asingle composite service. In addition, xSOA provides aseparate tier for service management that can be used

to monitor the correctness and overall functionality ofaggregated/orchestrated services, supporting complexaggregate (cross-component) management use cases,such as service-level agreement enforcement anddynamic resource provisioning.

This paper has surveyed approaches, technologies,and research issues related to services architectures andunderlying technologies. Particularly, it has reviewedseveral technologies, including integration brokers, busi-ness process management, and application servers thatimplement the backbone of an Enterprise Service Bus,which is of critical importance to make the service-oriented computing paradigm operational in a businesscontext.

References

1. Alonso, G., Casati, F., Kuno, H., Machiraju, V.: Web Ser-vices: Concepts, Architectures and Applications. Springer,Heidelberg (2004)

2. Anagol-Subbaro A.: J2EE Web Services on BEA WebLogic.Prentice-Hall, Upper Saddle River (2005)

3. Anderson, S., et al.: Web Services Trust language (WS-Trust).Public draft release, Actional Corporation, BEA Systems,Computer Associates International, International BusinessMachines Corporation, Layer 7 Technologies, Microsoft Cor-poration, Oblix Inc., OpenNetwork technologies, Ping Iden-tity, Reacticity, RSA Security, and Verisign, February (2005)

4. Andrews, T., et al.: Business process execution language(BPEL), version 1.1. Technical-report, BEA Systems andInternational Business Machines Corporation, MicrosoftCorporation, SAP AG and Siebel Systems, May 2003

5. Arkin, A.: Business process modeling language (BPML).Last Call Draft Report, BPMI.Org, November 2002

6. Arora, A., et al.: Web services for management (WS-Management). Technical report, Advanced Micro Devices,Dell, Intel, Microsoft Corporation and Sun Microsystems,October 2004

7. Arsanjani, A.: Introduction to the special issue on developingand integrating enterprise components and services. Com-mun. ACM 45(10), 30–34 (2002)

8. Atkinson, B., et al.: Web Services Security (WS-Security).Technical report, Microsoft, IBM and Verisign, April 2002

9. Bajaj, S., et al.: Web Services Policy framework (WS-Policy).Technical report, BEA Systems Inc., International BusinessMachines Corporation, Microsoft Corporation, Inc., SAPAG, Sonic Software, and VeriSign Inc., September 2004

10. Ballinger, K., et al.: Web services-interoperability (WSI),Basic profile version 1.1, 2004-08-24. Technical report, WSIOrganization (WS-I), 2004

11. Barbir, A., et al.: Basic security profile, version 1.0. Technicalreport, Web Services-Interoperability Organization (WS-I),2004

12. Baresi, L., Guinea, S.: Towards dynamic monitoring of WS-BPEL processes. In: Proceedings of the Third InternationalConference on Service Oriented Computing, pp. 269–282.Springer, Amsterdam (2005)

13. Bloomberg, J.: Events vs. services. Available at: http://www.zapthink.com, ZapThink white paper, October 2004

14. Boag, S., et al.: Xquery 1.0: An XML query language, W3Cworking draft. Technical report, W3C, April 2005


15. Booth, D., et al.: Web Service Architecture. http://www.w3.org/tr/ws-arch/, W3C, Working Notes, 2003/2004

16. Box, D., et al.: Simple Object Access Protocol (SOAP), Ver-sion 1.1. W3C Note, W3C, May 2000. http://www.w3.org/TR/SOAP/

17. Bui, T., Gachet, A.: Web services for negotiation and bargain-ing in electronic markets: Design requirements and imple-mentation framework. In: Proceedings of the 38th HawaiiInternational Conference on System Sciences, IEEE, 2005

18. Burbeck, S.: The tao of e-business services: the evolutionof Web applications into service-oriented components withWeb services. IBM DeveloperWorks, 2000. http://www-106.ibm.com/developerworks/Webservices/library/ws-tao/

19. Burdett, D., Kavantzas, N.: WS-Choreography Model Over-view. W3c working draft, W3C, March 2004

20. Buschmann, F., et al.: Pattern-oriented software architecture:a system of patterns. Wiley, New York (1996)

21. Business Process Project Team: ebXML Business Pro-cess Specification Schema, version 1.01. OASIS, 2001.http://www.ebxml.org/specs/ebbpss.pdf

22. Bussler, C.: B2B Integration: Concepts and Architecture.Springer, Berlin (2003)

23. Candadai, A.: A dynamic implementation framework forSOA-based applications. Web Logic Dev. J. WLDJ Septem-ber/October, 6–8 (2004)

24. Cardelli, L., Wegner, P.: On understanding types, dataabstraction and polymorphism. ACM Comput. Surv. 17(4),211–221 (1985)

25. Casati, F. et al.: Business-oriented management of Web ser-vices. Commun. ACM 46(10), 55–60 (2003)

26. Catania, N., et al.: Web services management framework,version 2.0. Technical report, HP, July 2003

27. Chappell, D.: Enterprise Service Bus. O’Reilly Media, Inc.,Sebastopol (2004)

28. Chappell, D.: ESB myth busters: Clarity of definition fora growing phenomenon. Web Serv. J. February, pp. 22–26(2005)

29. Charfi, A., Mezini, M.: Hybrid Web service composition: busi-ness processes meet business rules. In: ICSOC ’04: Proceed-ings of the 2nd international conference on Service orientedcomputing, pp. 30–38. ACM Press, New York (2004)

30. Christensen, E., et al.: Web Services Description Lan-guage (WSDL) 1.1. W3C Note, W3C, March 2001.http://www.w3.org/TR/2001/NOTE-wsdl-20010315

31. Colan, M.: Service-Oriented Architecture expands the visionof Web services, Part 2. IBM DeveloperWorks, April 2004

32. Colobo, E., Mylopoulos, J., Spoletini, P.: Modeling and Ana-lyzing Context-Aware Composition of Services. In: Pro-ceedings of the Third International Conference on ServiceOriented Computing, pp. 198–213. Springer, Amsterdam(2005)

33. Dan, A. et al.: Web services on demand: WSLA-driven auto-mated management. IBM Syst. J. 43(1), 136–158 (2004)

34. Deora, V., et al.: A quality of service management frame-work based on user expectations. In: Proceedings of the FirstInternational Conference on Service Oriented Computing(ICSOC03), Springer, Heidelberg (2003)

35. Deora, V., et al.: Incorporating QoS specifications in ser-vice discovery. In: Proceedings of WISE Workshops, LectureNotes of Springer Verlag, 2004

36. Dhesiaseelan, A., Ragunathan, V.: Web Services ContainerReference Architecture (WSCRA). In: Proceedings of theInternational Conference on Web Services, IEEE, pp. 806–805, 2004

37. Ding, X., et al.: Similarity search for Web services. In: Pro-ceedings of the 30th VLDB Conference, pp. 372–383, 2004

38. ebXML Technical Architecture Project Team: ebXML Tech-nical Architecture Specification, v1.0.4. Technical report, eb-XML.org, February, 2001

39. Farell, S., et al.: Assertions and protocol for the OASIS secu-rity assertion markup language (SAML), V1.1. Committeespecification, OASIS, July 2003

40. Francis, T., et al.: Professional IBM WebSphere 5.0 Applica-tion Server. Wrox, 2002

41. Fremantle, P., Weerawarana, S., Khalaf, R.: Enterprise ser-vices. Commun. ACM 45(10), (2002)

42. Ganek, A.G., Corbi, T.A.: The dawning of the autonomiccomputer era. IBM Syst. J. 42(11), 5–18 (2003)

43. Graham, S., et al.: Web Services Resource (WS-Resource),version 1.2, working draft 03. Technical report, OASIS, March2005

44. Graham, S., Niblett, P.: Web Services Base Notification,version 1.0. Akamai Technologies, Computer AssociatesInternational, Inc., Fujitsu Limited, Hewlett-Packard Devel-opment Company, International Business Machines Corpo-ration, SAP AG, Sonic Software Corporation, The Universityof Chicago and Tibco Software Inc., 2004

45. Hapner, M., et al.: Java Messaging Service, version 1.1. Suntechnical report, specification, SUN Microsystems, April 2002

46. Hauck, R., Reiser, H.: Monitoring quality of service acrossorganizational boundaries. In: Trends in Distributed Systems:Torwards a Universal Service Market. Proceedings of thethird International IFIP/GI Working Conference, 2000

47. Holley, K., Channabasavaiah, K., Tuggle, E.M., Jr.: Migratingto a Service-Oriented Architecture. IBM DeveloperWorks,December 2003

48. Horrocks, I., et al.: SWRL: A Semantic Web Rule Languagecombining OWL and RULEML, W3C member submission.W3C, 21 May 2004

49. Iwasa, K. (principal ed.) WS-Reliability, version 1.1, com-mittee draft 1.086, 24 august 2004. http://www.oasis-open.org/committees/wsrm/documents/specs/(tbd), OASIS, WebServices Reliable Messaging TC, 2004

50. J2CA Group.: J2EE Connector Architecture Specification,version 1.5. Technical report, SUN Microsystems, 2003

51. Jaeger, M.C., Tang, S.: Ranked matching for service descrip-tions using DAML-S. In: Grundspenkis, J., Kirikova, M.,(eds.), Proceedings of CAiSE’04 Workshops, pp. 217–228.Riga Technical University Riga, Latvia, June 2004

52. Keen, M., et al.: Patterns: Implementing an SOA using anEnterprise Service Bus. IBM Redbook, 22 July 2004

53. Klein, M., Konig-Ries, B., Obreiter, P.: Stepwise refinableservice descriptions: Adapting DAML-S to staged servicetrading. In: Proceedings of 1st International Conference onService Oriented Computing, December 2003

54. Klein, M., Konig-Ries, B., Mussig, M.: What is needed forSemantic Service Descriptions? A proposal for suitable lan-guage constructs. Int. J. Web Grid Serv. 2, (2005)

55. Krafzig, D., Banke, K., Slama, D.: Enterprise SOA: ServiceOriented Architecture Best Practices. Prentice-Hall, Engle-wood Cliffs (2005)

56. Kreger, H.: Fulfilling the Web services promise. Commun.ACM 46(6), 29–ff (2003)

57. Kumar, S., Rana, R.: Service on demand portals: a primer onfederated portals. Web Logic Dev. J. WLDJ, September/Octo-ber, 22–24 (2004)

58. Lazovik, A., et al.: Associating assertions with business pro-cesses and monitoring their execution. In: Proceedings of theSecond International Conference on Service Oriented Com-puting, 2004

59. Leymann, F., Roller, D.: Production Workflow: Concepts andTechniques. Prentice-Hall, Englewood Cliffs (2000)


60. Leymann, W.F., Roller, D., Schmidt, M.-T.: Web servicesand business process management. IBM Syst. J. 41(2), 198–211 (2002)

61. Linthicum, D.: Next Generation Application Integration:From Simple Information to Web Services. Addison-Wesley,Reading (2003)

62. Lowey, J.: Programming .NET Components, Reading (2003)1st edn. O’Reilly Sebastopol (2003)

63. Lubinsky, B., Farrel, M.: enterpise architecture and J2EE.EAI J., pp. 12–15 November (2001)

64. Luckham, D.: The Power of Events. An Introduction to Com-plex Event Processing in Distributed Enterprise Systems.Addison-Wesley, Reading, April 2002

65. Ludwig, H., Dan, A., Kearney, R.: Crona: an architectureand library for creation and monitoring of WS-Agreements.In: ICSOC ’04: Proceedings of the 2nd international confer-ence on Service oriented computing, pp. 65–74. ACM Press,New York (2004)

66. Martin, J., Arsanjani, A., Tarr, P., Hailpern, B.: Web Ser-vices: Promises and Compromises. Queue, ACM 1(1), 48–58(2003)

67. McGoveran, D.: An introduction to BPM and BPMS. Bus.Integr. J., pp. 2–10 April (2004)

68. Meyer, B.: Object-oriented Software Construction, 2nd edn.Prentice-Hall Professional Technical Reference, EnglewoodCliffs (1997)

69. Maximilien, E.M., Singh, M.P.: Toward autonomic Web ser-vices trust and selection. In: ICSOC ’04: Proceedings of the2nd international conference on Service oriented computing,pp. 212–221. ACM Press, New York (2004)

70. Monson-Haefel, R., Chappell, D.: Java Message Services.O’Reilly, 2001.

71. Mukherjee, B., et al.: An efficient multicast protocol forcontent-based publish-subscribe systems. In: ICDCS ’99: Pro-ceedings of the 19th IEEE International Conference on Dis-tributed Computing Systems, p. 262. IEEE Computer Society,Washington, DC (1999)

72. Ossher, H., Tarr, P.: Multi-dimensional separation of concernsand the hyperspace approach. In: Proceedings of the Sympo-sium on Software Architectures and Component Technology:The State of the Art in Software Development, 2000

73. Papazoglou, M., Georgakopoulos, D.: Introduction to aspecial issue on service oriented computing. Commun.ACM, 46(10), 25–28 (2003)

74. Papazoglou, M.P., Ribbers, P.M.A.: e-Business: Organiza-tional and Technical Foundations. Wiley, New York April2006

75. Papazoglou, M.P.: Extending the Service Oriented Architec-ture. Bus. Integr. J., pp. 18–21 February (2005)

76. Parent, C., Spaccapietra, S.: Issues and Approaches of Data-base Integration. Commun. ACM 41(5), 166–178 (1998)

77. Patil, A.A., et al.: Meteor-S: web service annotation frame-work. In: WWW ’04: Proceedings of the 13th internationalconference on World Wide Web, pp. 553–562. ACM Press,New York (2004)

78. Ran, S.: A Model for Web Services Discovery withQoS. SIGecom Exch. 4(1), 1–10 (2003)

79. Robinson, R.: Understand Enterprise Service Bus scenariosand solutions in Service-Oriented Architecture. IBM Devel-operWorks, June (2004)

80. Roch, E.: Application Integration: Business and Technologytrends. EAI J. August (2002)

81. Sahin, O.D., et al.: SPiDeR: P2P-Based Web Service Discov-ery In: Proceedings of the Third International Conference onService Oriented Computing, pp. 157–170. Springer, Amster-dam (2005)

82. Schulte, R.: Predicts 2003: Enterprise service buses emerge.Report, Gartner, December 2002

83. Seacord, R., et al.: Legacy modernization strategies. TechnicalReport CMUSEI-2001-TR-025, Carnegie Mellon University,Pittsburgh (2001)

84. Seacord, R.C., Plakosh, D., Lewis, G.A.: Modernizing LegacySystems. Carnegie Mellon, SEI. Addison-Wesley, Reading(2003)

85. Sing, I., et al.: Designing Web Services with the J2EE 1.4Platform. Addison-Wesley, Reading (2004)

86. Sirin, E., Parsia, B.: Planning for Semantic Web Services. In:Martin, D., Lara, R., Yamaguchi, T. (eds.) Proceedings of theISWC 2004 Workshop on Semantic Web Services: Preparingto Meet the World of Business Applications, 2004

87. Skogsrud, H., Benatallah, B., Casati, F.: Trust-serv: model-driven lifecycle management of trust negotiation policies forWeb services. In: WWW ’04: Proceedings of the 13th inter-national conference on World Wide Web, pp. 53–62. ACMPress, New York (2004)

88. Sloman, M.: Policy driven management of distributed sys-tems. J. Netw. Syst. Manag. 2, 333–360 (1994)

89. Smith, D.: Web services enable Service Oriented and Event-driven Architectures. Bus. Integr. J., May, 12–13 (2004)

90. Solanki, M., Cau, A., Zedan, H.: Augmenting semanticWeb service descriptions with compositional specification. In:WWW ’04: Proceedings of the 13th international conferenceon World Wide Web, pp. 544–552. ACM Press, New York(2004)

91. Stal, M.: Web Services: Beyond Component-based Comput-ing. Commun. ACM 45(10), 71–76 (2002)

92. Tai, S., Mikalsen, T., Wohlstadter, E., Desai, N., Rouvellou,I.: Transaction policies for service-oriented computing. DataKnowl. Eng. 51(1), 59–79 (2004)

93. The DAML-S Coalition.: DAML-S: Web Service Descriptionfor the semantic Web. In: Horrocks, I., Hendler, J.A., (eds.)The Semantic Web - ISWC 2002, First International SemanticWeb Conference. Lecture Notes in Computer Science, 2002

94. Universal Description, Discovery, and Integration (UDDI):Technical report, UDDI.ORG, September 2000. http://www.uddi.org

95. van den Heuvel, W.J.: Integrating Modern Business Applica-tions with Legacy Systems: A Software Component Perspec-tive. MIT Press, Cambridge, February (2007)

96. van der Aalst, W.M.P.: Lectures on concurrency and petrinets: a tutorial on models, systems and standards for workflowmanagement., In: Business Process Management Demysti-fied, pp. 1–65. Springer, Berlin (2004)

97. Von Schilling, P., Lawrence, P.: Leveraging existing code withobject technology. Enterp. Syst. J. 7, 38–44 (1994)

98. W3C.: XSL Transformations (XSLT), Version 2.0. Technicalreport, W3C Working Draft, April 2005

99. Wahli, U., et al.: Websphere version 5.1 application developerWeb services handbook. IBM Redbook, New York (2004)

100. Wang, Y., Stroulia, E.: Semantic structure matching forassessing Web-service similarity. In: Proceedings of FirstInternational Conference on Service Oriented Computing(ICSOC03), pp. 194–207. Springer, Berlin (2003)

101. White, S., Hapner, M.: JDBC 2.1 API. Technical report, SUN,October 1999

102. Yang, J., Papazoglou, M.P.: Service components for managingthe life-cycle of service compositions. Inf. Syst. 28(1), 97–125(2004)

103. Yang, J.: Web Service Componentization. Commun. ACM46(10), 35–40 (2003)

104. Yendluri, P.: RosettaNet implementation framework (RNIF),Version 2.0, Technical report. RosettaNet, 2000

Service oriented architectures: approaches, …...service-oriented computing paradigm. xSOA serves...

Documents

Transcript of Service oriented architectures: approaches, …...service-oriented computing paradigm. xSOA serves...