June 20, 2011, 11:12 p.m.
posted by maxidax
The Technologies of Web Services
The term Web services has many different definitions, depending on your perspective. Some definitions that have been proposed by the media and Web services experts are so ambiguous as to be almost useless. This is not the fault of the people who have tried to define the term. They are simply attempting to verbalize something that has, until recently, been a somewhat sketchy idea.
In the J2EE 1.4 environment, however, the term "Web services" has a very specific meaning, which is based on a standard adopted by Sun Microsystems, Microsoft, IBM, BEA, Software AG, and just about every other major enterprise vendor. In a nutshell, Web services can be defined as follows:
That's a bit of a mouthful, but it's probably the most exact definition of the term you will encounter today. Before the WS-I defined the Basic Profile 1.0, the term "Web service" was simply too general to fulfill the technology's main purpose, interoperability. In other words, the main purpose of Web service technologies is to allow applications on different platforms to exchange business data. Web service technologies are used for Application-to-Application (A2A) integration or Business-to-Business (B2B) communication. A2A refers to disparate applications within a single organization communicating and exchanging data—A2A is also known as Enterprise Application Integration (EAI). B2B refers to multiple organizations, typically business partners, exchanging data. Web service technologies today are used mostly in A2A/EAI settings, but they are also seeing growth in the B2B arena.
For a computer programmer, interoperability is the capability of two different software applications to communicate. For example, the ability to access an application written in C++ running on Windows from a Java application running on Linux is a matter of interoperability. In order for a Java application on a Linux platform to access a C++ application on a Windows platform, you have to use network technologies that are independent of both the operating system and the hardware. This capability is already met by TCP/IP, DNS, and HTTP, and the Web service standards: XML, SOAP, WSDL, and UDDI.
XML (eXtensible Markup Language), SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language), and UDDI (Universal Description, Discovery, and Integration) are used in concert to provide Web service applications with a type system (XML), a messaging protocol (SOAP), an interface definition language (WSDL), and a registry for publishing Web services (UDDI). XML documents contain the information being exchanged between two parties, while SOAP provides a packaging and routing standard for exchanging XML documents over a network. WSDL allows an organization to describe the types of XML documents and SOAP messages that must be used to interact with their Web services. Finally, UDDI allows organizations to register their Web services in a uniform manner within a common directory, so clients can locate their Web services and learn how to access them. Figure shows how these pieces fit together in a Web service interaction between two parties.
The first three parts of this book cover XML, SOAP, WSDL, and UDDI. These core Web services technologies are also the basis of J2EE 1.4 Web Services. Each of the J2EE Web Services APIs (JAX-RPC, SAAJ, JAXR, JAXP) conforms with one or more of the Web services technologies, so developing a fundamental understanding of XML, SOAP, WSDL, and UDDI is crucial to understanding how J2EE 1.4 Web Services works. In addition to the specifications of XML, SOAP, WSDL, and UDDI, this book covers the WS-I Basic Profile 1.0, which is necessary to ensure interoperability across a broad range of platforms. The rest of this section provides an overview of the WS-I Basic Profile 1.0, XML 1.0, SOAP 1.1, WSDL 1.1, and UDDI 2.0. These topics are covered in more detail in Parts I through III.
1 WS-I Basic Profile 1.0
The Web Services Interoperability Organization is an organization of Web services vendors that are committed to defining a standard for Web services interoperability. The first deliverable of the WS-I was the Basic Profile 1.0, which details how to use the four primary Web services specifications together in Web services. The BP defines a set of conformance rules that clear up ambiguities in the specifications of XML, WSDL, SOAP, and UDDI, and defines in concrete terms how to use these technologies in concert to register, describe, and communicate with Web services.
The BP is necessary because the primary specifications are too broad and open to interpretation to make interoperability a given. For example, WSDL is a very generalized technology, which allows you to describe any kind of Web service. Unfortunately, WSDL is so general that it's difficult in some circumstances to determine exactly how, for example, a SOAP message exchanged with the Web service should be formatted. In addition, WSDL defines features that have, in practice, made interoperability more difficult, such as the SMTP and MIME bindings. The BP fixes these interoperability problems by telling us exactly how WSDL should describe SOAP-based Web services, and by restricting the use of WSDL.
No one is required to adhere to the BP, but doing so makes interoperability a lot easier. When you encounter a Web service that conforms with the BP, you have a much easier time locating and communicating with that Web service than you have with a non-conformant Web service. To be perfectly honest, interoperability without the BP is pretty difficult to achieve. While XML, SOAP, WSDL, and UDDI have important roles, their use together is not well coordinated because each specification was developed independently. The BP defines the glue that binds these technologies together into one coherent specification.
Microsoft, IBM, Sun Microsystems, BEA, and many others have agreed to support the BP, which means you should be able to communicate with WS-I-conformant Web services hosted by products from any of these vendors with little or no interoperability problems. The BP makes reality of what was basically a pipe dream in the past; it makes it possible to define applications that are interoperable across most application platforms.
The BP is the specification around which this book revolves, because J2EE 1.4 vendors are required to support it. This book assumes you will want to develop applications that conform to the BP because, if they don't, general interoperability simply isn't practical. Unless you have complete control over all the parties involved in a B2B or A2A system, defining a Web service that is interoperable with arbitrary systems is very difficult, if not impossible. The BP makes it possible to define Web services that are easily understood and operated on by any application written in any programming language (Java, C++, C#, Perl, et al.), on any operating system (Unix, Microsoft, Linux, Mac, et al.), using any development platform (the .NET Framework, WebLogic Application Server, WebSphere Application Server, et al.)
Although the BP is important, there is no chapter dedicated to the subject. Instead, this book addresses the requirements of the BP on Web service technologies and J2EE 1.4 Web Service APIs as they come up—directly in the text of each chapter. You'll know when you are seeing a BP-conformance rule because I will explicitly call it out, or will append the superscript BP to the end of a sentence that states a BP-conformance rule.
XML (eXtensible Markup Language) is used to organize documents and business data. XML files can be stored or transmitted between two applications on a network. Basically, they are just plain text documents that contain special tags that label different parts of a document or fields of data. For example, the XML document in Listing 1-1 contains Amazon.com's mailing address.
<?xml version="1.0" encoding="UTF-8"?> <address> <name>Amazon.com</name> <street>1516 2nd Ave</street> <city>Seattle</city> <state>WA</state> <zip>90952</zip> </address>
Notice how each piece of data (name, street, city, state, and zip) is demarcated by a pair of tags, such as <name> and </name>. This syntax makes it very easy to tell where a field of data begins and ends, and what it represents. The address information in Listing 1-1 might be stored in a text file or sent across the network to another application, perhaps to synchronize mailing information in a database.
XML is the foundation for all the other Web services technologies, so having a good understanding of XML is critical. Part I (Chapters 2 and 3) of this book provides a detailed overview of XML and XML schema, which is the typing system used to validate the contents of XML documents.
Currently there is only one version, XML 1.0, which is managed by the World Wide Web Consortium (W3C). XML is dialect of SGML, which the publishing industry and the U.S. military among others have used for years to provide structure to written documents. Although XML has its roots in SGML, it has greatly surpassed its parent in popularity and usefulness.
When we think of Web services, we are basically discussing the exchange of XML documents, or data that is organized into an XML format. Although XML is an excellent technology for exchanging business data, until SOAP came along there was no widely accepted standard for routing and packaging XML data exchanged between two applications on a network. If you wanted to build an EAI or B2B system based on XML, you had to define your own networking, addressing, and routing protocols, or use a proprietary system provided by a vendor. No two vendors were using the same protocols for exchanging data, so interoperability was difficult, to say the least. Before SOAP, interoperability usually required tedious custom-built solutions to get any two XML-based systems to communicate.
SOAP (from Simple Object Access Protocol) defines a standard packaging format for transmitting XML data between applications on a network. It is not specific to any programming language, product, or hardware platform, so it can be used by just about any kind of application (C++, Java, .NET, Perl, legacy systems, and others). A SOAP message is just an XML document. SOAP is specially designed, however, to contain and transmit other XML documents as well as information related to routing, processing, security, transactions, and other qualities of service. For example, Listing 1-2 shows a SOAP message that contains XML address information. This message might be sent from one application to another to synchronize contact information on two different systems.
<?xml version="1.0" encoding="UTF-8"?> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:addr="http://www.Monson-Haefel.com/jwsbook/ADDR" > <soap:Body> <addr:address> <addr:name>Amazon.com</addr:name> <addr:street>1516 2nd Ave</addr:street> <addr:city>Seattle</addr:city> <addr:state>WA</addr:state> <addr:zip>90952</addr:zip> </addr:address> </soap:Body> </soap:Envelope>
SOAP takes advantage of advanced XML features like XML namespaces (similar to Java package names) and XML schemas (used to type data), all of which are covered in detail in Part I of this book. The important thing to understand at this point is that SOAP messages serve as a network envelope for exchanging XML documents and data. Having a single industry standard for packaging and exchanging XML data makes Web service applications more interoperable, more understandable, and easier to implement. Part II (Chapters 4 and 5) provides a very detailed discussion of the SOAP messaging protocol and processing requirements, as described by the SOAP 1.1 and WS-I Basic Profile 1.0 standards.
There are actually two versions of SOAP today, versions 1.1 and 1.2. SOAP 1.1 was defined as a Note by the W3C in 2000 and has been the basis for most Web services development since that time. The BP requires the use of SOAP 1.1 and provides a number of clarifications and restrictions that largely eliminate interoperability problems associated with this sometimes poorly specified standard. SOAP 1.2 wasn't finalized until 2003 and, while it represents a significant improvement over SOAP 1.1, adoption of SOAP 1.2 by vendors may take a while because they are currently focused on providing solutions based on SOAP 1.1 and the BP. This book covers only SOAP 1.1—SOAP 1.2 was only in draft form when this book was written, and it's not supported by J2EE 1.4 Web Services.
There is an ancillary specification called SOAP Messages with Attachments (SwA) that is covered in Appendix E. SwA defines a message format for attaching binary data (images, sound files, documents, and so on) to SOAP messages. Although SwA is not sanctioned by the BP, support for it is required by the J2EE 1.4 Web Services specifications—SwA will also be supported in the next version of the BP, version 1.1, which is still in development.
WSDL (Web Services Description Language) is a standard for describing the structure of the XML data exchanged between two systems using SOAP. When you create a new Web service, you can also create a WSDL document that describes the type of data you're exchanging. WSDL is complicated and unless you're already familiar with it an example WSDL document will make no sense at all. Suffice it to say that WSDL is based on XML. It's used to describe the SOAP messages that can be transmitted between Web service clients and servers. WSDL is covered in detail in Part II of this book.
There are two versions of WSDL today, versions 1.1 and 1.2. Like SOAP 1.1, WSDL 1.1 was defined as a Note by the W3C (February 2001) and has been used a lot in Web services development. WSDL 1.1 is a good specification, but its flexibility creates interoperability problems. The BP requires the use of WSDL 1.1, but also provides strict rules on how it's used, to improve interoperability. WSDL 1.2 wasn't completed when this book was being written, and is not supported by J2EE 1.4 Web Services, so it's not covered by this book.
Although WSDL provides an excellent format for describing the types of SOAP messages used by a Web service, it provides no guidance on where to store the WSDL documents or how to find them. In other words, WSDL doesn't describe where the WSDL documents should be kept so that others can find them easily and use them to communicate with your Web services.
UDDI (Universal Description, Discovery, and Integration) defines a standard set of Web service operations (methods) that are used to store and look up information about other Web service applications. In other words, UDDI defines a standard SOAP-based interface for a Web services registry. You can use a UDDI registry to find a particular type of Web service, or to find out about the Web services hosted by a specific organization. A UDDI registry is often referred to as a "Yellow Pages" for Web services. When you look up information about a Web service in a UDDI registry, you can narrow your search using various categories (technologies used, business types, industry, and so on). Each entry in a UDDI registry provides information on where the Web service is located and how to communicate with it. The UDDI registry also provides information about the organization that hosts a particular Web service.
The UDDI specification is now maintained by the Organization for the Advancement of Structured Information Standards (OASIS), but was originally created by Microsoft and IBM, which led a multi-vendor organization called UDDI.org. The UDDI.org has set up a free UDDI registry open to everyone—something like a Yahoo! for Web services. Most UDDI registries, however, are private systems deployed by individual companies or trade organizations. For example, a very large organization like General Electric might set up a private UDDI registry that contains information about all the Web service applications offered within the corporation. Another example is a trade organization, like the Association of American Manufacturers, which might set up a UDDI registry that contains information about all its members and their Web service applications.
Of the four principal Web services technologies, UDDI is the only one the BP says is optional. You don't have to use UDDI, but if you need a Web service registry, UDDI is the preferred technology. UDDI is covered in detail in Part III (Chapters 6–8).
There are three versions of UDDI at this time, versions 1.0, 2.0, and 3.0. The BP specifies the use of UDDI version 2.0, the one covered by this book. While version 3.0 is more recent, it was only newly completed when the BP was finalized and so wasn't supported by enough vendors for the WS-I to consider it.