context block or one element per type

After thinking about the structure of context 
further, there was some concerned that the current structure may inhibit 
adoption by potential users of the specification because it does require a 
change to existing context structures (or at least to recipients of the 
context). If we take the case of an activity that has security and transactions 
involved, then the current format of that context would be:

 

<SOAP:header>

    <wsctx:ctx>

        
<security>

        
    ...

        
</security>

        
<transactions>

        
    ...

        
</transactions>

    </wsctx:ctx>

</SOAP:header>

 

whereas normally you'd expect (because this is how 
the relevant specs. would define it) the context to be:

 

<SOAP:header>

    <security>

        
...

    </security>

    
<transactions>

        
...

    
</transactions>

</SOAP:header>

 

We've said from the start that existing services 
should just be able to plug in to Context and be used as-is. If we take the case 
of ALSs then that may well be the case (the difference between the formats of 
context can be hidden from the individual ALSs by the context service). However, 
that's not the case for user-level services (those things that actually consume 
the context), because we would need to look for a mangled form of their 
current context structure in the WS-Context format. Is this is a big 
thing? Maybe it makes sense to differentiate WS-Context aware user-level 
services from those that aren't?

 

If we changed the structure to say that there wasn't an all-encompassing 
context "wrapper", then it does allow non-Context 
aware services to be driven within a Context activity transparently - they just 
can't tell the difference since the context structure is identical. However, we 
would lose relationship information and Greg put this quite well:

 

"For one thing, I've found these kinds of non-nested relationships in XML 
to be awkward to work with and somewhat non-intuitive -- this is how the EJB 
spec structured that transcation attributes, for example, and I must say as an 
implementor I hated it."

 

If we were to change the structure of context so 
drastically (and I'm not convinced that it's required), I'd suggest we keep 
the basic context data element from the original context, but have it as a 
specific element. So:

 

<SOAP:header>

    <security>

        
...

    </security>

    
<transactions>

        
...

    
</transactions>

    
<activity-service>

        
...

    
</activity-service>

</SOAP:header>

 

A side-effect of such a change is that we'd lose 
the automatic nesting structure of the context. However, how services (ALSs) 
deal with nesting in their own context element is up to them. The problem comes 
if there's a required relationship between the various contexts (e.g., 
transactions only belong to the lowest-level child in a nested activity.) I 
haven't had a chance to fully think the implications of this change through yet, 
but I suspect we could either punt on this to the respective specifications, or 
provide some related-to schema element:

 

<SOAP:header>

    
<wsctx:related-to>

        
<security>

        
    ...

        
</security>

        
<transactions>

        
    ...

        
</transactions>

    
<wsctx:related-to>

</SOAP:header>

 

with attributes that allow you to specify where 
within a nested hierarchy a specific context element applies. But this looks 
complex.

 

Mark.

 

----
Mark Little,
Chief Architect, Transactions,
Arjuna 
Technologies Ltd.
 
www.arjuna.com