【正文】 Simple Object Access Protocol pieces of software to municate with each other. The Simple Object Access ProtocolAfter SOAP, the Web Services Description Language (WSDL) and Universal Discovery, Description, Integration (UDDI) specifications were introduced with an equal amount of industry support. Other specifications were rapidly introduced, including ebXML, OASIS technical munities, and a variety of SOAP extensions. Some specifications were met with acclaim and others with disappointment. Either way, the industry has unified around SOAP, WSDL, and UDDI. These core technologies are required to achieve true software interoperability for the future.It was only a matter of time before developers wanted to use web services technology. Even though web services are language and platform independent, developers still have to develop programs in programming languages. With Java and J2EE being the primary environment for enterprise development, it wasn39。t long before technology used to integrate web services with the J2EE platform appeared. Java programs need to be able to create, locate, and consume web services.Many specifications and technologies have been introduced to bridge the gap between Java and web services. This book provides an introduction to both web services and the Java technologies that have been introduced to support web services. It highlights major web services technologies and investigates the current happenings in the Java standardization munity. As the web services revolution continues, it will be increasingly important for software developers to understand how web services work and when to use them. Reading this book may be one of the smartest career moves you will ever make. Potential Interoperability Issues There are certainly enough interoperability issues to worry about in the present. Unfortunately, they aren39。t the entire story. A number of other issues are poised to bee a problem as web services standards continue to develop. Layering Decisions Several extensions, such as security and reliability, are necessary to plete the web services picture. However, standards bodies have not yet decided where these extensions belong. IBM has proposed HTTPR (reliable HTTP), while other participants in web services standards development disagree about whether reliability belongs at the transport protocol level. XML has added reliability in their message protocol standard. The same issue exists for security (some of these issues are discussed in Chapter 10) and quality of service (QoS). Java Web Services Standards Development and Proliferation Currently, the W3C and other standards bodies are trying to identify which gaps in the web services standards most need to be filled. Reliability and security are mentioned most often, but beyond that, there is no consensus about which missing standards are most critical or what the list should even include. Standards groups are not coordinated as they try to address these gaps, so a proliferation of peting standards often duplicates or overlaps. This proliferation will undoubtedly cause additional interoperability issues to surface. To add to the confusion, vertical markets often create their own standards to expedite business exchange within (or between) markets. The result is that the most widely implemented standard usually wins, whether or not it represents the best solution. However, until the dust settles, interoperability will bee more of a nightmare as web services implementations increasingly require a level of sophistication beyond the existing ubiquitous standards such as SOAP, XML, and HTTP. Here is is an overview of some of the developing standards that could have an effect on the interoperability challenge: W3C In April 2001, the W3C held a Web Services Workshop, during which a number of presentations proposed work items for the W3C. The following working groups were identified (in order of priority): New Wire working group XML protocol extensions (QoS, reliable messaging, attachments, messaging models, routing, and publish/subscribe) Definition language (conversation, QoS, security, representation for business process and state changes, contracts, and negotiation) Orchestration (conversations, work flow, and business process) Discovery/Registration (generic query language and expression of vocabularies/terminologies) Management Architecture Group (security and QoS) Coordination Group (including external groups) ebXML The ebXML effort, initiated jointly by OASIS and UN/CEFACT, is developing standards in a number of areas, including: Messaging (based on SOAP with reliability, intermediaries, and some security) Business process Collaboration party profiles and party agreements OASIS OASIS efforts include: Security Assertion Markup Language (SAML) Business Transaction Processing (BTP) Universal Business Language (UBL—business process) Java Web Services 200 Web Services for Interactive Applications (WSIA—previously the Web Services Component Model [WSCM]) Conformance and interoperability standards There has been some call for standardized interoperability. This standard would include definitions of interoperability requirements between deployment environments and strong conformance statements as part of the Another proposed idea is that layers of SOAP interoperability should be defined with a minimal SOAP implementation and several extended implementations scoped above the minimum (for example, base SOAP plus reliability). The ebXML Message Specification has taken this approach in their latest draft (). One argument against this approach is that the goal is to encourage open munication among implementations。 defining optional subsets increases the risk of interoperability problems.Unit Testing Unit testing basically involves writing test cases to ensure that your classes function tests are typically fairly lowlevel and modular—ideally, you shou