<h1>The JBoss.net deployment model</h1>

<p> 
<img SRC="../../../../../modules/html/developers/guides/jboss.net/jboss-net.png" align=LEFT> 
The core of JBoss.net is built by the <a href="http://xml.apache.org/axis">Apache AXIS</a> 
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 <em>serializers</em>, <em>handlers</em>, 
<em>providers</em> 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.
</p>

<p> 
<cite>
Here is an 
<a href="../../../../../modules/html/developers/guides/jboss.net/AddressBookSoapBindingImpl.java">example
bean implementation</a> to be exposed as a web service and its associated 
<a href="../../../../../modules/html/developers/guides/jboss.net/addr-web-service.xml">wsdd</a>. 
See the JAX-RPC specification and the 
<a ref="http://cvs.apache.org/viewcvs.cgi/~checkout~/xml-axis/java/docs/user-guide.html">Axis User Guide</a> 
for more information.</cite>
</p>

<p> 
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 (<code>%JBOSS%/server/default/deploy/jboss-net.sar/jboss-net.war</code>); 
the integrated Axis web service engine is exposed under the default 
prefix <code>http://%YOURHOST%:%WEBSERVERPORT%/jboss-net</code>).
</p>

<p> 
<img src="../../../../../modules/html/developers/guides/jboss.net/addr-wsr.jpg" 
 alt="Sample Web Service Archive" align="right"/> 
Instead of placing loose sets of files, individual web services are deployed in 
JBoss.net through convenient packaging units which we call 
<em>web service archives</em> (WSRs, see figure). WSRs are either compressed 
zip files or filesystem folders named with the suffix &quot;.wsr&quot;. 
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 <code>META-INF/web-service.xml</code>.
</p>

<p> 
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.
</p>

<p> 
Similarly to EARs, JARs, WARs, RARs and SARs, WSRs can be arranged as 
sub-deployments of any other deployment unit, e.g., a 
<a href="../../../developers/guides/jboss.net/ejb">web service archive
can be embedded into an enterprise application</a> 
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.
</p>

<h2>Alternative Approach (only JB4)</h2>
<p> 
With the advent of <a href="../../../developers/guides/jboss.net/ws4ee">WS4EE</a>, 
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.
</p>

<h2>Legacy Approach</h2>

<p> 
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 
<code>%JBOSS%/server/default/deploy/jboss-net.sar/jboss-net.war</code> 
for placing code and descriptors) and the web-based remote 
administration (<code>http://%YOURHOST%:%WEBSERVERPORT%/jboss-net/servlets/AdminServlet</code>). 
The default configuration of the JBoss.net engine can be found and manipulated 
under <code>%JBOSS%/server/default/deploy/jboss-net.sar/axis-config.xml</code>. 
The http transport endpoints are described in 
<code>%JBOSS%/server/default/deploy/jboss-net.sar/jboss-net.war/web.xml</code>.
</p>

<p> 
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 
<code>%JBOSS%/server/default/deploy/jboss-net.sar/jboss-net.war</code> 
directory is possible.
</p>

<h2>Information For Developers</h2>

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

<p> 
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.
</p> 

<p>
<em>Deprecated</em>[In JB<4, we had a somewhat more complicated implementation where two 
handlers <code>org.jboss.net.axis.SetClassLoaderHandler</code> and
<code>org.jboss.net.axis.ResetClassLoaderHandler</code> 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.]
</p>

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

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

<p> 
For easy client testing with a dynamic proxy approach, we have 
built the <code>org.jboss.net.axis.AxisInvocationHandler</code>. 
It is however common use to generate client-stub code (including 
meta-data information) using the <a href="http://www-124.ibm.com/developerworks/projects/wsdl4j/">WSDL4J tool</a>, 
so AxisInvocationHandler has been marked deprecated.
</p>

<p>"Dr. Schorsch" (<a ref="mailto:christoph.Jung@jboss.org">christoph.jung@jboss.org</a>) - 2001/09/29, Last update on 2003/10/15</p>

<p><small>All mentioned trademarks on this page are 
copyright of their respective owners ... like that ... </small></p>
