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