The Java API for XML Web Services (JAX-WS) is a Java programming language API for creating web services. The Java Web Services Developer Pack is a toolkit provided by Sun to demonstrate how to build Web services solutions using Java. This toolkit provides everything needed to build and deploy Java-based Web services solutions. It is meant to serve as the reference implementation for all other Java-based Web services.
The toolkit also packages together a number of Java extension libraries that are used to process various pieces of the Web services suite. It is not really important to know too much about these APIs because the tools found in the toolkit will abstract away much of their use. Instead, just know that they’re there, and what they do at a high level. These APIs include:
- Java API for XML Processing (JAXP): Provides a standardized interface for different types of XML parsers. By writing to this API, the underlying XML parser can be switched out for ones with different performance and memory characteristics without forcing a change in user code.
- Java API for XML-based RPC (JAX-RPC): Gives developers the hooks needed to build Web applications and Web services incorporating XML-based RPC functionality according to the Simple Object Access Protocol (SOAP) 1.2 specification. Typically, this is the API that you will use the most for building Web services.
- Java API for XML Messaging (JAXM): Provides much of the underlying code needed to create SOAP messages and perform the communication between systems.
- SOAP with Attachments API for Java (SAAJ): Enables developers to produce and consume messages conforming to the SOAP 1.2 specification and SOAP with attachment notes.
- Java API for XML Registries (JAXR): Gives a standard Java API for accessing different kinds of XML registries. We will use this API when communicating with a UDDI or an ebXML registry.
- Java Architecture for XML Binding (JAXB): Makes XML easy to use by compiling an XML schema into one or more Java classes.
There are three different ways to approach developing applications with JAX-WS:
The WSDL to Java approach: Point to a WSDL and use tools such as wsimport to generate portable web service artifacts.
The Java to WSDL approach: Create a Service Endpoint Interface as Java source files. Use them as inputs to generate the WSDL and other required portable artifacts.
The Start from Java and WSDL approach: This can be a smart way of working. Write Java classes and let wsgen create WSDL and schema for you.Then save the generated artifacts locally, modify them as necessary, and point your service implementation to them via the wsdlLocation attribute of the @WebService annotation. This means you have to keep your classes in synch with your schema and WSDL, but it puts you in the sweet spot that maximizes convenience and control.
With any approach, JAX-WS will generate significant amount of code for you, and reduce the challenges of dealing with what was designed to be machine-readable code.
The SOAP with Attachments API for Java (SAAJ) was created to specifically address the needs of burgeoning SOAP-based web services developers. It allows you to programmatically manipulate SOAP envelopes. Using its classes and methods, you can create an envelope, add a header to the envelope, put data in the header, create a SOAP body, add an XML document to the SOAP body, and add the body to the envelope.
Once your message is complete, you can ship the complete SOAP message off over HTTP to invoke a web service using a dispatcher. Once you have used SAAJ to create a SOAP message structure, you can send requests and receive responses using a SOAPConnection object. SAAJ connections are based on the java.net.URL class, which is extendable to support any network protocol.
From a practical standpoint, using SAAJ means that you don’t use tools such as 'wsimport' or 'wsdl2java'. Those are for use with JAX-WS, and are the means by which a client can generate domain objects and operate almost as if they were not using web services at all. With SAAJ, you have no domain view of a service. You are really working with the plumbing. Development with JAX-WS can be much quicker and easier, and generally does not cause you any loss in control. But JAX-WS is a convenience layer, and it can be comforting to know that if you wield some command of SAAJ, you’ll be ready to do anything that a WSDL interface requires of you.
The Java Web Services are used to help with the creation of the interface code. Sun refers to these pieces of code as ties (the Service side module) and stubs (the client side modules). See Figure 1.
Figure 1. JAX-WS architecture (how the system is structured)
The ties and stubs are generated by a packaged set of tools called 'wsdeploy' and 'wscompile', respectively. 'Wsdeploy' examines the methods found in your service and creates a series of classes that handle the un-marshaling of the passed in SOAP message, and the marshaling of the return data. The WSDL file is created by this tool as well. The wscompile tool works by looking at the WSDL file for the specified service. It examines the XML descriptors in that file to generate a set of proxy classes that will handle the communications to the service and the marshaling of all method calls. In essence, wsdeploy and wscompile are conjugates of each other. Together, these tools take a lot of the manual labor out of building the Web service interconnects. Without them, you’d have to write all the code to build up the XML SOAP envelopes, consume them, and convert the data to and from Java objects. This would require much more intimate knowledge of the API’s included in the pack and adds a lot more complexity to the development process.