ENTERPRISE SERVICES. By Paul Fremantle, Sanjiva Weerawarana, and Rania Khalaf

By Paul Fremantle, Sanjiva Weerawarana, and Rania Khalaf ENTERPRISE SERVICES Examining the emerging field of Web Services and how it is integrated into existing enterprise infrastructures. oth on the Web and on internal networks, there is an increasing effort to connect computer systems. The reasons for this are widespread, but there are two major themes behind these reasons. The first theme is e-business, which is motivating companies to expose their business processes over the Web. This entails linking their core business systems to the Web site. As e-business and the Web have developed, more and more integration is being pushed through the portal model. In the portal model, a single Web site becomes a desktop at which users can access the main systems, functions, and data they need. For example: a Web portal might offer news, stock prices, sports results, weather, shopping and travel information from a single Web site; a developer portal could offer developers access to the code, compilers, GUI tools, and documentation they need to do their jobs; and a business portal may offer business data, marketing and sales information, stock levels, access to Web site hit statistics, and trade information. All these activities require integration. The second theme is business process management (BPM), which is the systematic automation of everyday business processes by integrating core systems. BPM requires a change in the way applications are viewed. Monolithic applications are reevaluated as a set of components and services that are then reaggregated into new processes. The focus of BPM is integration of processes, and in many cases, BPM is driven by the need to expose processes to Web users efficiently and effectively so the processes can scale if the Web site attracts many users. The base standards of the Web services technology stack are outlined here. SOAP. The Simple Object Access Protocol (SOAP) is typically understood to be a request-response (RPC) mechanism, based on HTTP. In fact, SOAP is fundamentally much simpler. SOAP starts out as just XML message format: an envelope, which contains an address, some headers (or none), and a body. The body consists of one or more elements. The elements may be encoded using a standard SOAP encoding, more simply stated, a standard way of capturing programming language data elements integers, doubles, strings in a common interoperable format. The SOAP message may be part of an RPC operation, in which case the parameters are encoded as child elements of a common parent, whose name indicates the operation, and whose namespace indicates which service. Finally, SOAP can be sent over a transport typically HTTP but other transports such as RMI/IIOP, Instant Messaging, IBM WebSphere MQSeries, or BEEP are also possible (see www-3.ibm.com/software/ts/mqseries/ and www. beepcore.org). SOAP is key to interoperability, because almost every vendor, both large and small, supports it. In addi- COMMUNICATIONS OF THE ACM October 2002/Vol. 45, No. 10 77

tion, major B2B standards such as ebxml and RosettaNet have agreed to use SOAP as a messaging protocol (see www.ebxml.org and www.rosettanet. org). WSDL. The Web Services Description Language offers the ability to describe the inputs and outputs of a Web service (see www.w3.org/2002/ws/desc/). It allows a server to publish the interface of a service, so a client knows that if it sends a SOAP message in format A to the service, it will receive a reply in format B. WSDL has two key strengths: It enforces a separation between the interface and implementation. The interface must be described as an abstract PortType, which is defined in terms of the input and/or output messages that it supports for each operation. This abstract service is then bound to a particular implementation at a particular location using a Port (location) and Binding (implementation style). Secondly, WSDL is inherently extensible. The core WSDL specification only describes the abstract interface and the structure of ports and bindings. Actual implementation types, such as SOAP, are described using extensions. This extensibility means WSDL can be used to describe almost any service-oriented interaction. Tools based on WSDL allow the creation of proxies that can communicate and use Web services and implementation skeletons or templates for implementing a Web service within a specific programming model. These proxies and skeletons/templates offer a simple familiar programming model to use Web services and do not require any knowledge or manipulation of the raw SOAP or XML messages. Using XML and message models for communication allows message broker products (for example, IBM WebSphere MQ Integrator) to observe in-flight messages and perform transparent addition of capability. Some examples are message transformations, content-based routing, publish/ subscribe models, and automatic warehousing of messages. UDDI. UDDI is both a standard and a set of public implementations hosted by companies such as IBM and Microsoft. These public UDDI implementations can be used by any Internet-connected business to publish, search for, and locate businesses and services. Businesses can be organized and categorized according to their industry. Each service is assigned a unique identifier called a tmodel, which allows users of UDDI to search for particular services across businesses. UDDI can also be implemented within a closed user group, or within a closed network to provide details of businesses or organizations where the public UDDI is not appropriate. This usage is called Private UDDI, though a private UDDI server might still be accessible by anyone on the Internet. WSIL. The Web Services Inspection Language complements the discovery features of UDDI (see www-106.ibm.com/developerworks/webservices/ library/ws-wsilspec.html). UDDI provides for a global or wide-scale directory of services. Analogous to large-scale Web-content directories such as the Open Directory Project (see dmoz.org), UDDI is key to finding and identifying services. However, it is also important to be able to understand which local services are available on a particular site. The Inspection standard offers this ability to query a given site or server and retrieve a list of available services. The list of services includes pointers to either WSDL documents or UDDI service entries. WSIL is a useful lightweight way of accessing a service description without requiring access to a UDDI server. Most person-facing Web sites provide a site map to help guide users; WSIL is a similar function for programs that wish to explore a site. What Is a Web Service? The basic SOAP/WSDL/UDDI standards are a particular implementation of the concept of a serviceoriented architecture. In fact, it is sometimes useful to consider the benefits of these standards as two separate aspects. For simplicity, we ll call these two aspects of Web services the Web aspect and the Services aspect. What we are describing as the Web aspect of Web services are the following attributes: Web-based protocols: Web services based on SOAP-over-HTTP are designed to work over the public Internet. The use of HTTP for transport means these protocols can traverse firewalls, and can work in a heterogenous environment. Interoperability: SOAP defines a common standard that allows differing systems to interoperate. For example, the tooling allows Visual Basic clients to access Java server components and vice versa. XML-based: The Extensible Markup Language is a standard framework for creating machine-readable documents. Managed by the World Wide Web Consortium (www.w3.org), XML is an open Web standard for creating interoperable standard documents. The Services aspect has the following attributes: 78 October 2002/Vol. 45, No. 10 COMMUNICATIONS OF THE ACM

Modular: Service components are useful in themselves, reusable, and it is possible to compose them into larger components. Available: Services are available to systems that wish to use them. Services must be exposed outside of the particular paradigm or system they are available in. Described: Services have a machine-readable description that can be used to identify the interface of the service (that is, what sort of service it is), and its location and access information (that is, where it is). Implementation-independent: The service interface must be available in a way that is independent of the ultimate implementation. For example, SOAP services can be hosted by almost any technology. Published: Service descriptions are made available in a repository where users can find the service and use the description to access the service. All of these benefits are important to the Web services vision, especially when connecting disparate systems across the Web. However, many companies have invested heavily in existing integration mechanisms, such as message-oriented middleware and CORBA. As we talk to such companies, we often hear they are tempted by the simplicity and power of the Web services vision, but they want to use existing tried and trusted infrastructure in conjunction with the service-oriented architecture. One other powerful aspect of the Web services vision is that it unifies two styles of integration: request-response and messaging. Typically, many integration approaches have selected either tightly coupled request-response approach, or the loosely coupled one-way messaging. Each approach has different strengths, and as companies have become involved in more complex Web integration, they have often discovered that a well-built user experience requires both styles. Both SOAP and WSDL offer support for using and describing one-way and request-response style interactions. Enterprise Architectures and Service Orientation The service-oriented model builds on software components that are deployed as services. Such components are then described in WSDL and the descriptions are published in a registry (UDDI) or made available for discovery (WSIL). When another enterprise component needs a service that satisfies some functionality, then a query is made against the registry to find the WSDL of an available service or the WSDL is discovered by some mechanism. Once the service is found, the service client binds to the service provider and exchanges messages in some format/protocol (such as SOAP) to solve the problem. The programming model for service orientation is thus defined by the component model of WSDL. WSDL offers a simpler programming model than distributed object systems; instead it offers a componentoriented view. Many of the key features of distributed object systems are avoided in WSDL; despite this lack of advanced functionality, there is wide support to keep the service component model of Web services at that level. The main motivation for this is that while OO concepts are invaluable in building the service components themselves, typically such interfaces are too complex for building cross-application distributed processes or integration. This simplified model has a lot of resonance for users of legacy enterprise systems. Many such systems offer interfaces similar to the services model, which can be mapped onto Web services very simply. For example, many mainframe applications are built using the CICS system (www-3.ibm.com/software/ ts/cics/). In CICS, each operation is known as a transaction, and has a specific ID. The transaction has an input that is a datastream, and an output that is a datastream. These datastreams are either screen data or packed binary arrays known as COMMAR- EAs and typically have data at fixed points. It is an interesting exercise to look through the attributes of Web services we described earlier and compare them to the main CICS interface: Protocol: CICS does support HTTP, but the main protocol for calling transactions across a network is SNA, which is not a Web-based protocol! Interoperability: CICS is actually quite interoperable, as there exist clients on most platforms to call CICS systems. XML-based: No. Modular: Yes, in fact many CICS transactions are used and reused by other systems. Available: CICS supports access from a number of different clients (COM, Java, C/C++, Windows, Unix, and other mainframe applications). Described: The transaction description is buried in the Cobol or C source code for the transaction where the commarea or screen map is defined. Implementation-independent: The interface offered by CICS is very specific to CICS, and it is not feasible to replace CICS transactions by other implementations with significant change to the calling application. Published: There is no directory of available transactions. COMMUNICATIONS OF THE ACM October 2002/Vol. 45, No. 10 79

The services-oriented vision offers many benefits to enterprises, and the creation of a class of enterprise services allows us to create services that are modular, accessible, well-described, implementation-independent, and interoperable. We can see from this analysis that CICS transactions offer a few of the services attributes, but significantly lack the description, independence of technology, and open protocols. Here, we describe two approaches to making enterprise systems into enterprise services. The first approach is SOAP-enabling the transaction; the second approach is creating a service infrastructure for enterprise systems. In fact both approaches are likely to be used together. Using Web Services to Integrate Enterprises It is quite easy to map a CICS transaction or other enterprise system into a Web service. For example, IBM provides a tool 1 that reads the Cobol or C definitions, generates connector objects that use the Java Connector Architecture, and deploys these as SOAP-enabled, WSDL-described services in an application server. In this model, a Web application server provides SOAP and HTTP support, and connects using SNA, for example, to the mainframe, and the conversion logic to convert between the SOAP structures and legacy structures is stored as generated Java code produced by the tool. The same approach is available to other enterprise systems that provide connectors via the Java J2EE Connector Architecture (see java.sun.com/j2ee/connector/). Other enterprise systems are also providing similar tools that Web service-enable their systems. For example, IBM WebSphere Application Server, BEA Weblogic Application Server, and other J2EE systems are exposing their business components, Enterprise JavaBeans, written to the Java 2 Enterprise Edition (J2EE), as SOAP-enabled services. This approach is a very useful first step, as it allows different enterprise systems to be connected using lightweight protocols and XML-based technology. Composition, Choreography, and Processes One of the main benefits of the service architecture is the separation between the interface and the implementation. The outcome of this separation is that it encourages the separation of the business 1 WebSphere Studio Application Developer, Integration Edition 4.1. logic of the application from the implementation and infrastructure details. We can take this a step further by allowing the whole process to be specified using a process document that captures the flows, states, and activities involved in the process and allows the process to be executed by a process manager. This approach is an alternative to the programmatic way of building business logic and offers some significant differences. First, such processes can be built graphically, and at the highest level are comprehensible and usable by business analysts. Secondly, the process manager executing the process has the ability to manage aspects of the process more closely than a normal execution runtime. In particular, the use of compensation and extended transactional models can significantly enhance the architecture and the ability to build successful crossenterprise process integration. Compensation. Traditional enterprise systems have relied on the two-phase commit model of transactions in order to deliver consistency and robustness. In this model, resources are locked during the duration of any business operation, and then all resources involved are updated simultaneously. This model has proved successful in tightly coupled, highly-available systems such as mainframes. However, two-phase commit is not well suited to the distributed integration model we have been describing. Resources may become locked for long periods of time, holding up other transactions until the enterprise systems no longer function effectively. The alternative to this model is known as compensation. In the compensation model, each activity in a larger business process is committed as the process proceeds. Then, at a later stage, if there is a problem with the process then the activities are compensated. A simple example shows the difference between the two models. In two-phase commit, during a transaction, a bank account would be locked and no other credits or debits would be allowed. If there was a failure the account balance would be reset to the level it was before the transaction started. In the compensation model, the balance would be updated (say a debit of $500). Other transactions would continue to modify the account balance. If there was a problem, a compensation 80 October 2002/Vol. 45, No. 10 COMMUNICATIONS OF THE ACM

An example of a business process built from wiring together existing services. and choreograph those as parts of a larger business process. In this approach, the business process is choreographed by a process manager, which sends SOAP-over-HTTP requests to application servers, which in turn use connectors to invoke existing legacy applications using proprietary protocols and approaches. Although this model is relatively easy to understand, and it has a number of benefits: transaction would occur which in this case would be a credit of $500. Web Services Business Process Languages. There have been a number of proposed languages for specifying business processes in terms of Web services, including XLANG from Microsoft and WSFL from IBM. Recently, BEA, IBM, and Microsoft jointly published a converged specification that supercedes WSFL and XLANG: Business Process Execution Language for Web Services (BPEL4WS); see www.ibm.com/developerworks/library/ws-bpel/. Such languages allow graphical tools to be used to define business processes. The tool creates a process document that is an XML document describing the process, and the process manager can then execute this document. An important aspect of this document is that it describes the process purely in terms of the interface of the service. In WSDL terms, it is the PortType of the service that is used. Therefore, when the process is deployed, or at the beginning of a new process, the process must be bound to a real set of services. This underscores the separation between the business logic and the implementation and infrastructure. The business process is an abstract process that can be bound to a real set of services at the time of execution. The accompanying figure shows an example of a business process built by wiring together existing services into a flow. So far we have described technology that can expose existing enterprise applications as services, The business process is clearly defined in a machine-readable language and can be created and edited using graphical tools. The process is defined in terms of the business activities. These are services, which have welldefined interfaces in WSDL, and these can be published in a controlled private UDDI directory. The system is heterogenous and interoperable, as the links between systems are based on open protocols. There are also a number of issues with the model that can be addressed to take the architecture onward: The systems are interconnected using SOAP-over- HTTP. This protocol is not reliable (though work is occurring to add reliability). More importantly, there is no management and monitoring infrastructure for this. Many organizations will be unwilling in the near-term to replace existing reliable, managed, secure infrastructures with SOAPover-HTTP. The linkages and logic of the connections to the existing systems are stored as compiled components in the application server, as described previously. So while there is significant metadata and description of the Web services aspect of the system, there is a hard stop, at which point we move to generated connector objects that are deployed. This makes ongoing maintenance and management more difficult, and also obscures the final COMMUNICATIONS OF THE ACM October 2002/Vol. 45, No. 10 81

system and service from the description. There can be significant inefficiency in this system. The process manager may have direct access to the application server where the connectors are running. For example, they may be two components running in the same application server process, but all communication is happening through the network, over HTTP, and via XML. This involves significant parsing and processing of XML, as well as additional sockets and threads in the HTTP server. Moving Beyond SOAP In building the structure and architecture of a process manager for Web services, it is important to address the issues previously listed. The Web Services Invocation Framework (WSIF) addresses these aspects by providing a way to describe the underlying services directly, and also how to invoke them independently of the underlying protocol or transport (see the WSIF link at xml.apache.org/axis). As we ve discussed, ports and bindings of WSDL are extensible. WSIF uses this ability by allowing the creation of extensions of WSDL for describing how to access enterprise systems, and allowing those extensions to be used to access systems. For example, a WSDL document could contain a description of how to access an existing CICS-based enterprise service directly through the Java Connector Architecture, through RMI-IIOP to an EJB, and via SOAP. For each of these system types, a pluggable component called a WSIF provider allows the WSIF runtime to invoke the services directly. This allows the enterprise developer to use a tool to create a description of the CICS transaction, EJB, or other service. Users of the service build their application or process based on the abstract description. At deployment time or runtime, the service is bound to a particular port and binding through the provider. WSIF is an extensible framework, which can be enhanced by creating new providers. A provider supports a specific extensibility type of WSDL, for example SOAP or Enterprise JavaBeans. The provider is the glue that links the code the developer wrote to use the service to the actual implementation available. WSIF supports late binding, so a service can be relocated at runtime, or even moved to a different system, protocol and provider, and the clients can automatically pick up the updated WSDL and retarget the new service. This approach allows the service provider to provide the service through multiple protocols for example the same CICS transaction could be exposed and published as available through direct access to the CICS system, via an Enterprise JavaBean (available over RMI- IIOP) and as a SOAP-over-HTTP service. The client software can examine the WSDL and choose the most appropriate binding available. For example, a Web client on a wide area network will ignore all but the SOAP binding, while another application server running a business process could invoke the service using RMI-IIOP. This approach offers a much clearer enterprise services architecture, which allows the enterprise services to be described more clearly, and addresses the major issues with the SOAP-only integration approach. WSIF also incorporates a Dynamic Invocation Interface (DII). The WSIF DII allows system applications to invoke Web services where the interface may not be defined until runtime. For example, a tool may offer a test client that examines the WSDL description and prompts the user for inputs based on the structure of the parameters, and then uses the WSIF DII to invoke the service. Other examples of software that might (and do) use the DII are: process managers, which are coordinating multiple services based on a process document; Web services intermediaries, which are performing on-the-fly interception of service requests; and other middleware servers.wsif is an open-source project under the auspices of the Apache Foundation (www.apache.org). Conclusion We have described an architecture that builds upon the Web services proposals in a standard and extensible way. We believe the services-oriented vision offers many benefits to enterprises, and the creation of a class of enterprise services allows us to create services that are modular, accessible, well-described, implementation-independent and interoperable, yet still efficient, manageable and that work with existing infrastructures. Using this infrastructure, process managers can allow business processes to be composed and choreographed based on exposed enterprise and Web services. c Paul Fremantle (pzf@uk.ibm.com) is a senior software engineer with the IBM Software Group at the Hursley Park Laboratory, U.K. Sanjiva Weerawarana (sanjiva@us.ibm.com) is a research staff member with IBM Research at the T.J. Watson Research Center in Hawthorne, NY. Rania Khalaf (rkhalaf@us.ibm.com) is a software engineer with IBM Research at the T.J. Watson Research Center in Hawthorne, NY. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. 2002 ACM 0002-0782/02/1000 $5.00 82 October 2002/Vol. 45, No. 10 COMMUNICATIONS OF THE ACM