<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Comments inlined,<br>
<br>
Rio<br>
<br>
On 11/24/2010 10:42 AM, Alessio Soldano wrote:
<blockquote cite="mid:4CECDE10.20405@redhat.com" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<div class="jive-rendered-content">
<p>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.</p>
<p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p>
<p><strong>DOMAIN MODEL</strong></p>
<p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p>
<p>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.<br>
</p>
</div>
</blockquote>
ok<br>
<blockquote cite="mid:4CECDE10.20405@redhat.com" type="cite">
<div class="jive-rendered-content">
<p> 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.).<br>
</p>
</div>
</blockquote>
Agreed. We'll discuss the configuration & related API in
separate thread later.<br>
<blockquote cite="mid:4CECDE10.20405@redhat.com" type="cite">
<div class="jive-rendered-content">
<p> 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).<br>
</p>
</div>
</blockquote>
I don't like this records management framework<br>
(don't take it personal Alessio, please ;) ).<br>
I didn't notice on our forums or from our customers<br>
they use it (I might be wrong of course)?<br>
<br>
For now I'd say this is NICE TO HAVE FEATURE once we're done<br>
with AS 7 integration work and we're passing TCK6 with it.<br>
We can keep it in mind a provide integration hooks to our<br>
JBossWS API/SPI so it's easily implementable in the future ;)<br>
<br>
<blockquote cite="mid:4CECDE10.20405@redhat.com" type="cite">
<div class="jive-rendered-content">
<p> 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].</p>
</div>
</blockquote>
I don't see real world usecases here.<br>
If you'll provide some we can start discussing it.<br>
<br>
For now I'd say again this is NICE TO HAVE FEATURE once we're done<br>
with AS 7 integration work and we're passing TCK6 with it.<br>
We can keep it in mind a provide integration hooks to our<br>
JBossWS API/SPI so it's easily implementable in the future ;)<br>
<br>
<blockquote cite="mid:4CECDE10.20405@redhat.com" type="cite">
<div class="jive-rendered-content">
<p><strong>API REVIEW</strong></p>
<p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p>
<p>In the process of revisiting the JBossWS SPI, we need to
properly split the current jbossws-spi project contents into:<br>
- 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)<br>
</p>
</div>
</blockquote>
This is what we have today. But I definitely agree this needs
further/proper cleanup!<br>
BTW there's EJB3 integration review on my plate. Hopefully this will
be fixed with AS7 integration.<br>
<blockquote cite="mid:4CECDE10.20405@redhat.com" type="cite">
<div class="jive-rendered-content">
<p> - a public API meant for actual user consumption, which
would end up in a AS7 module visible to user deployments<br>
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.)</p>
</div>
</blockquote>
Yes, we'll discuss this later.<br>
<blockquote cite="mid:4CECDE10.20405@redhat.com" type="cite">
<div class="jive-rendered-content">
<p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p>
<p><strong>CONTAINER INTEGRATION</strong></p>
<p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p>
<p>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.<br>
</p>
</div>
</blockquote>
This is good point for another discussion.<br>
For the beginning I'd say AS 7 service<br>
is something similar to AS 6 deployers.<br>
We've been leveraging AS 6 deployers<br>
to call our DAs. I'd say for initial AS 7<br>
integration we should leverage AS 7 service for that purpose.<br>
Once this is done (and we'll be more familiar with AS 7
architecture)<br>
we can get it to the next level.<br>
<br>
<blockquote cite="mid:4CECDE10.20405@redhat.com" type="cite">
<div class="jive-rendered-content">
<p> 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. </p>
</div>
</blockquote>
My 2c:<br>
* This won't work for JAXRPC.<br>
* nice idea, but we need to discuss it in more details <br>
(i.e. how to do it for JAXWS endpoints (don't forget about EJB3
JAXWS endpoints here))<br>
<blockquote cite="mid:4CECDE10.20405@redhat.com" type="cite">
<div class="jive-rendered-content">
<p>We should be able to parse and digest an endpoint
configuration, properly setup the transport layer and then
simply trigger the endpoint deployment.<br>
</p>
</div>
</blockquote>
Yes, we'll probably need to read proprietary SOAP stack DDs. Maybe
another candidate for API?<br>
<blockquote cite="mid:4CECDE10.20405@redhat.com" type="cite">
<div class="jive-rendered-content">
<p> 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:<br>
1) DAs dealing with figuring out / processing basic and
container related informations (context root, url pattern,
endpoint address, endpoint name)<br>
2) DAs converting information coming from merged metadata
(descriptors + annotations) into the jbossws-spi metadata<br>
3) DAs dealing with the transport (creating / modifying the
jbossweb metadata for ws endpoints)<br>
4) DAs dealing with ws stack internals (for native: UMDM
creating, eventing, rm, eager init, ... for cxf: jbossws-cxf
descriptor creation, bus creation, ...)<br>
</p>
</div>
</blockquote>
Correct! Nice recapitulation and grouping ;)<br>
<blockquote cite="mid:4CECDE10.20405@redhat.com" type="cite">
<div class="jive-rendered-content">
<p> 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.<br>
The jbossws-spi should be seen as the interface for feeding
the ws services that deal with endpoints.</p>
</div>
</blockquote>
Definitely!<br>
<blockquote cite="mid:4CECDE10.20405@redhat.com" type="cite">
<div class="jive-rendered-content">
<p>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)).</p>
</div>
</blockquote>
We'll discuss this in more details once we'll dive into AS 7
integration ;)<br>
<blockquote cite="mid:4CECDE10.20405@redhat.com" type="cite">
<div class="jive-rendered-content">
<p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p>
<p><strong>WS SERVICES</strong></p>
<p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p>
<p>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.<br>
</p>
</div>
</blockquote>
OK, makes sense.<br>
<blockquote cite="mid:4CECDE10.20405@redhat.com" type="cite">
<div class="jive-rendered-content">
<p> 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.<br>
</p>
</div>
</blockquote>
I like it. U're becoming perfectionist like me Alessio :)<br>
<blockquote cite="mid:4CECDE10.20405@redhat.com" type="cite">
<div class="jive-rendered-content">
<p> 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).<br>
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).<br>
At the end of the day, most (if not all) the information is
the Bus (for jbossws-cxf) / the UMDM (for jbossws-native).</p>
</div>
</blockquote>
This is too low level. In general it makes sense to me.<br>
But we'll discuss this when we'll start/be working on it.<br>
<blockquote cite="mid:4CECDE10.20405@redhat.com" type="cite">
<div class="jive-rendered-content">
<p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p>
<p><br>
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.</p>
</div>
</blockquote>
Let's hope this will kick off some interesting discussion ;)<br>
<blockquote cite="mid:4CECDE10.20405@redhat.com" type="cite">
<div class="jive-rendered-content">
<p style="min-height: 8pt; height: 8pt; padding: 0px;"> </p>
<p><br>
[1] JBWS-2709, JBWS-3115, JBWS-3105, JBWS-2338<br>
<span>[2] </span><a moz-do-not-send="true"
class="jive-link-external-small"
href="http://community.jboss.org/message/571376#571376"
target="_blank">http://community.jboss.org/message/571376#571376</a><br>
[3] JBossWS 4 will most probably at first support AS 7.x only</p>
</div>
<pre class="moz-signature" cols="72">--
Alessio Soldano
Web Service Lead, JBoss</pre>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
jbossws-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:jbossws-dev@lists.jboss.org">jbossws-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/jbossws-dev">https://lists.jboss.org/mailman/listinfo/jbossws-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Richard Opalka
<a class="moz-txt-link-abbreviated" href="mailto:ropalka@redhat.com">ropalka@redhat.com</a>
JBoss, by Red Hat
Office: +420 222 365 200
Mobile: +420 731 186 942
</pre>
</body>
</html>