Eddie,
Thanks for your weighing in here... I'll respond to your notes and Rajith's at the same
time. I've included Rajith's comments in <RA> blocks and Eddie's in <EKO>
blocks. I apologize if the note is a bit unreadable. I couldn't figure out a better way
to include all of the comments.
** Exposing the annotated endpoint as either JAX-WS or Axis2 **
<RA>A) Expose every JSR 181 annotated POJO as Axis2 endpoint as well as a JAX-WS
endpoint. So we are creating two Axis2 services with one having a Suffix as
JAXWS.</RA>
I think I understand where you are going with this, but it still leaves us with
the issue of which service to target as a request is coming in. If all we have
is the inbound message as the identifier, there's no way to tell from just that
whether that message should be targeted to the Axis2 endpoint or the JAX-WS
endpoint. Also, I'm generally uncomfortable with configuring a service twice
here. The goal should be to just produce one configuration instance to reduce
complexity and confusion.
<RA>B) Allow a services.xml approach where we can explicitly specify the Message
Receiver</RA>
This approach is probably the easiest, but then prevents us from getting to the
ultimate goal of removing the services.xml completely and just deploying with
annotations. I'm ok with using this one as a way to get ourselves up and
running.
<EKO>How about a metadata driven approach that uses an annotation to describe
how a service should be exposed? For example, using something like:
@Axis2ServiceBinding(types={ServiceBindingType.NATIVE ,
ServiceBindingType.JAXWS})
</EKO>
This is certainly another solution that makes sense would be relatively easy,
but I don't believe we'll pass the JAX-WS TCK if we require this additional
annotation. Requiring deployment descriptors is not a problem since we're not
conflicting with anything defined by the spec.
** What happens to the other (non JSR-181) deployment info **
<RA>to be honest that's where I think JSR 181 falls short. The spec has clearly
failed to cater to these scenarios.
They should have some mechanism to enable security, RM, addressing or Policy
stuff
So again I can think of a few solutions here.
A) as u mentioned, to introduce axis2 specific annotations
B) or else once service is deployed, use the admin console to engage the modules
C) Have the services.xml approach to supplement the missing information.
</RA>
<EKO>My $0.02 would be that in the presence of a services.xml file, the annotations
are ignored and services.xml wins. I agree with the idea of using annotations to wire-up /
configure custom functionality in Axis -- this metadata could either drive generation of
services.xml or be processed to wire the service at runtime.</EKO>
Each of Rajith's proposals seem like a suitable way to resolve this. I don't
think they are mutually exclusive either. You would just have to be clear
about which takes precedence. I agree with Eddie's comment that in the
presence of a deployment descriptor, that should win if it overlaps with any of
the annotation information. But, there could be annotated information that
doesn't exist in the in the deployment descriptor should not be ignored.
** The scope of WSMService **
<EKO>True -- today, the WSMService doesn't support this, though it could certainly be extended
to do so. The goal of WSM was to provide a core set of functionality in three areas: #1 making it
possible to read metadata from a variety of sources (Java5, annogen, XDoclet, etc) #2 semantic
validation of 181 annotations (2) reading annotations from a variety of metadata sources #3
supporting generation of resources needed for deployment. All three of these stages were meant to be
pluggable. The "checking" phase would require verifying the 181 annotations but could be
extended to support additional annotations / checks. The code generation phase is pluggable and could
generate resources for Axis2, JAX-RPC, etc. All of this would pass the 181 TCK and still support
value-add functionality. FWIW, we're mostly there today. I'll take some time in the next day or two
to describe this architecture in more detail and send along a pointer.</EKO>
I think the pluggability that you are mentioning here is going to be key. We
certainly need to read metadata from multiple sources as you described. The
tricky part is what we do with that metadata. I'm a little confused as to what
the semantic checking is that needs to be done with respect to just 181. I'll
plead ignorance here in that I don't really know what the 181 TCK will/would
test for beyond making sure that the particular annotations are located in the
right places on the classes? That will certainly be needed and because it's
181 specific, could be burned in to WSM.
The plugpoint will need to be exploited when it comes time to handle some of
the JAX-WS specific validation of those annotations. My interpretation of the
181 spec is that it tries to provide a minimal set of rules about how the
annotations should be used and points to the appropriate spec (JAX-RPC in
version 1.0 and JAX-WS in the maintenance release) to handle the mapping to a
WSDL. So maybe the processing would go something like this:
Note: the flow described below is one that we're looking at for the JAX-WS
client implementation.
1. The first thing we are given is a WSDL document. We need to build the
metadata based on just that at first since we may not get any annotation data
at all. This is done using the WSDL11ToAxisServiceBuilder.
2. Next, we'll be given an annotated Service Endpoint Interface, so we need to
build a WSMService from an annotated class
- WSM uses whatever annotation technology (annogen, java reflection, apt)
it chooses to read those annotations
- While it's building the WSMService from that information, it performs the
181 specific validation
- Then it calls a plug point to handle the programming model specific
validation
3. Once (1) and (2) are complete, we then need to merge the metadata collected
from the annotations in with the WSDL information. As of now, we'd been
thinking of this as a JAX-WS specific piece and not something that would be in
WSM since it's specific to the current implementation (the info being stored in
the AxisService tree) and is based completely on JAX-WS rules.
So, based on what you mentioned above, I think each of your 1 and 2 items are
still applicable. The JAX-WS runtime would use items 1 and 2 in the scenario
I've outlined. I'm a little unclear though on what item 3 is. Does this mean
that WSM would generate an actual deployment descriptor?
** The scope of the JSR-181 TCK **
<EKO>Yep -- we intend to pass the TCK in which case the semantic checks for
"javax.jws" annotations would remain fixed w.r.t the specification.</EKO>
I *think* this should be addressed above. If my understanding of what's being
checked is correct, then I agree.
I was all over the place there so I hope that makes some amount of sense...
Let me know if anything needs clarification.
Thanks,
Nicholas Gallardo
WebSphere - WebServices Development
[EMAIL PROTECTED]
Phone: 512-838-1182
Building: 901 / 5G-016
"Eddie O'Neil" <[EMAIL PROTECTED]>
08/02/2006 10:44 PM
Please respond to
[email protected]
To [email protected]
cc
Subject Re: [Axis2] JSR 181 support
Nicholas / Rajith--
This is a good discussion. To frame the rest of my comments, I'll say that
I'm not a JAX-WS expert so if I say something that seems incongruous about 181
vs. JAX-WS below, let's talk about it.
I have been hoping that we could get JSR-181 (WSM) implemented for Axis2 (and Axis1),
"upgrade" the annotations to support the newest version of the specification,
and finally pass the TCK. I'd assumed that this would align with JAX-WS. Additionally,
the WSM annotation processors should be extensible enough to add support for additional,
Axis-specific annotations or for the standards.
We should also discuss the buildtime vs. runtime annotation processing
requirements. To date, WSM has focused on the buildtime requirements and
relied on a web service stack to wire / deploy the service. I'll start a
separate thread on this.
More comments below marked with "[eko]".
Eddie
- I don't yet know how we're going to solve the problem of determining when an
annotated class is intended for JAX-WS deployment vs. Axis2. Say for instance
a service implementation bean is annotated with just @WebService at the class
level and @WebMethod for each of the methods. As the deployment is happening,
how will we tell whether this is supposed to be an Axis2 endpoint or a JAX-WS
endpoint? We'll need to know the difference to determine which message
receiver to configure, the JAXWSMessageReceiver or the RPCMessageReceiver (I'm
guessing that's the one that would be used). Since they are both just
annotated beans and neither implements an interface, I can't figure out what
characteristic could be used to distinguish between the two.
[RA]
Very Good question. I currently use the RPCMessageReceiver and it's exposed
as an Axis2 endpoint. (I was hoping to sync up with you guys to work on
exposing the service as a JAX-WS endpoint).
Now we have two possible solutions for this problem
A) Expose every JSR 181 annotated POJO as Axis2 endpoint as well as a JAX-WS
endpoint. So we are creating two Axis2 services with one having a Suffix as
JAXWS.
Ex. If we have a Greeting.java POJO annotated with JSR 181, after deployment
we have to endpoints
a) GreetingService (Axis2 endpoint with RPC message receiver)
b) GreetingServiceJAXWS (JAXWS endpoint with JAXWS message receiver)
B) Allow a services.xml approach where we can explicitly specify the Message
Receiver
I prefer option A, but we can definitely make this configurable, so there is a
lot of flexibility here.
[eko] How about a metadata driven approach that uses an annotation to describe
how a service should be exposed? For example, using something like:
@Axis2ServiceBinding(types={ServiceBindingType.NATIVE ,
ServiceBindingType.JAXWS})
Then, the developer can specify how a service is exposed, and an
administration infrastructure could override this.
- On the topic of deployment, you have a comment in the code (DeploymentEngine)
that asks whether we can ignore the services.xml if we know we have a set of
annotated Java classes. While that's the ultimate goal, relying on the JSR-181
annotation data alone will not allow you to do this. If the services.xml is
ignored, where does the non-WSDL related config information that was in there
come from? For example, what if I wanted to specify a few module references to
enable WS-Addressing and some custom module that I've built. If the
services.xml is ignored, then that info is lost. Unless you defined a way to
include that in some custom Axis2 annotations as well. That might just be a
limitation of the scenario though...
[RA] to be honest thats where I think JSR 181 falls short. The spec has
clearly failed to cater to these scenarios.
They should have some mechanism to enable security, RM, addressing or Policy
stuff
So again I can think of a few solutions here.
A) as u mentioned, to introduce axis2 specific annotations
B) or else once service is deployed, use the admin console to engage the
modules
C) Have the services.xml approach to supplement the missing information.
[eko] My $0.02 would be that in the presence of a services.xml file, the
annotations are ignored and services.xml wins. I agree with the idea of using
annotations to wire-up / configure custom functionality in Axis -- this
metadata could either drive generation of services.xml or be processed to wire
the service at runtime.
Some comments from a JAX-WS perspective...
- While the WSMService provides the abstraction for the JSR-181 view of the
data, it cannot currently capture the JAX-WS specific annotation data. JAX-WS
defines a set of annotations on top of what is included in JSR-181 that are
required for some of the pretty common scenarios. Example: for a doc/lit
wrapped pattern service, there are @RequestWrapper and @ResponseWrapper
annotations that are required for any method that implements the wrapped
pattern.
[RA] I see your point here. Eddie will probably try to answer this question
from the WSM side.
[eko] True -- today, the WSMService doesn't support this, though it could certainly be
extended to do so. The goal of WSM was to provide a core set of functionality in three
areas: #1 making it possible to read metadata from a variety of sources (Java5, annogen,
XDoclet, etc) #2 semantic validation of 181 annotations (2) reading annotations from a
variety of metadata sources #3 supporting generation of resources needed for deployment.
All three of these stages were meant to be pluggable. The "checking" phase
would require verifying the 181 annotations but could be extended to support additional
annotations / checks. The code generation phase is pluggable and could generate resources
for Axis2, JAX-RPC, etc. All of this would pass the 181 TCK and still support value-add
functionality. FWIW, we're mostly there today. I'll take some time in the next day or
two to describe this architecture in more detail and send along a pointer.
- The WSMServiceFactory has code in it that handles some of the mapping rules
built in to it. I didn't dig through in great detail, but noticed a few places
where it resolves issues between the implementation class annotations and the
SEI annotations. My preference would be to have all of the rules for JAX-WS
built in to our JAX-WS layer. If we need to make changes in there, they become
self-contained. The rules for JAX-WS are well-defined and should be strictly
maintained. I would feel a little uncomfortable with the possibility that
those could change in WSM to support a different effort and could break our
JAX-WS compliance.
[RA] Again Eddie from WSM will answer the question. AFIK they are comitted to
support and be spec complient to JSR 181. So I don't think they will
arbitarily change code without giving due consideration to compliance. Also
they are fully aware that we are using WSM to build our stuff.
[eko] Yep -- we intend to pass the TCK in which case the semantic checks for
"javax.jws" annotations would remain fixed w.r.t the specification.
- The utility that you have for scanning the classes with ASM could be
leveraged in JAX-WS. We really just need something to quickly tell us whether
or not this class has annotations. The rest of the processing could then be
done with whatever other tool.
[RA] ASM is supposed to be a fast approach to reading class info without
actually loading the class into memory. So yes we could leverage that.
[eko] That would be very cool. One point here about buildtime vs. runtime
annotation processing -- my $0.02 is that it's important to re-use the same
checking logic for both buildtime and runtime. Would rather not maintain two
copies of this code. :)
A bit of background on what we're doing in the JAX-WS layer. Right now the
only place we're doing any form of annotations processing is the in the client
side code that Nikhil has built up for the dynamic proxy. This is all using
reflection and just been scaffolding to get us up and runnig. The longer term
goal is what was originally called MDQ, but was recently renamed as the
ServiceDescriptionFactory. This will be able to take in annotated Java and
build the JAX-WS runtime model (which uses the AxisService and then includes
the JAX-WS specific info). The ServiceDescriptionFactory will also eventually
be able to merge the Java annotation information with the WSDL info that may or
may not have already existed to produce a single runtime config. The only
problem is that this all has to be done keep the JAX-WS specific rules in mind.
It isn't generic enough to support a separate model for Axis2.
[RA] So you are proposing to bring everything under one umbrella instead of
having different models to provide the annotation (meta-date) processing.
Again lets wait and see what Dims and others have to say about this.
(Sorry I am not ducking the question :-) .....)
Hope that makes sense...
Nicholas Gallardo
WebSphere - WebServices Development
[EMAIL PROTECTED]
Phone: 512-838-1182
Building: 901 / 5G-016
"Rajith Attapattu" <[EMAIL PROTECTED]>
08/01/2006 06:10 PM
Please respond to
[email protected]
To [email protected]
cc
Subject Re: [Axis2] JSR 181 support
Jeff,
Thanks for your comments on the patch.
Yes the validating against an existing WSDL is still outstanding along with
the following.
(WSM does provide some functionality around this and I hope to leverage that)
I have used the WSM code to process all annotations defined in the spec and
build a WSM Model.
However when creating an Axis Service based on the WSM model the informaiton
provided by the following annotations are still not used.
@SOAPBinding
@HandlerChain
@SOAPMessageHandlers
Also outstanding
============
generating the WSDL if not specified
Validating against an existing WSDL (if specified using wsdlLocation)
Jeff this patch is just the base and a lot more work needs to be done. The
current patch can do the following.
1) use ASM to scan classes marked with @WebService annotation
2) Process all the annotations and build a WSM Model.
3) Build an Axis2 service based on the WSM model. (Only uses information
provided by @WebService and @WebMethod and @OneWay
4) Deploy the service.
Hope this helps you to understand the patch more.
Please feel free to ask more questions.
Regards,
Rajith
On 8/1/06, Jeff Barrett <[EMAIL PROTECTED] > wrote:
Hello Rajith,
From looking at the patch, I was wondering how WSDL and annotations will
interact with each other.
It seems to me (from looking at the JSR-181 spec and the JAX-WS spec) that annotations might
augment information specified in the WSDL. Specificaly, from JSR-181 (version 1.0 June 1, 2005)
section 2.2.2 "Start with WSDL" states: "...JSR-181 annotations supply
implementation details that are left out of the original WSDL contract, such as binding or service
location information."
It seems that building the AxisService from JSR-181 annotations needs to also
consider (and merge as well as possibly validate against) WSDL if there is any.
Thanks,
Jeff
IBM Software Group - WebSphere Web Services Development
Phone: 512-838-4587 or Tie Line 678-4587
Internet e-mail and Sametime ID: [EMAIL PROTECTED]
"Rajith Attapattu" <[EMAIL PROTECTED] >
07/27/2006 02:45 PM
Please respond to
[email protected]
To [email protected]
cc
Subject Re: [Axis2] JSR 181 support
Nicholas,
So sorry for the late reply, somehow I have missed it :-(
>>Sorry to jump in the middle here, but can you explain what the meta annotation is
and from which spec files it would be removed? I'm assuming you're talking >>about
the JSR-181 spec annotations declarations, but just wanted to make sure.
No need to appologize, sorry for not explaining it properly.
Annogen requires you to add an annotation, which it uses to generate the
AnnoBeans.
@AnnogenInfo(
annoBeanClass =
"org.codehaus.annogen.examples.stored_override.DeploymentInfoAnnoBean"
)
So I used the annotation on the spec files. For example on the
javax.jws.WebService which describes the @WebService annotation.
However it's illegal to modify a spec file without permission, so what we did
was to remove the annotation after we generated the necessary AnnoBeans.
The generated AnnoBeans were checked into the main source tree (since they
never change as the spec files are static)
>>Just for clarity, you are getting those from the WSM jars, correct?
Yes they come with the WSM jars. They will most likely be available in the
repos from today.
Hope this helps.
Regards,
Rajith
On 7/24/06, Nicholas L Gallardo <[EMAIL PROTECTED] > wrote:
Rajith,
Sorry to jump in the middle here, but can you explain what the meta annotation
is and from which spec files it would be removed? I'm assuming you're talking
about the JSR-181 spec annotations declarations, but just wanted to make sure.
Just for clarity, you are getting those from the WSM jars, correct?
Thanks,
Nicholas Gallardo
WebSphere - WebServices Development
[EMAIL PROTECTED]
Phone: 512-838-1182
Building: 901 / 5G-016
"Davanum Srinivas" <[EMAIL PROTECTED] >
07/24/2006 04:52 PM
Please respond to
[email protected]
To [email protected]
cc
Subject Re: [Axis2] JSR 181 support
Sounds good to me.
-- dims
On 7/24/06, Rajith Attapattu <[EMAIL PROTECTED] > wrote:
> Dims,
>
> Eddie was suggesting that we remove the meta annotation from the spec files
> since we already have the generated code.
> Since the spec file is static we can safely include the generated AnnoBeans
> in the main source tree.
>
> If we do that approach we can safely avoid the legal issue :-)
>
> What do u think?
>
> Regards,
>
> Rajith
>
>
> On 7/20/06, Rajith Attapattu <[EMAIL PROTECTED] > wrote:
> >
> > Hi All,
> >
> > I created a deployment hook which uses ASM to scan a jar file thats thrown
> into the axis2 repository to identify classes annotated with @WebServices.
> > Therefore there is no need for a services.xml to be present in the jar
> file.
> >
> > Currently support for @SOAPBinding, @HandlerChain, @SOAPMessageHandlers
> (on Axis2 side, the WSMModel is complete) and generating the WSDL is still
> outstanding.
> >
> > Comments/suggestions/reviews are most welcomed.
> >
> > I will wait for a general nod from the community about the direction,
> before I start on any further work.
> >
> > All required patches are attached to AXIS2-883
> >
> > Regards,
> >
> >
> > Rajith
> >
> >
> >
> >
> >
> > On 7/11/06, Eddie O'Neil <[EMAIL PROTECTED] > wrote:
> > > Rajith--
> > >
> > > I'm not super familiar with the Axis2 architecture, but in the
> > > absence of both a .aar file and service.xml, is there some default
> > > binding between a URL and a Java class? If so, the metadata could be
> > > checked and processed at runtime to dynamically wire-up a service
> > > based on the shape of a web service implementation class (and optional
> > > service endpoint).
> > >
> > > To close the loop on Dennis's question from a while ago, it *is*
> > > possible to get all of the type declarations that are annotated with a
> > > specific annotation. This method is available here:
> > >
> > >
>
http://java.sun.com/j2se/1.5.0/docs/guide/apt/mirror/com/sun/mirror/apt/AnnotationProcessorEnvironment.html#getDeclarationsAnnotatedWith(com.sun.mirror.declaration.AnnotationTypeDeclaration)
> > >
> > > and returns a collection of types (classes, fields, parameters) that
> > > are marked with some annotation.
> > >
> > > This doesn't really help us for wiring up web services at runtime,
> > > but it makes the build time very easy.
> > >
> > > Eddie
> > >
> > >
> > > On 7/11/06, Rajith Attapattu <[EMAIL PROTECTED] > wrote:
> > > > Hi Guillaume,
> > > >
> > > > if the service deployed as an ".aar" then we know which classes to
> > > > introspect or use ASM.
> > > > If there is a service.xml then we can easily figure out what the class
> is.
> > > > The above approach will make life easier.
> > > >
> > > > But I think the expectation is that service.xml is optional.
> > > > Also there maybe an expectation that the annotated POJO's need not be
> > > > deployed as an ".aar"
> > > >
> > > > I maybe wrong here, but it would be interesting to know what the
> expectation
> > > > is within the community.
> > > > ideas/comments please?
> > > >
> > > > Regards,
> > > >
> > > > Rajith
> > > >
> > > > On 7/11/06, Guillaume Sauthier
> > > > < [EMAIL PROTECTED] >
> > > > wrote:GuilGuillaumelaume
> > > > >
> > > > Rajith Attapattu wrote:
> > > > > Hi Dims,
> > > > >
> > > > > I finnaly managed to get an annotated POJO exposed as an axis2 web
> > > > > service.
> > > > > Before I submit the patch I need to clarify a few things.
> > > > >
> > > > > 1. We need to figure out a way to find the classes marked with
> > > > > @WebService.
> > > > > Right now I just have my test POJO hard corded in
> > > > > WSMToAxis2ServiceBuilder to test things.
> > > > >
> > > > > Ideas? suggestions pls?
> > > > Hi
> > > >
> > > > Basically, you have to introspect deployed services to find annotated
> > > > classes.
> > > > Ie : when an aar is deployed (the archive usually with the
> service.xml),
> > > > you can either look at all the classes with reflection, or use ASM to
> > > > find annotated classes.
> > > > BTW, Is the service.xml optionnal ?
> > > >
> > > > Regards
> > > > Guillaume
> > > > > There was a few disscussion, but can we come to an agreement?
> > > > >
> > > > > 2. Generating Annogen beans for meta data (This is more or less a
> WSM
> > > > > problem, will cross post there as well)
> > > > > The annogen task that generates code based on the annotated
> > > > > classes seems to have bug with inner classes.
> > > > > For example WebParam.Mode gives compilation errors as it cannot
> > > > > the handle the inner class
> > > > > So I eidted the generated source file to get it working.
> > > > >
> > > > > This maybe an option since the javax.jws classes are static and
> > > > > does not need to go through annogen code generation all the time.
> > > > > But it would be nice if this worked so that I can add a task in
> > > > > wsm to compile the javax.jws classes and generate the required
> > > > > AnnoBeans without manual intervention.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Rajith
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> >
>
>
--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
