- Shopping Bag ( 0 items )
Ships from: STERLING HEIGHTS, MI
Usually ships in 1-2 business days
Ships from: Irving, TX
Usually ships in 1-2 business days
Chapter 2 Processing XML Documents with SAX
Chapter 3 Processing XML Documents with DOM
Chapter 4 XML Transformations
Chapter 5 Using JSTL (JSP Standard Tag Library)
Chapter 6 Writing SOAP Clients
Chapter 7 Writing SOAP Servers
Chapter 8 Using XML-based RPC
Chapter 9 Locating Web Services
Chapter 10 Java Secure Sockets Layer
Chapter 11 Using JWSDP Tools
As just mentioned, the JWSDP is a collection of existing tools, and is, in some sense, a marketing response to Microsoft’s .Net initiative, gathering and highlighting existing technologies, and giving them a common name. In most cases, this works to the benefit of the user. You no longer have to worry about what APIs are going to survive in the long run; the APIs in the JWSDP have Sun’s blessing and are good choices to standardize on. You also don’t have to wonder about version compatibility between different libraries; so long as the libraries all come with the JWSDP, you shouldn’t have compatibility problems.
There are a few places where the gathering of libraries results in some oddities. In particular, the JAXM, JAXP, and JAX-RPC libraries were developed as separate initiatives by the Apache Jakarta project and the Java Community Process. Because they were developed separately, there are places where the APIs overlap—for instance, some functionalities in the JAXM is also provided in JAXP. These places are pointed out in the text. It remains unclear if future versions of the JWSDP will address these issues. The other aspect that can be confusing about the JWSDP is that some parts of it are available in different forms on the Web. For example, the JAXP libraries are shipped as a part of the JDK 1.4 release. JWSDP includes these libraries for capability with older versions of the JDK, especially as it will take some time for vendors to migrate to supporting the newer JDK releases.
Having said all that, it’s worth looking at the individual components of the JWDSP.
The Java API for XML Processing (JAXP) provides standardized interfaces for parsing and transforming XML documents. JAXP is designed to fill a hole in the XML standard interfaces: there are standard interfaces for transforming and parsing XML, but no standard interfaces for obtaining the transformers and parsers.
When XML first started gaining popularity, there were no standards for processing it. As time went on, standards developed for processing XML, but these standards were all interface-based—they did not contain any required classes. Libraries meeting the standards did so by implementing the standard interfaces and adding their own proprietary mechanisms for creating instances of those implementing classes. So, while your XML processing code, based in the interfaces, might be portable, the small bits of code used to create those objects were not. This meant XML libraries could not be swapped in and out without making small changes to the application code. JAXP provides a standard set of interfaces, and more importantly classes, that allow for the creation of these implementation objects. JAXP does not redefine XML standards; instead, it leverages those standards (DOM, SAX, XSL) that already have wide acceptance. JAXP ensures that code utilizing the standards will not have to be changed if the XML library supporting the standard interfaces is changed.
Because JAXP does not define XML interfaces on its own, you will find that some interfaces exposed in JAXP are not in the Java or javax packages. Instead, Sun chose to adopt those standards already in wide use. This means that modifying code to use JAXP will hopefully be limited to those sections of code that create the parsers and transformers.
The next three chapters of the book cover the three aspects of JAXP: parsing using SAX and DOM parsers, and processing XML through XSL transforms.
The Java API for XML messaging addresses a similar problem: when the SOAP (Simple Object Access Protocol) standard was proposed, it did not have a standard set of libraries for Java. Not particularly surprising, given Microsoft’s involvement in the creation of the standard, but still a problem for Java programmers. JAXM addresses this issue by providing a standard interface for SOAP 1.1 with attachments, so that Java programmers can easily send and receive SOAP messages.
JAXM provides a number of features above just the implementation of the SOAP standards. It gives vendors a mechanism for supporting reliable delivery of messages, and for partial population of SOAP messages for specific SOAP-based protocols (such as ebXML).
It was earlier mentioned that some areas of the JWSDP overlap. JAXM is one example of this. Parts of JAXM provide a simple implementation for manipulating XML documents—an example of what JAXP provides in greater detail, and with standard interfaces. Ideally, JAXM would just leverage the interfaces provided by JAXP, but it doesn’t.
This is because JAXM and JAXP were developed in parallel, by separate Java Community Process teams. It’s unfortunate and confusing, however, and makes the processing of XML documents with both JAXM and JAXP harder. If you have to receive a message via SOAP, and process it further (for example, with XSL transforms), you have to transform the document from one representation to another.
Sun has not, to my knowledge, publicly discussed this issue. However, one can hope that future JAXM releases will fix this problem.
JAXM is discussed in detail in Chapters 6 and 7 of this book.
The Java API for XML-based Remote Procedure Calls (JAX-RPC) provides a mechanism for making what appear to be object calls across a network via SOAP-based messages. JAX-RPC allows for the implementation of Web services described by WSDL (Web Service Definition Language) documents—the apparent standard for describing Web services.
With JAX-RPC, the implementation of what appears to be a Java object can, in reality, be hosted on a machine across a network (including the Internet), in any language that supports SOAP. This gives a powerful mechanism for decoupling business systems. Unlike other distributed systems (COM, CORBA), XML-based RPC can span architectures without requiring a large investment in common support software. All that is required is you process XML documents at each end. The mechanism for processing them, and the underlying system, are completely unimportant.
JAX-RPC acts much like RMI in that stub objects are created for use in invoking remote objects. Conceptually, you use the two systems identically. What differs between JAX-RPC and RMI is the format of the data transferred between the two machines. RMI uses low-level, Java-specific protocols (or CORBA IIOP), while JAX-RPC uses XML. Because of this, RMI may be faster—since the protocols are more efficient—but it is important to remember that JAX-RPC isn’t about performance, it’s about interoperability. JAX-RPC, like JAXM, was a Java Community Process project, and was developed in parallel. However, JAX-RPC does a better job of hiding the implementation details. It does not need to expose the underlying XML structures as much as JAXM did. The current reference implementation does not appear to use JAXP, but implementations from other vendors could (as could the reference implementation in future releases). Again, this is a legacy from when JAX-RPC might have been downloaded without downloading JAXP – a problem the JWSDP (and JDK 1.4) eliminates.
JAX-RPC is covered in Chapter 8 of this book.
Once Web services have been defined via WSDL, there needs to be a mechanism for finding them. WSDL documents are often published in registries, which are public databases of WSDL documents. Registries allow users to search for services that will fulfill their needs, and download the specifications for those services.
The most common registry interfaces right now are the Universal Description Discovery and Integration (UDDI) and the ebXML (Electronic Business using XML) Registry and Repository. JAXR, the Java API for XML Registries, provides an abstract interface for querying registries; JAXR can be used to isolate the user from having to know the specifics of either UDDI or ebXML. Registries provide rich, complex mechanisms for categorizing services. A large part of the JAXR API is targeted toward providing a standardized view of these categories. This is the main reason JAXR was created as a separate library, rather than extending JNDI (Java Naming and Directory Interface, which provides a similar functionality). The categories used by JAXR would be meaningless to most JNDI users, so it did not make sense to include them in the JNDI package. On the other hand, it isn’t possible to use WSDL repositories without these categories, therefore JAXR is a package that stands on its own.
JAXR, like packages discussed previously, was developed in parallel. However, the JAXR committee did a good job of watching the other Java Community Process efforts, and has come up with a specification that can be implemented using JAX-RPC, JAXM, and JAXP.
JAXR is covered in Chapter 9 of this book.
At this point, you might have the impression that the JWSDP is nothing but XML processing. That isn’t really true. JWSDP is closely related to the Java XML pack, which is limited to those packages discussed earlier. However, the JWSDP includes additional packages useful for creating Web-based applications.
The Java Secure Socket Extension (JSSE) is a good example of this. JSSE provides a mechanism for communicating over encrypted network connections and managing the keys associated with that encryption.
JSSE provides a royalty free implementation of SSL (Secure Sockets Layer) v3 and TLS (Transport Layer Security) 1.0 support. More importantly, the JSSE implementation may be exported from the United States, dramatically easing the adoption of secure communication in worldwide organizations. In addition to providing low-level socket support for encryption, JSSE provides additional URL handlers, so that the java.net.URL class can understand and process HTTP URLs. This means that Web services, which require transport-level security, can be easily implemented in Java. The JSSE is discussed in Chapter 10.
Just as Web services are not only about XML, they are not only about business processing. There needs to be a mechanism for presenting functionality to end users, as well as to remote machines. It’s common to use Java Server Pages (JSPs) to encapsulate the user interface of an application; this provides a simpler interface than coding servlets by hand. However, JSPs have traditionally had to include either direct Java code or custom-written tag libraries in order to access the underlying business functionality. The JSP Standard Tag Library (JSTL) is designed to help ease this burden. JSTL provides a standard set of tags for common JSP tasks, such as iterating over a collection of objects, making database queries, and internationalizing text.
JSTL also provides for expression languages, which allow the user to directly access business objects with a simple expression. JSTL currently provides support for not one but a number of expression languages. This allows the user to choose the language that best suits their needs, but more importantly, protects the user from an upcoming JSP standard that should directly include expression languages.
JSTL comes directly from an Apache Jakarta project of the same name, which later came under the Java Community Process. JSTL is covered in Chapter 5. Ant and Tomcat.
Like JSTL, Ant comes from Apache Jakarta. Ant isn’t a Java library—rather, it’s a build tool. It’s included with the JWSDP simply because it makes writing and bundling Java applications easy to do. Ant comes with built-in tasks for creating WAR (Web Application aRchives), which are the default packing for Java Web Services. Ant is an open-source project, whose sources can be found on http://www.apache.org
Similarly, Apache Jakarta’s Tomcat is a reference implementation of the JSP and servlet standards. As such, it allows for the development hosting of servlet-based Web services, such as JAXM supports. Unlike Ant, you likely will not use Tomcat for production deployments; it does not support failover, reliable message delivery, EJBs, or a host of other production features. However, it is free, fast, and lightweight to install; you can easily run Tomcat as a test server on your development machine. Like Ant, Tomcat is open-source and available through Apache.
Along with Ant and Tomcat, JWSDP includes the WSDP (Web Services Developer Package) Registry server. This is a simple UDDI server, again for development and testing use. Unlike Ant and Tomcat, WSDP is a Sun project and is not open-source.
Ant, Tomcat, and WSDP Registry are covered in Chapter 11.