The Java camp, albeit after a slightly stuttering start, is determined to make sure that Microsoft does not hijack the Web-services market with .NET. As far as the Java camp is concerned , Web services offer a golden opportunity to level the playing field between proprietary (i.e., Microsoft) and open (i.e., Java) when it comes to application software. XML and Web services are platform independent and that is also Java s claim to fame ”though Java s platform independence, as discussed at the start of this chapter, is broader and more meaningful than what XML Web services set out to achieve. However, developing XML Web services and the applications that intend to use them in Java does ensure that one has the best of all worlds ” platform-independent solutions that can be easily ported across vastly disparate platforms (e.g., mainframes and PCs).
Since at least early 2002, it has been possible to develop Web services or applications that invoked Web services by using Java ”albeit typically with a high-end, commercial application server such as BEA s WebLogic or IBM s WebSphere. This was because total built-in support for SOAP etc. was not available in J2EE 1.3. Thus, one had to rely on implementation-specific Web services “related extensions. But all of this has been rectified with J2EE 1.4, which sets out not just to be Web services savvy but to be a preferred platform for Web services “related solutions. To this end many XML-related APIs have now been included in Java ”in particular, J2EE. This repertoire of APIs is known as the Java APIs for XML (JAX). The goal of JAX is to ensure that any and all Web services “ related software, on either side of the invoker-provider model, can be created entirely in standard Java without recourse to tools written in other languages or implementation-specific extensions.
The Java APIs for XML fall into two broad categories: those that deal explicitly with the processing of XML documents and those that deal with the procedures used to interchange XML-oriented documents. There are three XML document-oriented Java APIs:
Java API for XML Processing (JAXP)
Java Architecture for XML Binding (JAXB)
SOAP with Attachments API for Java (SAAJ)
There are two APIs that deal with the procedures used to interchange XML-oriented documents:
Java API for XML-based RPC (JAX-RPC)
Java API for XML Registries (JAXR)
JAXP is invaluable for processing XML documents. It is a powerful and extensible API based on the concept of using external plug-in modules. JAXP supports SAX, DOM, and XSLT ”replete with full XML namespace processing. SAX and DOM, as mentioned in Chapter 2, are the two most popular APIs associated with XML. They both work by using a document parsing model ”in this case the accepted XML document parsing methodology. All XML parsers verify that an XML document is well formed (e.g., check that there are no missing tags).
Some XML parsers are known as validating parsers. Validating parsers, in addition to verifying the structure of an XML document, go a step further by validating the contents of a well-formed XML document against the appropriate DTD or schema. Xerces, which is available from Apache in both Java and C++ versions, is a widely used example of a quintessential XML validating parser that supports both the SAX and DOM APIs.
JAXP does not implement either the SAX or DOM APIs. Instead, it allows any Java application to invoke a suitable XML parser from within the Java application. JAXP in essence allows XML parsers to be plugged in to a Java application via what Java refers to as the plugability layer. Xerces, which is comprehensive and all inclusive, is rapidly becoming the gold standard within the Java community for XML parsers. But other XML parsers are available from Oracle and others. There is also a very nimble , Java-based, nonvalidating XML parser known as Piccolo (piccolo. sourceforge .net).
SAX is an event-based parser best suited for interprogram interactions associated with Web services, while DOM is targeted at XML presentation-oriented applications such as XML editors or XML browsers. An event-based parser, when parsing a document, triggers an event each time it encounters a document construct it recognizes. Thus, in the example of an XML parser, an event could be triggered each time the parser encounters the < symbol, the </ string or whitespace characters . In the case of Java, the event triggered by SAX would be a previously defined method within the application. Thus, you would typically have a method to handle the start of an element that would be invoked each time the SAX parser encountered the < symbol. DOM, on the other hand, takes an XML document, parses it, and creates an object representation of that document ”in the form of a tree (e.g., the XML representation of an XML spreadsheet, as shown in Figure 2.3[b]).
The current version of JAXP also includes support for XSLT. Consequently, programmers can convert XML content obtained via a parser to other formats, including HTML. JAXP, very much in tune with XML trends, makes sure that there is full support for XML namespaces. Thus, the bottom line here is that JAXP ensures that Java applications have unconstrained access to the structure and content of any XML document through the use of an appropriate XML parser and moreover ensures that XML-defined data extracted in this manner can be easily converted to any other format by using XSLT.
JAXB is another way by which Java applications can process XML documets. It is a Java technology that enables developers to easily generate Java classes (i.e., templates for creating objects in the form of JavaBeans) from an XML schema. Thus, you can use JAXB to create a representation of an XML schema in terms of Java code. It provides an easy and convenient way by which Java developers can incorporate XML data and XML-related processing functionality into Java applications without even having to know much about the intricacies and mechanics of XML.
SAAJ, though categorized by the Java camp as an XML document-related API, is very different from the other two APIs. Rather than being an API related to processing XML documents, as is the case with JAXP and JAXB, SAAJ is in reality a SOAP-related API. It provides a standard means by which Java applications can send XML documents by using SOAP. SAAJ is obviously targeted at Web services “related scenarios. The current SAAJ API is based on the SOAP 1.2 specification.
As with SAAJ, JAX-RPC is another Web services “oriented API ”albeit this time on the procedural side rather than on the document-related side. JAX-RPC is the pivotal API when it comes to developing and deploying Web services on a Java platform. It is a featured highlight as well as a cornerstone of the J2EE 1.4 initiative. JAX-RPC, as implied by the name , is an RPC invocation mechanism. It enables Java applications to invoke XML-based RPC functionality per the SOAP 1.2 specification. It firmly aligns Java software with accepted Web services modus operandi for I/O, as discussed in the previous chapter. JAX-RPC enables Java software to participate, with aplomb and ease, anywhere within a Web services “related programming scenario ”either as Web services being invoked by other applications or as applications invoking Java or non-Java-based Web services.
JAXR, from a Java perspective, puts the icing on the cake vis--vis Web services. It is a uniform and standardized API for accessing and querying different kinds of XML registries ”with UDDI and the OASIS-sponsored ebXML registry being key among these. It provides Java applications with a unified information model that describes the content and meta-data included within XML registries. With JAXR, Java developers can write powerful and versatile registry client software ”for example, for UDDI registration, update, and query. With this set of APIs, all of which are integral parts of J2EE 1.4, the Java camp has indeed gone all out to make sure that it has left no bases uncovered when it comes to unstinted support for Web services. But it did not stop there. It raised the ante, obviously against .NET, by packaging all of these XML-related APIs and more into what is called the Java Web Services Developer Pack (Java WSDP) 1.2.
Java WSDP is a free integrated toolkit to help Java developers create any type of XML-related software with the latest Java APIs. It can be downloaded at will from java.sun.com, for the four traditional reference platforms supported by Java: Sun Solaris, Windows 2000, Window XP, and RedHat Linux. Consistent with the fact that the current J2EE 1.4 support for the core Web services “related technologies is highly standards compliant, Web services “related software developed with WSDP is assured to conform to WS-I s basic profile 1.0. In addition to offering JAXP, JAXB, SAAJ, JAX-RPC, and JAXR, WSDP also includes additional value-added capabilities, such as JavaServer Faces (JSF) and access to all of the J2EE security features (including authentication and encryption). JSF is a technology for simplifying the building of user interfaces for server-side Java software. JSF enables Java programmers to quickly and easily assemble reusable UI components into a displayable page, connect these components to the appropriate application data sources, and then correlate client-generated events to server-side event handlers.
The bottom line here is that with J2EE 1.4, all of the XML-related APIs, and the free WSDP it is difficult for anybody to cogently argue that Java does not provide adequate support for developing and deploying Web services or applications that invoke Web services. One has to agree that at least on paper, J2EE 1.4 is indeed an extremely complete, and as such compelling, platform for Web services. Furthermore, it is worth remembering that all of this, at least for the Solaris, Windows, and RedHat Linux platforms, is available for free on an open-source basis.
This is obviously a boon for those who want to develop Java-based Web services (maybe on a low-overhead, cottage-industry basis) ”keeping in mind that per the Java mantra, Java software developed on a Windows or Linux platform can still be deployed on any other platform that includes a suitable run-time environment. Then there are the commercial Java-based studios and application servers, discussed in Section 6.4, that set out to make development, testing, and deployment even easier, more flexible, and global in terms of platform permutations . So when it comes to Java and Web services, no person, at least with a rational frame of mind, can claim that there is a shortage of germane technology and tools.