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 eﬀectively and
ically business operations running in an SOA comprise quickly to opportunities in today’s, ever more com-
a number of invocations of these diﬀerent 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)
ﬂects 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) (, ). The purpose of
of functions that are designed to oﬀer 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 oﬀers integration services. tems isomorphically to the overall business process ﬂow.
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 deﬁned, 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 deﬁnition 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 . 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 . The driving goal of SOA is to
E-mail: email@example.com eliminate these barriers so that applications integrate
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
ﬂexibility and agility that business users require, deﬁn- 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 ﬂow. 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 eﬃciently and cost-eﬀectively. While this goal eration for enterprises that are seeking to deploy demand
is deﬁnitely not new , SOA seeks to eclipse previous driven computing environments.
eﬀorts such as modular programming, code reuse, and Services in an SOA exhibit the following main char-
object-oriented software development techniques. acteristics :
– All functions in an SOA are deﬁned as services
SOA as a design philosophy is independent of any
. This includes purely business functions, business
speciﬁc 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 deﬁned by a
ceived as opaque by external components. Service
description language (WSDL  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 eﬀect the invocation, nor which infrastructure
sumes that services can be dynamically located, invoked
components are required to establish the connection.
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 deﬁnes 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 .
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 . 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 ﬂexible architecture that uni- deﬁning service interfaces in a unambiguous and trans-
ﬁes 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
Service Oriented Architectures: 3
requester Provider Requester
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 ﬂexible and adaptable environ- mented using one or more web service components .
ment. This survey is unique in that that it uniﬁes the Web service components may be hosted within a web
principles, concepts and developments in the area of ap- services container , 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 () 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 . Finally,
the response that the provider sends back to the client
takes again the form of a SOAP envelope carrying an
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 reﬂects a provider, which is especially important over the Internet
type of a participant in a Service Oriented Architecture where two parties may reside in diﬀerent organizations
(, ). 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) . nies used IBM’s WebSphere MQ to exchange XML doc-
SOAP entails a light-weighted protocol allowing RPC- uments between them . 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 deﬁned. 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 oﬀering the desired quality
4 Mike P. Papazoglou, Willem-Jan van den Heuvel
Provider bind Client
Fig. 2 Service brokering.
of service. For the service provider, the design of compo- security and privacy standards such as SAML  and
nents, their service exposure and management reﬂect key WS-Trust , introduce another role which addresses
architecture and design decisions that enable services in these issues, called a service broker .
SOA. The provider view oﬀers a perspective on how to Service brokers are trusted parties that force service
design the realization of the component that oﬀers 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 oﬀer 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 . The service aggrega- include diﬀerences 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 oﬀers 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  and BPML . 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 ﬁguration the UDDI registry serves as a broker where the
process is shown in Figure-1. service providers publish the deﬁnitions of the services
While service aggregation may oﬀer direct beneﬁts to they oﬀer using WSDL and where the service requestors
the requester, it is a form of service brokering that of- ﬁnd 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 oﬀerings? 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 . In particular, all tech-
as the UDDI . SOA technologies such as UDDI, and nologies that directly implement service interfaces with
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- , 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, ﬂow 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 simpliﬁed 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 ﬁrst 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 eﬃcient
manage and maintain as it introduces a tighter form value-added integration of a number of diﬀerent applica-
of coupling to harmonize transport protocols, document tion components, by positioning them behind a service-
formats, interaction styles etc . 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 ﬁgure, a distributed query engine, which is nor-
terchange without impacting other systems. In addition, mally based on XQuery  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 . 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) (, ). The ESB exhibits tion independence oﬀers the services that are connected
two prominent features . 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 conﬁgured 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 . The ESB is de- and outages .
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, conﬁgured and orchestrated in a uniﬁed and clearly
e.g., Message Oriented Middleware, and now combines deﬁned distributed process.
6 Mike P. Papazoglou, Willem-Jan van den Heuvel
Custom Portals Service
Reliable Asynchronous Secure Messaging
Distributed Web JMS/ MQ
query engine Services J2EE gateway
WebSphere Java apps Mainframe
, .NET & legacy
Data sources Enterprise Multi-platform
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, diﬀerent 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 reconﬁgured. The latter requirements requires vices.
that corresponding changes in processes must be
made without rewriting the services or underlying
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 aﬀect the normal course
may also be used to create services by integrating pack- of a business process at any point in time . 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 ﬂow, but must be deﬁned dynamically, driven by
from traditional EAI broker functionality in that it pro- incoming, parallel and a-synchronous event ﬂows. 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 (, ). An event-driven
mation, and adapters to applications . 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 diﬀerence 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
. 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 .
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.
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- ﬁned. 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 speciﬁc action. To achieve its functionality, the ESB mal service contracts themselves.
supports both the established web services technologies,
To eﬀectively 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  and WS-
cludes a distributed processing framework and XML-
based services. To exemplify these features, a simpliﬁed
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 conﬁgured and deployed using an ESB.
tween the provider and client of a service is the service The ﬁgure 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 ﬂow 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 ,
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 suﬃcient security arrangements are not Although this ﬁgure 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 . plier to fulﬁl 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 , 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 reconﬁgure 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 conﬁgure, deploy and man-
tively, meta-data is available about the event, including age services and endpoints. This allows the free move-
8 Mike P. Papazoglou, Willem-Jan van den Heuvel
Replenishment Sourcing Supplier order Purchase order Invoicing
service service service service service
Fig. 4 Simpliﬁed distributed procurement process.
ment and reconﬁguration 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 eﬀect 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 speciﬁed 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
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 ﬁxed, 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 . Content-based
thors such as (, , , and ).
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 diﬀerent 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
Service Oriented Architectures: 9
Replenishment Supplier order
Replenishment Supplier order
Enterprise Service Bus
the vendor of choice.
Purchase Order Credit check
Purchase Order Credit check
Supplier Legacy cc
Fig. 5 Enterprise service bus connecting remote services.
it to be processed by an internal warehouse fulﬁl- 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 eﬀorts such associated with the services involved using a policy
WS-Eventing and WS-Notiﬁcation. standard such as the WS-PolicyFramework .
– 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 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 diﬀer 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- speciﬁcally, 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 diﬀerent, 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 diﬀerent 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 . 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 aﬃnity 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. Eﬀective 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 oﬀer 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 signiﬁcance 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  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 reﬂect 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-
. 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
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 eﬀective solu- a reality.
tion that promotes ﬂexibility 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 signiﬁes 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 (, ). 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 uniﬁed portal packages, external application subscriptions and newly
framework that provides a usable, eﬃcient, 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 uniﬁed 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 eﬀorts : – Evolutionary application portfolios that protect in-
1. JSR 168: This is an industry standard that deﬁnes 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 ﬁnancial 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  is
some remote, distributed portlets that are executed in a the process of providing a consistent access to all the data
12 Mike P. Papazoglou, Willem-Jan van den Heuvel
in the enterprise, by all the applications that require it, in we use the simpliﬁed distributed procurement process
whatever form they need it, without being restricted by shown in Figure-4. Figure-6 exempliﬁes 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 ﬂow is triggered
transformation facilities, aggregation services to merge and ﬁrst 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
proﬁles, 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 ﬁgure 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 diﬀer-
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 conﬁguration
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 speciﬁc 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 simpliﬁed or not coupled conﬁguration.
clearly deﬁned. 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 speciﬁc 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 eﬀort 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 . 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-
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 ﬁgure 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
Service Oriented Architectures: 13
• Application integration
• Business Processes
• Business Rules
• Data Transformation integrating application
• Message Routing (contains busines composition logic)
Inventory Supplier ERP
adapter data adapter
Replenishment Sourcing Generate PO Send PO
signal Sourcing Generate PO Send PO
Reference ERP Supplier
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 . 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 , IBM’s up new models of sales and distribution. The compo-
WebSphere  and Microsoft’s .NET , typically nent wrappers in this ﬁgure 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 deﬁned 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 deﬁnes 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 ,
existing enterprise systems and expose them through a .
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 Mike P. Papazoglou, Willem-Jan van den Heuvel
Web- CORBA/COM -based
client client client
• Front-end of many EAI initiatives,
• Application connectivity
• Business Processes
• Business Rules
• Transaction Mgt
• Message Routing Web server
Wrapper Wrapper Wrapper
Wrapper Wrapper Wrapper
ERP application CRM application
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” . 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 .
to work together, while a connector enables the commu- The adapter/component wrapper pairs in the archi-
nication between to interoperable components . 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 deﬁnes 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 oﬀer also
that is understandable to the internal code and data. asynchronous communication.
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 , the Java integrating on such a scale, enterprises need a greater
2 Connector Architecture (J2CA) , 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 .
can be used with many diﬀerent 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-
oﬀer the capability of simulating a synchronous re- trol over all parts of a long-lived, multi-step information
quest/response mode . 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 .
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 workﬂow-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 speciﬁcally 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, workﬂow 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 deﬁnes 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 deﬁne the business process
nect to back-end EIS, such as ERP, CRM and legacy and the underlying ﬂows 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 workﬂow as it involves integration between
Database Connectivity)  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 ﬂow of information
provide a J2CA container that allows packaged or legacy between applications to fulﬁl business processes. Tradi-
applications to be plugged into the ESB through J2CA tional workﬂow 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 . This may or may
fulﬁls 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 workﬂow that changes
oﬀerings. 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-
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 workﬂow
connected to their customers, suppliers, and partners. into a managed, end-to-end process .
To achieve this, they are integrating a wide range of dis- BPM codiﬁes value-driven processes and institution-
crete business processes across application boundaries of alises their execution within the enterprise . This
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, deﬁne 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 deﬁnition, 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 beneﬁt 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 . 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 deﬁnition and redeﬁnition, resource alloca- deploy, and reﬁne such a process-driven integration so-
tion, scheduling, measurement of process quality and ef- lution.
ﬁciency, 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 ﬂows 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 deﬁnitions are called for alternative ways an application can exchange informa-
in an ESB, a process orchestration engine – that sup- tion with the ESB include :
ports BPEL  or some other process deﬁnition language
such as ebXML Business Process Speciﬁcation Schema 1. Application-provided web service interface: Some
(BPSS)  – 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 deﬁnes
parallel execution paths, with branching, and merging the interface to communicate directly with the appli-
of message ﬂow 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
www.chordiant.com application-speciﬁc adapter can be supplied to pro-
www.pega.com vide a basic intermediary between the application
www.fuego.com API and the ESB.
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 . 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-speciﬁc 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 ﬁrst 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-Notiﬁcation.
An adapter can expose either a synchronous and
WS-Notiﬁcation deﬁnes 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 . The
of transformation services including support for complex
Web Services Notiﬁcation Framework deﬁnes 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
systems, and so on. Messages are ﬁrst transformed into
an intermediate state (either IDL, XML, or Java Inter- WS-Notiﬁcation  is a family of related speciﬁca-
faces) before being formatted. An adapter typically pro- tions that deﬁne a standard web services approach to no-
vides support for a range of date/time conversion func- tiﬁcation using a topic-based publish/subscribe pattern.
tions, EBCDIC/ASCI, binary and character conversion The WS-Notiﬁcation speciﬁcation deﬁnes 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 ﬁelds. Furthermore, it that wish to participate in notiﬁcations 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 , ebXML , 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 tiﬁcations. WS-Notiﬁcation allows notiﬁcation messages
together to implement complex integration scenarios in- to be attached to WSDL PortTypes. The current WS-
volving federated ESBs spanning multiple organizations , Notiﬁcation speciﬁcation 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 fulﬁl its service contract. The drivers of ponents tying up diﬀerent EISs inside the company. This
data synchronization and web services are also diﬀer- 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 speciﬁc 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
http://www.cxml.org other EISs to fulﬁl their part in the business process,
http://eco.commerce.net they will use resource adapters.
18 Mike P. Papazoglou, Willem-Jan van den Heuvel
service client service client service client
Topic-based and Content-based ESB
Publish and Subscribe Components
DNS Router Internet DNS Router
Existing EIS &
Proprietary Proprietary Proprietary Middleware
interfaces interfaces interfaces Platforms
Legacy ERP Data
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 deﬁnes 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) , . The xSOA is an attempt to stream- These interactions involve the publishing, ﬁnding 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 stratiﬁed service-based architecture. The architectural network accessible software module. The service provider
layers in the xSOA, which are depicted in Figure-9, em- deﬁnes a service description, and publishes it to a client
brace a multi-dimensional, separation of concerns  in (or service discovery agency) through which a service de-
such a way that each layer deﬁnes 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
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 ﬁgure also indicate that nature matching . 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-speciﬁc
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 (, ). Concrete solu-
providers into a distinct value added service. Service ag- tions exist only for typing conformance ,  as
gregators develop speciﬁcations 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 Eiﬀel or Java.
on the following facilities (in addition to web services in- – Coordination: controls the execution of the compo-
teroperation support provided by WSI proﬁles for service nent services (processes), web services transactions
descriptions  and security ): and manages dataﬂow as well as control ﬂow among
them and to the output of the component service
– Meta-data, standard terminology and reference mod- (e.g., by specifying workﬂow processes and using a
els: web services need to use meta-data to describe workﬂow 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 signiﬁcance
data need to be accompanied with standard termi- is the ability to be able to spot problems and ex-
nology to address business terminology ﬂuctuations 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 , to allow applications to deﬁne 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  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 . 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 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 ﬁnally, 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-deﬁned 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  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 . 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) ; 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 eﬃciently. 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 speciﬁc
stantly monitor the health of their applications. The per- conﬁguration 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. notiﬁcation 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., speciﬁc service markets,
in the xSOA.
the xSOA management services are divided in two com-
We could deﬁne web services management as the
plementary categories (, ):
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 conﬁguration, 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 . It spans a 2. Service market management that supports typical
range of activities from installation and conﬁguration to integrated supply chain functions and provides a
Service Oriented Architectures: 21
Role actions gement
•Ratin ation Manage
publishes •SLAs g d services
uses •Assura ons
becomes •Suppo nce
sition ite servic
Service provider •Monito
ring Basic se
tion & B
Fig. 9 Extended SOA
comprehensive range of services supporting industry- cation status notiﬁcations 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, ﬁnancial settle- refer to the role responsible for performing such opera-
ment, service certiﬁcation 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 speciﬁc 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 eﬀectiveness, 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 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 certiﬁcates, 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
deﬁne and support active capabilities versus traditional market administration and performs maintenance tasks
passive capabilities . 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 oﬀerings that meet speciﬁc
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 identiﬁes 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 fulﬁlled within the limits speciﬁed 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 deﬁnitions 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 ﬁnancial services industries. ular, extensible framework for service discovery, publi-
Service cooperatives operate much in the same way like cation and notiﬁcation 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 uniﬁed 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 oﬀering 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-speciﬁc functions that
by the ability of enterprises to make their oﬀerings vis- services provide, services may also support (diﬀerent)
ible to other enterprises and establish industry speciﬁc 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 uniﬁed view of products and ser- Tai et. al  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 oﬀer a comprehensive range of services support- assertions to advertise and match support for diﬀerent
ing industry-trade, including services that provide busi- transaction styles (direct transaction processing, queued
ness transaction negotiation and facilitation , ﬁnan- transaction processing, and compensation-based transac-
cial settlement, service certiﬁcation 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 speciﬁc 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.
Service Oriented Architectures: 23
To address this problem Deora et. al. (, ) 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 aﬀair.
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 eﬀorts is reported in: . spirit of lightweight and adaptive workﬂow method-
The AI and semantic web community has concen- ologies. These methodologies will include advanced
trated their eﬀorts 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  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 diﬀerent types of atomic-
tion, “automatic” composition, veriﬁcation 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 , 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 deﬁnition, scheduling, and construction to
(MWSAF). In particular, the MWSAF is designed to execution . Service compositions are divided in three
semi-automatically mark up Web service descriptions categories: ﬁxed, semi-ﬁxed 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 ﬁxed (pre-speciﬁed)
by-business-category mechanism for developers to review manner. Semi-ﬁxed compositions require that the entire
and select published services. It is generally believed that service composition s speciﬁed 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 ﬂy on the basis
proaches. In , a hybrid matching approach is sug- of a request expressed by a client (application developer).
gested, combining semantic and syntactic comparison In , a framework is introduced for enriching se-
algorithms of WSDL documents. Comparable research mantic service descriptions with two compositional asser-
eﬀorts have been reported in , , and . tions: assumption and commitment that help to reason
about service composition and veriﬁcation. 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 ﬁnd service providers that are able This framework is embedded in the Semantic Web Rule
to provide the services they need. Typically, this service Language , which combines Horn-like rules with an
trading needs to be executed in several stages as the OWL knowledge base.
oﬀer descriptions are not completely speciﬁed in most Harﬁ and Mezini  propose to modularize web-
cases and diﬀerent parameters have to be supplemented service composition adopting two dimensions, one for
by the service requestor and provider alternately. Un- outlining the business process ﬂow, 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 reﬁnement.
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 diﬀerent 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 . 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 . some work in the area of applying AI planning techniques
24 Mike P. Papazoglou, Willem-Jan van den Heuvel
to automate the composition of Web Services. In , 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)  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 oﬀering 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 ﬁner 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 magniﬁed rate and in a more con- while responding eﬀectively 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 speciﬁcally to operations manage- grating the various packaged and home-grown applica-
ment . 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 oﬀered 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  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 oﬀering ways to
management. achieve the desired levels of business integration eﬀec-
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 ﬂow.
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 oﬀers a uniﬁed backbone on top of which en-
ﬁcient 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 , 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
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 oﬀer 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–
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 deﬁnition
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 Charﬁ 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 proﬁle version 1.1, 2004-08-24. Technical
report, WSI Organization (WS-I), 2004. 30. V. Deora et al. Incorporating QoS speciﬁcations in ser-
10. Abbie Barbir et al. Basic security proﬁle, 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 Speciﬁcation, v1.0.4. Technical
http://www.w3.org/TR/SOAP/. report, ebXML.org, FEbruary, 2001.
26 Mike P. Papazoglou, Willem-Jan van den Heuvel
34. A. Lazovik et al. Associating assertions with business 55. Heather Kreger. Fulﬁlling the web services promise.
processes and monitoring their execution. In: Proceed- Communications of the ACM, 46(6):29–ﬀ, 2003.
ings of the Second International Conference on Service 56. F. Leymann and D. Roller. Production Workﬂow: 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 speciﬁcation, 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 eﬃcient 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 Speciﬁca- 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, speciﬁcation, 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
ﬁnable 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.
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,
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 speciﬁcation. 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–
91. Steve Graham and Peter Niblett. Web Services Base
Notiﬁcation, 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 Speciﬁcation Schema, version 1.01. OASIS, 2001.
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 Workﬂow Management., In: Business Process
Management Demystiﬁed, pages 1–65. Springer-Verlag,