axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksander Slominski <>
Subject Re: [Axis2] Addressing info in the message context
Date Thu, 23 Dec 2004 05:25:45 GMT
Eran Chinthaka wrote:

>Thought of giving some updates on addressing info in the message context, as people might
be using these.
>I created some classes under org.apache.axis.addressing package and I looked both Dims'
ws-addressing impl and the new addressing spec (10th August, 2004) for that.
>MessageID --> java.lang.String
>RelatesTo --> org.apache.axis.addressing.miheaders.RelatesTo (this is special type
of URI as it has RelationshipType also) 
AFAIR it is eii with content type of URI and attribute RelationshipType 
that is QName

>To --> org.apache.axis.addressing.EndpointReferenceType (I have doubt here. To my understanding,
according to the spec, wsa:To is a URI, not an EPR. But Sanjiva said wsa:To is an EPR ???.
Refer 3.1 in addressing spec)
wsa:destination is MIH that is  SOAP Header and as it is URI and what is 

>Action --> java.lang.String

>>>From --> org.apache.axis.addressing.EndpointReferenceType
>ReplyTo --> org.apache.axis.addressing.EndpointReferenceType
>FaultTo --> org.apache.axis.addressing.EndpointReferenceType

>Note : I opted to use String for URIs for the time being. We can create a URI from the
string whenever we like. And URLs in Java are much slower.
URIs are much more type safe and intuitive IMHO

i think you would to create hundreds (or thousands) of them per call to 
have noticeable slowdowns ...

>org.apache.axis.addressing.EndpointReferenceType has all the methods to retrieve the information
like Address, portType, referenceProperties, etc.,
>In addition to what is in Spec, I put a String param in this to identify the type of this
EPR (i.e. whether this refers to wsa:From, wsa:replyTo, etc.,), as then it will be easier
to serialize.
this should be name of element (ns + localname)

>Plus I'm creating a class to hold all the MI Headers called, AddressingHeaders. This will
ease the use of addressing info, as it contains the whole set. 
this can work pretty well - i did the same in xsul and i was quite happy 
with it

>And there I put a method to convert the information to OM. 
>public void toOM(SOAPHeader)
>This will convert whatever info in the AddressingHeader class to SOAPHeaderBlocks in OM.

>And there is another class OMEndpointReference, so that given an EndpointReferenceType,
this will convert the info to SOAPHeaderBlocks in OM.
in xsul i called that "exploding" EPR content into SOAP Header (as 
reference properties and parameters become headers)

>(I opted not to put that method within EndpointReferenceType class, as for me EndpointReferenceType
class is the direct mapping to XML-Infoset based representation for an EPR)
when i was implementing it then i made EPR class to extend XmlElement in 
xsul (equivalent of OmElement)

>MessageContext will have methods to set/get MI headers. 
that is where it gets interesting.


The best way to predict the future is to invent it - Alan Kay

View raw message