4.7.1 SOAP Architecture This section discusses the characteristics of the SOAP architecture, their architecture implications, and the outlook of the technology. W3C's XML Protocol working group is currently incorporating SOAP 1.2 as part of the new XML Protocol. Details can be referenced at http://www.w3.org/2000/xp/Group/ . Characteristics. Applications built on the SOAP architecture share the following characteristics: -
They are built on loosely- coupled message-based architecture. -
They have two modes of communication: synchronous (request “reply, RPC), and asynchronous (document, one-way). -
The transport and message levels are decoupled. SOAP 1.2 does not mandate SOAPAction in the HTTP header; thus the SOAP message can be decoupled from the HTTP header. Also refer to Chapter 3, Web Services Technology Overview. Architecture Implication . The underlying transport HTTP is stateless. In other words, synchronous communication simulates request “reply on stateless HTTP by storing the state. We need different SOAP message constructs to handle synchronous and asynchronous modes. We cannot use the same client to handle both modes. The security needs to be handled by a mixture of transport-, message-, and application-level protection. The configuration files and WSDL stored in the SOAP server are in clear text, and this may have security implications. SOAP Constraints and Beyond. The protocol itself does not provide guaranteed message delivery or message-level Quality of Service. For instance, SOAP-RPC invokes remote application calls but it does not assure the call is always successful. It cannot specify Quality of Service priority (that is, high, critical, guaranteed delivery) when passing messages. The protocol cannot support polymorphism, for example, based on the parameter to invoke different methods . It does not provide workflow integration capability. Technology Outlook. HTTPR ( http://www-106.ibm.com/developerworks/ webservices /library/ws-httprspec/ ) is a proprietary extension to HTTP proposed by IBM, which enhances the transport-level security. It is not yet clear whether it has gained any strong traction in the industry yet. SOAP-JMS binding provides guaranteed message delivery or Quality of Service depending on the quality of the underlying JMS vendor. The reliability of SOAP messaging is gaining more attention from developers. There are some vendor products that address the reliability issue of SOAP messaging by providing a JMS Bridge (such as Progress SonicXQ) and some vendors are beginning to support ebMS (such as TIBCO). The business process model applied to Web Services is preliminary. Further convergence with ebXML is expected (for example, BPEL4WS proposal (http://www-106.ibm.com/developerworks/webservices/library/ ws-bpel /) is a step toward workflow integration). It is anticipated that W3C and OASIS will take a more proactive role in working toward a common standard for business process orchestration using Web Services technology. DCOM, CORBA, and Web Services. Wahili, Tomlinson, Zimmermann, Deruyck, and Hendriks have noticed some interesting comparisons between DCOM, CORBA, and Web Services (see Table 4-3). Table 4-3 shows a comparison of DCOM, CORBA, and Web Services, where Web Services technology provides more flexibility using XML and a loosely coupled client “server computing approach. Interestingly, IBM's UDDI registry was developed by the CORBA development team, who reuse many of the CORBA objects previously developed. Table 4-3. Comparing DCOM, CORBA, and Web Services | | DCOM | CORBA | Web Services | | End-point naming | OBJREF | Interoperable object reference (IOR) | URL/URN | | Interfaces | Single | Multiple | Multiple ”WSDL | | Payload types | Binary | Binary | Text | | Payload parameter value format | Network data representation (DR) | Common data representation | XML | | Server address resolution | Directory | Naming service | IP routing, URN | | Message dispatcher | ID-based | ID-based | Namespace, and parameter types | | Client “server coupling | Tight | Tight | Loose | 4.7.2 UDDI Architecture This section discusses the design of the UDDI Service Registry and its architecture implications to developers. Most UDDI implementations today use version 2.0, and are targeted as a private Service Registry, not a public Service Registry. UDDI version 3.0 ( http://www.oasis- open .org/ committees /uddi-spec/tcspecs.shtml#uddiv3 ) is currently available. Nevertheless, the commercial implementation is still maturing. Information Model. UDDI has a sound business information model, tModel, to represent business service information. Business and service information is cross-referenced by service keys. Access Design. UDDI Service Registry is intended to be like DNS (for IP address for domains). The UDDI browser plug-in is available for client browsers. The service look-up performance and UDDI server security depend on the vendor implementation. Architecture Implication. You do not need to look up the service end-point by service keys in order to invoke the Web services. UDDI look-up provides the benefits of central repository of services information and run-time bindings (instead of hardcoding ). Every user is able to browse and access the UDDI Service Registry, provided that it has access. Vendor-specific implementation may provide additional security (for example, UDDI implemented on a LDAP server). Differentiator. The key differentiator for UDDI implementation is the availability of a powerful, algorithmic-based, search engine to navigate and locate Service Provider information faster. Another feature is the browser-based GUI to create multiple levels of tModel relationships and Service Provider product hierarchy. A user-friendly GUI administration wizard to guide defining GUID and service end-points would be essential, as it does not require users to understand the nitty-gritty of tModels. It is also useful to have a test UDDI prior to publishing it, tight integration to any developer workbench, and a built-in UDDI browser plug-in available for Web browsers. All in all, there should be robust local UDDI security features (for example, RDBMS security, Access Control Levels for different UDDI levels, and capability to support LDAP authentication). The UDDI implementation should not lock in any underlying vendor product infrastructure or software platform. Constraints. The reliability and scalability of UDDI implementation is vendor-specific. UDDI does not address trading partner profiles and communications contracts like CPP and CPA in ebXML. Thus, there is no constraint or service agreement in client “server or server “server data exchange. Technology Outlook. The private UDDI Service Registry seems to be more easily accepted than a public UDDI. UDDI will evolve to address trading partner agreement, tangent to ebXML's CPP and CPA. Should trading partner's work flow information (for example, BPEL4WS) be stored in UDDI as well? 4.7.3 ebXML Architecture This section discusses the design features of ebXML, the architecture implications, and their constraints. This technology is gaining more industry support ( http://www.ebxml.org/endorsements.htm ) with increasing vendor support and commercial implementations since 2001. Characteristics. There are plenty of ebXML business and conceptual architecture documents available from the official Web site ( http://www.ebxml.org/ specs /index.htm ). In summary, ebXML architecture, which now supports Web Services, has the following characteristics: -
They should have loosely-coupled message-based architecture. -
Similar to SOAP, ebXML decouples transport and message level and supports synchronous and asynchronous communication. -
They have sophisticated business process models, and some of them reflect previous EDI data exchange paradigms (many OASIS participants and contributors are EDI veterans ). Architecture Implication. The architecture foundation is good, though commercial offerings are still maturing. The Collaboration Partner Profile and Collaborative Partner Agreement (aka the service contract between trading partners) need to be agreed upon between trading partners . This is more complicated to implement than WSDL-UDDI-SOAP technology because ebXML can be used to support complex Web Services for workflow processing and collaboration. ebXML Message Service (ebMS) allows guaranteed delivery of messages even if the recipient is not online temporarily. It requires a message provider class that ensures messages are delivered after the recipient is back online. Nowadays, the SOAP message service can be made more reliable by binding it to Java Message Service (JMS). It is sometimes called SOAP-JMS binding for message services. This requires using a JMS bridge to intercept a SOAP message, with a message provider delivering the message to the recipient using the underlying middleware infrastructure. Nevertheless, SOAP-JMS binding technology is not part of the SOAP or JMS specification yet. Constraints. The complexity of the business process model makes design and implementation difficult. Thus, it may take longer for architects and developers to implement complex workflow processing using ebXML. In contrast, WSDL-UDDI-SOAP technology is not mature enough to implement complex workflow processing, though the recent Business Process Execution Language for Web Services (BPEL4WS) and Web Services Choreography Interface (WSCI) are examples of new initiatives that address these requirements. Industry support and implementation for ebXML is growing slowly. There are also a number of customers holding a "wait-and-see" position regarding ebXML technology, perhaps because the concept of implementing complex Web Services with workflow capability is still young and maturing. Technology Outlook. We are seeing further convergence of ebXML and SOAP technology. OASIS recently changed its strategy in ebXML standards development. Sun's Web Services Developer Pack will expedite and shape future evolution of ebXML implementation. Sun will continue to support ebXML, especially in providing reference implementation such as ebXML Service Registry.  | 