<!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 12:24 PM, Alessio Soldano wrote:
<blockquote cite="mid:4CECF5D2.4000902@redhat.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Hi Richard,<br>
<br>
On 11/24/2010 11:18 AM, Richard Opalka wrote:<br>
<blockquote cite="mid:4CECE668.1040506@redhat.com" type="cite">
<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>
</blockquote>
<br>
yeah, for sure this is not the main focus of the discussion, nor a
top priority thing, it was just an example of something whose
configuration is to be at server level and not at deployment
level. Regarding liking it or not... we can think about improving
it :-P In the end, anyway, this is one of the things that could
serve as a starting point / hook for a decent JON integration...
(you know productivity, if only we find some time for getting back
to that again..)<br>
</blockquote>
I see what you mean regarding JBossWS JON plugin.<br>
But believe me, admin consoles are used mainly by administrators<br>
and they don't care about exchanged messages for particular
endpoints.<br>
Maybe exchanged messages count & other minimalistic statistics.<br>
<br>
But I wouldn't do/support SOAP envelope inspections like we do
today.<br>
This is developers focus and they usually use<br>
SOAP UI or similar protocol sniffering tools ;)<br>
<blockquote cite="mid:4CECF5D2.4000902@redhat.com" type="cite"> <br>
<blockquote cite="mid:4CECE668.1040506@redhat.com" type="cite">
<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>
</blockquote>
<br>
This would both be a proof that a proper separation of concerns is
in place and come for free once the endpoint service is ready.
Basically you have endpoints configurable from the domain.<br>
Regarding usecases, for sure there're cases requiring the endpoint
creation to be a service (Thomas Diesler has been mentioning that
to me for his osgi work, for instance). We can for sure delay the
domain part of this work, but that's just a thin wrapper around
the actual work (providing the endpoint service) ;-)<br>
</blockquote>
Aha, you mean OSGi service depends on some JAXWS endpoints.<br>
What's the added value? Maybe Thomas can comment here from OSGi POV<br>
and clarify requirements (and providing use cases)?<br>
<blockquote cite="mid:4CECF5D2.4000902@redhat.com" type="cite"> <br>
<blockquote cite="mid:4CECE668.1040506@redhat.com" type="cite">
<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>
Yes. This is one of the reason I'd like to get started with this
jbws 4 work asap, Carlo is needing any changes to the interface
with WS well before AS 7 goes Beta1 (as EJB3 is meant for Beta1 as
far as I understood)<br>
</blockquote>
I can do some EJB3 dependencies cleanup in AS 6 trunk to clarify it
before AS 6 goes final?<br>
Or I can use custom 3.4.0 JBossWS branches against AS CR1? Depends
on decision how we'll proceed.<br>
I created <a class="moz-txt-link-freetext" href="https://jira.jboss.org/browse/JBWS-3167">https://jira.jboss.org/browse/JBWS-3167</a><br>
Please prioritize it and assign proper targets where U wanna it to
be fixed.<br>
We can ask Carlo when exactly he want to have this list of
dependencies?<br>
<blockquote cite="mid:4CECF5D2.4000902@redhat.com" type="cite"> <br>
<br>
<blockquote cite="mid:4CECE668.1040506@redhat.com" type="cite">
<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>
</blockquote>
What I'm saying is that AS7 deployers are not going to do all the
things they used to do in AS6. Part of the work is not actually up
to the deployers and needs to be factored out to a more generic
service / set of services everybody can use, regardless of
deployers being used or not.<br>
</blockquote>
I see what U mean be we need some baseline we can start from.<br>
I'd say integrate to AS7 first to have some results, optimize later.<br>
<blockquote cite="mid:4CECF5D2.4000902@redhat.com" type="cite"> <br>
<br>
<blockquote cite="mid:4CECE668.1040506@redhat.com" type="cite">
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>
</blockquote>
Well, a good part of the changes in AS7 is in this service way of
thinking. I'd like to get to a good design with that, then we can
think about possible milestones to get there. </blockquote>
Service 's kinda thinking shouldn't be a problem here.<br>
I can imagine refactoring of "AS 6 deployers calling DAs"<br>
to "AS 7 deployers calling DAs & services" without introducing
regressions ;)<br>
<blockquote cite="mid:4CECF5D2.4000902@redhat.com" type="cite">Please
note that anything not really make use of the AS facilities
properly is not going to be pulled upstream</blockquote>
Well U need some JBossWS AS7 baseline first<br>
which will help U to learn basic AS 7 architecture rapidly.<br>
AS 7 team cannot expect/force others to be AS 7 experts first<br>
(before contributing anything to AS7)<br>
and doing "everything" right in first pull request.<br>
Software development is iteration process not one shoot process.<br>
I think it's kinda politics to get some functional JBossWS baseline
to AS7 :D<br>
<blockquote cite="mid:4CECF5D2.4000902@redhat.com" type="cite"> and
this is a major release both for AS and JBWS, so it's a chance for
reviewing the design.<br>
</blockquote>
Definitely. We'll do our best!<br>
<blockquote cite="mid:4CECF5D2.4000902@redhat.com" type="cite"> <br>
<br>
<blockquote cite="mid:4CECE668.1040506@redhat.com" type="cite">
<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>
please do not get me wrong, I'm not saying I want to directly use
the Endpoint API. </blockquote>
Don't worry. I didn't.<br>
<br>
<blockquote cite="mid:4CECF5D2.4000902@redhat.com" type="cite">I'm
just saying that we can see this similarly, we need to think about
the deployment process in terms of a) something strictly related
to setting up the container for the ws deployment, b) actually
creating the endpoint and connecting it to the container.
Theoretically speaking (b) is pretty much what is going to the
service. This said, for sure we need to deal with the details, but
that comes after agreeing on a vision.<br>
</blockquote>
My vision is to support both AS 6 (CR1 or GA) & AS 7 in JBossWS
4.0.x series.<br>
This is very important to track integration regressions we might
introduce during the AS 7 integration process.<br>
And we need to come to an agreement what we'll target with JBossWS 4
series ASAP ;)<br>
<blockquote cite="mid:4CECF5D2.4000902@redhat.com" type="cite">
Regarding JAXRPC, it's legacy stuff, so it's acceptable to treat
that differently if we need to (meaning no domain / public
available service & api for that). Just the "minimum" required
for certification.<br>
</blockquote>
Yes, but this legacy staff needs some minimal cleanup too.<br>
I bet JAXRPC will be the biggest pain when integrating on top of AS
7 :(<br>
(because all it's dependencies and fugly hacks needed to make it
work)<br>
<blockquote cite="mid:4CECF5D2.4000902@redhat.com" type="cite"> <br>
<br>
<blockquote cite="mid:4CECE668.1040506@redhat.com" type="cite">
<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>
yes, that's what I've mentioned later in the WS Services section.<br>
<br>
</blockquote>
ok<br>
<blockquote cite="mid:4CECF5D2.4000902@redhat.com" type="cite"> <br>
<blockquote cite="mid:4CECE668.1040506@redhat.com" type="cite">
<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>
Sure, this was written here to convey the idea of what should be
up to the deployers and what should be in the service instead.<br>
<br>
</blockquote>
ok<br>
<blockquote cite="mid:4CECF5D2.4000902@redhat.com" type="cite"> <br>
<blockquote cite="mid:4CECE668.1040506@redhat.com" type="cite">
<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>
OK<br>
<br>
Cheers<br>
Alessio<br>
<br>
<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>