Java Reference
In-Depth Information
There are a few steps to doing this, so we'll take it step by step. This solution will use the
schema and WSDL for the Credit Authorization service defined in Chapter 7 .
NOTE
This recipe is the client side of the Credit Authorization example using custom schema with JAXB-
generated types from Creating a Web Service That Uses Complex Types Based on Custom WSDL
and a Custom Schema . You can also reference Validating Against a Schema During Marshaling and
Unmarshaling for a discussion on schema validation in JAXB.
Here's an overview of what you'll do:
1. Import a copy of the schema into your local project. This is easy to do within NetBeans 6,
which will snag all schemas referenced from a single WSDL. Alternatively, you can get
them from a browser and copy them based on the schema location in the WSDL.
2. Generate and compile the Java types that are defined in the schema associated with the
WSDL. Use these Java objects in your application.
3. Validate the Java objects during marshaling into XML, as shown in Validating Against
a Schema During Marshaling and Unmarshaling . Basically you do this by reading in the
schema and attaching it to the JAXB Marshal object.
4. Attach the raw XML in a DOM object as the child of the body of a SOAP message that
you create with SAAJ. Use Dispatch<T> to invoke your web service directly with the
XML representation.
5. The SAX parser will throw any validation exceptions as SAXParseException s during
marshaling, before the service is invoked. You can then handle those exceptions, probably
by reporting them back to the client.
Let's first look at the JUnit 4.4 test, which you'll use as your service consumer. The list of
imports required is retained for clarity. The test defines a physical path to the locally saved
schema file that will be used for validation. That schema defines the CreditCard , Name , and
Authorization types that are used in request and response messages. These classes are gen-
erated from the WSDL into the com.soacookbook.ns.credit package using the wsimport
tool.
The test will start off creating credit card and name objects and populating them just as you
would with a client GUI. But instead of using the Service derivative that was also generated
during import, you'll call your own validateAndInvoke method. It will use other methods to
do the translation into XML manually using JAXB and then pass the payload into a method,
so you can construct the SOAPMessage ourselves. The process at that point becomes a black-
Search WWH ::




Custom Search