axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: [Axis2] Re-visiting WS-A implementation
Date Thu, 08 Dec 2005 14:09:16 GMT
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
> ( and WS-A CR
> (, 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 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 

and a Xom based one that I am using

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.


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.


View raw message