JBossWS Deployers Architecture

[ropalka]

"Bill Burke" wrote:
I have to write a deployer for RESTEasy (JAX-RS) and it will be very similar to WS deployer.
My question is, how does JBossWeb know to ignore a JAXWS class
and let WS handle things? How do you override things? I can't seem to find the code for it.

[ropalka]

Hi Bill,

we distinguish two JAX-WS endpoint types:
* POJO
* EJB3 (the same like POJO, but annotated with EJB3 @Stateless annotation)
This WSTypeDeployer detects webservices deployment type.

For every POJO endpoint our users have to provide web.xml DD
where every servlet-class contains POJO Web Service Endpoint class name.

For every EJB3 endpoint we're generating JBossWeb meta data in WebMetaDataCreator
(called by our aspectized deployer wrapping WebMetaDataCreatingDeploymentAspect)
where every servlet-class contains EJB3 Web Service Endpoint class name.

The following applies to both EJB3 and POJO webservice endpoint types.

This servlet-class is lately overriden in our WebMetaDataModifier (lines 118-127)
(called by our aspectized deployer wrapping WebMetaDataModifyingDeploymentAspect).
The servlet-class is replaced with our transport servlet class (that extends AbstractEndpointServlet)
and we're providing init-param to let the transport class know which endpoint class is associated with it.

"Bill Burke" wrote:

My question is, how does JBossWeb know to ignore a JAXWS class
and let WS handle things? How do you override things?

JBossWeb doesn't ignore JAX-WS class. As I mentioned above,
we're modifying servlet-class in WebMetaDataModifier and replacing
it with real servlet. JBossWS does its job via aspectized deployers
(see stack agnostic deployment aspects and stack specific deployment aspects)

[bill.burke]

Thanks for explanation. I've looked at your code a bit. Are the aspectized deployers just a abstraction for JBossWS so that it can move/integration smoothly between different deployment mechanisms?

All and all, it looks like things would be pretty straighforward to create a RESTEasy integration. Its just a matter of writing descriptor and real deployers and then importing, modifying, and exporting the correct metadata.

BTW, would be interesting to hear what you think of the JBoss 5 deployment framework. So far, it looks like it is solving what it was intended to do.

[ropalka]

All and all, it looks like things would be pretty straighforward to create a RESTEasy integration. Its just a matter of writing descriptor and real deployers and then importing, modifying, and exporting the correct metadata.

Exactly.

BTW, would be interesting to hear what you think of the JBoss 5 deployment framework. So far, it looks like it is solving what it was intended to do.

AlesJ, Warjort and others involved did an excellent job IMO. What about JBossWS team, we like JBoss5 deployment framework and had no real issues with it ;)

[ropalka]

Are the aspectized deployers just a abstraction for JBossWS so that it can move/integration smoothly between different deployment mechanisms?

Exactly, U got it ;)

Let me explain you our architecture more high level.

There are three main JBossWS integration points:
* SPI
* ASIL (application server integration layer)
* SSIL (SOAP stack integration layer)

Our SPI provides abstraction for different JBossAS servers and SOAP stacks.
The SPI help us to be both JBossAS and SOAP stack agnostic.
To achieve it, our SPI have its own UMDM (universal meta data model)
that is generated from both JBossAS and SOAP stack MD (meta data).

The ASIL always resides in JBossAS/webservices module
and implements our SPI (to be JBossAS agnostic).
Of course it has no notion about SOAP stack and uses our SPI to integrate with it.
The goals of ASIL are:
* AS components integration (EJB3 invocations, injection, Web MD modification)
* AS MD => UMDM translation (translate JBossAS MD to JBossAS agnostic MD)
* deployers integration (moves deployers abstraction one step higher, we have custom
WSDeploymentAspectDeployer that allows us to decouple from JBossAS specific deployers
and thus allows us to support multible JBossAS versions as pictured above)

The SSIL allows us to support different SOAP stacks. Currently we provide support for three SOAP stacks:
* Native (SVN, Home Page)
* Metro (SVN, Home Page)
* CXF (SVN, Home Page)

The SSIL always resides in separate JBoss SVN
and implements our SPI (to be SOAP stack agnostic).
Of course it has no notion about JBossAS server and uses our SPI to integrate with it.

So back to answer your question.

Are the aspectized deployers just a abstraction for JBossWS so that it can move/integration smoothly between different deployment mechanisms?

We have WSDeploymentAspectDeployer to decouple from JBossAS internals and
allow us to execute both JBossAS and SOAP stack agnostic DAs (Deployment Aspects).