Communications of the ACM

• 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.

• 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:

• 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.

• 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.

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.

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.

• 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 well-defined 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 SOAP-over-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 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.