Alessio Soldano [
http://community.jboss.org/people/alessio.soldano%40jboss.com] created
the discussion
"AS7: Re-thinking WS container integration"
To view the discussion, visit:
http://community.jboss.org/message/572530#572530
--------------------------------------------------------------
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.
http://community.jboss.org/servlet/JiveServlet/showImage/2-572530-10658/A...
http://community.jboss.org/servlet/JiveServlet/downloadImage/2-572530-106...
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 on this forum
discussion. 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
http://community.jboss.org/message/571376#571376
[3] JBossWS 4 will most probably at first support AS 7.x only
--------------------------------------------------------------
Reply to this message by going to Community
[
http://community.jboss.org/message/572530#572530]
Start a new discussion in JBoss Web Services Development at Community
[
http://community.jboss.org/choose-container!input.jspa?contentType=1&...]