axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eran Chinthaka" <>
Subject RE: [Axis2] OM issues
Date Mon, 06 Dec 2004 03:49:57 GMT

Excellent comments Glen. 

I read the preceding mail of Sanjiva. But since, I want to comment on Geln's
comments, I use this email.
>>Some comments about OM:
>>* 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.
[Chinthaka] (refer Sanjiva's reply)

>>* Despite SAAJ doing it this way, I really don't like having a separate
>>object for SOAPHeader and SOAPBody, especially since you don't really do
>>anything with them except use them as containers.  To me, it's much more
>>natural to have the SOAPEnvelope class allow you to add/remove/view
>>headers (the world calls them "headers" and not "header blocks", so I'd
>>prefer the API to as well) and bodies without using the extra layer of
>>objects.  Example:
>>SOAPEnvelope env = new SOAPEnvelope(VERSION11);
>>SOAPHeader security = SecurityExtension.makeSecurityHeader();

[Chinthaka] I agree with you that SOAPHeader is just a container.
OK the rationale behind this approach was like this.

1. we tried to map the SOAP message elements directly to the api as well. So
we have Envelope in the XML and OMEnvelope in the API. SO as the Header.
Then comes HeaderBlocks. 
2. Header is giving out some functionality for the use to get some specific
header only. For example he can ask for getHeadersWithMustUnderstand(). I
think if we are removing, these methods have to be moved to OMEnvelope,
which is OK. 

>>* I don't understand the examine/extract APIs for header blocks.  Why do
>>we need extract?  Can't the user just remove them themselves?
[Chinthaka] This is user convenience.

User can just *read* headers using examine methods. Or he can *read and
detach* while reading using extract. I put this method specifically keeping
security in mind. Where user may sometime need to read and detach some
nodes. Rather than he specifically doing that, the method, internally calls
the detach method.

>>* I think that a given SOAPEnvelope should have a "context" of some kind
>>associated with it, which includes at least the currently active roles.
>>  Then when you iterate over the headers, the default behavior is to
>>iterate over just the ones targeted at those roles.
>>SOAPContext context = new SOAPContext();
>>Iterator i = envelope.examineHeaders();
>>// this iterator now only covers headers targeted to
>>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().

[Chinthaka] for this I agree with Sanjiva's comments.

>>* I don't understand the various fault-related operations in OMBody.
>>Why isn't a fault just a particular kind of element?
[Chinthaka] +1
>>* Fault codes are QNames, not strings.  And in SOAP 1.2, we have
>>subcodes as well.

[Chinthaka] ok
>>* We should in general be using the SOAP 1.2 terminology for the API.
>>So for instance the header APIs for actor/role (currently on
>>OMHeaderBlock, which I want to call SOAPHeader) should be
>>getRole()/setRole() - if we want getActor()/setActor() as synonyms
>>that's OK too but the SOAP 1.2 versions should be there.  Same for
>>faultString/reason - should have getReason()/setReason() on OMFault
>>(which I want to be SOAPFault).

[Chinthaka] ok, I just got names from SAAJ API :(

>>* Related to the above, we should have relay and node accessors on the
>>SOAPHeader/OMHeaderBlock class.
>>* There are no APIs for getting pull events from OMElements yet?

[Chinthaka] Its there using wrappers. We can pass any OMElement to a
StreamingWrapper. For example OMStaxWrapper and can get StAX events from

>>* Namespace APIs seem like they need some work.  First off, an element
>>appears to only enable a single namespace (that of the element QName
>>itself) right now - if I add multiple namespace mappings to a given
>>element I would expect to see them serialized.  Second, it's nice for
>>the programmer if they can do things in terms of QNames, and have the OM
>>handle the namespace mapping stuff for them.  This goes along with the
>>fact that I don't want OM to be harder to use than the current Axis1.2
>>MessageElement APIs.  I want to be able to do:
>>QName qn = new QName("http://foo", "element");
>>OMElementImpl el = new OMElementImpl(qn);
>>...and have the system be able to serialize that as:
>><ns1:element xmlns:ns1="http://foo"/>

[Chinthaka] This is already in the api. For an OMElement u can add any
number of namespaces. 
public OMNamespace createNamespace(String uri, String prefix);

and it will be serialized properly. There is a SimpleOMSerializer, if u want
to check this.

>>* 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?

[Chinthaka] I think u don't have to type "impl" over and over again. U
always use a factory, and there exists a factor for each and every
Yes, there may not much of impls of OM. But we'd better keep the
flexibility, to improve OM. Remember we are greedy to have a better OM with
HIGH performance and LOW memory foot print.

Thankx and regards,

Eran Chinthaka
>>Thoughts appreciated.

View raw message