Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

The service wrapper tool provides a way of wrapping OWL-S services such that they can be called as a standard SOAP service. There are two approaches which the wrapper allows.

First, it is possible to provide an OWL-S description of a service, along with a set of XSL transformations which can convert the inputs and outputs between XML and RDF. The wrapper will then deploy an endpoint which can be used as usual (for example, in combination with a hand-written WSDL file). Upon invocation, this endpoint will run the transformations on the inputs, invoke the OWL-S service, and transform the outputs to be returned to the caller.

It is also possible to give solely an OWL-S description of the service. In this situation, the wrapper will examine it, and build a complete synthetic service which is deployed as a JAX-WS endpoint, so that WSDL can be generated automatically. Beans relating to the inputs and outputs of the service are also synthesised, so no XSL transformations are required since mappings are handled by the wrapper.

How it works

The main servlet, Composer, is what processes the configuration file and deploys the endpoints. For each service in the file, it constructs a synthetic service (more on this later). For each service it deploys a WebServiceProvider which reads the OWL-S process, looks up transformations for each of the inputs, executes the process, then transforms the outputs and returns them to the client. If a transformation is not provided for an input or output, the invocation fails.
 
It also generates a synthetic form of each service using ASM. To do this, it reads the OWL-S process, then examines the OWL Class of each of the inputs, and constructs a bean where each of the datatype properties relates directly to a field in the bean. It then constructs a service class with JAX-WS annotations, and a service method with the input beans previously generated as inputs. For outputs, it constructs a bean for each output type as with inputs, and then wraps each output bean inside a single bean of outputs in order to allow services to match the Java programming model where methods (which are similar to services) can only return one output.
 
When this is deployed, CXF sees it as any other JAX-WS service, and so lets one generate WSDL and invoke it as you would expect. Upon invocation, the generated service method simply pushes all parameters into a list and calls a static method in InvokeService which then deals with the deconstructing of bean objects back into OWL individuals (a fairly trivial task, since each field in the bean corresponds to a single property of the OWL type, and each individual is represented by a single object) which are then used to execute the process.The same process is used to read output values into Objects, which can be returned the to the client at the end of execution.