axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanjiva Weerawarana <sanj...@opensource.lk>
Subject Re: [Axis2] Sharing properties among MessageContexts
Date Thu, 25 Aug 2005 14:48:40 GMT
Hi Glen,

This was very carefully thought out .. the reason for multiple operation
context implementations (and OperationContextFactory) was because the
behavior of the operation context is dependent on the MEP. That is, when
a message comes in, its the operation context which has to figure out
which slot to put the message into in the MEP. 

So imagine the MEP is IN-OUT-OUT-IN. Then when a message comes in to the
operation (which you know by having a relatesTo which puts you into this
OperationContext) you have to detect from the message whether its in or
out and which one it is. 

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

Yes :). We already have that: see 
	OperationContext.addMessageContext (MessageContext mc)
	OperationContext.getMessageContext (int messageLabel)

> 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.

MessageIDs are UUIDs. So when a message comes in, we can use the
relatesTo messageID (if any) as a key to see whether there is an
operation context into which it fits. If there's no relatesTo, then the
message is a new one as far as the OperationContext is concerned. If
there are multiple relatesTo headers then they all better key back into
the same operationContext instance or the world is become flat again.

> 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.

Glen the 99% case for MEPs is going to be in-out or in-only. We *have*
to optimize that case. Doing a hashmap lookup for that is unnecessary. 

We *do* have a way to get at messages generically thru a
messageReference!

> 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);

Have this with an int key.

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

Definitely these are just cached; the current code has it like that
too. 

> }
> 
> 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.

The reason you need it is because when a message comes in, after the
operation context is found, the message is added to the operation
context using addMessageContext(). The *only* info avail at that time
for the operation context to figure out what message that corresponds to
in the MEP is the message and the current state of the operation context
object itself. So, if this is generic, then its impossible for it to
know what messageReference (using WSDL 2.0 speak) to assign to the given
message. 

I think I sent a detailed message explaining this when we did this. I
also commented OperationContext carefully. I hope this explains why it
has to be this way .. if not keep poking and maybe we got it wrong.

Sanjiva.


Mime
View raw message