axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <g...@thoughtcraft.com>
Subject Re: [Axis2] Sharing properties among MessageContexts
Date Thu, 25 Aug 2005 13:41:52 GMT
Hi Chinthaka:

>> Along these lines, if we really want to support more than in-out MEPs, 
>> shouldn't we remove the inMessageContext/outMessageContext fields in 
>> OperationContext and replace them with a Map keyed by messageReference?
> 
> I think u have missed couple of mails sent earlier on OperationContext 
> stuff:).
> Let me explain the reason behind the current impl of OperationContext.
> What we actually could have done was to create an interface or an 
> abstract class for OperationContext and then implement/extend it for 
> InOperationContext, InOurOperationContext, etc., But we gave top class 
> support for IN only and IN-OUT MEPs in the impl and collapsed 
> InOperationContext and InOurOperationContext functionality to 
> OperationContext itself. This was done intentionaly.
> This will not anyway hinder the flexibility to support other/custom 
> MEPs. We do have an operationContextMap in OperationContext. One need to 
> extend OperationContext to provide support for other MEPs.
> So Glen, I think current OperationContext is fine, IMHO.

I'm not so sure.  I've just taken a quick look at the implementation of 
this stuff and have a couple of issues / questions:

First of all, the "operationContextMap" comes from the 
ConfigurationContext, and seems to be a map of messageID's (i.e. 
WS-Addressing message IDs) to OperationContexts.  So the 
operationContextMap isn't the same thing at all as being able to 
reference MessageContexts by messageReference (URLs for "inMessage1", 
"inMessage2", etc) from the OperationContext.  Am I missing something?
MessageID seems like an instance-oriented runtime thing, and 
messageReference (i.e. message label) is a more abstract concept.  I 
want to be able to write generic code that uses message references to 
get at MessageContexts without caring about the particular MEPs involved.

Second, the only reason I can see for having the 
inMessageContext/outMessageContext fields is to avoid doing Map lookups 
- in other words they are just a cache for the common case of in-only or 
in-out.  I can see that being reasonable depending on how many times 
they are going to be accessed, but a HashMap lookup shouldn't be that 
bad, and this might be a case of premature optimization.  Also, we 
should have a generic way to get at these by messageReference anyway, 
which we do not yet.

IMHO, we do need a map that goes from message name to MessageContext in 
any case, and if we want the fast optimized version that's OK too.  The 
APIs should be:

OperationContext {
     // Generic, works for any message reference
     MessageContext getMessageContext(String msgRef);

     // Optimized versions to get at the cached "common" ones
     MessageContext getInMessageContext();
     MessageContext getOutMessageContext();
}

I don't think we should need to subclass OperationContext for particular 
MEPs, either.  I can see how you could design it that way, but then you 
lose the ability to do generalized coding.

Thoughts?

--Glen

Mime
View raw message