Unity Logo

Castor

Castor is a flexible XML binding tool that provides run-time marshalling and unmarshalling of XML and Java objects. One strength of Castor when compared to most (not all) other Java XML binding frameworks is that re-compilation of the Java code is not required if the mapping definition changes. Therefore, systems where the web service layer is being developed independently from the business layer can benefit from using Castor. XFire support for Castor is currently available in the latest XFire release. Two approaches to developing a Web service using Castor with XFire are presented below: top-down (schema first) and bottom-up (code first).  Before proceeding, check the Dependency Guide for required castor module dependencies.

Assumptions about Reader

  • Competence with Java and XML
  • Basic knowledge of Castor XML binding framework
  • Experience configuring Java webapp and deploying
  • Nominal familiarity with Spring framework

Important Notes

Castor unfortunately does not support element lists or unbound container elements for lists as top-level elements. For example, direct collection binding for the following XML documents and service class is not possible.

Root-level element list:

Unbound root-level list container:

Service interface to bind to:

The work-around is to create a container class to bind the list to, and use a root-level list container.

The web service interface will need to be modified to support the container class.

Another issue with Castor is that the mapping does not support direct or indirect binding to interfaces. Therefore, your service class will need to accept a concrete class as a method attribute, and not an interface.

Top-down Approach (starting with XML schema):

Firstly, the XML schema that defines the structure of your web service messages must be developed. For the purposes of this guide, we'll borrow a schema from http://www.webservicex.net/WeatherForecast.asmx?WSDL which defines a pre-existing weather forecast service.

The borrowed schema below should be saved under META-INF/schema/ in the classpath:

Next, we'll use castor to generate POJO classes from the service schema. First, define the source generator task and a goal for generation. The example below is for a maven 1.x configuration. Go to Using the Source Code Generator for a full reference on generating java classes from XML schema.

After running the generate-source goal, the supporting classes will be in the generated-src directory under the net.webservicex package.  Along with each class is an accompanying Descriptor class file (e.g. WeatherDataDescriptor.java) that contains XML binding information.

Next, write a Web service with the support of the generated classes.  Note, the example below is a trivial implementation.

After this, configure the service in Xfire. The example below takes the XML configuration approach (which uses Spring integration). In addition, XFire supports integration of configuration into containers such as Plexus and PicoContainer. For more control over the Web service definition, JSR 181 Annotations should be used in the service code.

The configuration goes in the services.xml descriptor. This file goes in META-INF/xfire/ on the classpath:

The service definition specifies the web service implementation class with the <serviceClass> property. A list of <schemas> can be provided to be included in WSDL generation. In this case, the borrowed schema definition in the classpath at META-INF/schema/WeatherForecast.xsd has been included.

The request and response messages were defined in our schema and were included as a single parameter and return type, respectively, in our service method. This lends itself to a bare (or unwrapped) parameter-style.  The service definition specifies a bare parameter-style by setting the <style> property as 'document'.  If a wrapped parameter-style is preferable, the request and response schema definitions and generated classes would not be needed, as the operation name would wrap any request parameters and return type. The style property in the service definition would not be needed as service factories create services as wrapped style by default. The service method signature for a wrapped style service would be:

Service factories are responsible for creating the service inside of XFire. In this case, we want to use an ObjectServiceFactory with Castor binding, so the beans 'castorTypeRegistry', 'bindingProvider' and 'castorServiceFactory' are defined. Notice that these beans are using spring-style bean definitions (e.g. <bean id=...>) since XML Configuration uses Spring to build its services. We reference this service factory in the <serviceFactory> property of the service definition as #castorServiceFactory. The '#' denotes a reference to another defined bean. Read the Bindings section to learn more about setting up service factories with different xml binding mechanisms.

After configuring the service within XFire, the service needs to be exposed so it can be reached by client-proxies. This can be done over HTTP by defining a servlet in the web.xml. Since we have taken the XML Configuration approach, it is best to set up the XFireConfigurableServlet in our web.xml. XFireConfigurableServlet will load the services.xml along with the included org.codehaus.xfire.spring.xfire.xml files upon initialization. Reference the XML Configuration for how to write the web.xml file.

Finally, deploy the web application to your favorite servlet container, and the service should be visible at /services/WeatherService?wsdl under the deployed webapp context path.

 Bottom-up Approach (starting with Java classes):

Let's say you want to leverage your pre-existing business code by exposing certain methods with a Web Service. That's not too hard to do with Castor binding and XFire, but it's a different approach that involves mapping Java to XML rather than generating Java classes from schema. Service-oriented architecture discourages simply exposing the domain model, but in this example we're going to be rebellious and not insulate it. This doesn't mean that the bottom-up approach can't follow SOA best practices, altogether.

Below is a Book class that's part of the domain:

Next, is a service class that has a couple methods we want to expose as a web service. Note: This service class could have existed already as a business service, or could have been written specifically to be a web service. As you might have noticed, the implementation is quite trivial (ie. stoopid).

Let's create an XSD that matches the Book class, so that we know what the XML element for the Book class should look like. The Book.xsd schema below should be saved under META-INF/schema/ in the classpath:

The schema outlines a complex type that has three string elements. It is important to note that the namespace prefix for XML schema namespace is 'xsd' and the namespace prefix for the target namespace is 'tns'. These are the prefixes used by the XFire WSDL builder when creating the schema section, and this schema will actually be inserted inline into the schema section of the WSDL.

Now we need to specify how to transform our Book class to an XML element that conforms to the XSD, and vice versa. This is done with a castor mapping file. More information on writing castor mappings is available at http://www.castor.org/xml-mapping.html

The castor.xml mapping file below should be saved under the foo.bar package:

Castor also support mapping file auto-generation.  This is done with the Castor MappingTool class.  Please refer to the document http://castor.codehaus.org/xml-faq.html#Are-there-any-tools-to-automatically-create-a-mapping-file? for more information.

Note again, the target namespace and tns prefix are the same as in the XSD. The element-defintion attribute denotes whether the XSD definition is a concrete element or an abstract complex type. In this case, it is a complex type so element-definition is false (which is actually is default value).

All the distinct parts are there, time to configure the service in Xfire. The example below takes the XML configuration approach (which uses Spring integration).

The configuration goes in the services.xml descriptor. This file goes in META-INF/xfire/ on the classpath:

The service definition specifies the web service implementation class with the <serviceClass> property. A list of <schemas> can be provided to be included in WSDL generation. In this case, the schema definition in the classpath at META-INF/schema/Book.xsd has been included. Our service is of parameter style 'wrapped', as the method names in the service will wrap our request and response messages (e.g. <findBook>). The style property in the service definition is not be needed as service factories create services as wrapped style by default.

Service factories are responsible for creating the service inside of XFire. In this case, we want to use an ObjectServiceFactory with Castor binding, so the beans 'castorTypeRegistry', 'bindingProvider' and 'castorServiceFactory' are defined. Notice that these beans are using spring-style bean definitions (e.g. <bean id=...>) since XML Configuration uses Spring to build its services. We reference this service factory in the <serviceFactory> property of the service definition as #castorServiceFactory. The '#' denotes a reference to another defined bean. The 'castorTypeRegistry' definition sets the 'mappingFile' property to point to the castor.xml mapping file in the classpath.

After configuring the service within XFire, the service needs to be exposed so it can be reached by client-proxies. This can be done over HTTP by defining a servlet in the web.xml. Reference the XML Configuration for how to write the web.xml file.

After configuring the service and web application, deploy it to your favorite servlet container, and the service should be visible at /services/BookService?wsdl under the deployed webapp context path.

© 2003-2008 Codehaus