Service Oriented Architectures:

1,956 views

Published on

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

No Downloads
Views
Total views
1,956
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
55
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Service Oriented Architectures:

  1. 1. The VLDB Journal manuscript No. (will be inserted by the editor) Mike P. Papazoglou · Willem-Jan van den Heuvel Service Oriented Architectures: Approaches, Technologies and Research Issues Received: June, 2005 / Accepted: date Abstract SOA is an emerging approach that addresses 1 Introduction the requirements of loosely coupled, standards-based, and protocol-independent distributed computing. Typ- Modern enterprises need to respond effectively and ically business operations running in an SOA comprise quickly to opportunities in today’s, ever more com- a number of invocations of these different components, petitive and global markets. To accommodate business often in an event-driven or asynchronous fashion that re- agility, enterprises are supposed to streamline (existing) flects the underlying business process needs. To build an business processes while exposing the various packaged SOA a highly distributable communications and integra- and home-grown applications found spread throughout tion backbone is required. This functionality is provided the enterprise in a highly standardized manner. A con- by the Enterprise Service Bus (ESB) that is an inte- temporary approach for addressing these critical issues is gration platform that utilizes web services standards to embodied by (web) services that can be easily assembled support a wide variety of communications patterns over to form a collection of autonomous and loosely-coupled multiple transport protocols and deliver value-added ca- business processes. pabilities for SOA applications. The emergence of web services developments and This paper reviews technologies and approaches that standards in support of automated business integration unify the principles and concepts of Service Oriented Ar- has driven major technological advances in the inte- chitecture with those of event-based programming. The gration software space, most notably, the Service Ori- paper also focuses on the ESB and describes a range ented Architecture (SOA) ([15], [35]). The purpose of of functions that are designed to offer a manageable, this architecture is to address the requirements of loosely standards-based SOA backbone that extends middleware coupled, standards-based, and protocol-independent dis- functionality throughout by connecting heterogeneous tributed computing, mapping enterprise information sys- components and systems and offers integration services. tems isomorphically to the overall business process flow. Finally, the paper proposes an approach to extend the In a SOA, software resources are packaged as “ser- conventional SOA to cater for essential ESB require- vices”, which are well defined, self-contained modules ments that include capabilities such as service orches- that provide standard business functionality and are in- tration, ”intelligent” routing, provisioning, integrity and dependent of the state or context of other services. Ser- security of message as well as service management. The vices are described in a standard definition language, layers in this extended SOA, in short xSOA, are used to have a published interface, and communicate with each classify research issues and current research activities. other requesting execution of their operations in order to collectively support a common business task or process Keywords service oriented architecture · asynchronous [42]. Services that utilize Web services standards, e.g., and event-driven processing · application and service WSDL, SOAP, and UDDI, are the most popular type of integration · enterprise bus · web services services available today. SOA is designed to allow developers to overcome many distributed enterprise computing challenges in- cluding application integration, transaction manage- INFOLAB, Tilburg University PO Box 90500, 5000 LE, Tilburg, The Netherlands ment, security policies, while allowing multiple platforms Tel.: +31-13-466 2349 and protocols and leveraging numerous access devices Fax: +31-13-466 3069 and legacy systems [4]. The driving goal of SOA is to E-mail: mikep@uvt.nl eliminate these barriers so that applications integrate
  2. 2. 2 Mike P. Papazoglou, Willem-Jan van den Heuvel and run seamlessly. In this way an SOA can deliver the Services used in composite applications may be brand flexibility and agility that business users require, defin- new service implementations, they may be fragments ing coarse grained services, which may be aggregated of old applications that were adapted and wrapped, or and reused to facilitate ongoing and changing needs of they may be combinations of the above. Often the de- business, as the key building block of enterprises. signers for the client of the service do not have direct In contrast to conventional software architectures pri- access to the service implementation, other than indi- marily delineating the organization of a system in its rectly through its interface. External Internet-based ser- (sub)systems and their interrelationships, the Service vice providers and SOA packaged applications simply of- Oriented Architecture captures a logical way of designing fer the interfaces without revealing the inner workings of a software system to provide services to either end-user their environment. Thus, with SOA, an enterprise can applications or other services distributed in a network create, deploy and integrate multiple services and chore- through published and discoverable interfaces. SOA is ograph new business functions by combining new and ex- focused on creating a design style, technology, and pro- isting application assets into a logical flow. Accordingly cess framework that will allow enterprises to develop, SOA can serve as an enabler of just-in-time integration interconnect, and maintain enterprise applications and and interoperability of legacy applications; a key consid- services efficiently and cost-effectively. While this goal eration for enterprises that are seeking to deploy demand is definitely not new [64], SOA seeks to eclipse previous driven computing environments. efforts such as modular programming, code reuse, and Services in an SOA exhibit the following main char- object-oriented software development techniques. acteristics [51]: – All functions in an SOA are defined as services SOA as a design philosophy is independent of any [2]. This includes purely business functions, business specific technology, e.g., web-services or J2EE enterprise transactions composed of lower-level functions, and beans. This is achieved by limiting the number of imple- system service functions as well. mentation restrictions to the level of the service interface. – All services are autonomous. Their operation is per- SOA requires that functions, or services, are defined by a ceived as opaque by external components. Service description language (WSDL [25] in the case of web ser- opaqueness guarantees that external components nei- vices) and have interfaces that perform useful business ther know nor care how services perform their func- processes. The fundamental intent of a service in an SOA tion, they merely anticipate that they return the is to represent a reusable unit of business-complete work. expected result. The implementation and execution A service in SOA is an exposed piece of functionality space of the application providing the desired func- with three essential properties. Firstly, a SOA-based ser- tionality is encapsulated behind the service interface. vice is self-contained, i.e., the service maintains its own – In the most general sense, the interfaces are invoca- state. Secondly, services are platform-independent, im- ble. This implies that it is irrelevant whether services plying that the interface contract to the service is limited are local or remote, the interconnect scheme or proto- to platform-independent assertions. Lastly, the SOA as- col to effect the invocation, nor which infrastructure sumes that services can be dynamically located, invoked components are required to establish the connection. and (re-)combined. SOA’s loose-coupling principle - especially the clean Logically, a service in a SOA is a bound pair of a ser- separation of service interfaces from internal implemen- vice interface and a service implementation. Service in- tations - to guide planning, development, integration, terface defines the identity of a service and its invocation and management of their network application platforms logistics. Service implementation implements the work make them indispensable for enterprise-wide and cross- that the service is designated to do. Because interfaces enterprise applications [2]. are platform-independent, a client from any communica- Web services seem to become the preferred imple- tion device using any computational platform, operating mentation technology for realizing the SOA promise of system and any programming language can use the ser- maximum service sharing, reuse, and interoperability vice. The two facets of the service are distinct and are [55]. Web services and SOA reduce complexity of enter- designed and maintained as distinct items, though their prise application eco-systems by encapsulation and min- existence is highly interrelated. imizing the requirements for shared understanding by An SOA provides a flexible architecture that uni- defining service interfaces in a unambiguous and trans- fies business processes by modularizing large applications parent manner. Also web services enable just-in-time into services. A client from any device, using any operat- integration and interoperability of legacy applications. ing system, in any programming language, can access a Based on open and pervasive standards, web services SOA service to create a new business process. A SOA cre- seem poised for success, as these are only built on top ates a collection of services that can communicate with of existing, ubiquitous infrastructure like HTTP, SOAP each other using service interfaces to pass messages from and XML. one service to another, or coordinating an activity be- In this article, we survey the underpinnings of SOA, tween one or more services. assessing methodologies and technologies that serve
  3. 3. Service Oriented Architectures: 3 Service Service Provider Provider Service requester Provider Requester Provider Requester Aggregator Service Service Provider Provider Fig. 1 The role of service aggregator. as the enabling springboard for business integration Requested operations of web services are imple- projects and deliver a flexible and adaptable environ- mented using one or more web service components [100]. ment. This survey is unique in that that it unifies the Web service components may be hosted within a web principles, concepts and developments in the area of ap- services container [31], serving as an interface between plication integration, middleware and integration bro- business services and low-level, infrastructure services. kers, service oriented architectures, event-driven com- In particular, web service containers are similar to J2EE puting, and adapters, and explains how they operate as containers ([3]) providing facilities such as location, rout- part of an emerging distributed computing technology ing, service invocation, and management. In particular, named the Enterprise Service Bus. Moreover, this pa- a service container is the physical manifestation of the per develops and explores an extension to conventional abstract service endpoint, and provides the implemen- Service Oriented Architectures (SOAs), entitled the eX- tation of the service interface. In addition, service con- tended SOA (xSOA). xSOA is an attempt to stream- tainers provide facilities for lifecycle management such line, group together and logically structure the functional as start up, shutdown, and resource cleanup. A service requirements of complex applications that make use of container can host multiple services, even if they are not the service-oriented computing paradigm. xSOA serves part of the same distributed process. Thread pooling al- as the reference for reviewing available technologies, and lows multiple instances of a service to be attached to assessing open research issues. multiple listeners within a single container [22]. Finally, the response that the provider sends back to the client takes again the form of a SOAP envelope carrying an XML message. 2 Service Roles in SOA SOAP is by nature a platform-neutral and vendor- SOAs and web services solutions support two key roles: neutral standard. These characteristics allow for a a service requestor (client) and service provider, which loosely-coupled relationship between requester and communicate via service requests. A role thus reflects a provider, which is especially important over the Internet type of a participant in a Service Oriented Architecture where two parties may reside in different organizations ([15], [54]). or enterprises. However, SOA does not require the us- Service requests are a messages formatted accord- age of SOAP. Prior to SOAP, for example, some compa- ing to the Simple Object Access Protocol (SOAP) [13]. nies used IBM’s WebSphere MQ to exchange XML doc- SOAP entails a light-weighted protocol allowing RPC- uments between them [77]. While this type of infrastruc- like calls over the Internet using a variety of transport ture clearly does not support web services because they protocols including HTTP, HTTP/S and SMTP. In prin- communicate using SOAP, they are another example of ciple, SOAP messages may be conveyed using any proto- service invocation in an SOA. Currently WebSphere MQ col as long as a binding is defined. The SOAP request is is, of course, equipped with direct support for SOAP. received by a run-time service (a SOAP ”listener”) that While SOA services are visible to the service client, accepts the SOAP message, extracts the XML message their underlying web components are transparent. The body, transforms the XML message into a native pro- service consumer does not have to be concerned with the tocol, and delegates the request to the actual business implementation of the service, as long as it supports the process within an enterprise. required functionality, while offering the desired quality
  4. 4. 4 Mike P. Papazoglou, Willem-Jan van den Heuvel Service Service Broker Broker publish find Service Service Service Service Provider Provider bind Client Client Fig. 2 Service brokering. of service. For the service provider, the design of compo- security and privacy standards such as SAML [40] and nents, their service exposure and management reflect key WS-Trust [80], introduce another role which addresses architecture and design decisions that enable services in these issues, called a service broker [27]. SOA. The provider view offers a perspective on how to Service brokers are trusted parties that force service design the realization of the component that offers the providers to adhere to information practices that comply services; its architectural decisions and designs. with privacy laws and regulations, or in the absence of The process of a service requester having to di- such laws, industry best practices. In this way broker- rectly interact with a service provider exposes service sanctioned service providers are guaranteed to offer ser- requesters to the potential complexity of discovering, ex- vices that are in compliance with local regulations and ploring, negotiating and reserving services between dif- create a more trusted relationship with customers and ferent service providers. An alternative approach is for partners. A service broker maintains an index of available an organisation to provide this combined functionality service providers. The service broker is able to ’add value’ directly to the service requester. This service role com- to its registry of application service providers by provid- bines the role of service requester and provider, and is ing additional information about their services. This may labelled as a service aggregator [63]. The service aggrega- include differences about the reliability, trustworthiness, tor thus performs a dual role. First, it acts as an applica- the quality of the service, service level agreements, and tion service provider as it offers a complete ’service’ solu- possible compensation routes to name a few. tion, by creating composite, higher-level services, which Figure-2 shows an SOA where a service broker serves it provides to the service client. Service aggregators can as an intermediary that is interposed between service re- accomplish this composition using specialized choreog- questers and service providers. Figure-2 falls under this raphy languages like BPEL [5] and BPML [6]. Second, category with the service registry (UDDI operator) being it acts as a service requester as it may need to request a specialised instance of a service broker. Under this con- and reserve services from other service providers. This figuration the UDDI registry serves as a broker where the process is shown in Figure-1. service providers publish the definitions of the services While service aggregation may offer direct benefits to they offer using WSDL and where the service requestors the requester, it is a form of service brokering that of- find information about the services available. fers a convenience function - all the required services are grouped ’under one roof’. However, an important ques- tion that needs to be addressed is how does a service re- 3 Enterprise Service Bus quester determine which one out of a number of potential application service providers, should be selected for their Essentially web services denote an important technol- service offerings? The service requester could retain the ogy for implementing SOAs, however, other more con- right to select an application service provider based on ventional programming languages or middleware plat- those that can be discovered from a registry service, such forms may be adopted as well [90]. In particular, all tech- as the UDDI [1]. SOA technologies such as UDDI, and nologies that directly implement service interfaces with
  5. 5. Service Oriented Architectures: 5 WSDL, and communicate with XML messages, can also conventional EAI technologies with web services, XSLT be involved in SOA. As indicated earlier, other technolo- [96], and orchestration technologies. Physically, an ESB gies such as, for instance, established middleware tech- provides an implementation backbone for an SOA. It es- nologies like J2EE, CORBA and IBM’s WebSphere MQ tablishes proper control of messaging as well as applies , can now also participate in an SOA, using new features the needs of security, policy, reliability and accounting, that work with WSDL. in an SOA architecture. The ESB, is responsible for the Fundamentally, there are only two options for solving proper control, flow and translations of all messages be- technology and information model mismatches: tween services, using any number of possible messaging protocols. An ESB pulls together applications and dis- 1. Build the client module to conform exactly to the crete integration components to create assemblies of ser- characteristics of every server module that it will in- vices to form composite business processes, which in turn voke. automate business functions in an enterprise. 2. Insert a layer of integration logic between the client Figure-3 depicts a simplified architecture of an ESB and server modules. that integrates a J2EE application using JMS, a .NET application using a C# client, an MQ application that The first approach requires to “develop an interface” interfaces with legacy applications, as well as external for each connection, resulting in a point-to-point topol- applications and data sources using web services. An ogy. This topology has long been known to be hard to ESB, as portrayed in Figure-3, enables the more efficient manage and maintain as it introduces a tighter form value-added integration of a number of different applica- of coupling to harmonize transport protocols, document tion components, by positioning them behind a service- formats, interaction styles etc [58]. This makes it harder oriented faade and by applying web services technology. to change either of the two systems involved in an in- In this figure, a distributed query engine, which is nor- terchange without impacting other systems. In addition, mally based on XQuery [12] or SQL, enables the creation point-to-point integration is not scalable and very com- of data services to abstract the complexity of underly- plex as the number of integration points increases as ing data sources. A portal in Figure 5 is a user-facing number of systems increases and can quickly become aggregation point of a variety resources represented as unmanageable. Hence the broad use of Enterprise Ap- services, e.g., retail, divisional, corporate employee, and plication Integration middleware supporting a variety of business partner portals. hub-and-spoke integration patterns [69]. This leaves the Endpoints in the ESB, depicted in Figure-3, provide second approach as the most viable alternative. abstraction of physical destination and connection infor- The second approach introduces an integration layer mation (like TCP/IP hostname and port number) tran- that must support interoperability among, and coex- scending plumbing level integration capabilities of tradi- ist with deployed infrastructure and applications. The tional, tightly-coupled, distributed software components. requirements to provide an appropriately capable and Endpoints allow services to communicate using logical manageable integration infrastructure for web services connection names, which an ESB will map to actual and SOA are coalescing into the concept of the Enter- physical network destinations at runtime. This destina- prise Service Bus (ESB) ([82], [22]). The ESB exhibits tion independence offers the services that are connected two prominent features [37]. Firstly, it promotes loose to the ESB, the ability to be upgraded, moved, or re- coupling of the systems taking part in an integration. placed without having to modify code and disrupt exist- Secondly, the ESB can break up the integration logic ing ESB applications. For instance, an existing ESB in- into distinct easily manageable pieces. voicing service could be easily upgraded by a new service, The Enterprise Service Bus (ESB) is an open, without disrupting the execution of other applications. standards-based message bus designed to enable the im- Additionally, duplicate processes can be set up to han- plementation, deployment, and management of SOA- dle fail-over if a service is not available. Endpoints also based solutions with a focus on assembling, deploying, provide the asynchronous and highly reliable commu- and managing distributed service-oriented architectures. nication between service containers. The endpoints can The ESB provides the distributed processing, standards- be configured to use several levels of quality of service, based integration, and enterprise-class backbone re- which guarantee communication despite network failures quired by the extended enterprise [37]. The ESB is de- and outages [22]. signed to provide interoperability between large-grained To successfully build and deploy a distributed applications and other components via standards-based Service-Oriented Architecture, there are four primary as- adapters and interfaces. The bus functions as both trans- pects that need to be addressed: port and transformation facilitator to allow distribution of these services over disparate systems and computing 1. Service enablement: Each discrete application needs environments. to be exposed as a service. Conceptually, the ESB has evolved from the store- 2. Service orchestration: Distributed services need to be and-forward mechanism found in middleware products, configured and orchestrated in a unified and clearly e.g., Message Oriented Middleware, and now combines defined distributed process.
  6. 6. 6 Mike P. Papazoglou, Willem-Jan van den Heuvel Custom Portals Service applications orchestration Reliable Asynchronous Secure Messaging service interface Distributed Web JMS/ MQ Adapters query engine Services J2EE gateway WebSphere Java apps Mainframe , .NET & legacy apps apps Data sources Enterprise Multi-platform applications support Fig. 3 Enterprise service bus connecting diverse applications and technologies. 3. Deployment: Emphasis should be shifted from test is illustrated in Figure-3 where applications running on to the production environment, addressing security, different platforms are abstractly decoupled from each reliability, and scalability concerns. other, and can be connected together through the bus as 4. Management: Services must be audited, maintained logical endpoints that are exposed as event-driven ser- and reconfigured. The latter requirements requires vices. that corresponding changes in processes must be made without rewriting the services or underlying application. Services can be programmed using application devel- 3.1 Event-driven SOA opment tools (like Microsoft .NET, Borland JBuilder, or BEA WebLogic Workshop), which allow new or existing In the enterprise context, business events, e.g., a cus- distributed applications to be exposed as web services. tomer order, the arrival of a shipment at a loading dock, Technologies like J2EE Connector Architecture (JCA) or the payment of a bill, may affect the normal course may also be used to create services by integrating pack- of a business process at any point in time [61]. This im- aged applications (like ERP systems), which would then plies that business processes can not be designed a-priori be exposed as services. assuming that events are predetermined following a par- To achieve its operational objectives the ESB draws ticular flow, but must be defined dynamically, driven by from traditional EAI broker functionality in that it pro- incoming, parallel and a-synchronous event flows. Sup- vides integration services such as connectivity and rout- porting enterprise applications then must communicate ing of messages based on business rules, data transfor- using an Event-Driven SOA ([88], [22]). An event-driven mation, and adapters to applications [23]. These capabil- SOA thus denotes an architectural approach on how en- ities are themselves SOA-based in that they are spread terprises could implement an SOA, respecting the highly out across the bus in a highly distributed fashion and volatile nature of business events. An ESB requires that hosted in separately deployable service containers. This applications and event-driven services are tied together is crucial difference from traditional integration brokers in the context of an SOA in a loosely coupled fashion. are usually highly centralised and monolithic in nature This allows them to operate independently from each [69]. The SOA approach allows for the selective deploy- other while still providing value to a broader business ment of integration broker functionality exactly where function [23]. it is needed with no additional over-bloating. The dis- In an ESB-enabled event-driven SOA, applications tributed nature of the ESB container model allows in- and services are treated as abstract service endpoints, dividual event-driven services to plugged into the ESB which can readily respond to asynchronous events [?]. backbone on an as needed basis, be highly decentralised The event-driven SOA provides a means of abstracting and work together in a highly distributed fashion, while away from the details of underlying service connectivity they are scaled independently from one another. This and protocols.
  7. 7. Service Oriented Architectures: 7 Services in this SOA variant are not required to un- its size, format, etc. In contrast to service interfaces how- derstand protocol implementations or have any knowl- ever, meta-data that is associated to events is generated edge on routing of messages to other services. An event on an ad-hoc basis, instead of being static and prede- source typically sends messages through some middle- fined. In particular, ad-hoc meta-data describe published ware integration mechanism like an ESB, and then the events that consumers can subscribe to, the interfaces middleware publishes the messages to the services that that service clients and providers exhibit as well as the have subscribed to the events. The event itself encapsu- messages they exchange, and even the agreed format and lates an activity, constituting a complete description of context of those meta-data, without falling into the for- a specific action. To achieve its functionality, the ESB mal service contracts themselves. supports both the established web services technologies, To effectively orchestrate the behaviour of services including, SOAP, WSDL, and BPEL, as well as emerging in a distributed process, the ESB infrastructure in- standards such as WS-ReliableMessaging [74] and WS- cludes a distributed processing framework and XML- Notification [91]. based services. To exemplify these features, a simplified As we already explained earlier in this section, in a distributed procurement business process as shown in brokered SOA (see Figure-2) the only dependency be- Figure-4, will be configured and deployed using an ESB. tween the provider and client of a service is the service The figure shows that when an automated inventory sys- contract (described in WSDL), which the third-party tem triggers a replenishment signal, an automated pro- service registry advertises. The dependency between the curement process flow is triggered and a series of logi- service provider and the service client is a run-time de- cal steps need to be performed. First the sourcing ser- pendency, not a compile-time dependency. The client ob- vice queries the enterprise’s supplier reference database tains and uses all the information it needs about the ser- to determine the list of possible suppliers, who could be vice at run-time. The service interfaces are discovered prioritized on the basis of existing contracts and supplier dynamically, and messages are constructed dynamically. metrics. A supplier is then chosen based on some crite- The service consumer does not know the format of the rion and the purchase order is automatically generated request message or response message or the location of in an ERP purchasing module and is sent the vendor of the service until it needs a particular service. choice. Finally, this vendor uses an invoicing service to Service contracts and other associated meta-data, in- bill the customer. cluding meta-data about policies and agreements [28], lay the groundwork for enterprise SOAs that involve The ESB distributed processing infrastructure is many clients operating with a complex, heterogeneous aware of applications and services and uses content-based application infrastructure. However, many of today’s routing facilities to make informed decisions about how SOA implementations are not that elaborate. In many to communicate with them. The services that are part of cases, when small or medium enterprises implement the distributed procurement business process depicted in SOA, neither service interfaces in WSDL nor UDDI look- Figure-4 can be seen in use in Figure 3. For this example, ups tend to be available. This is often either due to the the inventory is assumed to be out of stock, and the re- fact that the SOA in place provides for limited function- plenishment message is routed to a supplier order service. ality or because sufficient security arrangements are not Although this figure shows only a single supplier order yet in place. In these cases an event-driven SOA provides service as part of the inventory in reality a plethora of a more lightweight, straightforward set of technologies to supplier services may exist. The supplier order service, build and maintain the service abstraction for client ap- which executes a remote web service at a chosen sup- plications [11]. plier to fulfil the order, generates its output in an XML message format that is not understood by the purchase To achieve a more lightweight arrangement an event- order service. To avoid heterogeneity problems, the mes- driven SOA requires that two participants in an event sage from the supplier order service leverages the ESB’s (server and client) be fully decoupled [11], not just transformation service to convert the XML into a format loosely coupled. With fully decoupled exchanges the two that is acceptable by the purchase order service. Figure participants in an event need not have any knowledge 3 also shows that JCA is used within the ESB to allow about each other, before engaging in some business trans- legacy applications, such as credit check service, to be action. In this case, there is no need for a service (WSDL) placed onto the ESB through JCA resource adapters. contract that explicates the behavior of a server to the client. The only relationship is indirect, through the Once services that are part of the distributed pro- ESB, to which clients and servers are subscribed as sub- curement business process depicted in Figure-5 have scribers and publishers of events. Despite the notion of been chained together, it is essential to provide a way to decoupling in event-driven SOA, recipients of events re- manage and reconfigure them to react to changes in busi- quire meta-data about those events. The publishers of ness processes. Ideally, this could be achieved through the events often organize them on the basis of some (top- a sophisticated graphical business process management ical) taxonomy, which is a form of meta-data. Alterna- tool that can be used to configure, deploy and man- tively, meta-data is available about the event, including age services and endpoints. This allows the free move-
  8. 8. 8 Mike P. Papazoglou, Willem-Jan van den Heuvel Sending application Replenishment Sourcing Supplier order Purchase order Invoicing service service service service service Receiving application Fig. 4 Simplified distributed procurement process. ment and reconfiguration of services without requiring and integrated with modern technologies and appli- re-writing or modifying the services themselves. cations. – Service Communication Capabilities: A critical abil- ity of the ESB is to route service interactions through a variety of protocols, and to transform from one pro- 3.2 Key Capabilities tocol to another where necessary. Another important aspect of an ESB implementation is the capacity to In order to implement an SOA, both applications and support service messaging models consistent with the infrastructure must support SOA principles (see section- SOA interfaces, as well as the ability of transmit- 1). Enabling an application for SOA involves the creation ting the required interaction context, such as security, of service interfaces to existing or new functions, either transaction, or message correlation information. directly or through the use of adaptors. Enabling the in- – Dynamic Connectivity Capabilities: Dynamic con- frastructure, at the most basic level, involves provision nectivity pertains to the ability to connect to web ser- of the capabilities to route and deliver service requests vices dynamically without using a separate static API to the correct service provider. However, it is also vital or proxy for each service. Most enterprise applications that the infrastructure supports safe substitution of one today operate on a static connectivity mode, requir- service implementation by another, without any effect to ing some static piece of code for each service. Dy- the clients of that service. This requires not only that the namic service connectivity is key capability for a suc- service interfaces be specified according to SOA princi- cessful ESB implementation. The dynamic connectiv- ples, but also that the infrastructure allows client code ity API is the same regardless of the service imple- to invoke services irrespectively of the service location mentation protocol (web services, JMS, EJB/RMI, and the communication protocol involved. Such service etc.). routing and substitution are amongst the many capabil- – Topic/Content-based Routing Capabilities: The ESB ities of the ESB. Additional capabilities can be found in should be equipped with routing mechanisms to fa- the following list that describes detailed functional re- cilitate not only based, topic-based routing but also, quirements for an ESB. more sophisticated, content-based routing. Topic- We consider this ESB capabilities lists to be neces- based routing assumes that messages can be grouped sary to support the functions of a useful and meaningful into fixed, topical classes, so that subscribers can ex- ESB. Some of the ESB functional requirements described plicate interest in a topic and as a consequence receive in the list below have also been discussed by other au- messages associated to that topic [43]. Content-based thors such as ([78], [19], [51], and [22]). routing on the other hand, allows subscriptions on constraints of actual properties (attributes) of busi- – Leveraging Existing Assets: Legacy applications are ness events. The content of the message thus deter- technically obsolete mission critical elements of an mines their routing to different end-points in the ESB organisation’s infrastructure - as they form the core infrastructure. For example, if a manufacturer pro- of larger enterprise’s business processes – but are too vides a wide variety of products to its customers, frail to modify and too important to discard and thus only some of which are made in-house, depending must be reused. Strategically, the objective is to build on the product ordered it might be necessary to di- a new architecture that will yield all the value hoped rect the message to an external supplier, or route for, but tactically, legacy assets must be leveraged
  9. 9. Service Oriented Architectures: 9 Procurement Inventory Order J2EE application application Replenishment Supplier order Replenishment Supplier order service service service service SOAP/ XML/ HTTP JMS Enterprise Service Bus the vendor of choice. SOAP/ XML/ JMS JMS Purchase Order Credit check Purchase Order Credit check service service service service Invoicing Invoicing service service JCA JCA connector connector ERP Invoice Supplier Legacy cc application application Finance Fig. 5 Enterprise service bus connecting remote services. it to be processed by an internal warehouse fulfil- it desirable for the client to select the best endpoint ment service. In a typical application, a message is at run-time, rather than hard-coding endpoints at routed by opening it up and applying a set of rules build time. The ESB should therefore be capable of to its content to determine the parties interested in supporting various qualities of service. Clients can its content. Content-based routing is often depen- query a web service, such as an organizational UDDI dant on the message constructed in XML, and will service, to discover the best instance with which to usually be built on top of Message Oriented Middle- interact based on QoS properties. Ideally, these ca- ware, or JMS based messaging. Such ESB capabili- pabilities should be controlled by declarative policies ties could be based on emerging standard efforts such associated with the services involved using a policy WS-Eventing and WS-Notification. standard such as the WS-PolicyFramework [39]. – Endpoint Discovery with Multiple Quality of Ser- – Integration Capabilities: To support SOA in a het- vice Capabilities: The ESB should support the fun- erogeneous environment, the ESB needs to integrate damental SOA need to discover, locate, and bind to with a variety of systems that do not directly support services. Increasingly these capabilities will be based service-style interactions. These may include legacy around web services standards such as WSDL, SOAP, systems, packaged applications, COTS components, UDDI, and WS-PolicyFramework. As many network etc. When assessing the integration requirements for endpoints can implement the same service contract, ESB, several types or ”styles” of integration must the ESB should support service interactions with dif- be considered. Due their importance ESB integration ferent values to the business. Several scenarios make styles are discussed in some detail late in this article.
  10. 10. 10 Mike P. Papazoglou, Willem-Jan van den Heuvel – Transformation Capabilities: The various compo- vices - services that tend to run for long duration, nents hooked into the ESB have their own expec- exchanging message (conversation) as they progress. tations of messaging models and data formats, and Typical examples are an online reservation system, these might differ from other components. A major which interacts with the user as well as various ser- source of value in an ESB is that it shields any in- vice providers (airline ticketing, car reservation, hotel dividual component from any knowledge of the im- reservation, etc). plementation details of any other component. The In addition, it is of vital importance that the ESB transformation services make it possible to en- ESB provides certain transactional guarantees. More sure that messages and data received by any com- specifically, the ESB needs to be able to provide a ponent is in the format it expects, thereby removing means for various applications to interact and mes- the burden to make changes. The ESB plays a major sage with each other and to recover should some form role in transformations between different, heteroge- of technical or process failure occur. The challenge at nous data and messaging models, whether between hand is to ensure that complex transactions are han- legacy data formats (e.g., a COBOL/VSAM applica- dled in a highly-reliable manner and if failure should tion, running on an OS/390 host) and XML, between occur, transactions should be capable of rolling back basic XML formats and web services messages, or be- processing to the original, pre-request state. tween different XML formats (e.g., transforming an – Management and Monitoring Capabilities: In an SOA industry standard XML message to a proprietary or environment, applications cross system (and even or- custom XML format). ganizational) boundaries, they overlap, and they can – Reliable Messaging Capabilities: Reliable messaging change over time. Managing these applications is a refers to the ability to queue service request mes- serious challenge [7]. Examples include dynamic load sages and ensure guaranteed delivery of these mes- balancing, fail-over when primary systems go down, sages to the destination. It also includes the ability and achieving topological or geographic affinity be- to respond, if necessary, back to the requestor with re- tween the client and the service instance, and so sponse messages. Reliable messaging supports asyn- on. Effective systems and application management chronous store-and-forward delivery as well as guar- in an ESB requires a management framework that anteed delivery capabilities. Primarily used for han- is consistent across an increasingly heterogeneous dling events, this capability is crucial for responding set of participating component systems, while sup- to clients in an asynchronous manner, and for a suc- porting complex aggregate (cross-component) man- cessful ESB implementation. agement use cases, like dynamic resource provision- – Security Capabilities: Generically handling and en- ing and demand-based routing, service-level agree- forcing security is a key success factor for ESB im- ment enforcement in conjunction with policy-based plementations. The ESB needs to both provide a se- behaviour. The latter implies the ability to select ser- curity model to service consumers and integrate with vice providers dynamically based on the quality of the (potentially varied) security models of service service they offer compared to the business value of providers. Both point-to-point (e.g., SSL encryption) individual transactions. and end-to-end security capabilities will be required. An additional requirement for a successful ESB im- These end-to-end security capabilities include feder- plementation is the ability to monitor the health, ca- ated authentication, which intercepts service requests pacity and performance of services. Monitoring is the and adds the appropriate username and credentials; ability to track service activities that take place via validation of each service request and authorization the bus and accommodate visibility into various met- to make sure that the sender has the appropriate rics and statistics. Of particular significance is the privilege to access the service; and, lastly, encryp- ability to be able to spot problems and exceptions tion/decryption of XML content at the element level in the business processes and move toward resolving for both message requests and responses. To address them as soon as they occur. Process monitoring ca- these intricate security requirements trust models, pabilities are currently provided by toolsets in plat- WS-Security [8] and other security related standards forms for developing, deploying and managing service have been developed. applications, such as, for instance, WebLogic Work- – Long Running Process and Transaction Capabilities: shop. Service-orientation, as opposed to distributed object – Scalability Capabilities: With a widely distributed architectures such as .NET or J2EE, make it possi- SOA, there will be the need to scale some of the ble to more closely reflect real-world processes and services or the entire infrastructure to meet inte- relationships. It is believed that SOA represents a gration demands. For example, transformation ser- much more natural way to model and build soft- vices are typically very resource intensive and may ware that solves real-world business processing needs require multiple instances across two or more com- [2]. Accordingly, the ESB should provide the ability puting nodes. At the same time, it is necessary to to support business processes and long running ser- create an infrastructure that can support the large
  11. 11. Service Oriented Architectures: 11 nodes present in a global service network. The loose remote container. With JSR 168 and WSRP maturing, coupled nature of a SOA requires that the ESB uses the possibility of a true EJB federated portal can become a decentralized model to provide a cost effective solu- a reality. tion that promotes flexibility in scaling any aspect of Application connectivity: Application connectiv- the integration network. A decentralized architecture ity is an integration style concerned with all types of enables independent scalability of individual services connectivity that the ESB integration layer must sup- as well as the communications infrastructure itself. port. At the infrastructure level, this means concerns such as synchronous and asynchronous communications, As ESB integration capabilities in the above list are routing, transformation, high speed distribution of data, central in understanding the material that follows and a and gateways and protocol converters. On the processing key element of the ESB when performing service-oriented level, application connectivity also relates to the virtual- integration, we shall consider them in some detail in the ization of input and output, or sources and sinks. remainder of this section. Virtualization signifies the fact that input are re- ceived and passed to applications in the ESB in a source- 3.3 Integration Styles neutral way. Special purpose front-end device and pro- tocol handlers should make that possible. For connec- ESBs employ a service-oriented integration solution that tivity, an ESB can utilize J2EE components such as leverages amongst other issues open standards, loose the Java Message Service for MOM connectivity, and coupling, and the dynamic description and discovery ca- J2EE Connector Architecture for connecting to appli- pabilities of web services to reduce the complexity, cost cation adapters. An ESB can also integrate easily with and risk of integration. Other salient characteristics of applications built with .NET, COM, C#, C++ and C. the ESB architectural integration style are that it is In addition, an ESB can integrate easily with any appli- technology agnostic and can reuse functionality in ex- cation that supports SOAP and web services. isting applications to support new application develop- Application Integration: Application integration ment. There is a series of important technical require- is concerned with building and evolving an integration ments that need to be addressed by a service-oriented backbone capability that enables fast assembly and dis- integration solution ([51], [37]). These include: assembly of business software components. Application Integration at the presentation-tier: Integration integration is an integral part of the assembly pro- at the presentation-tier is concerned with how the com- cess that facilitates pragmatic ’best of breed’ portfolio plete set of applications and services a given user accesses strategies which combine legacy applications, acquired are fabricating a highly distributed yet unified portal packages, external application subscriptions and newly framework that provides a usable, efficient, uniform and built components. The ESB should focus on a service- consistent presentation-tier. In this way, the EJB can based application integration style that enables better- provide one face to the users resulting in consistent user structured integration solutions that deliver: experience, with unified information delivery while al- – Applications comprised of interchangeable parts that lowing underlying applications remain distributed. Two are designed to be adaptable to business and tech- complementary industry standards that are emerging in nology change. the portal space, can assist with these efforts [75]: – Evolutionary application portfolios that protect in- 1. JSR 168: This is an industry standard that defines a vestment and can respond rapidly to new require- standard way to develop portlets. It allows portlets ments and business processes to be interoperable across portal vendors. For exam- – Integration of various platform and component tech- ple, portlets developed for BEA WebLogic Portal can nologies. be interoperable with IBM Portal. This allows orga- nizations to have a lower dependency on the portal Process Integration: Process integration is con- product vendor. cerned with the development of automated processes 2. WSRP (Web Service for Remote Portals): This is that map to and provide solutions for business processes, an industry standard that allows remote portlets to integration of applications into processes, and integrat- be developed and consumed in a standard manner ing processes with other processes. Process-level integra- and facilitates federated portals. WSRP combines the tion may include the integration of business processes power of web services and portal technologies and is and applications within the enterprise (viz. EAI solu- fast becoming the major enabling technology for dis- tions). It also may involve the integration of whole pro- tributed portals in an enterprise. cesses, not just individual services, from external sources, such as supply chain management or financial services JSR 168 complements WSRP by dealing with local that span multiple institutions (viz. e-Business integra- rather than distributed portlets. A portal page may have tion solutions). certain local portlets which are JSR 168 compliant and Data Integration: Information integration [72] is some remote, distributed portlets that are executed in a the process of providing a consistent access to all the data
  12. 12. 12 Mike P. Papazoglou, Willem-Jan van den Heuvel in the enterprise, by all the applications that require it, in we use the simplified distributed procurement process whatever form they need it, without being restricted by shown in Figure-4. Figure-6 exemplifies that when an au- the format, source, or location of the data. This require- tomated inventory system triggers a replenishment sig- ment, when implemented, might involve adapters and nal, an automated procurement process flow is triggered transformation facilities, aggregation services to merge and first the enterprise’s supplier reference database is and reconcile disparate data, e.g., merging two customer queried to determine the list of possible suppliers, who profiles, and validation to ensure data consistency, e.g., could be prioritized on the basis of existing contracts and minimum income should be equal to or exceed a certain supplier metrics. A supplier is then chosen based and the threshold. Data should be transformed irrespectively of purchase order is automatically generated in the ERP the formats under which it exists, the operating system purchasing module and is sent to the vendor of choice. that manages the data, and the location where the data The figure illustrates that the integration-broker is is stored. the system centrepiece. The integration-broker facilitates Integration design and development method- information movement between two or more resources ology: One of the requirements for the application de- (source and target applications) and accounts for differ- velopment environment must be that it takes into ac- ences in application semantics and heterogeneous plat- count all the styles and levels of integration that could forms. The various existing (or component) Enterprise be implemented within the enterprise, and provide for Information Systems (EIS), such as Customer Relation- their development and deployment. To be truly robust, ship Management, ERP systems, transaction processing the development environment must rely on a method- monitors, legacy systems and so on, in this configuration ology that clearly prescribes how services and compo- are connected to the integration broker by means of re- nents are designed and built in order to facilitate reuse, source adapters. A resource adapter is used to provide eliminate redundancy, and simplify integration, testing, access to a specific EIS. The purpose of the adapters is deployment, and maintenance. to provide a reliable insulation layer between application All of the styles of integration listed above will have APIs and the messaging infrastructure. These adapters some form of incarnation within any enterprise, even enable non-invasive application integration in a loosely though in some cases they might be simplified or not coupled configuration. clearly defined. It is important to note that all integra- Integration brokers are able to share information with tion styles must be considered when embarking on an a multitude of systems by using an asynchronous, event- ESB implementation. driven mechanism thus they constitute an ideal support framework for asynchronous business processes. Integra- tion brokers, as realized in enterprise application integra- 3.4 Enabling Technologies tion suites, have historically been used for the integration of packaged applications via specific and often heavily In this section, we will review the technological under- customized adapters. Nowadays, this type of middleware pinnings of ESBs in some more detail. Fundamentally, is responsible for brokering messages exchanged between ESBs fuse the following four types of technologies: in- multiple applications, providing the ability to transform, tegration brokers, application servers, business process store, and route messages, also the ability to apply busi- management and adapters. ness rules and respond to events. The integration broker architecture presents several 3.4.1 Integration Brokers advantages as it tries to reduce the application integra- tion effort by providing pre-built functionality common A prominent technology to interconnect disparate busi- to many integration scenarios. The value proposition ness applications, many of which are home-grown, ERP rests on reuse (in terms of middleware infrastructure and systems or legacy systems, constitutes integration bro- the application integration logic) across multiple appli- kers. Integration brokers come in many manifestations, cations and initiatives. Modern integration brokers in- ranging from early application-to-application brokers to corporate integration functionality such as: transforma- more sophisticated broker topologies managing transac- tion facilities, process integration, business process man- tions, security, (resource) adapters and application pro- agement and trading partner management functionality, tocols [18]. Some examples of commercially available in- packaged adapters, and user-driven applications through tegration brokers include: IBM’s WebSphere Integration front-end capabilities such as Java Server Pages (JSP). Broker, PeopleSoft’s AppConnect, and Sun ONE Inte- gration Server. Figure-6 presents a high-level view of the typical ar- 3.4.2 Application Servers chitecture for implementing integration broker. In par- ticular, this figure illustrates the use of an integration Application servers are widely used to develop and de- broker to integrate functions and information from a va- ploy back-end server logic. Application servers enable riety of back-end enterprise information systems. To ef- the separation of application (or business) logic and in- fectively illustrate the workings of the integration broker, terface processing and also coordinate many resource
  13. 13. Service Oriented Architectures: 13 • Application integration • Business Processes • Business Rules • Meta-data Meta- • Data Transformation integrating application • Message Routing (contains busines composition logic) logic) Integration Broker Inventory Supplier ERP adapter data adapter adapter Replenishment Replenishment Sourcing Generate PO Send PO signal Sourcing Generate PO Send PO signal Supplier Inventory Reference ERP Supplier Management Database Fig. 6 Integration broker integrating disparate back-end systems. connections. The most prominent features of applica- Unlike integration brokers, they do not integrate back- tion servers include secure transactional execution en- end systems directly. vironment, load balancing, application-level clustering Because application servers were created for Web- across multiple servers, failover management should one based transactions and application development and be- of these servers break down [58]. In addition, application cause of their ability to provide component-based inte- servers provide application connectivity and thus access gration to back-end applications makes make them useful to data and functions associated with EIS applications, as support framework for integrating business processes. such as ERP, CRM and legacy applications. While appli- cation servers are focused on supporting new application Figure 10 illustrates the use of an application server development, they do not natively support integration. for a wholesale application that brings together ERP ca- pabilities with sophisticated customer interfaces to open Application servers, such as SUN’s J2EE [36], IBM’s up new models of sales and distribution. The compo- WebSphere [41] and Microsoft’s .NET [59], typically nent wrappers in this figure facilitate point-integration provide Web connectivity for extending existing solu- of component systems, e.g., ERP, CRM and distributor tions and bring transaction processing mechanisms to the databases, as they introduce each of them to the appli- Web. In essence, an application server is simply a collec- cation server. A component wrapper may be defined as tion of services that support the development, run-time a software layer that encapsulates legacy data and logic execution, and management of business logic for Web- and defines its services in the wrapper API. The wrap- enabled applications. The application server middleware per API mediates between calls from client application enables the functions of handling transactions and ex- components to the underlying legacy code and data, by tending back-end business data and applications to the transforming incoming requests into a message format Web. Application servers retrieve information from many that is understandable to the internal code and data [81], existing enterprise systems and expose them through a [83]. single interface, typically a Web browser. This makes ap- The terms “adapter’ and “wrapper” are often used in- plication servers ideal for portal-based EAI development. terchangeably, as we will also do throughout this article.
  14. 14. 14 Mike P. Papazoglou, Willem-Jan van den Heuvel Java/EJB-based Java/EJB- Web-based Web- CORBA/COM -based client client client • Front-end of many EAI initiatives, Front- (i.e. composites) • Application connectivity • Business Processes • Business Rules • Security • Transaction Mgt • Message Routing Web server Application development tools Application server Component Component Component Component Component Component Wrapper Wrapper Wrapper Wrapper Wrapper Wrapper Adapter Adapter Adapter Adapter Adapter Adapter Distributor ERP application CRM application data Fig. 7 Application server providing access to back-end systems. Another term that is often adopted in the same context Execution in this type of architecture occurs among of that of wrappers, is the term ”connector”. A connector component wrappers within the application server. refers to the encapsulation of a communication mecha- These component wrappers wrap back-end resources nism. This term originates from architectural descrip- such as databases, ERP, transaction mainframe systems tion languages (ADLs), while the design pattern which and legacy systems so that they can express data and is concerned with the encapsulation of the communica- messages in the standard internal format expected by the tion between components is called “Mediator” [17]. The application server. The application server is oblivious to prime distinction between a connector and an adapter is the fact that these components are only the external fa- that an adapter bridges an interoperability problem, i.e., cade of existing EIS that do the real processing activities without the adapter the components would not be able [60]. to work together, while a connector enables the commu- The adapter/component wrapper pairs in the archi- nication between to interoperable components [94]. tecture illustrated in Figure-7 are responsible for provid- ing a layer of abstraction between the application server Simply speaking, a component wrapper contains a and the component EIS. This layer allows for EIS com- software layer that encapsulates legacy data and logic ponent communications, as if the component EIS were and defines its services in the wrapper API. The wrap- executed within the application server environment it- per API mediates between calls from client application self. Traditional application servers constitute an ideal components to the underlying legacy code and data, by support framework for synchronous business processes. transforming incoming requests into a message format However, newer generation application servers offer also that is understandable to the internal code and data. asynchronous communication.
  15. 15. Service Oriented Architectures: 15 Web application servers already provide database all kinds. Application boundaries may range from simple connectivity, transaction management, EAI-style con- enquiries about a customer’s order involving two appli- nectors, message queuing, and are gradually evolving cations, to complex, long-lived transactions for process- into business process execution engines. They also facil- ing an insurance claim involving many applications and itate reliability, scalability, and availability, while at the human interactions, to parallel business events for ad- same time automating application development tasks. vanced planning, production and shipping of goods along In concluding, a few words about application server the supply chain involving many applications, human in- implementation. Application servers are principally teractions and business to business interactions. When J2EE-based and include support for JMS [47], the Java integrating on such a scale, enterprises need a greater 2 Connector Architecture (J2CA) [46], and even web ser- latitude of functionality to overcome multiple challenges vices. arising from the existence of proprietary interfaces, di- JMS is a transport-level API that enterprises can verse standards, and approaches targeting the techni- combine with web service solutions for messaging, data cal, data, automated business process, process analysis persistence, and access to Java-based applications. JMS and visualization levels. Such challenges are addressed is a vendor agnostic API for enterprise messaging that by business process management (BPM) technology [95]. can be used with many different MOM vendors. JMS BPM is the term used to describe the new generation of frameworks function in asynchronous mode but also technology that provides end-to-end visibility and con- offer the capability of simulating a synchronous re- trol over all parts of a long-lived, multi-step information quest/response mode [68]. For application server im- request or transaction/process that spans multiple ap- plementations, JMS provides access to business logic plications and human actors in one or more enterprises distributed among heterogeneous systems. Having a [57]. message-based interface enables point to point and pub- Specialised capabilities of BPM software solutions in lish/subscribe mechanisms, guaranteed information de- an ESB setting include workflow-related business pro- livery, and interoperability between heterogeneous plat- cesses, process analysis and visualization techniques. In forms. particular, BPM allows the separation of business pro- J2EE Connector Architecture is an emerging tech- cesses from the underlying integration code. Before we nology that has been specifically designed to address the explain further characteristics and typical elements of hardships of integrating applications. J2CA provides a BPM, it is useful to distinguish between the concepts standardized method for integrating disparate applica- of process automation, workflow and business processes tions in J2EE application architectures. It provides sup- management. port for resource adaptation, which maps the J2EE secu- All enterprises have business processes that require rity, transaction, and communication pooling to the cor- process automation. Any process automation tool should responding EIS technology. J2CA defines a set of func- be able to easily control and coordinate activity and tionality that application server vendors can use to con- provide an easy method to define the business process nect to back-end EIS, such as ERP, CRM and legacy and the underlying flows of information between appli- systems and applications. Using J2CA to access enter- cations. Process automation is distinct from traditional prise information systems is akin to using JDBC (Java document workflow as it involves integration between Database Connectivity) [98] to access a database. When computer-based systems and manual steps and tasks. It J2CA is used in an ESB implementation, the ESB could is implemented for automating the flow of information provide a J2CA container that allows packaged or legacy between applications to fulfil business processes. Tradi- applications to be plugged into the ESB through J2CA tional workflow tools focus instead on handling the move- resource adapters. For instance, a process order service ment of documents between people who are required to uses JCA to talk to a J2EE application that internally perform tasks on these documents [56]. This may or may fulfils incoming orders. The latest versions of many appli- not be directly associated with managing a business pro- cation servers, including BEA WebLogic and IBM Web- cess. For example, an order may generate a shipping no- Sphere, support J2CA adapters for enterprise connectiv- tice. The shipping notice may in turn generate a monthly ity. In addition, major packaged application vendors have invoice that encompasses many orders for the same cus- also announced plans to support JCA in future product tomer. This is an example of a workflow that changes offerings. The ESB uses J2CA to facilitate application focus several times. It is not tracking the order to com- integration between existing applications and services. pletion, but rather, it tracks only the information gener- ated. 3.4.3 Business Process Management A business process includes both automated and manual processes. Business process automation combines Today enterprises are striving to become electronically process automation together with task-based workflow connected to their customers, suppliers, and partners. into a managed, end-to-end process [56]. To achieve this, they are integrating a wide range of dis- BPM codifies value-driven processes and institution- crete business processes across application boundaries of alises their execution within the enterprise [79]. This
  16. 16. 16 Mike P. Papazoglou, Willem-Jan van den Heuvel implies that BPM tools, such as Chordiant 1 , Pega 2 based routing to create an SOA that solves complex inte- and Fuego 3 , can help analyse, define and enforce pro- gration problems. An ESB uses the concept of itinerary- cess standardisation. BPM provides a modelling tool to based routing to provide a message with a list of routing visually construct, analyse and execute cross-functional instructions. In an ESB, routing instructions, which rep- business processes. Design and modelling of business pro- resent a business process definition, are carried with the cesses is accomplished by mans of sophisticated graphical message as it travels through the bus across service in- tools. In the previous example, BPM would enable the vocations. The remote ESB service containers determine modelling of the broader order management process en- where to send the message next, making this type of compassing order receipt, perhaps credit approval, ship- routing a special category of content-based routing. ping and invoicing. Combining BPM with real-time anal- The ESB can also benefit from products developed ysis allows business managers to not only track where by BPM vendors such as IBM’s WebSphere, HP’s HP orders are in this process, but also to understand the Process Manager, BEA’s WebLogic, and Vitria’s Busi- company’s exposure with regard to orders in total at nessWare. Microsoft BizTalk is another good example of any given point in time. a BPM integration product, but its use is limited to Mi- BPM is a commitment to expressing, understanding, crosoft Windows and .NET servers. Commercial BPM representing and managing a business (or the portion of solutions such as, for instance, Vitria’s BusinessWare-4 business to which it is applied) in terms of a collection of provide organisations with a number of mechanisms for business processes that are responsive to a business en- simplifying the deployment and management of an in- vironment of internal or external events [66]. The term tegration solution. They consist of range of tools and management of business processes includes process anal- technologies that allow the organisation to model, test, ysis, process definition and redefinition, resource alloca- deploy, and refine such a process-driven integration so- tion, scheduling, measurement of process quality and ef- lution. ficiency, and process optimisation. Process optimisation includes collection and analysis of both real-time mea- sures (monitoring) and strategic measures (performance 3.5 Adapters management), and their correlation as the basis for pro- cess improvement and innovation. For the most part, business applications in an enter- A BPM solution is a graphical productivity tool for prise are not designed to communicate with other ap- modelling, integrating, monitoring, and optimising pro- plications. There is often an interoperability mismatch cess flows of all sizes, crossing any application, company between the technologies used within internal systems boundary, or human interaction. BPM is driven primar- and with external trading partner systems. In order to ily by the common desire to integrate supply chains, as seamlessly integrate these disparate applications, there well as internal enterprise functions, without the need must be a way in which a request for information in one for even more custom software development. This means format can easily be transformed into a format expected that the tools must be suitable for business analysts, by the called service. For instance, in Figure-3 the func- requiring less (or no) software development. They must tionality of a J2EE application needs to bee exposed to reduce maintenance requirements because internally and non-J2EE clients such as .NET applications and other externally integrated environments routinely require ad- clients. In doing so, a web service may have to integrate ditions and changes to business processes. BPM promises with other instances of enterprise information systems in the ability to monitor both the state of any single pro- an organisation, or the J2EE application itself may have cess instance and all instances in the aggregate, using to integrate with other EISs. In such scenarios, how the present real-time metrics that translate actual process application exchanges information to the ESB depends activity into key performance indicators. on the application accessibility options. There are three When sophisticated process definitions are called for alternative ways an application can exchange informa- in an ESB, a process orchestration engine – that sup- tion with the ESB include [37]: ports BPEL [5] or some other process definition language such as ebXML Business Process Specification Schema 1. Application-provided web service interface: Some (BPSS) [93] – may be layered onto the ESB. The pro- applications and legacy application servers have cess orchestration may support long-running, stateful adopted the open standards philosophy and have in- processes, just like BPEL. In addition, it may support cluded a web services interface. The WSDL defines parallel execution paths, with branching, and merging the interface to communicate directly with the appli- of message flow execution paths based on join conditions cation business logic. Where possible, taking a direct or transition conditions being met. Sophisticated process approach is always preferred. orchestration can be combined with stateless, itinerary- 2. Non-web service interface: The application does not expose business logic via web services. An 1 www.chordiant.com application-specific adapter can be supplied to pro- 2 www.pega.com vide a basic intermediary between the application 3 www.fuego.com API and the ESB.

×