axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <>
Subject Re: [Axis2] OM issues
Date Mon, 06 Dec 2004 03:34:23 GMT
Hi Sanjiva:

Sanjiva Weerawarana wrote:
>>* Regardless of what we do with respect to "full infoset support", I 
>>think that it's important to factor the SOAP-specific stuff now so that 
>>we have the ability to cleanly allow OM to evolve into something people 
>>can use to do XML+datbinding+XOP even without SOAP.  I'd suggest very 
>>strongly that we a) rename OMEnvelope/OMHeader/OMBody/OMFault to 
>>SOAPEnvelope/SOAPHeader/SOAPBody/SOAPFault, and b) put them in another 
>>package, perhaps, or org.apache.axis.soap.
> I was against this earlier, but Alek has brought up a point that
> has made me change my position on it (I think .. need to think
> some more). Alek's point was that if one is including an entire XML
> doc via MTOM, then it would be awkward to tell the user "use our 
> API to read the XML directly on SOAP, but otherwise use a standard
> XML API." I have to agree that would indeed be awkward.
> To make that work properly OM has to be complete and separate from SOAP.

While I'm definitely in the same camp as Alek here, I think what I'm 
asking for is a slightly simpler thing.  Although I would certainly be 
for making OM work outside the context of SOAP, I'm not even suggesting 
we go all the way to doing that right now - just that the SOAP specific 
classes should be named in what I think is the right way, which also 
happens to aid factoring it for more genericity.

>>SOAPEnvelope env = new SOAPEnvelope(VERSION11);
>>SOAPHeader security = SecurityExtension.makeSecurityHeader();
> Hmmmm. I kinda like having SOAPBody and SOAPHeader because then users
> can add namespace declarations to them for example. Also, I'd like
> to tie-in JXPath (or something similar) to provide XPath nav over
> the OM at some point .. retaining the actual XML structure will
> make that much much easier.
> Now, that said, I have no objection to providing what you showed
> as a convenience API. That will allow the user to work as if
> SOAPHeader doesn't exist .. unless they want to care. For example
> the WS-Addressing handler will want to care as that will allow it
> to avoid having the same namespace declared repeatedly for each
> occurence of a wsa: element.

+1, that sounds fine to me.

> Header block vs. Header .. my bad; I thought that the world indeed
> called them header blocks because that's what SOAP 1.2 calls 'em.

Have you heard the world doing this?  In the WSDL group, in the 
addressing group, etc, I keep hearing things like "add a header that 
will...", "process the <To> header...", etc.  That seems a pretty 
natural usage to me.

>>The context gets created and associated with incoming envelopes by the 
>>engine, which knows the roles via configuration of the engine and the 
>>service.  If there is no context associated with a given SOAPEnvelope 
>>(as when we're creating one from scratch), examineHeaders() would just 
>>return everything just like examineAllHeaders().
> So the lifecycle of the context is 1-1 with that of the message?
> Hence it would be 1-1 with that of the MessageContext as well. 
> I'm concerned this is overengineering it. I can see a use-case for
> looking for specific roles but are there other use-cases? Note that
> we already have MessageContext which is 1-1 with the envelope; I
> don't want to create any more objects on a per-message basis than
> needed.

The use case actually isn't looking for specific roles one-by-one.  The 
use case is the SOAP processing model - where a given node, when 
processing a SOAP message, should collect ALL the headers targeted at 
"it".  That means a) everything targeted at "next", b) everything 
targeted at "ultimateReceiver" if we're the ultimate receiver (the usual 
case), and c) everything targeted at any other custom role that this 
node is playing.  These headers, as a group, are the ones that we 
normally care about.

I don't think having this kind of thing is overengineering at all.  To 
answer your lifecycle questions, I don't think there needs to be a 1-1 
relationship - the set of actors that a given engine / service is 
playing is generally fixed and I see no reason not to take advantage of 

> Also, what's the usage status of role? I know that I haven't used
> them in any of the specs I've been involved with .. since role has
> something to do with intermediaries and since the SOAP intermediary
> stuff hasn't caught on as expected, I'm more towards -1 towards 
> adding this level of power right now. 

I think we have to have this or something very much like it in order to 
be SOAP compliant, and to support future use of this stuff.  We've 
experimented with it, and I know BEA has done some work with 
intermediaries too - plus this stuff (unlike the RPC encoding) is in the 
core spec, and not optional.  It's not very heavyweight; take a look at 
Axis 1.2, which does this sort of thing already.

>>* Incidentally, typing "Impl" all the time feels a little strange when 
>>building up OM structures.  So I'd like to consider one of two 
>>possibilities - first, don't bother making the OM classes interfaces. 
>>Are we really expecting lots of different implementations, or are we 
>>trying to simply build a lightweight API like JDOM (which just uses 
>>classes and is VERY easy)?  Second, if we stick with interfaces can we 
>>shift to using "IOMElement" for the interface and "OMElement" for the 
>>implementation class?
> As Srinath noted the idea is to enable multiple implementations.
> However, the user will *not* have to type "Impl" .. they should be
> creating from the factory (which is discovered via a JAXP like 
> mechanism).

Stylistic choice, I guess - I don't so much like factories for this.  I 
really really love the simplicity of JDOM, and would like it if we could 
be almost that easy to use.  Nice APIs make playing at "the XML level" 
much more pleasant.


View raw message