 | |||
|
Wednesday January 23 2002 Web Services Architectures How they stack up Download the free extended PDF version of this article. Each vendor, standards organization, or marketing research firm defines Web Services in a different way. Gartner, for instance, defines Web Services as "loosely coupled software components that interact with one another dynamically via standard Internet technologies." Forrester Research takes a more open approach to Web Services as "automated connections between people, systems and applications that expose elements of business functionality as a software service and create new business value." For these reasons, the architecture of a Web Services stack varies from one organization to another. The number and complexity of layers for the stack depend on the organization. Each stack requires Web Services interfaces to get a Web Services client to speak to an application server or middleware, such as Common Object Request Broker Architecture (CORBA), Java 2 Enterprise Edition (J2EE), and .NET. To enable the interface, you need Simple Object Access Protocol (SOAP), SOAP with Attachments (SwA), and Java Remote Method Invocation (RMI) among other Internet protocols. In this article, we will take a look at three Web Services Architecture stacks, those from WebServices.Org, IBM, and the W3C. Of course, Microsoft, Sun, The Stencil Group, Oracle, Borland, BEA, and Hewlett-Packard have outlines for stacks themselves, but we choose not to include these for the sake of brevity. As we look at these Web Services architecture stacks, we will explain a little of what purpose the technologies under discussion serve. Although we have a variety of Web Services architectures, Web Services, at a basic level, can be considered a universal client-server architecture that allows disparate systems to communicate with each other without using proprietary client libraries, according to a webMethods white paper on Implementing Enterprise webServices with the webMethods Integration Platform (December 2001). The white paper points out that "this [architecture] simplifies the development process typically associated with client/server applications by effectively eliminating code dependencies between client and server" and "the server interface information is disclosed to the client via a configuration file encoded in a standard format (e.g., (WSDL)." Doing so allows the server to publish a single file for all target client platforms. WebServices.Org The following is the Web Services stack from WebServices.Org:
Service Negotiation The business logic process starts at the Services Negotiation layer (the top) with, say, two trading partners negotiating and agreeing on the protocols used to aggregate Web Services. This layer is also referred to as the Process Definition Layer covering document, workflow, transactions, and process flow. Workflow, Discovery, Registries The stack then moves to the next layer to establish workflow processes using Web Services Flow Language (WSFL) and MS XLANG, an XML-based language to describe workflow processes and spawn them. The W3C web site has not indicated whether it has received the WSFL proposal for consideration. If it has, the proposal has not yet been posted on the web site. WSFL specifies how a Web Service is interfaced with another. With it, you can determine whether the Web Services should be treated as an activity in one workflow or as a series of activities. While WSFL complements WSDL (Web Services Definition Language) and is transition-based, XLANG is an extension of WSDL and block structured-based. WSFL supports two model types: flow and global models. The flow model describes business processes that a collection of Web Services needs to achieve. The global model describes how a set of Web Services interacts with one another. XLANG, on the other hand, allows orchestration of Web Services into business processes and composite Web Services. WSFL is strong on model presentation while XLANG does well with long-running interaction of Web Services. Among the software supporting WSFL is IBM MQ Series Workflow (now known as WebSphere Process Manager) that automates business process flows, optimizes Enterprise Application Integration (EAI) with people workflow, provides scalability, and complies with the Workflow Coalition and multi-platform capabilities. MSXLANG is the language implemented in BizTalk, the XML integration server from Microsoft. Web Services that can be exposed may, for example, get information on credit validation activities from a public directory or registry, such as Universal Description, Discovery and Integration (UDDI). The ebXML, E-Services Village, BizTalk.org, and xml.org registries, and Bowstreet's (a stock service brokerage) Java-based UDDI (jUDDI) are other directories that could be used with UDDI in conjunction with Web Services for business-to-business (B2B) transactions in a complex EAI infrastructure under certain conditions. Hewlett Packard Company, IBM, Microsoft, and SAP launched beta implementations of their UDDI sites that have conformed to the latest specification (UDDI v2), including enhanced support for deploying public and private Web Service registries, and the interface (SOAP/HTTP API) that the client could use to interact with the registry server. In addition to the public UDDI Business Registry sites, enterprises can also deploy private registries on their intranet to manage internal Web Services using the UDDI specification. Access to internal Web Service information may also be extended to a private network of business partners. Service Description Language As you move down the stack, you need WSDL to specify how to connect to a Web Service. This language is an XML format for describing network services. With it, service requesters can search for and find the information on services via UDDI, which, in turn, returns the WSDL reference that can be used to bind to the Web Service. Web Service Conversational Language (WSCL) helps developers use the XML Schema to better describe the structure of data in a common format (say, with new data types) the customers, Web browsers, or indeed any XML enabled software programs can recognize. This protocol can be used to specify a Web Service interface and to describe service interactions. Messaging Now, we get to the Messaging Layer in the stack where SOAP acts as the envelope for XML-based messages, covering message packaging, routing, guaranteed delivery and security. Messages are sent back and forth regarding the status of various Web Services as the work progresses (say, from customer order to shipping product out of the warehouse). Transport Protocols When a series of messages completes its rounds, the stack goes to its last layer: the transport layer, using Hypertext Transfer Protocol (HTTP), Secure HTTP (HTTPS), Reliable HTTP (HTTPR), File Transfer Protocol (FTP), or Standard Mail Transfer Protocol (SMTP). Then, each Web Service takes a ride over the Internet to provide a service requester with services or give a status to a service provider or broker. Business Issues Finally, the Business Issues row in the table lists other key areas of importance to the use and growth of Web Services. Without consideration to these points, Web Services could quickly become objects of ridicule. IBM The IBM Conceptual Web Services stack is part of Web Services Conceptual Architecture (WSCA) 1.0 (http://www-4.ibm.com/software/solutions/webservices/pdf/WSCA.pdf). It is presented in a slightly different way than that of the WebServices.Org stack, by starting with Web Services tools and then showing what purpose of each layer is used for.
The IBM Web Services Stack does not show WSCL and ebXML, included in the WebServices.Org stack. It associates the Network layer with IBM MQSeries messaging systems (now called WebSphere MQ) and the Internet Inter-ORB Protocol (IIOP) - a protocol CORBA uses to transmit data, information, and messages between applications. These do not appear in the WebServices.Org stack. IBM considers WSDL as a description of the service endpoints where individual business operations can be accessed. WSFL uses WSDL for the description of service interfaces and their protocol bindings. WSFL also relies on WSEL (Web Services Endpoint Language), an endpoint description language to describe non-operational characteristics of service endpoints, such as quality-of-service properties. Together, WSDL, WSEL, and WSFL provide the core of the Web Services computing stack. IBM perceives UDDI in two categories: static and direct. Static UDDI refers to a service directory established after applying WSFL to Service Flow, while dynamic UDDI pertains to service publication of directory items. Similarly to the WebServices.Org stack, the IBM stack applies QoS, management, and security to all layers. As of May 2001, IBM announced software and tools that enable businesses to create, publish, securely deploy, host, and manage Web Services applications, using the IBM Services Stack as the framework. They include WebSphere Application Server Version 4.0, WebSphere Studio Technology Preview for Web Services, WebSphere Business Integrator, DB2 Version 7.2, Tivoli Web Services Manager (to monitor performance of all aspects of the Web Services environment), and Lotus software suite (to enable Web collaboration, knowledge management and distance learning). WebSphere was originally the collective name of IBM's J2EE application server family. It has since been stretched to include most of their Middleware and application development offerings, such as MQSeries Workflow now (known as WebSphere Process Manager). IBM currently offers a Web Services ToolKit (WSTK) to help in designing and executing Web Service applications so they can find one another and collaborate in business transactions without programming requirements or human intervention. W3C The W3C Web Services Workshop, led by IBM and Microsoft, has agreed that the architecture stack consists of three components: Wire, Description, and Discovery. The following table shows what layers constitute the Wire Stack.
As you will notice, this Wire Stack has extensions to two layers: SOAP and XML. This means whenever the SOAP is used as the envelope for the XML messages, they must be attached, secure, reliable, and routed to the intended service requester or provider. In the stacks of other organizations, SOAP and XML are not treated as "extensions." IBM, for instance, refers to SOAP as a tool for its stack layer, "XML-Based Messaging." The Description Stack, the most important component, consists of five layers:
This stack starts with orchestration of business processes from which the messages are sequenced, depending on how service capabilities are configured. Whatever comes out of the proposal on combining WSFL/MS XLANG that IBM and Microsoft submitted to the W3C last year will be the tool for the Business Process Orchestration layer. What needs to be resolved is to consider what parts of WSFL and MS XLANG are more open than the other: transition-based versus block structured-based control flow, and extending versus complementing WSDL among others. The Service Capabilities layer is similar to IBM's WSEL as mentioned in IBM WSCA 1.0 and WSFL 1.0 (http://www-4.ibm.com/software/solutions/webservices/pdf/WSFL.pdf). Like IBM, the W3C uses WSDL to describe service interface and service implementation, neither of which is explicitly highlighted in other stacks. WSDL may use a hefty chuck of XML Schema and takes advantage of SOAP/HTTP bindings to WSDL. SMTP, Reliable HTTP (HTTPR), and HTTP Get are other possible bindings that could be used. As the name implies, the Discovery Stack involves the use of the UDDI, allowing businesses and trading partners to find, discover and inspect one another in a directory or so over the Internet, as follows:
The Inspection Layer refers to the WSIL (Web Services Inspection Language, or WS-Inspection) specification. WSIL assists in the inspection of a site for available services. Due to the decentralized nature of Web Services, this specification doesn't work well if the communication partner is unknown. In such cases, you would be better off with UDDI. This specification was announced by both IBM and Microsoft to the W3C in November 2001. It is another service discovery mechanism (http://www-106.ibm.com/developerworks/library/ws-wsilover/index.html) and is complementary to UDDI (http://www.webservicesarchitect.com/content/articles/modi01.asp). Putting all three stack-components together, we have the Architecture Stack.
Conclusion Based on initial findings and the current state of implementations, IBM's architecture is most acceptable. All architectures, however, will eventually come into one umbrella, as there is a risk that if companies go away and keep on building their own extensions to the Basic architecture stack, the promise of Web Services could be lost. The IBM versions, current and future, could serve as an industry-wide Standard Stack model, after W3C accepts new standards resulting from, for example, the convergence of IBM WSFL and Microsoft XLANG on workflow processes. This article is an extract from Web Services Business Strategies and Architectures. Buy the book from Amazon.com Download the free extended PDF version of this article. Web
Services Architectures by Judith M. Myerson Adobe Acrobat format (PDF) - 54K Keep up to date with all the new articles and features on
Web Services Architect: | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
