On Sun, 2005-11-13 at 08:06 -0500, Anne Thomas Manes wrote:
> +1 to separating the programming model from the implementation model.
+1 in principle but let's remember the different levels of PMs we have:
- handler/module author: clearly needs the full MC as they need to know
the whole story of what's going on. For example the Sandesha module does
lots of fun stuff to work.
- message receiver author: needs at least the OperationContext and most
likely more as that's the way to have a service lifecycle (scope =
session/request/application stuff). Some of the stuff may not be needed,
however, its not practical to introduce yet another level of hiding for
that .. so needs the full MC.
- service implementor: We already have the option of giving a service
implementor just the SOAPEnvelope. If they want *more* than the
SOAPEnvelope, is it realistic to say that all they will need is the SOAP
envelope + the addressing concepts abstracted? (They already have the
XML version of the headers inside the envelope.) What about transport
info? Basically if you step beyond the SOAPEnvelope, its not clear to me
you can draw a line across just the addressing abstraction stuff.
Do you have a better idea of how to slice the PMs Axis2 has? Given the
above slices I'm no longer entirely convinced a SOAPMessageContext
concept has a sufficiently large constituent base to justify it. (?)
In any case, I think the addressing stuff can be brought closer to the
SOAP stuff in Axis2 with a bit of refactoring:
- o.a.axis2.om
XML Infoset representation
- o.a.axis2.soap
SOAP Infoset representation, extending OM
- o.a.axis2.soap.addressing
SOAP addressing concepts; basically the stuff we now
have in o.a.axis2.core.addressing (WSA version independent
addressing concepts .. should drop "wsa" from names!)
If we want a SOAPMC, then it'd go as o.a.axis2.soap.SOAPMessageContext
in the above structure.
Sanjiva.
