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

Wed Nov 24 05:18:16 EST 2010

Comments inlined,

Rio

On 11/24/2010 10:42 AM, Alessio Soldano wrote:
>
> 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.
>
ok
>
> 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.).
>
Agreed. We'll discuss the configuration & related API in separate thread 
later.
>
> 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).
>
I don't like this records management framework
(don't take it personal Alessio, please ;) ).
I didn't notice on our forums or from our customers
they use it (I might be wrong of course)?

For now I'd say this is NICE TO HAVE FEATURE once we're done
with AS 7 integration work and we're passing TCK6 with it.
We can keep it in mind a provide integration hooks to our
JBossWS API/SPI so it's easily implementable in the future ;)

> 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].
>
I don't see real world usecases here.
If you'll provide some we can start discussing it.

For now I'd say again this is NICE TO HAVE FEATURE once we're done
with AS 7 integration work and we're passing TCK6 with it.
We can keep it in mind a provide integration hooks to our
JBossWS API/SPI so it's easily implementable in the future ;)

> *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)
>
This is what we have today. But I definitely agree this needs 
further/proper cleanup!
BTW there's EJB3 integration review on my plate. Hopefully this will be 
fixed with AS7 integration.
>
> - 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.)
>
Yes, we'll discuss this later.
>
> *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.
>
This is good point for another discussion.
For the beginning I'd say AS 7 service
is something similar to AS 6 deployers.
We've been leveraging AS 6 deployers
to call our DAs. I'd say for initial AS 7
integration we should leverage AS 7 service for that purpose.
Once this is done (and we'll be more familiar with AS 7 architecture)
we can get it to the next level.

> 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.
>
My 2c:
  * This won't work for JAXRPC.
  * nice idea, but we need to discuss it in more details
    (i.e. how to do it for JAXWS endpoints (don't forget about EJB3 
JAXWS endpoints here))
>
> We should be able to parse and digest an endpoint configuration, 
> properly setup the transport layer and then simply trigger the 
> endpoint deployment.
>
Yes, we'll probably need to read proprietary SOAP stack DDs. Maybe 
another candidate for API?
>
> 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, ...)
>
Correct! Nice recapitulation and grouping ;)
>
> 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.
>
Definitely!
>
> 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)).
>
We'll discuss this in more details once we'll dive into AS 7 integration ;)
>
> *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.
>
OK, makes sense.
>
> 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.
>
I like it. U're becoming perfectionist like me Alessio :)
>
> 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).
>
This is too low level. In general it makes sense to me.
But we'll discuss this when we'll start/be working on it.
>
>
> 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.
>
Let's hope this will kick off some interesting discussion ;)
>
>
> [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
>
>
> _______________________________________________
> jbossws-dev mailing list
> jbossws-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbossws-dev

-- 
Richard Opalka
ropalka at redhat.com
JBoss, by Red Hat

Office: +420 222 365 200
Mobile: +420 731 186 942

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbossws-dev/attachments/20101124/2fbfa3c8/attachment.html 