# The JBoss.net deployment model

The core of JBoss.net is built by the Apache AXIS implementation of JAX-RPC. Axis is usually deployed itself as a traditional web application for inclusion into standard servlet containers, such as Tomcat or Jetty. Web Services are then deployed into Axis by placing their code (consisting of custom serializers, handlers, providers and, potentially, application logic in the form of JavaBeans) together with an Axis deployment descriptor (written in the XML-based Web Service Deployment Descriptor language - WSDD) into the web application directory.

Here is an example bean implementation to be exposed as a web service and its associated wsdd. See the JAX-RPC specification and the Axis User Guide for more information.

JBoss.net has been designed such that any JAX-RPC/Axis-compatible web service code as well as any wsd-descriptor will work equally well in the JBoss environment, but without the hassle of the sometimes erroneous Axis deployment. JBoss.net is already reasonably preinstalled as a proper jboss service (`%JBOSS%/server/default/deploy/jboss-net.sar/jboss-net.war`); the integrated Axis web service engine is exposed under the default prefix `http://%YOURHOST%:%WEBSERVERPORT%/jboss-net`).

Instead of placing loose sets of files, individual web services are deployed in JBoss.net through convenient packaging units which we call web service archives (WSRs, see figure). WSRs are either compressed zip files or filesystem folders named with the suffix ".wsr". Quite analogous to the already well-known j2ee-EARs, ejb-JARs, web-WARs, jca-RARs, and jboss-SARs, these archives assemble the web service code together with its deployment descriptor that is placed under `META-INF/web-service.xml`.

Analogous to EARs, JARs, WARs, RARs, and SARs, it is sufficient to drop WSRs into the jboss deployment directory such that they are automatically deployed into the JBoss.net engine. It is sufficient to delete the WSRs in the deployment directory in order to tear the appropriate web services down. It is sufficient to replace the WSR in order to redeploy its web service contents.

Similarly to EARs, JARs, WARs, RARs and SARs, WSRs can be arranged as sub-deployments of any other deployment unit, e.g., a web service archive can be embedded into an enterprise application or a service archive. The classloading and scoping model follows the JBoss architecture, i.e., the web service code (custom handlers, serializers, and providers) will be provided with an individual classloader that is interconnected to the classloaders of the super and sibling deployment units, e.g., ejb interfaces and bean classes placed in an ejb-JAR, or mbean interfaces placed in a jboss-SAR.

## Alternative Approach (only JB4)

With the advent of WS4EE, an alternative deployment model in the context of J2EE containers has been standardized. It is sometimes not quite that flexible as the wsr-scheme and will be emulated by JBoss.net by reduction to the presented Axis WSDD approach.

## Legacy Approach

Since quite a few people already got used to "pure" Apache-SOAP and Axis in the context of servlet containers, it is still possible to interact with the JBoss.net Axis engine through the filesystem (use `%JBOSS%/server/default/deploy/jboss-net.sar/jboss-net.war` for placing code and descriptors) and the web-based remote administration (`http://%YOURHOST%:%WEBSERVERPORT%/jboss-net/servlets/AdminServlet`). The default configuration of the JBoss.net engine can be found and manipulated under `%JBOSS%/server/default/deploy/jboss-net.sar/axis-config.xml`. The http transport endpoints are described in `%JBOSS%/server/default/deploy/jboss-net.sar/jboss-net.war/web.xml`.

With JB4, even the drop-in deployment of descriptor-less JWS files (JavaBean source code that is to be compiled and immediately exposed as a web service quite analogous to JSPs) into the `%JBOSS%/server/default/deploy/jboss-net.sar/jboss-net.war` directory is possible.

## Information For Developers

The core mbean of JBoss.net hosting the Axis engine is named `jboss.net:service=Axis` and implemented through the class `org.jboss.net.axis.server.AxisService` which satisfies the common JBoss Sub-Deployer interface for registration in the maindeployer, etc. Our http-transport servlet `org.jboss.net.axis.server.AxisServlet` is setup through the embedded `%JBOSS%/server/default/deploy/jboss-net.sar/jboss-net.war/web-xml` and will contact the axis service (it gets the JMX ObjectName as an initial parameter).

Because of our deployment model differing from the axis one, JBoss.net web services are annotated with the deployment unit (including the deployment classloader) that has installed them. From JB4 on, the axis engine embedded into jboss.net will automatically cater for tagging MessageContexts with the right classloader and scoped typemapping registries.

Deprecated[In JB<4, we had a somewhat more complicated implementation where two handlers `org.jboss.net.axis.SetClassLoaderHandler` and `org.jboss.net.axis.ResetClassLoaderHandler` were configured in the global http request and response chains. These handlers would (re-)associate the calling thread (usually taken from the WebServer threadpool) with the correct classloader before entering the service request chain and after leaving the response chain also in the failure case. The old classloader was memorized in the messagecontext. There was no scoped TypeMappingRegistry except the service-specific ones such that typemapping declarations in the wsdd could be seen globally and conflict between deployments.]

Similarly, a specialized `org.jboss.net.axis.JWSHandler` has been inserted that will interface the jboss classloading information for compiling the jws files correctly.

The `org.jboss.net.axis.server.WSDLAwareHttpActionHandler` should be used in replacement of the Axis `org.apache.axis.handlers.http.HTTPActionHandler`, because, in conjunction with jboss.net provider classes, it will help to correctly annotate the generated WSDL with SOAPAction informations.

For easy client testing with a dynamic proxy approach, we have built the `org.jboss.net.axis.AxisInvocationHandler`. It is however common use to generate client-stub code (including meta-data information) using the WSDL4J tool, so AxisInvocationHandler has been marked deprecated.

"Dr. Schorsch" (christoph.jung@jboss.org) - 2001/09/29, Last update on 2003/10/15

All mentioned trademarks on this page are copyright of their respective owners ... like that ...