[jbossws-dev] AS7: Re-thinking WS container integration

[Alessio Soldano]

JBossWS 4 is going to be the jbossws integration layer for JBoss AS 7. 
This is both a chance of working on major spi changes / cleanup [1] as 
well as revisiting the whole way the installed ws stack (CXF or Native) 
is used for deploying endpoints.

*DOMAIN MODEL*

One of the idea AS7 comes with is exposing a domain for centralized 
control of the application server(s). JBossWS is going to contribute a 
ws subsystem to that domain, at least for setting the server level 
configuration aspects of the webservice engine.
The most obvious element being included in ws subsystem of the AS7 
domain are the information required for setting the "WS config", i.e. 
what we currently have in the WSServerConfig bean declared in 
stack-agnostic-jboss-beans.xml (webServiceHost, modifySoapAddress, etc.).
We'll then have the records' management configuration, which is also 
something configured at server level (WSMemoryBufferRecorder, 
WSLogRecorder, etc. currently in stack-specific-jboss-beans.xml).
Besides the easy things above, we should probably allow for 
pre-configuring a given application server instance with default 
endpoints (perhaps clients too in the future), meaning users can specify 
an endpoint configuration and have that endpoint included as part of the 
application server, the same way they would have had if they deployed an 
archive with the corresponding endpoint declaration [2].

*API REVIEW*

In the process of revisiting the JBossWS SPI, we need to properly split 
the current jbossws-spi project contents into:
- a set of classes/interfaces required for proper abstraction of jbossws 
components (pretty much what we have today, 2 stacks, perhaps multiple 
supported target container[3], ...) and to have a defined interface 
towards other related jboss projects (EJB3 for instance)
- a public API meant for actual user consumption, which would end up in 
a AS7 module visible to user deployments
The latter is going to include the classes/interfaces the domain model 
maps to (ws config, records stuff, service/endpoint/deployment basic 
stuff like endpoint class, publish address, ...) and what's required for 
tooling (wsconsume / wsprovide Ant tasks, command classes, etc.)

*CONTAINER INTEGRATION*

For integrating into AS7, we need to rethink the way jbossws handles 
deployments in terms of services (which are one of the key elements of 
AS7). At the end of the day, what the ws subsystem is supposed to do is 
providing facilities for starting/stopping webservice endpoints (and 
clients). Given the management requests of AS7, the domain model, etc. 
it's time to think about that as something not directly tied to the 
deployment process only, but generally available as a service instead. 
Other services in the application server might depend on or simply make 
use of this service [2]. The deployers (DeploymentUnitProcessors in AS7) 
should just be "clients" of this service.
To a certaint extent this way of thinking about the container 
integration fits with what has been done in JAXWS 2.2 Endpoint API and 
-for instance- the way an Apache CXF endpoint is started. We should be 
able to parse and digest an endpoint configuration, properly setup the 
transport layer and then simply trigger the endpoint deployment.
Currently (AS 5/6) the ws deployment goes through many ws deployers, 
most of which wrap jbossws "deployment aspects" (DA). Those can probably 
be splitted into few groups:
1) DAs dealing with figuring out / processing basic and container 
related informations (context root, url pattern, endpoint address, 
endpoint name)
2) DAs converting information coming from merged metadata (descriptors + 
annotations) into the jbossws-spi metadata
3) DAs dealing with the transport (creating / modifying the jbossweb 
metadata for ws endpoints)
4) DAs dealing with ws stack internals (for native: UMDM creating, 
eventing, rm, eager init, ... for cxf: jbossws-cxf descriptor creation, 
bus creation, ...)
Some of these are most probably meant for remaining part of the 
deployers (probably 1,2,3), the rest (probably 4) is actually going to 
become part of the services providing facilities for starting/stopping 
an endpoint.
The jbossws-spi should be seen as the interface for feeding the ws 
services that deal with endpoints.

AS7int.gif 
<http://community.jboss.org/servlet/JiveServlet/showImage/2-572530-10658/AS7int.gif>
While the AS7 / domain management system is going to simply make use of 
the public api part of jbossws-spi, the deployers are probably going to 
process all the metadata information coming from annotations and 
deployment descriptors into the jbossws-spi metadata and then feed the 
endpoint creation service. Deployers will also deal with / set required 
dependencies on other services involved in the deployment phase, for 
instance the web server service (which for instance will be required to 
properly create a context for the endpoint(s)).

*WS SERVICES*

What is then required to be a (WS) service? Apart from some obvious 
facilities like the endpoint registry and a server configuration 
provider service, the main service is the one meant for 
starting/stopping endpoints.
We need to carefully define a stable interface for this service, so that 
it can be maintained without much changes in the future. This mainly 
implies establishing the inputs for creating/starting an endpoint, 
basically the metadata carrying the required information for that. 
Ideally that should already be covered by what we have in jbossws-spi, 
plus stack specific configuration stuff.
For CXF that's everything that can be included in the jbossws-cxf.xml / 
cxf.xml, for Native it's what comes from the union of the info in 
endpoint configurations (configName / configFile...) and other 
additional optional descriptors (e.g. the jboss-wsse-*.xml).
For the sake of practically supporting future extensions / changes, the 
stuff above should most probably be modelled as AS7 extensions, each 
coming with its own parser bound to a given xsd namespace. For 
supporting advanced usecases (iow WS-*), the domain model should 
probably simply accept a pointer to additional xml configuration (beyond 
what's in the basic user API which is part of jbossws-spi, etc. - see 
above). Depending on the default namespace of the provided xml, the 
proper parser (coming from the installed ws stack) would be used and the 
domain enriched with the provided information for creating endpoint(s).
At the end of the day, most (if not all) the information is the Bus (for 
jbossws-cxf) / the UMDM (for jbossws-native).


What do you think about this all? My plan would be to get to an 
agreement on the main design for JBossWS 4 / AS 7 integration, perhaps 
by some iteration here. Then we can isolate/create/update jiras for what 
needs to be done and start scheduling things.


[1] JBWS-2709, JBWS-3115, JBWS-3105, JBWS-2338
[2] http://community.jboss.org/message/571376#571376
[3] JBossWS 4 will most probably at first support AS 7.x only

-- 
Alessio Soldano
Web Service Lead, JBoss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbossws-dev/attachments/20101124/a42fe11c/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AS7int.gif
Type: image/gif
Size: 13676 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/jbossws-dev/attachments/20101124/a42fe11c/attachment-0001.gif