You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Eran Chinthaka <ch...@opensource.lk> on 2005/12/08 02:06:55 UTC
[Axis2] Re-visiting WS-A implementation
Hi all,
You might know the WS-A working group is getting ready for a testing
phase that will be started in next January. So I think its the best time
to re-visit the current implementation of WS-A in Axis2 and do necessary
changes, if required.
So here are my suggestions.
1. We will only handle WS-A Submissoin version
(http://schemas.xmlsoap.org/ws/2004/08/addressing) and WS-A CR
(http://www.w3.org/2005/08/addressing), which will ultimately become the
Final version with minor changes.
2. Lets have two handlers for each pipe to handle the two versions
separately, of course with code sharing via inheritance. So we will have
AddressingHandler
/\
|
----------------------------------------------------------------------
AddressingInHandler
AddressingOutHandler
/\
/\
|
|
-------------------------------------------
-------------------------------------------
|
| |
|
AddressingSubmissionInHandler AddressingFinalInHandler
AddressingSubmissionOutHandler AddressingFinalOutHandler
FYI :
The major changes between the two specs are the contents that are
included in EPR. MessageInformationHeader will still be common to both
of the versions.
In addition to that, I think we need to implement the fault handling of
addressing as well. Can we differ i, until we are done with this ?
Comments are mostly welcome, especially from the WS-A experts we have
here :-)
-- Chinthaka
Re: [Axis2] Re-visiting WS-A implementation
Posted by Steve Loughran <st...@apache.org>.
Eran Chinthaka wrote:
> Hi all,
>
> You might know the WS-A working group is getting ready for a testing
> phase that will be started in next January. So I think its the best time
> to re-visit the current implementation of WS-A in Axis2 and do necessary
> changes, if required.
> So here are my suggestions.
>
> 1. We will only handle WS-A Submissoin version
> (http://schemas.xmlsoap.org/ws/2004/08/addressing) and WS-A CR
> (http://www.w3.org/2005/08/addressing), which will ultimately become the
> Final version with minor changes.
>
> 2. Lets have two handlers for each pipe to handle the two versions
> separately, of course with code sharing via inheritance. So we will have
>
> AddressingHandler
>
> /\
>
> |
>
> ----------------------------------------------------------------------
> AddressingInHandler
> AddressingOutHandler
> /\
>
> /\
>
> |
> |
>
> -------------------------------------------
> -------------------------------------------
> |
> | |
> |
> AddressingSubmissionInHandler AddressingFinalInHandler
> AddressingSubmissionOutHandler AddressingFinalOutHandler
>
>
> FYI :
>
> The major changes between the two specs are the contents that are
> included in EPR. MessageInformationHeader will still be common to both
> of the versions.
>
> In addition to that, I think we need to implement the fault handling of
> addressing as well. Can we differ i, until we are done with this ?
yes, we need to return the proper faults for WS-A problems.
> Comments are mostly welcome, especially from the WS-A experts we have
> here :-)
(resending, I think I used the hpl.hp.com alias so it didnt get through)
WS-A is the bane of my life. Some of my thoughts on the matter have
recently been expressed on SOAPBuilders. We have something as
fundamental as a new way of addressing SOAP packets, yet the spec was
written without a single test. In my experience, interop between
implementations is pretty minimal, and the many versions of WS-A out in
the field makes things worse.
As I work with WS-DM and WS-RF /WS-N, I have to use the 2003/03 and the
2004/08 version, and have lots of classes to help me. A defunct XMLBeans
one:
http://cvs.sourceforge.net/viewcvs.py/smartfrog/core/components/deployapi/src/org/smartfrog/services/deployapi/binding/xmlbeans/BeanUtils.java?view=markup
and a Xom based one that I am using
http://cvs.sourceforge.net/viewcvs.py/smartfrog/core/components/deployapi/src/org/smartfrog/services/deployapi/binding/EprHelper.java?view=markup
Some of the things I do in the latter are
-extract an EPR from returned 2003 and 2004 EPRs returned inside a
message. One SOAP call returns an EPR which I need to turn into an axis
endpointReference; currently this has to be done by hand
Feature request #1: code to go from Axiom to EPRs, supporting all main
(2003-2005) drafts you encounter in the field.
-Take an EPR and turn it into some inline content.
Feature request #2: code to go from EPRs to Axiom, supporting all main
(2003-2005) drafts you encounter in the field.
-Print an EPR for logging
Feature request #3: toString() does something useful, above and beyond
what I do
public static String stringify(EndpointReference epr) {
return epr.getAddress();
}
-Compare two EPRs for equivalence. This gets complex fast. currently I
just compare addresses.
public static boolean compareEndpoints(EndpointReference e1,
EndpointReference e2) {
return e1.getAddress().equals(e2.getAddress());
}
Feature request #4: an equals() operator that returns true if two EPRs
point to the same address/params
-Support complex stuff in the resource parameters
I know my endpoints only use extended URLs, but things like MUSE use
reference properties/params to identify destinations.
Feature request #5: full support for all the funny bits of the later specs.
-Interop
Feature request #6: pass the test suite that is being slowly put
together at the W3C.
I know these are a lot of requests, and I have too many other tests
failing to work on any of these, not until march when I return to the
SOAP API. I have done what I need, namely fix Axis2's dispatching to
properly dispatch stuff to the right place when the wsa:address contains
a URL with a ?name=value bit at the end of the string. Even that was
broken in 0.92.
-steve