Your SlideShare is downloading. ×
Service Oriented Architectures:
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Service Oriented Architectures:

1,662
views

Published on


0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,662
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
54
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. The VLDB Journal manuscript No. (will be inserted by the editor) Mike P. Papazoglou · Willem-Jan van den Heuvel Service Oriented Architectures: Approaches, Technologies and Research Issues Received: June, 2005 / Accepted: date Abstract SOA is an emerging approach that addresses 1 Introduction the requirements of loosely coupled, standards-based, and protocol-independent distributed computing. Typ- Modern enterprises need to respond effectively and ically business operations running in an SOA comprise quickly to opportunities in today’s, ever more com- a number of invocations of these different components, petitive and global markets. To accommodate business often in an event-driven or asynchronous fashion that re- agility, enterprises are supposed to streamline (existing) flects the underlying business process needs. To build an business processes while exposing the various packaged SOA a highly distributable communications and integra- and home-grown applications found spread throughout tion backbone is required. This functionality is provided the enterprise in a highly standardized manner. A con- by the Enterprise Service Bus (ESB) that is an inte- temporary approach for addressing these critical issues is gration platform that utilizes web services standards to embodied by (web) services that can be easily assembled support a wide variety of communications patterns over to form a collection of autonomous and loosely-coupled multiple transport protocols and deliver value-added ca- business processes. pabilities for SOA applications. The emergence of web services developments and This paper reviews technologies and approaches that standards in support of automated business integration unify the principles and concepts of Service Oriented Ar- has driven major technological advances in the inte- chitecture with those of event-based programming. The gration software space, most notably, the Service Ori- paper also focuses on the ESB and describes a range ented Architecture (SOA) ([15], [35]). The purpose of of functions that are designed to offer a manageable, this architecture is to address the requirements of loosely standards-based SOA backbone that extends middleware coupled, standards-based, and protocol-independent dis- functionality throughout by connecting heterogeneous tributed computing, mapping enterprise information sys- components and systems and offers integration services. tems isomorphically to the overall business process flow. Finally, the paper proposes an approach to extend the In a SOA, software resources are packaged as “ser- conventional SOA to cater for essential ESB require- vices”, which are well defined, self-contained modules ments that include capabilities such as service orches- that provide standard business functionality and are in- tration, ”intelligent” routing, provisioning, integrity and dependent of the state or context of other services. Ser- security of message as well as service management. The vices are described in a standard definition language, layers in this extended SOA, in short xSOA, are used to have a published interface, and communicate with each classify research issues and current research activities. other requesting execution of their operations in order to collectively support a common business task or process Keywords service oriented architecture · asynchronous [42]. Services that utilize Web services standards, e.g., and event-driven processing · application and service WSDL, SOAP, and UDDI, are the most popular type of integration · enterprise bus · web services services available today. SOA is designed to allow developers to overcome many distributed enterprise computing challenges in- cluding application integration, transaction manage- INFOLAB, Tilburg University PO Box 90500, 5000 LE, Tilburg, The Netherlands ment, security policies, while allowing multiple platforms Tel.: +31-13-466 2349 and protocols and leveraging numerous access devices Fax: +31-13-466 3069 and legacy systems [4]. The driving goal of SOA is to E-mail: mikep@uvt.nl eliminate these barriers so that applications integrate
  • 2. 2 Mike P. Papazoglou, Willem-Jan van den Heuvel and run seamlessly. In this way an SOA can deliver the Services used in composite applications may be brand flexibility and agility that business users require, defin- new service implementations, they may be fragments ing coarse grained services, which may be aggregated of old applications that were adapted and wrapped, or and reused to facilitate ongoing and changing needs of they may be combinations of the above. Often the de- business, as the key building block of enterprises. signers for the client of the service do not have direct In contrast to conventional software architectures pri- access to the service implementation, other than indi- marily delineating the organization of a system in its rectly through its interface. External Internet-based ser- (sub)systems and their interrelationships, the Service vice providers and SOA packaged applications simply of- Oriented Architecture captures a logical way of designing fer the interfaces without revealing the inner workings of a software system to provide services to either end-user their environment. Thus, with SOA, an enterprise can applications or other services distributed in a network create, deploy and integrate multiple services and chore- through published and discoverable interfaces. SOA is ograph new business functions by combining new and ex- focused on creating a design style, technology, and pro- isting application assets into a logical flow. Accordingly cess framework that will allow enterprises to develop, SOA can serve as an enabler of just-in-time integration interconnect, and maintain enterprise applications and and interoperability of legacy applications; a key consid- services efficiently and cost-effectively. While this goal eration for enterprises that are seeking to deploy demand is definitely not new [64], SOA seeks to eclipse previous driven computing environments. efforts such as modular programming, code reuse, and Services in an SOA exhibit the following main char- object-oriented software development techniques. acteristics [51]: – All functions in an SOA are defined as services SOA as a design philosophy is independent of any [2]. This includes purely business functions, business specific technology, e.g., web-services or J2EE enterprise transactions composed of lower-level functions, and beans. This is achieved by limiting the number of imple- system service functions as well. mentation restrictions to the level of the service interface. – All services are autonomous. Their operation is per- SOA requires that functions, or services, are defined by a ceived as opaque by external components. Service description language (WSDL [25] in the case of web ser- opaqueness guarantees that external components nei- vices) and have interfaces that perform useful business ther know nor care how services perform their func- processes. The fundamental intent of a service in an SOA tion, they merely anticipate that they return the is to represent a reusable unit of business-complete work. expected result. The implementation and execution A service in SOA is an exposed piece of functionality space of the application providing the desired func- with three essential properties. Firstly, a SOA-based ser- tionality is encapsulated behind the service interface. vice is self-contained, i.e., the service maintains its own – In the most general sense, the interfaces are invoca- state. Secondly, services are platform-independent, im- ble. This implies that it is irrelevant whether services plying that the interface contract to the service is limited are local or remote, the interconnect scheme or proto- to platform-independent assertions. Lastly, the SOA as- col to effect the invocation, nor which infrastructure sumes that services can be dynamically located, invoked components are required to establish the connection. and (re-)combined. SOA’s loose-coupling principle - especially the clean Logically, a service in a SOA is a bound pair of a ser- separation of service interfaces from internal implemen- vice interface and a service implementation. Service in- tations - to guide planning, development, integration, terface defines the identity of a service and its invocation and management of their network application platforms logistics. Service implementation implements the work make them indispensable for enterprise-wide and cross- that the service is designated to do. Because interfaces enterprise applications [2]. are platform-independent, a client from any communica- Web services seem to become the preferred imple- tion device using any computational platform, operating mentation technology for realizing the SOA promise of system and any programming language can use the ser- maximum service sharing, reuse, and interoperability vice. The two facets of the service are distinct and are [55]. Web services and SOA reduce complexity of enter- designed and maintained as distinct items, though their prise application eco-systems by encapsulation and min- existence is highly interrelated. imizing the requirements for shared understanding by An SOA provides a flexible architecture that uni- defining service interfaces in a unambiguous and trans- fies business processes by modularizing large applications parent manner. Also web services enable just-in-time into services. A client from any device, using any operat- integration and interoperability of legacy applications. ing system, in any programming language, can access a Based on open and pervasive standards, web services SOA service to create a new business process. A SOA cre- seem poised for success, as these are only built on top ates a collection of services that can communicate with of existing, ubiquitous infrastructure like HTTP, SOAP each other using service interfaces to pass messages from and XML. one service to another, or coordinating an activity be- In this article, we survey the underpinnings of SOA, tween one or more services. assessing methodologies and technologies that serve
  • 3. Service Oriented Architectures: 3 Service Service Provider Provider Service requester Provider Requester Provider Requester Aggregator Service Service Provider Provider Fig. 1 The role of service aggregator. as the enabling springboard for business integration Requested operations of web services are imple- projects and deliver a flexible and adaptable environ- mented using one or more web service components [100]. ment. This survey is unique in that that it unifies the Web service components may be hosted within a web principles, concepts and developments in the area of ap- services container [31], serving as an interface between plication integration, middleware and integration bro- business services and low-level, infrastructure services. kers, service oriented architectures, event-driven com- In particular, web service containers are similar to J2EE puting, and adapters, and explains how they operate as containers ([3]) providing facilities such as location, rout- part of an emerging distributed computing technology ing, service invocation, and management. In particular, named the Enterprise Service Bus. Moreover, this pa- a service container is the physical manifestation of the per develops and explores an extension to conventional abstract service endpoint, and provides the implemen- Service Oriented Architectures (SOAs), entitled the eX- tation of the service interface. In addition, service con- tended SOA (xSOA). xSOA is an attempt to stream- tainers provide facilities for lifecycle management such line, group together and logically structure the functional as start up, shutdown, and resource cleanup. A service requirements of complex applications that make use of container can host multiple services, even if they are not the service-oriented computing paradigm. xSOA serves part of the same distributed process. Thread pooling al- as the reference for reviewing available technologies, and lows multiple instances of a service to be attached to assessing open research issues. multiple listeners within a single container [22]. Finally, the response that the provider sends back to the client takes again the form of a SOAP envelope carrying an XML message. 2 Service Roles in SOA SOAP is by nature a platform-neutral and vendor- SOAs and web services solutions support two key roles: neutral standard. These characteristics allow for a a service requestor (client) and service provider, which loosely-coupled relationship between requester and communicate via service requests. A role thus reflects a provider, which is especially important over the Internet type of a participant in a Service Oriented Architecture where two parties may reside in different organizations ([15], [54]). or enterprises. However, SOA does not require the us- Service requests are a messages formatted accord- age of SOAP. Prior to SOAP, for example, some compa- ing to the Simple Object Access Protocol (SOAP) [13]. nies used IBM’s WebSphere MQ to exchange XML doc- SOAP entails a light-weighted protocol allowing RPC- uments between them [77]. While this type of infrastruc- like calls over the Internet using a variety of transport ture clearly does not support web services because they protocols including HTTP, HTTP/S and SMTP. In prin- communicate using SOAP, they are another example of ciple, SOAP messages may be conveyed using any proto- service invocation in an SOA. Currently WebSphere MQ col as long as a binding is defined. The SOAP request is is, of course, equipped with direct support for SOAP. received by a run-time service (a SOAP ”listener”) that While SOA services are visible to the service client, accepts the SOAP message, extracts the XML message their underlying web components are transparent. The body, transforms the XML message into a native pro- service consumer does not have to be concerned with the tocol, and delegates the request to the actual business implementation of the service, as long as it supports the process within an enterprise. required functionality, while offering the desired quality
  • 4. 4 Mike P. Papazoglou, Willem-Jan van den Heuvel Service Service Broker Broker publish find Service Service Service Service Provider Provider bind Client Client Fig. 2 Service brokering. of service. For the service provider, the design of compo- security and privacy standards such as SAML [40] and nents, their service exposure and management reflect key WS-Trust [80], introduce another role which addresses architecture and design decisions that enable services in these issues, called a service broker [27]. SOA. The provider view offers a perspective on how to Service brokers are trusted parties that force service design the realization of the component that offers the providers to adhere to information practices that comply services; its architectural decisions and designs. with privacy laws and regulations, or in the absence of The process of a service requester having to di- such laws, industry best practices. In this way broker- rectly interact with a service provider exposes service sanctioned service providers are guaranteed to offer ser- requesters to the potential complexity of discovering, ex- vices that are in compliance with local regulations and ploring, negotiating and reserving services between dif- create a more trusted relationship with customers and ferent service providers. An alternative approach is for partners. A service broker maintains an index of available an organisation to provide this combined functionality service providers. The service broker is able to ’add value’ directly to the service requester. This service role com- to its registry of application service providers by provid- bines the role of service requester and provider, and is ing additional information about their services. This may labelled as a service aggregator [63]. The service aggrega- include differences about the reliability, trustworthiness, tor thus performs a dual role. First, it acts as an applica- the quality of the service, service level agreements, and tion service provider as it offers a complete ’service’ solu- possible compensation routes to name a few. tion, by creating composite, higher-level services, which Figure-2 shows an SOA where a service broker serves it provides to the service client. Service aggregators can as an intermediary that is interposed between service re- accomplish this composition using specialized choreog- questers and service providers. Figure-2 falls under this raphy languages like BPEL [5] and BPML [6]. Second, category with the service registry (UDDI operator) being it acts as a service requester as it may need to request a specialised instance of a service broker. Under this con- and reserve services from other service providers. This figuration the UDDI registry serves as a broker where the process is shown in Figure-1. service providers publish the definitions of the services While service aggregation may offer direct benefits to they offer using WSDL and where the service requestors the requester, it is a form of service brokering that of- find information about the services available. fers a convenience function - all the required services are grouped ’under one roof’. However, an important ques- tion that needs to be addressed is how does a service re- 3 Enterprise Service Bus quester determine which one out of a number of potential application service providers, should be selected for their Essentially web services denote an important technol- service offerings? The service requester could retain the ogy for implementing SOAs, however, other more con- right to select an application service provider based on ventional programming languages or middleware plat- those that can be discovered from a registry service, such forms may be adopted as well [90]. In particular, all tech- as the UDDI [1]. SOA technologies such as UDDI, and nologies that directly implement service interfaces with
  • 5. Service Oriented Architectures: 5 WSDL, and communicate with XML messages, can also conventional EAI technologies with web services, XSLT be involved in SOA. As indicated earlier, other technolo- [96], and orchestration technologies. Physically, an ESB gies such as, for instance, established middleware tech- provides an implementation backbone for an SOA. It es- nologies like J2EE, CORBA and IBM’s WebSphere MQ tablishes proper control of messaging as well as applies , can now also participate in an SOA, using new features the needs of security, policy, reliability and accounting, that work with WSDL. in an SOA architecture. The ESB, is responsible for the Fundamentally, there are only two options for solving proper control, flow and translations of all messages be- technology and information model mismatches: tween services, using any number of possible messaging protocols. An ESB pulls together applications and dis- 1. Build the client module to conform exactly to the crete integration components to create assemblies of ser- characteristics of every server module that it will in- vices to form composite business processes, which in turn voke. automate business functions in an enterprise. 2. Insert a layer of integration logic between the client Figure-3 depicts a simplified architecture of an ESB and server modules. that integrates a J2EE application using JMS, a .NET application using a C# client, an MQ application that The first approach requires to “develop an interface” interfaces with legacy applications, as well as external for each connection, resulting in a point-to-point topol- applications and data sources using web services. An ogy. This topology has long been known to be hard to ESB, as portrayed in Figure-3, enables the more efficient manage and maintain as it introduces a tighter form value-added integration of a number of different applica- of coupling to harmonize transport protocols, document tion components, by positioning them behind a service- formats, interaction styles etc [58]. This makes it harder oriented faade and by applying web services technology. to change either of the two systems involved in an in- In this figure, a distributed query engine, which is nor- terchange without impacting other systems. In addition, mally based on XQuery [12] or SQL, enables the creation point-to-point integration is not scalable and very com- of data services to abstract the complexity of underly- plex as the number of integration points increases as ing data sources. A portal in Figure 5 is a user-facing number of systems increases and can quickly become aggregation point of a variety resources represented as unmanageable. Hence the broad use of Enterprise Ap- services, e.g., retail, divisional, corporate employee, and plication Integration middleware supporting a variety of business partner portals. hub-and-spoke integration patterns [69]. This leaves the Endpoints in the ESB, depicted in Figure-3, provide second approach as the most viable alternative. abstraction of physical destination and connection infor- The second approach introduces an integration layer mation (like TCP/IP hostname and port number) tran- that must support interoperability among, and coex- scending plumbing level integration capabilities of tradi- ist with deployed infrastructure and applications. The tional, tightly-coupled, distributed software components. requirements to provide an appropriately capable and Endpoints allow services to communicate using logical manageable integration infrastructure for web services connection names, which an ESB will map to actual and SOA are coalescing into the concept of the Enter- physical network destinations at runtime. This destina- prise Service Bus (ESB) ([82], [22]). The ESB exhibits tion independence offers the services that are connected two prominent features [37]. Firstly, it promotes loose to the ESB, the ability to be upgraded, moved, or re- coupling of the systems taking part in an integration. placed without having to modify code and disrupt exist- Secondly, the ESB can break up the integration logic ing ESB applications. For instance, an existing ESB in- into distinct easily manageable pieces. voicing service could be easily upgraded by a new service, The Enterprise Service Bus (ESB) is an open, without disrupting the execution of other applications. standards-based message bus designed to enable the im- Additionally, duplicate processes can be set up to han- plementation, deployment, and management of SOA- dle fail-over if a service is not available. Endpoints also based solutions with a focus on assembling, deploying, provide the asynchronous and highly reliable commu- and managing distributed service-oriented architectures. nication between service containers. The endpoints can The ESB provides the distributed processing, standards- be configured to use several levels of quality of service, based integration, and enterprise-class backbone re- which guarantee communication despite network failures quired by the extended enterprise [37]. The ESB is de- and outages [22]. signed to provide interoperability between large-grained To successfully build and deploy a distributed applications and other components via standards-based Service-Oriented Architecture, there are four primary as- adapters and interfaces. The bus functions as both trans- pects that need to be addressed: port and transformation facilitator to allow distribution of these services over disparate systems and computing 1. Service enablement: Each discrete application needs environments. to be exposed as a service. Conceptually, the ESB has evolved from the store- 2. Service orchestration: Distributed services need to be and-forward mechanism found in middleware products, configured and orchestrated in a unified and clearly e.g., Message Oriented Middleware, and now combines defined distributed process.
  • 6. 6 Mike P. Papazoglou, Willem-Jan van den Heuvel Custom Portals Service applications orchestration Reliable Asynchronous Secure Messaging service interface Distributed Web JMS/ MQ Adapters query engine Services J2EE gateway WebSphere Java apps Mainframe , .NET & legacy apps apps Data sources Enterprise Multi-platform applications support Fig. 3 Enterprise service bus connecting diverse applications and technologies. 3. Deployment: Emphasis should be shifted from test is illustrated in Figure-3 where applications running on to the production environment, addressing security, different platforms are abstractly decoupled from each reliability, and scalability concerns. other, and can be connected together through the bus as 4. Management: Services must be audited, maintained logical endpoints that are exposed as event-driven ser- and reconfigured. The latter requirements requires vices. that corresponding changes in processes must be made without rewriting the services or underlying application. Services can be programmed using application devel- 3.1 Event-driven SOA opment tools (like Microsoft .NET, Borland JBuilder, or BEA WebLogic Workshop), which allow new or existing In the enterprise context, business events, e.g., a cus- distributed applications to be exposed as web services. tomer order, the arrival of a shipment at a loading dock, Technologies like J2EE Connector Architecture (JCA) or the payment of a bill, may affect the normal course may also be used to create services by integrating pack- of a business process at any point in time [61]. This im- aged applications (like ERP systems), which would then plies that business processes can not be designed a-priori be exposed as services. assuming that events are predetermined following a par- To achieve its operational objectives the ESB draws ticular flow, but must be defined dynamically, driven by from traditional EAI broker functionality in that it pro- incoming, parallel and a-synchronous event flows. Sup- vides integration services such as connectivity and rout- porting enterprise applications then must communicate ing of messages based on business rules, data transfor- using an Event-Driven SOA ([88], [22]). An event-driven mation, and adapters to applications [23]. These capabil- SOA thus denotes an architectural approach on how en- ities are themselves SOA-based in that they are spread terprises could implement an SOA, respecting the highly out across the bus in a highly distributed fashion and volatile nature of business events. An ESB requires that hosted in separately deployable service containers. This applications and event-driven services are tied together is crucial difference from traditional integration brokers in the context of an SOA in a loosely coupled fashion. are usually highly centralised and monolithic in nature This allows them to operate independently from each [69]. The SOA approach allows for the selective deploy- other while still providing value to a broader business ment of integration broker functionality exactly where function [23]. it is needed with no additional over-bloating. The dis- In an ESB-enabled event-driven SOA, applications tributed nature of the ESB container model allows in- and services are treated as abstract service endpoints, dividual event-driven services to plugged into the ESB which can readily respond to asynchronous events [?]. backbone on an as needed basis, be highly decentralised The event-driven SOA provides a means of abstracting and work together in a highly distributed fashion, while away from the details of underlying service connectivity they are scaled independently from one another. This and protocols.
  • 7. Service Oriented Architectures: 7 Services in this SOA variant are not required to un- its size, format, etc. In contrast to service interfaces how- derstand protocol implementations or have any knowl- ever, meta-data that is associated to events is generated edge on routing of messages to other services. An event on an ad-hoc basis, instead of being static and prede- source typically sends messages through some middle- fined. In particular, ad-hoc meta-data describe published ware integration mechanism like an ESB, and then the events that consumers can subscribe to, the interfaces middleware publishes the messages to the services that that service clients and providers exhibit as well as the have subscribed to the events. The event itself encapsu- messages they exchange, and even the agreed format and lates an activity, constituting a complete description of context of those meta-data, without falling into the for- a specific action. To achieve its functionality, the ESB mal service contracts themselves. supports both the established web services technologies, To effectively orchestrate the behaviour of services including, SOAP, WSDL, and BPEL, as well as emerging in a distributed process, the ESB infrastructure in- standards such as WS-ReliableMessaging [74] and WS- cludes a distributed processing framework and XML- Notification [91]. based services. To exemplify these features, a simplified As we already explained earlier in this section, in a distributed procurement business process as shown in brokered SOA (see Figure-2) the only dependency be- Figure-4, will be configured and deployed using an ESB. tween the provider and client of a service is the service The figure shows that when an automated inventory sys- contract (described in WSDL), which the third-party tem triggers a replenishment signal, an automated pro- service registry advertises. The dependency between the curement process flow is triggered and a series of logi- service provider and the service client is a run-time de- cal steps need to be performed. First the sourcing ser- pendency, not a compile-time dependency. The client ob- vice queries the enterprise’s supplier reference database tains and uses all the information it needs about the ser- to determine the list of possible suppliers, who could be vice at run-time. The service interfaces are discovered prioritized on the basis of existing contracts and supplier dynamically, and messages are constructed dynamically. metrics. A supplier is then chosen based on some crite- The service consumer does not know the format of the rion and the purchase order is automatically generated request message or response message or the location of in an ERP purchasing module and is sent the vendor of the service until it needs a particular service. choice. Finally, this vendor uses an invoicing service to Service contracts and other associated meta-data, in- bill the customer. cluding meta-data about policies and agreements [28], lay the groundwork for enterprise SOAs that involve The ESB distributed processing infrastructure is many clients operating with a complex, heterogeneous aware of applications and services and uses content-based application infrastructure. However, many of today’s routing facilities to make informed decisions about how SOA implementations are not that elaborate. In many to communicate with them. The services that are part of cases, when small or medium enterprises implement the distributed procurement business process depicted in SOA, neither service interfaces in WSDL nor UDDI look- Figure-4 can be seen in use in Figure 3. For this example, ups tend to be available. This is often either due to the the inventory is assumed to be out of stock, and the re- fact that the SOA in place provides for limited function- plenishment message is routed to a supplier order service. ality or because sufficient security arrangements are not Although this figure shows only a single supplier order yet in place. In these cases an event-driven SOA provides service as part of the inventory in reality a plethora of a more lightweight, straightforward set of technologies to supplier services may exist. The supplier order service, build and maintain the service abstraction for client ap- which executes a remote web service at a chosen sup- plications [11]. plier to fulfil the order, generates its output in an XML message format that is not understood by the purchase To achieve a more lightweight arrangement an event- order service. To avoid heterogeneity problems, the mes- driven SOA requires that two participants in an event sage from the supplier order service leverages the ESB’s (server and client) be fully decoupled [11], not just transformation service to convert the XML into a format loosely coupled. With fully decoupled exchanges the two that is acceptable by the purchase order service. Figure participants in an event need not have any knowledge 3 also shows that JCA is used within the ESB to allow about each other, before engaging in some business trans- legacy applications, such as credit check service, to be action. In this case, there is no need for a service (WSDL) placed onto the ESB through JCA resource adapters. contract that explicates the behavior of a server to the client. The only relationship is indirect, through the Once services that are part of the distributed pro- ESB, to which clients and servers are subscribed as sub- curement business process depicted in Figure-5 have scribers and publishers of events. Despite the notion of been chained together, it is essential to provide a way to decoupling in event-driven SOA, recipients of events re- manage and reconfigure them to react to changes in busi- quire meta-data about those events. The publishers of ness processes. Ideally, this could be achieved through the events often organize them on the basis of some (top- a sophisticated graphical business process management ical) taxonomy, which is a form of meta-data. Alterna- tool that can be used to configure, deploy and man- tively, meta-data is available about the event, including age services and endpoints. This allows the free move-
  • 8. 8 Mike P. Papazoglou, Willem-Jan van den Heuvel Sending application Replenishment Sourcing Supplier order Purchase order Invoicing service service service service service Receiving application Fig. 4 Simplified distributed procurement process. ment and reconfiguration of services without requiring and integrated with modern technologies and appli- re-writing or modifying the services themselves. cations. – Service Communication Capabilities: A critical abil- ity of the ESB is to route service interactions through a variety of protocols, and to transform from one pro- 3.2 Key Capabilities tocol to another where necessary. Another important aspect of an ESB implementation is the capacity to In order to implement an SOA, both applications and support service messaging models consistent with the infrastructure must support SOA principles (see section- SOA interfaces, as well as the ability of transmit- 1). Enabling an application for SOA involves the creation ting the required interaction context, such as security, of service interfaces to existing or new functions, either transaction, or message correlation information. directly or through the use of adaptors. Enabling the in- – Dynamic Connectivity Capabilities: Dynamic con- frastructure, at the most basic level, involves provision nectivity pertains to the ability to connect to web ser- of the capabilities to route and deliver service requests vices dynamically without using a separate static API to the correct service provider. However, it is also vital or proxy for each service. Most enterprise applications that the infrastructure supports safe substitution of one today operate on a static connectivity mode, requir- service implementation by another, without any effect to ing some static piece of code for each service. Dy- the clients of that service. This requires not only that the namic service connectivity is key capability for a suc- service interfaces be specified according to SOA princi- cessful ESB implementation. The dynamic connectiv- ples, but also that the infrastructure allows client code ity API is the same regardless of the service imple- to invoke services irrespectively of the service location mentation protocol (web services, JMS, EJB/RMI, and the communication protocol involved. Such service etc.). routing and substitution are amongst the many capabil- – Topic/Content-based Routing Capabilities: The ESB ities of the ESB. Additional capabilities can be found in should be equipped with routing mechanisms to fa- the following list that describes detailed functional re- cilitate not only based, topic-based routing but also, quirements for an ESB. more sophisticated, content-based routing. Topic- We consider this ESB capabilities lists to be neces- based routing assumes that messages can be grouped sary to support the functions of a useful and meaningful into fixed, topical classes, so that subscribers can ex- ESB. Some of the ESB functional requirements described plicate interest in a topic and as a consequence receive in the list below have also been discussed by other au- messages associated to that topic [43]. Content-based thors such as ([78], [19], [51], and [22]). routing on the other hand, allows subscriptions on constraints of actual properties (attributes) of busi- – Leveraging Existing Assets: Legacy applications are ness events. The content of the message thus deter- technically obsolete mission critical elements of an mines their routing to different end-points in the ESB organisation’s infrastructure - as they form the core infrastructure. For example, if a manufacturer pro- of larger enterprise’s business processes – but are too vides a wide variety of products to its customers, frail to modify and too important to discard and thus only some of which are made in-house, depending must be reused. Strategically, the objective is to build on the product ordered it might be necessary to di- a new architecture that will yield all the value hoped rect the message to an external supplier, or route for, but tactically, legacy assets must be leveraged
  • 9. Service Oriented Architectures: 9 Procurement Inventory Order J2EE application application Replenishment Supplier order Replenishment Supplier order service service service service SOAP/ XML/ HTTP JMS Enterprise Service Bus the vendor of choice. SOAP/ XML/ JMS JMS Purchase Order Credit check Purchase Order Credit check service service service service Invoicing Invoicing service service JCA JCA connector connector ERP Invoice Supplier Legacy cc application application Finance Fig. 5 Enterprise service bus connecting remote services. it to be processed by an internal warehouse fulfil- it desirable for the client to select the best endpoint ment service. In a typical application, a message is at run-time, rather than hard-coding endpoints at routed by opening it up and applying a set of rules build time. The ESB should therefore be capable of to its content to determine the parties interested in supporting various qualities of service. Clients can its content. Content-based routing is often depen- query a web service, such as an organizational UDDI dant on the message constructed in XML, and will service, to discover the best instance with which to usually be built on top of Message Oriented Middle- interact based on QoS properties. Ideally, these ca- ware, or JMS based messaging. Such ESB capabili- pabilities should be controlled by declarative policies ties could be based on emerging standard efforts such associated with the services involved using a policy WS-Eventing and WS-Notification. standard such as the WS-PolicyFramework [39]. – Endpoint Discovery with Multiple Quality of Ser- – Integration Capabilities: To support SOA in a het- vice Capabilities: The ESB should support the fun- erogeneous environment, the ESB needs to integrate damental SOA need to discover, locate, and bind to with a variety of systems that do not directly support services. Increasingly these capabilities will be based service-style interactions. These may include legacy around web services standards such as WSDL, SOAP, systems, packaged applications, COTS components, UDDI, and WS-PolicyFramework. As many network etc. When assessing the integration requirements for endpoints can implement the same service contract, ESB, several types or ”styles” of integration must the ESB should support service interactions with dif- be considered. Due their importance ESB integration ferent values to the business. Several scenarios make styles are discussed in some detail late in this article.
  • 10. 10 Mike P. Papazoglou, Willem-Jan van den Heuvel – Transformation Capabilities: The various compo- vices - services that tend to run for long duration, nents hooked into the ESB have their own expec- exchanging message (conversation) as they progress. tations of messaging models and data formats, and Typical examples are an online reservation system, these might differ from other components. A major which interacts with the user as well as various ser- source of value in an ESB is that it shields any in- vice providers (airline ticketing, car reservation, hotel dividual component from any knowledge of the im- reservation, etc). plementation details of any other component. The In addition, it is of vital importance that the ESB transformation services make it possible to en- ESB provides certain transactional guarantees. More sure that messages and data received by any com- specifically, the ESB needs to be able to provide a ponent is in the format it expects, thereby removing means for various applications to interact and mes- the burden to make changes. The ESB plays a major sage with each other and to recover should some form role in transformations between different, heteroge- of technical or process failure occur. The challenge at nous data and messaging models, whether between hand is to ensure that complex transactions are han- legacy data formats (e.g., a COBOL/VSAM applica- dled in a highly-reliable manner and if failure should tion, running on an OS/390 host) and XML, between occur, transactions should be capable of rolling back basic XML formats and web services messages, or be- processing to the original, pre-request state. tween different XML formats (e.g., transforming an – Management and Monitoring Capabilities: In an SOA industry standard XML message to a proprietary or environment, applications cross system (and even or- custom XML format). ganizational) boundaries, they overlap, and they can – Reliable Messaging Capabilities: Reliable messaging change over time. Managing these applications is a refers to the ability to queue service request mes- serious challenge [7]. Examples include dynamic load sages and ensure guaranteed delivery of these mes- balancing, fail-over when primary systems go down, sages to the destination. It also includes the ability and achieving topological or geographic affinity be- to respond, if necessary, back to the requestor with re- tween the client and the service instance, and so sponse messages. Reliable messaging supports asyn- on. Effective systems and application management chronous store-and-forward delivery as well as guar- in an ESB requires a management framework that anteed delivery capabilities. Primarily used for han- is consistent across an increasingly heterogeneous dling events, this capability is crucial for responding set of participating component systems, while sup- to clients in an asynchronous manner, and for a suc- porting complex aggregate (cross-component) man- cessful ESB implementation. agement use cases, like dynamic resource provision- – Security Capabilities: Generically handling and en- ing and demand-based routing, service-level agree- forcing security is a key success factor for ESB im- ment enforcement in conjunction with policy-based plementations. The ESB needs to both provide a se- behaviour. The latter implies the ability to select ser- curity model to service consumers and integrate with vice providers dynamically based on the quality of the (potentially varied) security models of service service they offer compared to the business value of providers. Both point-to-point (e.g., SSL encryption) individual transactions. and end-to-end security capabilities will be required. An additional requirement for a successful ESB im- These end-to-end security capabilities include feder- plementation is the ability to monitor the health, ca- ated authentication, which intercepts service requests pacity and performance of services. Monitoring is the and adds the appropriate username and credentials; ability to track service activities that take place via validation of each service request and authorization the bus and accommodate visibility into various met- to make sure that the sender has the appropriate rics and statistics. Of particular significance is the privilege to access the service; and, lastly, encryp- ability to be able to spot problems and exceptions tion/decryption of XML content at the element level in the business processes and move toward resolving for both message requests and responses. To address them as soon as they occur. Process monitoring ca- these intricate security requirements trust models, pabilities are currently provided by toolsets in plat- WS-Security [8] and other security related standards forms for developing, deploying and managing service have been developed. applications, such as, for instance, WebLogic Work- – Long Running Process and Transaction Capabilities: shop. Service-orientation, as opposed to distributed object – Scalability Capabilities: With a widely distributed architectures such as .NET or J2EE, make it possi- SOA, there will be the need to scale some of the ble to more closely reflect real-world processes and services or the entire infrastructure to meet inte- relationships. It is believed that SOA represents a gration demands. For example, transformation ser- much more natural way to model and build soft- vices are typically very resource intensive and may ware that solves real-world business processing needs require multiple instances across two or more com- [2]. Accordingly, the ESB should provide the ability puting nodes. At the same time, it is necessary to to support business processes and long running ser- create an infrastructure that can support the large
  • 11. Service Oriented Architectures: 11 nodes present in a global service network. The loose remote container. With JSR 168 and WSRP maturing, coupled nature of a SOA requires that the ESB uses the possibility of a true EJB federated portal can become a decentralized model to provide a cost effective solu- a reality. tion that promotes flexibility in scaling any aspect of Application connectivity: Application connectiv- the integration network. A decentralized architecture ity is an integration style concerned with all types of enables independent scalability of individual services connectivity that the ESB integration layer must sup- as well as the communications infrastructure itself. port. At the infrastructure level, this means concerns such as synchronous and asynchronous communications, As ESB integration capabilities in the above list are routing, transformation, high speed distribution of data, central in understanding the material that follows and a and gateways and protocol converters. On the processing key element of the ESB when performing service-oriented level, application connectivity also relates to the virtual- integration, we shall consider them in some detail in the ization of input and output, or sources and sinks. remainder of this section. Virtualization signifies the fact that input are re- ceived and passed to applications in the ESB in a source- 3.3 Integration Styles neutral way. Special purpose front-end device and pro- tocol handlers should make that possible. For connec- ESBs employ a service-oriented integration solution that tivity, an ESB can utilize J2EE components such as leverages amongst other issues open standards, loose the Java Message Service for MOM connectivity, and coupling, and the dynamic description and discovery ca- J2EE Connector Architecture for connecting to appli- pabilities of web services to reduce the complexity, cost cation adapters. An ESB can also integrate easily with and risk of integration. Other salient characteristics of applications built with .NET, COM, C#, C++ and C. the ESB architectural integration style are that it is In addition, an ESB can integrate easily with any appli- technology agnostic and can reuse functionality in ex- cation that supports SOAP and web services. isting applications to support new application develop- Application Integration: Application integration ment. There is a series of important technical require- is concerned with building and evolving an integration ments that need to be addressed by a service-oriented backbone capability that enables fast assembly and dis- integration solution ([51], [37]). These include: assembly of business software components. Application Integration at the presentation-tier: Integration integration is an integral part of the assembly pro- at the presentation-tier is concerned with how the com- cess that facilitates pragmatic ’best of breed’ portfolio plete set of applications and services a given user accesses strategies which combine legacy applications, acquired are fabricating a highly distributed yet unified portal packages, external application subscriptions and newly framework that provides a usable, efficient, uniform and built components. The ESB should focus on a service- consistent presentation-tier. In this way, the EJB can based application integration style that enables better- provide one face to the users resulting in consistent user structured integration solutions that deliver: experience, with unified information delivery while al- – Applications comprised of interchangeable parts that lowing underlying applications remain distributed. Two are designed to be adaptable to business and tech- complementary industry standards that are emerging in nology change. the portal space, can assist with these efforts [75]: – Evolutionary application portfolios that protect in- 1. JSR 168: This is an industry standard that defines a vestment and can respond rapidly to new require- standard way to develop portlets. It allows portlets ments and business processes to be interoperable across portal vendors. For exam- – Integration of various platform and component tech- ple, portlets developed for BEA WebLogic Portal can nologies. be interoperable with IBM Portal. This allows orga- nizations to have a lower dependency on the portal Process Integration: Process integration is con- product vendor. cerned with the development of automated processes 2. WSRP (Web Service for Remote Portals): This is that map to and provide solutions for business processes, an industry standard that allows remote portlets to integration of applications into processes, and integrat- be developed and consumed in a standard manner ing processes with other processes. Process-level integra- and facilitates federated portals. WSRP combines the tion may include the integration of business processes power of web services and portal technologies and is and applications within the enterprise (viz. EAI solu- fast becoming the major enabling technology for dis- tions). It also may involve the integration of whole pro- tributed portals in an enterprise. cesses, not just individual services, from external sources, such as supply chain management or financial services JSR 168 complements WSRP by dealing with local that span multiple institutions (viz. e-Business integra- rather than distributed portlets. A portal page may have tion solutions). certain local portlets which are JSR 168 compliant and Data Integration: Information integration [72] is some remote, distributed portlets that are executed in a the process of providing a consistent access to all the data
  • 12. 12 Mike P. Papazoglou, Willem-Jan van den Heuvel in the enterprise, by all the applications that require it, in we use the simplified distributed procurement process whatever form they need it, without being restricted by shown in Figure-4. Figure-6 exemplifies that when an au- the format, source, or location of the data. This require- tomated inventory system triggers a replenishment sig- ment, when implemented, might involve adapters and nal, an automated procurement process flow is triggered transformation facilities, aggregation services to merge and first the enterprise’s supplier reference database is and reconcile disparate data, e.g., merging two customer queried to determine the list of possible suppliers, who profiles, and validation to ensure data consistency, e.g., could be prioritized on the basis of existing contracts and minimum income should be equal to or exceed a certain supplier metrics. A supplier is then chosen based and the threshold. Data should be transformed irrespectively of purchase order is automatically generated in the ERP the formats under which it exists, the operating system purchasing module and is sent to the vendor of choice. that manages the data, and the location where the data The figure illustrates that the integration-broker is is stored. the system centrepiece. The integration-broker facilitates Integration design and development method- information movement between two or more resources ology: One of the requirements for the application de- (source and target applications) and accounts for differ- velopment environment must be that it takes into ac- ences in application semantics and heterogeneous plat- count all the styles and levels of integration that could forms. The various existing (or component) Enterprise be implemented within the enterprise, and provide for Information Systems (EIS), such as Customer Relation- their development and deployment. To be truly robust, ship Management, ERP systems, transaction processing the development environment must rely on a method- monitors, legacy systems and so on, in this configuration ology that clearly prescribes how services and compo- are connected to the integration broker by means of re- nents are designed and built in order to facilitate reuse, source adapters. A resource adapter is used to provide eliminate redundancy, and simplify integration, testing, access to a specific EIS. The purpose of the adapters is deployment, and maintenance. to provide a reliable insulation layer between application All of the styles of integration listed above will have APIs and the messaging infrastructure. These adapters some form of incarnation within any enterprise, even enable non-invasive application integration in a loosely though in some cases they might be simplified or not coupled configuration. clearly defined. It is important to note that all integra- Integration brokers are able to share information with tion styles must be considered when embarking on an a multitude of systems by using an asynchronous, event- ESB implementation. driven mechanism thus they constitute an ideal support framework for asynchronous business processes. Integra- tion brokers, as realized in enterprise application integra- 3.4 Enabling Technologies tion suites, have historically been used for the integration of packaged applications via specific and often heavily In this section, we will review the technological under- customized adapters. Nowadays, this type of middleware pinnings of ESBs in some more detail. Fundamentally, is responsible for brokering messages exchanged between ESBs fuse the following four types of technologies: in- multiple applications, providing the ability to transform, tegration brokers, application servers, business process store, and route messages, also the ability to apply busi- management and adapters. ness rules and respond to events. The integration broker architecture presents several 3.4.1 Integration Brokers advantages as it tries to reduce the application integra- tion effort by providing pre-built functionality common A prominent technology to interconnect disparate busi- to many integration scenarios. The value proposition ness applications, many of which are home-grown, ERP rests on reuse (in terms of middleware infrastructure and systems or legacy systems, constitutes integration bro- the application integration logic) across multiple appli- kers. Integration brokers come in many manifestations, cations and initiatives. Modern integration brokers in- ranging from early application-to-application brokers to corporate integration functionality such as: transforma- more sophisticated broker topologies managing transac- tion facilities, process integration, business process man- tions, security, (resource) adapters and application pro- agement and trading partner management functionality, tocols [18]. Some examples of commercially available in- packaged adapters, and user-driven applications through tegration brokers include: IBM’s WebSphere Integration front-end capabilities such as Java Server Pages (JSP). Broker, PeopleSoft’s AppConnect, and Sun ONE Inte- gration Server. Figure-6 presents a high-level view of the typical ar- 3.4.2 Application Servers chitecture for implementing integration broker. In par- ticular, this figure illustrates the use of an integration Application servers are widely used to develop and de- broker to integrate functions and information from a va- ploy back-end server logic. Application servers enable riety of back-end enterprise information systems. To ef- the separation of application (or business) logic and in- fectively illustrate the workings of the integration broker, terface processing and also coordinate many resource
  • 13. Service Oriented Architectures: 13 • Application integration • Business Processes • Business Rules • Meta-data Meta- • Data Transformation integrating application • Message Routing (contains busines composition logic) logic) Integration Broker Inventory Supplier ERP adapter data adapter adapter Replenishment Replenishment Sourcing Generate PO Send PO signal Sourcing Generate PO Send PO signal Supplier Inventory Reference ERP Supplier Management Database Fig. 6 Integration broker integrating disparate back-end systems. connections. The most prominent features of applica- Unlike integration brokers, they do not integrate back- tion servers include secure transactional execution en- end systems directly. vironment, load balancing, application-level clustering Because application servers were created for Web- across multiple servers, failover management should one based transactions and application development and be- of these servers break down [58]. In addition, application cause of their ability to provide component-based inte- servers provide application connectivity and thus access gration to back-end applications makes make them useful to data and functions associated with EIS applications, as support framework for integrating business processes. such as ERP, CRM and legacy applications. While appli- cation servers are focused on supporting new application Figure 10 illustrates the use of an application server development, they do not natively support integration. for a wholesale application that brings together ERP ca- pabilities with sophisticated customer interfaces to open Application servers, such as SUN’s J2EE [36], IBM’s up new models of sales and distribution. The compo- WebSphere [41] and Microsoft’s .NET [59], typically nent wrappers in this figure facilitate point-integration provide Web connectivity for extending existing solu- of component systems, e.g., ERP, CRM and distributor tions and bring transaction processing mechanisms to the databases, as they introduce each of them to the appli- Web. In essence, an application server is simply a collec- cation server. A component wrapper may be defined as tion of services that support the development, run-time a software layer that encapsulates legacy data and logic execution, and management of business logic for Web- and defines its services in the wrapper API. The wrap- enabled applications. The application server middleware per API mediates between calls from client application enables the functions of handling transactions and ex- components to the underlying legacy code and data, by tending back-end business data and applications to the transforming incoming requests into a message format Web. Application servers retrieve information from many that is understandable to the internal code and data [81], existing enterprise systems and expose them through a [83]. single interface, typically a Web browser. This makes ap- The terms “adapter’ and “wrapper” are often used in- plication servers ideal for portal-based EAI development. terchangeably, as we will also do throughout this article.
  • 14. 14 Mike P. Papazoglou, Willem-Jan van den Heuvel Java/EJB-based Java/EJB- Web-based Web- CORBA/COM -based client client client • Front-end of many EAI initiatives, Front- (i.e. composites) • Application connectivity • Business Processes • Business Rules • Security • Transaction Mgt • Message Routing Web server Application development tools Application server Component Component Component Component Component Component Wrapper Wrapper Wrapper Wrapper Wrapper Wrapper Adapter Adapter Adapter Adapter Adapter Adapter Distributor ERP application CRM application data Fig. 7 Application server providing access to back-end systems. Another term that is often adopted in the same context Execution in this type of architecture occurs among of that of wrappers, is the term ”connector”. A connector component wrappers within the application server. refers to the encapsulation of a communication mecha- These component wrappers wrap back-end resources nism. This term originates from architectural descrip- such as databases, ERP, transaction mainframe systems tion languages (ADLs), while the design pattern which and legacy systems so that they can express data and is concerned with the encapsulation of the communica- messages in the standard internal format expected by the tion between components is called “Mediator” [17]. The application server. The application server is oblivious to prime distinction between a connector and an adapter is the fact that these components are only the external fa- that an adapter bridges an interoperability problem, i.e., cade of existing EIS that do the real processing activities without the adapter the components would not be able [60]. to work together, while a connector enables the commu- The adapter/component wrapper pairs in the archi- nication between to interoperable components [94]. tecture illustrated in Figure-7 are responsible for provid- ing a layer of abstraction between the application server Simply speaking, a component wrapper contains a and the component EIS. This layer allows for EIS com- software layer that encapsulates legacy data and logic ponent communications, as if the component EIS were and defines its services in the wrapper API. The wrap- executed within the application server environment it- per API mediates between calls from client application self. Traditional application servers constitute an ideal components to the underlying legacy code and data, by support framework for synchronous business processes. transforming incoming requests into a message format However, newer generation application servers offer also that is understandable to the internal code and data. asynchronous communication.
  • 15. Service Oriented Architectures: 15 Web application servers already provide database all kinds. Application boundaries may range from simple connectivity, transaction management, EAI-style con- enquiries about a customer’s order involving two appli- nectors, message queuing, and are gradually evolving cations, to complex, long-lived transactions for process- into business process execution engines. They also facil- ing an insurance claim involving many applications and itate reliability, scalability, and availability, while at the human interactions, to parallel business events for ad- same time automating application development tasks. vanced planning, production and shipping of goods along In concluding, a few words about application server the supply chain involving many applications, human in- implementation. Application servers are principally teractions and business to business interactions. When J2EE-based and include support for JMS [47], the Java integrating on such a scale, enterprises need a greater 2 Connector Architecture (J2CA) [46], and even web ser- latitude of functionality to overcome multiple challenges vices. arising from the existence of proprietary interfaces, di- JMS is a transport-level API that enterprises can verse standards, and approaches targeting the techni- combine with web service solutions for messaging, data cal, data, automated business process, process analysis persistence, and access to Java-based applications. JMS and visualization levels. Such challenges are addressed is a vendor agnostic API for enterprise messaging that by business process management (BPM) technology [95]. can be used with many different MOM vendors. JMS BPM is the term used to describe the new generation of frameworks function in asynchronous mode but also technology that provides end-to-end visibility and con- offer the capability of simulating a synchronous re- trol over all parts of a long-lived, multi-step information quest/response mode [68]. For application server im- request or transaction/process that spans multiple ap- plementations, JMS provides access to business logic plications and human actors in one or more enterprises distributed among heterogeneous systems. Having a [57]. message-based interface enables point to point and pub- Specialised capabilities of BPM software solutions in lish/subscribe mechanisms, guaranteed information de- an ESB setting include workflow-related business pro- livery, and interoperability between heterogeneous plat- cesses, process analysis and visualization techniques. In forms. particular, BPM allows the separation of business pro- J2EE Connector Architecture is an emerging tech- cesses from the underlying integration code. Before we nology that has been specifically designed to address the explain further characteristics and typical elements of hardships of integrating applications. J2CA provides a BPM, it is useful to distinguish between the concepts standardized method for integrating disparate applica- of process automation, workflow and business processes tions in J2EE application architectures. It provides sup- management. port for resource adaptation, which maps the J2EE secu- All enterprises have business processes that require rity, transaction, and communication pooling to the cor- process automation. Any process automation tool should responding EIS technology. J2CA defines a set of func- be able to easily control and coordinate activity and tionality that application server vendors can use to con- provide an easy method to define the business process nect to back-end EIS, such as ERP, CRM and legacy and the underlying flows of information between appli- systems and applications. Using J2CA to access enter- cations. Process automation is distinct from traditional prise information systems is akin to using JDBC (Java document workflow as it involves integration between Database Connectivity) [98] to access a database. When computer-based systems and manual steps and tasks. It J2CA is used in an ESB implementation, the ESB could is implemented for automating the flow of information provide a J2CA container that allows packaged or legacy between applications to fulfil business processes. Tradi- applications to be plugged into the ESB through J2CA tional workflow tools focus instead on handling the move- resource adapters. For instance, a process order service ment of documents between people who are required to uses JCA to talk to a J2EE application that internally perform tasks on these documents [56]. This may or may fulfils incoming orders. The latest versions of many appli- not be directly associated with managing a business pro- cation servers, including BEA WebLogic and IBM Web- cess. For example, an order may generate a shipping no- Sphere, support J2CA adapters for enterprise connectiv- tice. The shipping notice may in turn generate a monthly ity. In addition, major packaged application vendors have invoice that encompasses many orders for the same cus- also announced plans to support JCA in future product tomer. This is an example of a workflow that changes offerings. The ESB uses J2CA to facilitate application focus several times. It is not tracking the order to com- integration between existing applications and services. pletion, but rather, it tracks only the information gener- ated. 3.4.3 Business Process Management A business process includes both automated and manual processes. Business process automation combines Today enterprises are striving to become electronically process automation together with task-based workflow connected to their customers, suppliers, and partners. into a managed, end-to-end process [56]. To achieve this, they are integrating a wide range of dis- BPM codifies value-driven processes and institution- crete business processes across application boundaries of alises their execution within the enterprise [79]. This
  • 16. 16 Mike P. Papazoglou, Willem-Jan van den Heuvel implies that BPM tools, such as Chordiant 1 , Pega 2 based routing to create an SOA that solves complex inte- and Fuego 3 , can help analyse, define and enforce pro- gration problems. An ESB uses the concept of itinerary- cess standardisation. BPM provides a modelling tool to based routing to provide a message with a list of routing visually construct, analyse and execute cross-functional instructions. In an ESB, routing instructions, which rep- business processes. Design and modelling of business pro- resent a business process definition, are carried with the cesses is accomplished by mans of sophisticated graphical message as it travels through the bus across service in- tools. In the previous example, BPM would enable the vocations. The remote ESB service containers determine modelling of the broader order management process en- where to send the message next, making this type of compassing order receipt, perhaps credit approval, ship- routing a special category of content-based routing. ping and invoicing. Combining BPM with real-time anal- The ESB can also benefit from products developed ysis allows business managers to not only track where by BPM vendors such as IBM’s WebSphere, HP’s HP orders are in this process, but also to understand the Process Manager, BEA’s WebLogic, and Vitria’s Busi- company’s exposure with regard to orders in total at nessWare. Microsoft BizTalk is another good example of any given point in time. a BPM integration product, but its use is limited to Mi- BPM is a commitment to expressing, understanding, crosoft Windows and .NET servers. Commercial BPM representing and managing a business (or the portion of solutions such as, for instance, Vitria’s BusinessWare-4 business to which it is applied) in terms of a collection of provide organisations with a number of mechanisms for business processes that are responsive to a business en- simplifying the deployment and management of an in- vironment of internal or external events [66]. The term tegration solution. They consist of range of tools and management of business processes includes process anal- technologies that allow the organisation to model, test, ysis, process definition and redefinition, resource alloca- deploy, and refine such a process-driven integration so- tion, scheduling, measurement of process quality and ef- lution. ficiency, and process optimisation. Process optimisation includes collection and analysis of both real-time mea- sures (monitoring) and strategic measures (performance 3.5 Adapters management), and their correlation as the basis for pro- cess improvement and innovation. For the most part, business applications in an enter- A BPM solution is a graphical productivity tool for prise are not designed to communicate with other ap- modelling, integrating, monitoring, and optimising pro- plications. There is often an interoperability mismatch cess flows of all sizes, crossing any application, company between the technologies used within internal systems boundary, or human interaction. BPM is driven primar- and with external trading partner systems. In order to ily by the common desire to integrate supply chains, as seamlessly integrate these disparate applications, there well as internal enterprise functions, without the need must be a way in which a request for information in one for even more custom software development. This means format can easily be transformed into a format expected that the tools must be suitable for business analysts, by the called service. For instance, in Figure-3 the func- requiring less (or no) software development. They must tionality of a J2EE application needs to bee exposed to reduce maintenance requirements because internally and non-J2EE clients such as .NET applications and other externally integrated environments routinely require ad- clients. In doing so, a web service may have to integrate ditions and changes to business processes. BPM promises with other instances of enterprise information systems in the ability to monitor both the state of any single pro- an organisation, or the J2EE application itself may have cess instance and all instances in the aggregate, using to integrate with other EISs. In such scenarios, how the present real-time metrics that translate actual process application exchanges information to the ESB depends activity into key performance indicators. on the application accessibility options. There are three When sophisticated process definitions are called for alternative ways an application can exchange informa- in an ESB, a process orchestration engine – that sup- tion with the ESB include [37]: ports BPEL [5] or some other process definition language such as ebXML Business Process Specification Schema 1. Application-provided web service interface: Some (BPSS) [93] – may be layered onto the ESB. The pro- applications and legacy application servers have cess orchestration may support long-running, stateful adopted the open standards philosophy and have in- processes, just like BPEL. In addition, it may support cluded a web services interface. The WSDL defines parallel execution paths, with branching, and merging the interface to communicate directly with the appli- of message flow execution paths based on join conditions cation business logic. Where possible, taking a direct or transition conditions being met. Sophisticated process approach is always preferred. orchestration can be combined with stateless, itinerary- 2. Non-web service interface: The application does not expose business logic via web services. An 1 www.chordiant.com application-specific adapter can be supplied to pro- 2 www.pega.com vide a basic intermediary between the application 3 www.fuego.com API and the ESB.
  • 17. Service Oriented Architectures: 17 3. Service wrapper as interface to adapter: In some line bill payment, for example. User events can naturally cases the adapter may not supply the correct pro- be generated by applications such as an order manage- tocol (JMS, for example) that the ESB expects. In ment application requiring a customer status check from this case, the adapter would be web service enabled. an accounting system. On the other hand, a state change in a data object can be an activity like the addition of a Adapters provide connectivity and translation ser- new customer record in the customer service application vices between applications and collaborations [84]. An or an update to the customer’s billing address. These adapter provides services between the integration bro- state changes trigger an adapter to add the new cus- ker and the application-specific component, such as an tomer record or update the customer record in all other ERP or CRM application. Resource adaptors translate applications that keep their own copies of customer data. the applications’ messages to and from a common set of standards - standard data formats and standard commu- Routing of events from service requester to ser- nication protocols. When an application sends a message vice providers may basically occur in two ways, us- to another application, its adapter first translates the ing content-based or topic (subject)-based routing (see message into a standardized form. When the message section-3.4.1). Both routing mechanisms run on top of is received by the target application, another adapter elementary Internet-technologies for routing, e.g., DNS translates the standardized message into the target ap- routing. Currently, routing of events is standardized in plication’s native format and protocol. WS-Notification. An adapter can expose either a synchronous and WS-Notification defines a general, topic-based web asynchronous mode of communication between the client service system for publish and subscribe interactions, application and the EIS. The adapter provides a variety which relies on the WS-Resource framework [45]. The of transformation services including support for complex Web Services Notification Framework defines how the data structures from one data source to another, for ex- publish/subscribe pattern commonly used in message- ample, between COBOL copybooks and XML, complex oriented middleware products can be realized using web XML-to-XML vocabularies, IDL, ODL, legacy, database services. systems, and so on. Messages are first transformed into an intermediate state (either IDL, XML, or Java Inter- WS-Notification [91] is a family of related specifica- faces) before being formatted. An adapter typically pro- tions that define a standard web services approach to no- vides support for a range of date/time conversion func- tification using a topic-based publish/subscribe pattern. tions, EBCDIC/ASCI, binary and character conversion The WS-Notification specification defines standard mes- functions, EDI (via EDI module), and a number of func- sage exchanges to be implemented by service providers tions for splitting/combining data fields. Furthermore, it that wish to participate in notifications and standard can incorporate a native XML parser and provides sup- message exchanges - allowing publication of messages port for popular e-Commerce trading protocols such as from entities that are not themselves service providers. It RosettaNet [101], ebXML [33], cXML 4 , and xCBL 5 . also allows expressing operational requirements expected As complementary technologies in an ESB implemen- of service providers and requesters that participate in no- tation, (resource) adapters and web services can work tifications. WS-Notification allows notification messages together to implement complex integration scenarios in- to be attached to WSDL PortTypes. The current WS- volving federated ESBs spanning multiple organizations , Notification specification provides support for both bro- see Figure-8. Data synchronization (in addition to trans- kered as well as peer-to-peer publish/subscribe. lation services) is one of the primary objectives of re- source adapters. Adapters can thus take on the role of Reverting to the J2EE to .NET application connec- data synchronization and translation services, whereas tivity scenario, a connectivity service in the form of web services will enable application functions to interact a resource adapter is required. In this implementation with each other. Web services are an ideal mechanism for strategy, web services can become the interface between implementing a universally accessible application func- the company and its customers, partners, and suppliers; tion (service) that may need to integrate with other ap- whereas the resource adapters become integration com- plications to fulfil its service contract. The drivers of ponents tying up different EISs inside the company. This data synchronization and web services are also differ- is just one potential implementation pattern in which ent. Web services will generally be initiated by a user web services and resource adapters can coexist. Another request/event, whereas data synchronization is generally potential integration pattern in which web services and initiated by state changes in data objects (for example, resource adapters are required to collaborate is in busi- customer, item, order and so on). ness process integration. Applications that are part of a An event to which a web service reacts could be a specific business process will have to expose the required user initiated request such as a purchase order or an on- processes (functions), and web services are ideal for that purpose. When the applications need to integrate with 4 http://www.cxml.org other EISs to fulfil their part in the business process, 5 http://eco.commerce.net they will use resource adapters.
  • 18. 18 Mike P. Papazoglou, Willem-Jan van den Heuvel Clients service client service client service client WSDL/SOAP WSDL/SOAP WSDL/SOAP WSDL/SOAP WSDL/SOAP WSDL/SOAP Topic-based and Content-based ESB Publish and Subscribe Components “WS-Notification, WS-Topics” DNS Router Internet DNS Router WSDL/SOAP interface WSDL/SOAP interface WSDL/SOAP interface interface interface interface interface interface interface Adapter Adapter Adapter Adapter Adapter Adapter Existing EIS & Proprietary Proprietary Proprietary Middleware interfaces interfaces interfaces Platforms Legacy ERP Data Appl. Appl. System Warehouse Fig. 8 Combining web services with resource adapters. 4 Extending the SOA tional SOA (for example building simple applications) from more advanced service functionality needed for composing services and the need to distinguish between A basic SOA, i.e., the architecture depicted in Figure- the functionality for composing services from that of the 2, implements concepts such as service registration, dis- management of services. As shown in Figure-9, the xSOA covery, composition, and load balancing of service re- utilizes the basic SOA constructs as its bottom layer and quests. The essential ESB requirements, however, sug- layers service composition and management on top of it. gest that this approach be extended to support capa- bilities such as service orchestration, ”intelligent” rout- The bottom layer in the xSOA is identical to the ba- ing, provisioning, and service management. It should also sic SOA (see Figure-2) in that it defines an interaction guarantee the integrity and security of messages. Such between software agents as an exchange of messages be- overarching concerns are addressed by the extended SOA tween service requesters (clients) and service providers. (xSOA) [63], [71]. The xSOA is an attempt to stream- These interactions involve the publishing, finding and line, group together and logically structure the functional binding of operations. requirements of complex applications that make use of In a typical service-based scenario employing the ba- the service-oriented computing paradigm. The xSOA is sic services layer in the xSOA, a service provider hosts a a stratified service-based architecture. The architectural network accessible software module. The service provider layers in the xSOA, which are depicted in Figure-9, em- defines a service description, and publishes it to a client brace a multi-dimensional, separation of concerns [70] in (or service discovery agency) through which a service de- such a way that each layer defines a set of constructs, scription is advertised and made discoverable. The ser- roles and responsibilities and leans on constructs of its vice client (requestor) discovers a service (endpoint) and predecessor layer to accomplish its mission. The logical retrieves the service description directly from the service separation of functionality is based on the need to sep- (Metadata Exchange) or from a registry or repository arate basic service capabilities provided by the conven- like UDDI; it uses the service description to bind with the
  • 19. Service Oriented Architectures: 19 service provider and invoke the service or interact with poses constraints on the component services (e.g., to the service implementation. Service provider and service ensure enforcement of business rules), and performs client roles are logical constructs and a service may ex- data fusion activities. Service conformance comprises hibit characteristics of both. For reasons of conceptual three parts: typing, behavioural and semantic confor- simplicity in Figure-9, we assume that service clients, mance. Typing (syntactic) conformance is performed providers and aggregators could act as service brokers or at the data typing level by using principles such as service discovery agencies and publish the services they type-safeness, co-variance and contra-variance for sig- deploy. The role actions in this figure also indicate that nature matching [94]. Behavioural conformance en- a service aggregator entails a special type of provider. sures the correctness of logical relationships between The service composition layer in the xSOA encom- component operations that need to be blended to- passes necessary roles and functionality for the aggre- gether into higher-level operations. Behavioural con- gation of multiple services into a single composite ser- formance guarantees that composite operations do vice. Resulting composite services may be used by ser- not lead to spurious results and that the overall pro- vice aggregators as basic services in further service com- cess behaves in a correct and unambiguous manner. positions or may be utilized as applications/solutions Finally, semantic conformance ensures that services by service clients. Service aggregators thus become ser- and operations are annotated with domain-specific vice providers by publishing the service descriptions of semantic properties (descriptions) so that they pre- the composite service they create. As already explained serve their meaning when they are composed and can in section-2, a service aggregator is a service provider be formally validated. Service conformance is a topic that groups services that are provided by other service still under research scrutiny ([94], []). Concrete solu- providers into a distinct value added service. Service ag- tions exist only for typing conformance [67], [20] as gregators develop specifications and/or code that permit they are based on conformance techniques for pro- the composite service to perform functions that are based gramming languages such as Eiffel or Java. on the following facilities (in addition to web services in- – Coordination: controls the execution of the compo- teroperation support provided by WSI profiles for service nent services (processes), web services transactions descriptions [9] and security [10]): and manages dataflow as well as control flow among them and to the output of the component service – Meta-data, standard terminology and reference mod- (e.g., by specifying workflow processes and using a els: web services need to use meta-data to describe workflow engine for run-time control of service exe- what other endpoints need to know to interact with cution). them. Such meta-data gives high-level semantic de- – Monitoring: allows monitoring events or information tails regarding the structure and contents of the mes- produced by the component services, monitoring in- sages received and sent by web services, message op- stances of business processes, viewing process in- erations, concrete network protocols, and endpoint stance statistics, including the number of instances addresses used by web services; it also describes ab- in each state (running, suspended, aborted or com- stractly the capabilities, requirements, and general pleted), viewing the status, or summary for selected characteristics of web services and how they can in- process instances, suspend, and resume or terminate teroperate with other services. Web service meta- selected process instances. Of particular significance data need to be accompanied with standard termi- is the ability to be able to spot problems and ex- nology to address business terminology fluctuations ceptions in the business processes and move toward and reference models such as, for instance, Roset- resolving them as soon as they occur. Process moni- taNet PIPS [101], to allow applications to define data toring capabilities are currently provided by toolsets and processes that are meaningful not only to their in platforms for developing, deploying and manag- own businesses but also to their business partners ing service applications, such as, for instance, BEA’s while also maintaining interoperability (at the se- WebLogic and Vitria’s BusinessWare. mantic level) with other business applications. The – Policy enforcement: web service capabilities and re- purpose of combining meta-data, standard terminol- quirements can be expressed in terms of policies. In ogy and reference models is to enable business pro- particular, policies [87] may be applied to manage cesses to capture and convey their intended mean- a system or organize the interaction between web- ing and exchange requirements, identifying amongst services [4]. For example, knowing that a service sup- other things the meaning, timing, sequence and pur- ports a web services security standard such as WS- pose of each business collaboration and associated Security is not enough information to enable success- information exchange. ful composition. The client needs to know if the ser- – Conformance: conformance needs to be guaranteed at vice actually requires WS-Security, what kind of se- three levels: service, behavior and semantics. Service curity tokens it is capable of processing, and which conformance ensures the integrity of a composite ser- one it prefers. The client must also determine if the vice by matching its operations and parameter types service requires signed messages. And if so, it must with those of its constituent component services, im-
  • 20. 20 Mike P. Papazoglou, Willem-Jan van den Heuvel determine what token type must be used for the digi- collecting metrics and tuning to ensure responsive service tal signatures. And finally, the client must determine execution. The management layer in xSOA requires that when to encrypt the messages, which algorithm to a critical characteristic be realized: that services be man- use, and how to exchange a shared key with the ser- aged. In fact, the very same well-defined structures and vice. Trying to orchestrate with a service without un- standards that form the basis for web services also pro- derstanding these details may lead to erroneous re- vide opportunities for use in managing and monitoring sults. communications between services, and their underlying resources, across numerous vendors, platforms, technolo- Standards such BPEL and WS-Choreography [16] gies, and topologies. that operate at the service composition layer in xSOA Service management includes many interrelated func- enable the creation of large service collaborations that tions [38]. The most prominent functions of service man- go far beyond allowing two companies to conduct busi- agement are summarized in the following: ness in an automated fashion. We also expect to see much larger service collaborations spanning entire in- 1. Service-Level Agreement (SLA) Management. This dustry groups and other complex business relationships. may include QoS (e.g., sustainable network band- These developments necessitate the use of tools and utili- width with priority messaging service) [48]; service re- ties that provide them insights into the health of systems porting (e.g., acceptable system response time); and that implement web services and into the status and be- service metering. haviour patterns of loosely coupled applications. A con- 2. Auditing, Monitoring, and Troubleshooting. This sistent management methodology is essential for leverag- may include providing service performance and uti- ing a management framework for a production-quality, lization statistics, measurement of transaction arrival service-based infrastructure and applications. The ratio- rates and response times, measurement of transaction nale is very similar to the situation in traditional dis- loads (number of bytes per incoming and outgoing tributed computing environments, where systems admin- transaction), load balancing across servers, measur- istrators rely on programs/tools/utilities to make certain ing the health of services and troubleshooting. that a distributed computing environment operates reli- 3. Dynamic Services (or Resources) Provisioning. ably and efficiently. This may include provisioning services and Managing loosely coupled applications in an SOA resources to authorized personnel, dynamic inherently entails even more challenging requirements. allocation/deallocation of hardware, installa- Failure or change of a single application component can tion/deinstallation of software ”on demand” based bring down numerous interdependent enterprise applica- changing workloads, ensuring SLAs, management tions. The addition of new applications or components policies for messaging routing and security, and can overload existing components, causing unexpected reliable SOAP messaging delivery. degradation or failure of seemingly unrelated systems. 4. Service lifecycle/state management: This may in- Application performance depends on the combined per- clude exposing the current state of a service and formance of cooperating components and their interac- permit lifecycle management including the ability to tions. To counter such situations, enterprises need to con- start and stop a service, the ability to make specific stantly monitor the health of their applications. The per- configuration changes to a deployed web service, sup- formance should be in tune, at all times and under all port the description of versions of web services and load conditions. notification of a change or impending change to the Managing critical web service based applications re- service interface or implementation. quires in-depth administration and management capa- 5. Scalability/Extensibility: The web services support bilities that are consistent across an increasingly het- environment should be extensible and must permit erogeneous set of participating distributed component discovery of supported management functionality in systems, while supporting complex aggregate (cross- a given instantiation. component) management use cases, like service-level To manage critical applications/solutions and collab- agreement enforcement and dynamic resource provision- orations spanning entire industry groups and other com- ing. Such capabilities are provided by the topmost layer plex business relationships, e.g., specific service markets, in the xSOA. the xSOA management services are divided in two com- We could define web services management as the plementary categories ([63], [71]): functionality required for discovering the existence, avail- ability, performance, health, patterns of usage, extensi- 1. Service operations management that can be used to bility, as well as the control and configuration, life-cycle manage the service platform, the deployment of ser- support and maintenance of a web service or business vices and the applications and, in particular, moni- process within the context of SOAs. Service management tor the correctness and overall functionality of aggre- encompasses the control and monitoring of SOA-based gated/orchestrated services. applications throughout their life cycle [34]. It spans a 2. Service market management that supports typical range of activities from installation and configuration to integrated supply chain functions and provides a
  • 21. Service Oriented Architectures: 21 Market maker Service operator Mana- Role actions gement Market performs •Certific •Ratin ation Manage publishes •SLAs g d services Operati uses •Assura ons becomes •Suppo nce rt Compo Compos sition ite servic •Coordin es atio •Conform n ance Service provider •Monito ring Basic se •Seman rvices tics Descrip tion & B tio asic Op •Capab eration ility s •Interfac •Publica e tion •Behavio •Discov r ery •QoS •Selecti on •Binding Service client Service aggregator Fig. 9 Extended SOA comprehensive range of services supporting industry- cation status notifications when a particular activity is trade, including services that provide business trans- completed or when a decision condition is reached. We action negotiation and facilitation, financial settle- refer to the role responsible for performing such opera- ment, service certification and quality assurance, rat- tion management functions as the service operator. De- ing services, service metrics, and so on. pending on the application requirements a service oper- ator could be a service client or service aggregator. The xSOA’s service operations management func- tionality is aimed at supporting critical applications that Service operations management is a critical function require enterprises to manage the service platform, the that can be used to monitor the correctness and over- deployment of services and the applications. xSOA’s ser- all functionality of aggregated/orchestrated services thus vice operations management typically gathers informa- avoiding a severe risk of service errors. Considerations tion about the managed service platform, web services need also be made for modelling the context in which and business processes and managed resource status and a given service is being leveraged individual, composite, performance, and supporting specific management tasks part of a long-running business process, and so on. In or- (e.g., root cause failure analysis, SLA monitoring and der to successfully compose web services processes, one reporting, service deployment, and life cycle manage- must fully understand the service’s WSDL contract along ment and capacity planning). Operations management with any additional requirements, capabilities, and poli- functionality may provide detailed application perfor- cies (preferences). In this way one can avoid typical er- mance statistics that support assessment of the appli- rors that may occur when individual service-level agree- cation effectiveness, permit complete visibility into in- ments (SLAs) are not properly matched. Proper man- dividual business processes and transactions, guarantee agement and monitoring provides a strong mitigation of consistency of service compositions, and deliver appli- this type of risk, since the operations management level
  • 22. 22 Mike P. Papazoglou, Willem-Jan van den Heuvel allows business managers to check the correctness, con- a special kind of service aggregator that has added re- sistency and adequacy of the mappings between the in- sponsibilities, such as issuing certificates, maintaining in- put and output service operations and aggregate services dustry standard information and introducing new stan- in a service composition. dards, endorsing service providers/aggregators, etc. The It is increasingly important for service operators to market maker assumes the responsibility of the service define and support active capabilities versus traditional market administration and performs maintenance tasks passive capabilities [44]. For example, rather than merely to ensure the administration is open and fair for business raising an alert when a given web service is unable to and, in general, provides facilities for the design and de- meet the performance requirements of a given service- livery of integrated service offerings that meet specific level agreement, the management framework should be business needs and conform to industry standards. able to take corrective action. This action could take the form of rerouting requests to a backup service that is less heavily loaded, or provisioning a new application server 5 Research Activities and Open Issues with an instance of the software providing the service if no backup is currently running and available. This section focuses on ongoing research activities con- Finally, service operations management should also ducted on services. Also, it identifies open research is- provide global visibility of running processes, comparable sues. We classify both the research activities and open to that provided by BPM tools. Management visibility research issues on the basis of the functional layers of is expressed in the form of real-time and historical re- xSOA. ports, and in triggered actions. For example, deviations from key performance indicator target values, such as the percent of requests fulfilled within the limits specified by 5.1 xSOA basic services layers a service level agreement, might trigger an alert and an escalation procedure. Research activities in the basics services layer to date Another aim of xSOA’s service management layer is target formal service description language(s) for holistic to provide support for service markets (aka of open ser- service definitions addressing, besides functional aspects, vice marketplaces). Currently, there exist several vertical also behavioral as well as non-functional aspects associ- industry marketplaces, such as those for the semiconduc- ated with services. They also concentrate on open, mod- tor, automotive, travel, and financial services industries. ular, extensible framework for service discovery, publi- Service cooperatives operate much in the same way like cation and notification mechanisms across distributed, vertical marketplaces, however, they are open. Their pur- heterogeneous, dynamic (virtual) organizations as well pose is to create opportunities for buyers and sellers to as unified discovery interfaces and query languages for meet and conduct business electronically, or aggregate multiple pathways. In the following we summarize sev- service supply/demand by offering added value services eral research activities contribute to these and related and grouping buying power (just like a co-operative). problems. The scope of such a service market would be limited only In addition to the application-specific functions that by the ability of enterprises to make their offerings vis- services provide, services may also support (different) ible to other enterprises and establish industry specific sets of protocols and formats addressing extra-functional protocols by which to conduct business. Service markets concerns such as transaction processing and reliable mes- typically support supply chain management by provid- saging. ing to their members a unified view of products and ser- Tai et. al [92] address the problem of transactional vices, standard business terminology, and detailed busi- coordination in service-oriented computing. The authors ness process descriptions. In addition, service markets of this publication argue for the use of declarative policy must offer a comprehensive range of services support- assertions to advertise and match support for different ing industry-trade, including services that provide busi- transaction styles (direct transaction processing, queued ness transaction negotiation and facilitation [14], finan- transaction processing, and compensation-based transac- cial settlement, service certification and quality assur- tion processing) and introduce the concept of and system ance, rating services, service metrics such as number of support for transaction coupling modes as the policy- current service requesters, average turn around time, and based contracts guiding transactional business process manage the negotiation and enforcement of SLAs. The execution. xSOA market management functionality as illustrated in The web services approach requires that developers Figure-9 is aimed to support these open service market discover (at development time) service descriptions on functions. UDDI and, by reading these descriptions they are able Service markets introduce a new role that of a market to code client applications that can (at run time) bind to maker. A market maker is a third trusted party or con- and interact with services of a specific type (i.e., compli- sortium of organizations that brings the suppliers and ant to a certain interface and protocol). Understanding vendors together. Essentially, a service market maker is the execution semantics is a rather cumbersome task.
  • 23. Service Oriented Architectures: 23 To address this problem Deora et. al. ([29], [30]) pro- 5.2 xSOA composition layer: research activities pose a quality of service management framework based on user expectations. This framework collects expecta- Service composition is today largely a static affair. tions as well as ratings from the users of a service and All service interactions are anticipated in advance and then the quality of the service is calculated only at the there is a perfect match between output and input sig- time a request for the service is made and only by us- natures and functionality. More ad hoc and dynamic ing the ratings that have similar expectations. Similar service compositions are required very much in the research efforts is reported in: [76]. spirit of lightweight and adaptive workflow method- The AI and semantic web community has concen- ologies. These methodologies will include advanced trated their efforts in giving richer semantic descriptions forms of co-ordination, less structured process mod- of Web services that describe the properties and capabil- els, and automated planning techniques as part of the ities of web services in an computer-interpretable form. integration/composition process. On the transactional For this purpose DAML-S [26] language has been pro- front, although standards like WS-Transaction, WS- posed to facilitate the automation of Web service tasks Coordination and BTP are a step in the right direction, including better means of web service discovery, execu- they fall short of describing different types of atomic- tion, “automatic” composition, verification and execu- ity needs for e-business and e-government applications. tion monitoring. The following two publications are rep- These do not distinguish between transaction phases and resentative publications from this community that pro- conversational sequences, e.g., negotiation. Another area pose semantic extensions to the basic SOA functionality. that is lacking research results is advanced methodologies in support for the service composition lifecycle. Several In addition, in [73], an approach is described that research activities contribute to these and related prob- builds on top of existing Web services technologies lems. and combines them with some concepts borrowed from Yang and Papazoglou present an integrated frame- the Semantic Web to leverage web service discov- work and prototype system that manage the entire life- ery and composition. This approach is captured by cycle of service components ranging from abstract service the METEOR-S Web Service Annotation Framework component definition, scheduling, and construction to (MWSAF). In particular, the MWSAF is designed to execution [99]. Service compositions are divided in three semi-automatically mark up Web service descriptions categories: fixed, semi-fixed and explorative composi- with ontologies. tions. Fixed service compositions require that their con- In the basic SOA UDDI provides a simple browsing- stituent services be synthesized in a fixed (pre-specified) by-business-category mechanism for developers to review manner. Semi-fixed compositions require that the entire and select published services. It is generally believed that service composition s specified statically but the actual discovery based on keyword-search could be improved service bindings are decided at run time. Finally, explo- considerably by introducing more powerful matching ap- rative compositions are generated on the fly on the basis proaches. In [94], a hybrid matching approach is sug- of a request expressed by a client (application developer). gested, combining semantic and syntactic comparison In [89], a framework is introduced for enriching se- algorithms of WSDL documents. Comparable research mantic service descriptions with two compositional asser- efforts have been reported in [97], [50], and [32]. tions: assumption and commitment that help to reason about service composition and verification. The frame- In order for service-oriented architectures to become work uses the Interval Temporal Logic(ITL) language for successful, powerful mechanisms are needed that allow representing and proving temporal properties of systems. service requestors to find service providers that are able This framework is embedded in the Semantic Web Rule to provide the services they need. Typically, this service Language [49], which combines Horn-like rules with an trading needs to be executed in several stages as the OWL knowledge base. offer descriptions are not completely specified in most Harfi and Mezini [24] propose to modularize web- cases and different parameters have to be supplemented service composition adopting two dimensions, one for by the service requestor and provider alternately. Un- outlining the business process flow, using languages such fortunately, existing service description languages (like as BPEL and BPL, and a second dimension comprising DAML-S) treat service discovery as a one shot activity business rules, which may be attached to the business rather than as an ongoing process and accordingly do processes and evolve independently. not support this stepwise refinement. The AI community has been concerned with design- Klein et. al introduce the concept of partially in- ing semantic web standards for adding semantic mark-up stantiated service descriptions containing different types to web service descriptions, and has proposed seman- of variables which are instantiated successively, thereby tic type matching algorithms, interleaved search mecha- mirroring step-by-step progress in a trading process [52]. nisms and execution algorithms that together allow for The suggested approach is grounded on service ontolo- basic automated service composition. There has been gies that were developed in the DIANE project [53]. some work in the area of applying AI planning techniques
  • 24. 24 Mike P. Papazoglou, Willem-Jan van den Heuvel to automate the composition of Web Services. In [85], the enterprise boundaries. This environment demands that authors descibe how an OWL reasoner can be integrated contracts are set up, stipulating agreements between ser- with an AI planner to overcome the problem of closed vices regarding their collaboration, both at the func- world semantics of planners versus open world semantics tional and non-functional level, in a concise manner. of OWL. These contracts may serve as the basis for process mon- In all of these works the authors assume to be in- itoring and adaptation. teracting with services that are described in a standard Ludwig et al. (IBM) [62] suggest to standardize on and possibly formal manner, i.e. all services which pro- agreements between enterprise domains, proposing the vide the same functionality are called in the same way, WS-Agreement standard. Their work addresses both the require the same inputs and produce the same outputs. contract creation and monitoring from the perspective of service providers and consumers. Service providers are supported by an infrastructure offering agreement tem- 5.3 xSOA management layer plates, and facilities to dynamically check the state of an agreement. Likewise, service requesters are in need Service management constitutes the foundation of the of contract templates and some monitoring capacities. upper layer of the extended SOA. Traditional manage- Lastly, the paper presents the Creation and Monitoring ment applications fail to meet enterprise requirements in of Agreements (CREMONIA) architecture, implement- a service-centric world. Conventional systems manage- ing WS-Agreements. ment approaches and products view the world in a very coarse (mostly applications oriented) manner. The most recent wave of management product categories does not have the business-awareness that services management 6 Summary will require. The finer grained nature of services (as op- posed to applications) requires evaluating processes and Modern enterprises need to align into virtual alliances, transactions at a more magnified rate and in a more con- while responding effectively and swiftly to competitive textually aware manner. challenges. Therefore, they are required to streamline Casati et al. shift attention to the management layer both internal and external business processes by inte- of the xSOA and more specifically to operations manage- grating the various packaged and home-grown applica- ment [21]. The proposed business oriented management tions found spread throughout an enterprise. This re- of web services is an attempt to assess the impact of quires an agile approach that allows enterprise business service execution from a business perspective and, con- services (those offered to customers and partners) to versely, to adjust and optimize service executions based be easily assembled from a collection of smaller, more on stated business objectives. This is a crucial issue as fundamental business services. This challenge in auto- corporations strive to align service functionality with mated business integration has driven major advances business goals. in technology within the integration software space. As In [86] a model-driven trust negotiation framework a result the Service-Oriented Architecture (SOA) has for web services management is explored. The framework emerged recently, essentially addressing the requirements adopts a model for trust negotiation that employs state of service requesters, providers and service brokers, re- machines, which incorporate security policies. The pol- garding loosely coupled, standards-based, and protocol- icy model underlying this framework facilitates lifecycle independent distributed computing and offering ways to management. achieve the desired levels of business integration effec- The ability to gauge the quality of a service is crit- tively, mapping IT implementations more closely to the ical if we are to achieve the service oriented comput- overall business process flow. ing paradigm. Many techniques have been proposed and Combining the SOA paradigm with event-driven pro- most of them attempt to calculate the quality of a ser- cessing lays the foundation for an emerging technology, vice by collecting quality ratings from the users of the that amalgamates various conventional distributed com- service, and then combining them in one way or another. puting, middleware, BPM and EAI technologies, and Collecting quality ratings alone from the users is not suf- thereby offers a unified backbone on top of which en- ficient for deriving a reliable or accurate quality measure terprise services can be advertized, composed, planned, for a service. executed, monitored and decommissioned. This overar- In [65], Maximilien extends the usage of the Quality ching implementation backbone to SOA is referred to as of Service concept for not only selecting web-services, but the Enterprise Service Bus. also establishing trust between trading partners. This To cater for essential ESB requirements that include paper outlines an agent-oriented approach, including an capabilities such as service orchestration, ”intelligent” architecture and programming model. The work is vali- routing, provisioning, integrity and security of message dated empirically, based on a series of simulations. as well as service management, the basic service descrip- Ideally, services are collaborating in highly dis- tion/publication/discovery functions of the conventional tributed environments, naturally cutting across various Service-Oriented Architecture need to be extended into
  • 25. Service Oriented Architectures: 25 the extended SOA (xSOA). Particularly, the xSOA incor- 14. Tung Bui and Alexandre Gachet. Web services for ne- porates a service composition tier to offer necessary roles gotiation and bargaining in electronic markets: Design and functionality for the consolidation of multiple ser- requirements and implementation framework. Proceed- ings of the 38th Hawaii International Conference on Sys- vices into a single composite service. In addition, xSOA tem Sciences, IEEE, 2005. provides a separate tier for service management that 15. S. Burbeck. The tao of e-business ser- can be used to monitor the correctness and overall func- vices: The evolution of web applications into tionality of aggregated/orchestrated services, supporting service-oriented components with web services. IBM DeveloperWorks, 2000. http://www- complex aggregate (cross-component) management use 106.ibm.com/developerworks/webservices/library/ws- cases, such as service-level agreement enforcement and tao/ dynamic resource provisioning. 16. David Burdett and Nickolas Kavantzas. WS- This paper has surveyed approaches, technologies Choreography Model Overview. W3c working draft, and research issues underlying two emerging paradigms W3C, March 2004. 17. Frank Buschmann et al. Pattern-oriented software ar- for engineering business applications with services, chitecture: a system of patterns. John Wiley & Sons, named (x)SOA and event-driven, distributed comput- Inc., 1996. ing. In addition, it reviews technologies (e.g., integra- 18. C. Bussler. B2B Integration: Concepts and Architecture. tion brokers, business process management and appli- Springer, Berlin, 2003. cation servers) implementing the backbone of an Enter- 19. A. Candadai. A dynamic implementation framework for prise Service Bus, which is of critical importance to make SOA-based applications. Web Logic Developers Journal: WLDJ, pp. 6-8, September/October, 2004. the service-oriented computing paradigm operational in 20. L. Cardelli and P. Wegner. On understanding types, a business context. data abstraction and polymorphism. ACM Computing Surveys, 17(4):211–221, 1985. 21. Fabio Casati et al. Business-oriented management of References web services. Communincations of the ACM, 46(10):55– 60, 2003. 22. D. Chappell. Enterprise Service Bus. O’Reilly Media, 1. Universal Description, Discovery, and Integration Inc., 2004. (UDDI). Technical report, UDDI.ORG, September 2000. http://www.uddi.org. 23. D. Chappell. ESB myth busters: Clarity of definition 2. Ali Arsanjani Introduction to the special issue on de- for a growing phenomenon. Web Services Journal, pages veloping and integrating enterprise components and ser- 22–26, February 2005. vices. Communications of the ACM, 45(10):30–34, 2002. 24. Anis Charfi and Mira Mezini. Hybrid web service com- 3. Anjali Anagol-Subbaro. J2EE Web Services on BEA position: business processes meet business rules. In: IC- WebLogic. Prentice Hall, Upper Saddle River, Newy SOC ’04: Proceedings of the 2nd international confer- Jersey, 2005. ence on Service oriented computing, pages 30–38, New 4. G. Alonso, F. Casati, H. Kuno and V. Machiraju. York, NY, USA, ACM Press, 2004. Web Services: Concepts, Architectures and Applications. 25. E. Christensen et al. Web Services Description Lan- Springer, 2004. guage (WSDL) 1.1. W3C Note, W3C, March 2001. 5. T. Andrews et al. Business Process Execution Language http://www.w3.org/TR/2001/NOTE-wsdl-20010315. (BPEL), version 1.1. Technical report, BEA Systems 26. The DAML-S Coalition. DAML-S: Web Service De- and International Business Machines Corporation, Mi- scription for the semantic web. In I. Horrocks and J. A. crosoft Corporation, SAP AG and Siebel Systems, May Hendler, editors, The Semantic Web - ISWC 2002, First 2003. International Semantic Web Conference. Lecture Notes 6. A. Arkin. Business Process Modeling Language in Computer Science, 2002. (BPML). Last call draft report, BPMI.Org, November 27. M. Colan. Service-Oriented Architecture expands the 2002. vision of web services, Part 2. IBM DeveloperWorks, 7. A. Arora et al. Web Services for Management (WS- April 2004. Management). Technical report, Advanced Micro De- 28. A. Dan et al. Web services on demand: WSLA- vices, Dell, Intel, Microsoft Corporation and Sun Mi- driven automated management. IBM Systems Journal, crosystems, October, 2004. 43(1):136–158, March, 2004. 8. B. Atkinson et al. Web Services Security (WS-Security). 29. V. Deora et al. A quality of service management Technical report, Microsoft, IBM and Verisign, April framework based on user expectations. Proceedings of 2002. the First International Conference on Service Oriented 9. Keith Ballinger et al. Web Services-Interoperability Computing (ICSOC03), Springer, 2003. (WSI), Basic profile version 1.1, 2004-08-24. Technical report, WSI Organization (WS-I), 2004. 30. V. Deora et al. Incorporating QoS specifications in ser- 10. Abbie Barbir et al. Basic security profile, version 1.0. vice discovery. In: Proceedings of WISE Workshops, Technical report, Web Services-Interoperability Organi- Lecture Notes of Springer Verlag, 2004. zation (WS-I), 2004. 31. Arulazi Dhesiaseelan and Venkatavaradan Ragu- 11. J. Bloomberg. Events vs. services. available at: nathan. Web Services Container Reference Architecture www.zapthink.com, ZapThink white paper, October (WSCRA). In: Proceedings of the International Confer- 2004. ence on Web Services, IEEE, pages 806–805, 2004. 12. Scott Boag et al. Xquery 1.0: An XML query language, 32. X. Ding et al Similarity search for web services. In: W3C working draft. Technical report, W3C, April, Proceedings of the 30th VLDB Conference, pages 372– 2005. 383, 2004. 13. D. Box et al. Simple Object Access Protocol 33. ebXML Technical Architecture Project Team. ebXML (SOAP), Version 1.1. W3C Note, W3C, May 2000. Technical Architecture Specification, v1.0.4. Technical http://www.w3.org/TR/SOAP/. report, ebXML.org, FEbruary, 2001.
  • 26. 26 Mike P. Papazoglou, Willem-Jan van den Heuvel 34. A. Lazovik et al. Associating assertions with business 55. Heather Kreger. Fulfilling the web services promise. processes and monitoring their execution. In: Proceed- Communications of the ACM, 46(6):29–ff, 2003. ings of the Second International Conference on Service 56. F. Leymann and D. Roller. Production Workflow: Con- Oriented Computing, 2004. cepts and Techniques. Prentice-Hall, Inc., New Jersey, 35. Booth et al. Web Service Architecture. 2000. http://www.w3.org/tr/ws-arch/, W3C, Working 57. W.F. Leymann, D. Roller, and M.-T. Schmidt. Web Notes,, 2003/2004. Services and Business Process Management. IBM Sys- 36. In Sing et al. Designing Web Services with the J2EE tems Journal, 41(2):198–211, 2002. 1.4 Platform. Addison-Wesley, 2004. 58. D. Linthicum. Next Generation Application Integration: 37. Keen et al. Patterns: Implementing an SOA using an From Simple Information to Web Services. Addison- Enterprise Service Bus. IBM Redbook, 22 July 2004. Wesley, 2003. 38. Nicolas Catania et al. Web Services Management 59. J. Lowey. Programming .NET Components. O’Reilly Framework, version 2.0. Technical report, HP, July, (1st Edition), April, 2003. 2003. 60. B. Lubinsky and M. Farrel. Enterpise Architecture and 39. Siddharth Bajaj et al. Web Services Policy frame- J2EE. EAI Journal, November, 2001. work (WS-Policy). Technical report, BEA Systems 61. D. Luckham. The Power of Events. An Introduction Inc., International Business Machines Corporation, Mi- to Complex Event Processing in Distributed Enterprise crosoft Corporation, Inc., SAP AG, Sonic Software, and Systems. Addison-Wesley Press, April 2002. VeriSign Inc., September, 2004. 62. Heiko Ludwig, Asit Dan, and Robert Kearney. Crona: 40. Stephen Farell et al. Assertions and Protocol for the an architecture and library for creation and monitoring OASIS Security Assertion Markup Language (SAML), of WS-Agreements. In: ICSOC ’04: Proceedings of the V1.1. Committee specification, OASIS, July 2003. 2nd international conference on Service oriented com- 41. Tim Francis et al. Professional IBM WebSphere 5.0 puting, pages 65–74, New York, NY, USA, 2004. ACM Application Server. Wrox, 2002. Press. 42. Paul Fremantle, Sanjiva Weerawarana and Rania Kha- 63. M. Papazoglou and D. Georgakopoulos. Introduction to laf. Enterprise services. Communication of the ACM, a Special Issue on Service Oriented Computing. Com- 45(10), 2002. munications of the ACM, 46(10):25–28, October 2003. 43. B. Mukherjee et al. An efficient multicast protocol for 64. Joanne Martin, Ali Arsanjani, Peri Tarr, and Brent content-based publish-subscribe systems. In: ICDCS ’99: Hailpern. Web Services: Promises and Compromises. Proceedings of the 19th IEEE International Conference Queue, ACM, 1(1):48–58, 2003. on Distributed Computing Systems, page 262, IEEE 65. E. Michael Maximilien and Munindar P. Singh. Toward Computer Society, Washington, DC, USA, 1999. autonomic web services trust and selection. In: ICSOC 44. A.G. Ganek and T.A. Corbi. The dawning of the auto- ’04: Proceedings of the 2nd international conference on nomic computer era. IBM Systems Journal, 42(11):5– Service oriented computing, pages 212–221, New York, 18, 2003. NY, USA, 2004. ACM Press. 45. Steve Graham et al. Web Services Resource (WS- 66. D. McGoveran. An introduction to BPM and BPMS. Resource), version 1.2, working draft 03. Technical re- Business Integration Journal, April 2004. port, OASIS, March, 2005. 67. B. Meyer. Object-Oriented Software Construction, Sec- 46. J2CA Group. J2EE Connector Architecture Specifica- ond Edition. Prentice Hall Professional Technical Ref- tion, version 1.5. Technical report, SUN Microsystems, erence, 1997. 2003. 68. R. Monson-Haefel and D. Chappell. Java Message Ser- 47. Mark Hapner et al. Java Messaging Service, version 1.1. vices. O’Reilly, 2001. Sun technical report, specification, SUN Microsystems, 69. M.P. Papazoglou and P.M.A. Ribbers. e-Business: Or- April 2002. ganizational and Technical Foundations. John Wiley & 48. R. Hauck and H. Reiser. Monitoring Quality of Service Sons, Forthcoming 2005. across Organizational Boundaries. In: Trends in Dis- 70. H. Ossher and P. Tarr. Multi-dimensional separation of tributed Systems: Torwards a Universal Service Market. concerns and the hyperspace approach. In: Proceedings Proceedings of the third International IFIP/GI Working of the Symposium on Software Architectures and Com- Conference, 2000. ponent Technology: The State of the Art in Software 49. Ian Horrocks et al. SWRL: A Semantic Web Rule Lan- Development, 2000. guage combining OWL and RULEML, W3C member 71. M.P. Papazoglou. Extending the Service Oriented Ar- submission. W3C, 21 May 2004. chitecture. Business Integration Journal, February 2005. 50. Michael C. Jaeger and Stefan Tang. Ranked match- 72. Christine Parent and Stefano Spaccapietra. Issues and ing for service descriptions using DAML-S. In Ja- Approaches of Database Integration. Communications nis Grundspenkis and Marite Kirikova (editors), Pro- of the ACM, 41(5):166–178, 1998. ceedings of CAiSE’04 Workshops, pages 217-228, Riga, 73. Abhijit A. Patil et al. Meteor-S: Web Service Annota- Latvia, June 2004. Riga Technical University. tion Framework. In: WWW ’04: Proceedings of the 13th 51. K. Holley K. Channabasavaiah and Jr. E. M. Tuggle. international conference on World Wide Web, pages Migrating to a Service-Oriented Architecture. IBM De- 553–562. ACM Press, 2004. veloperWorks, December 2003. 74. Kazunori Iwasa (principal editor). WS- 52. M. Klein, B. Konig-Ries, and P. Obreiter. Stepwise re- Reliability, version 1.1, committee draft finable service descriptions: Adapting DAML-S to staged 1.086, 24 august 2004. http://www.oasis- service trading. In: Proc. Of 1st International Confer- open.org/committees/wsrm/documents/specs/(tbd), ence on Service Oriented Computing, December, 2003. OASIS, Web Services Reliable Messaging TC, 2004. 53. Michael Klein, Birgitta Konig-Ries, and Michael Mus- 75. S. Kumar R. Rana. Service on demand portals: A primer sig. What is needed for Semantic Service Descriptions? on federated portals. Web Logic Developers Journal: - a proposal for suitable language constructs. Interna- WLDJ, pages 22–24, September/October 2004. tional Jounal on Web and Grid Services, (2), 2005. 76. Shuping Ran. A Model for Web Services Discovery with 54. D. Krafzig, K. Banke, and D. Slama. Enterprise SOA: QoS. SIGecom Exchange, 4(1):1–10, 2003. Service Oriented Architecture Best Practices. Prentice 77. Ueli Wahli et al. Websphere version 5.1 application de- Hall, 2005. veloper web services handbook. IBM Redbook, 2004.
  • 27. Service Oriented Architectures: 27 78. R. Robinson. Understand Enterprise Service Bus sce- 96. W3C. XSL Transformations (XSLT), Version 2.0. Tech- narios and solutions in Service-Oriented Architecture. nical report, W3C Working Draft, April 2005. IBM DeveloperWorks, June 2004. 97. Y. Wang and E. Stroulia. Semantic structure match- 79. E. Roch. Application Integration: Business and Tech- ing for assessing web-service similarity. In: Proceed- nology trends. EAI Journal, August, 2002. ings of First International Conference on Service Ori- 80. S. Anderson, et al. Web Services Trust language (WS- ented Computing (ICSOC03), pages 194–207. Springer- Trust). Public draft release, Actional Corporation, BEA Verlag, 2003. Systems, Computer Associates International, Interna- 98. Seth White and Mark Hapner. JDBC 2.1 API. Techni- tional Business Machines Corporation, Layer 7 Tech- cal report, SUN, October, 1999. nologies, Microsoft Corporation, Oblix Inc., OpenNet- 99. J. Yang and M.P.Papazoglou. Service components for work technologies, Ping Identity, Reacticity, RSA Secu- managing the life-cycle of service compositions. Infor- rity, and Verisign, February, 2005. mation Systems, 28(1), 2004. 81. P. Von Schilling and P. Lawrence. Leveraging existing 100. Jian Yang. Web Service Componentization. Communi- code with object technology. Enterprise Systems Journal, cations of the ACM, 46(10):35–40, 2003. (7):38–44, July 1994. 101. P. Yendluri. RosettaNet Implementation Framework 82. R. Schulte. Predicts 2003: Enterprise service buses (RNIF), Version 2.0, Technical report. RosettaNet, emerge. Report, Gartner, December 2002. 2000. 83. R. Seacord et al. Legacy modernization strategies. Tech- nical Report CMUSEI-2001-TR-025, Carnegie Mellon University, Pittsburgh, Pa., 2001. 84. R.C. Seacord, D. Plakosh, and G.A. Lewis. Modernizing Legacy Systems. Carnegie Mellon, SEI, Addison-Wesley, 2003. 85. Evren Sirin and Bijan Parsia. Planning for Semantic Web Services. In: D. Martin, R. Lara, and T. Yamaguchi (Editors, Proceedings of the ISWC 2004 Workshop on Semantic Web Services: Preparing to Meet the World of Business Applications, 2004. 86. Halvard Skogsrud, Boualem Benatallah, and Fabio Casati. Trust-serv: model-driven lifecycle management of trust negotiation policies for web services. In: WWW ’04: Proceedings of the 13th international conference on World Wide Web, pages 53–62, New York, NY, USA, 2004. ACM Press. 87. M. Sloman. Policy driven management of distributed systems. Journal of Network and Systems Management, 2: 333–360, 1994. 88. D. Smith. Web services enable Service Oriented and Event-driven Architectures. Business Integration Jour- nal, pages 12–13, May, 2004. 89. Monika Solanki, Antonio Cau, and Hussein Zedan. Aug- menting semantic web service descriptions with compo- sitional specification. In: WWW ’04: Proceedings of the 13th international conference on World Wide Web, pages 544–552, New York, NY, USA, 2004. ACM Press. 90. Michael Stal. Web Services: Beyond Component-based Computing. Communications of the ACM, 45(10):71– 76, 2002. 91. Steve Graham and Peter Niblett. Web Services Base Notification, version 1.0. Akamai Technologies, Com- puter Associates International, Inc., Fujitsu Limited, Hewlett-Packard Development Company, International Business Machines Corporation, SAP AG, Sonic Soft- ware Corporation, The University of Chicago and Tibco Software Inc., 2004. 92. Stefan Tai, Thomas Mikalsen, Eric Wohlstadter, Nir- mit Desai, and Isabelle Rouvellou. Transaction policies for Service-Oriented Computing. Data and Knowledge Engineering, 51(1):59 - 79, 2004. 93. Business Process Project Team. ebXML Business Pro- cess Specification Schema, version 1.01. OASIS, 2001. http://www.ebxml.org/specs/ebbpss.pdf, 94. WJ van den Heuvel. Integrating Modern Business Ap- plications with Legacy Systems: A Software Component Perspective. MIT Press, To appear: Winter, 2005. 95. W.M.P. van der Aalst. Lectures on Concurrency and Petri Nets: A Tutorial on Models, Systems and Stan- dards for Workflow Management., In: Business Process Management Demystified, pages 1–65. Springer-Verlag, Berlin, 2004.