Server Usage

The JibxSoap implementation uses a simple Java servlet for the server implementation of web services. This servlet can be bundled as part of an existing web application, or as a standalone application. In either case, the jibx-soap.jar file from the JibxSoap distribution must be present in the WEB-INF/lib directory of the web application, along with the jibx-run.jar, xpp3.jar, and jibx-extras.jar files from the base JiBX distribution. The actual service implementation classes must also be included in the web application, either in a jar file within the WEB-INF/lib directory or as individual class files under the WEB-INF/classes directory. The web application that includes JibxSoap may be deployed to any ordinary servlet engine (such as Apache Tomcat, or Resin), as well as to any J2EE application server.

There are two aspects to defining JibxSoap services. The basic JibxSoap configuration lists the services to be included within a web application, while the service definition for each service provides the details of the ports and operations involved in that service. When a service is invoked, the body of the SOAP request is unmarshalled using the JiBX binding definitions associated with that service. The type of the unmarshalled object is used to determine the operation requested, by matching the object type to the parameters types of the defined operations (so if multiple operations are defined, each must take a different type of parameter). The return type of each operation method must be a type with a defined mapping, which is then used to marshal the returned object to the body of the SOAP response.

Extensions to support fault definitions, one-way operations, and service class per WSDL portType are planned for the future. The latter will allow multiple sets of operations to be defined for a service, with potentially different implementation classes used by each set of operations.