OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf-editors message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ws-caf-editors] [Fwd: What does context-by-value mean ( was RE: [ws-caf] context block or one element per type)]


One solution would be to say that each ALS is free to implement whatever combination of protocols it wishes, and need not be an atomic (single) service as we tend to imply in the current text. However, the combination of ALSs within a single activity is still allowed, but the implications of that are up to the using services. So in the case of transactions+security, there's never actually been anything to date that would prevent someone having a single ALS that did both, and hence returned the compound context for both during begin/begun; it's just that so far we've always talked about two ALSs (security ALS and transaction ALS).
 
I think all we need to do is lay out the rules and make recommendations. Along the lines of:
 
(i) an activity may have multiple ALSs registered with it; how those ALSs interact with each other is outside the scope of the context service. Likewise, any required ordering of ALS interactions by the context service cannot be assumed (though may be an implementation added value feature).
 
(ii) an ALS can represent one or more service types for context augmentation (e.g., security+transactions). If there are dependencies between context elements (e.g., security must happen after transactions) then this is the recommended way of ensuring that in a portable manner: both services augment the context within a single ALS.
 
(iii) nested activities may have different ALSs associated with them. So for example a context may have a single transaction ALS and a nested context may have a single security ALS.
 
Mark.
----- Original Message -----
Sent: Friday, March 26, 2004 9:15 PM
Subject: [ws-caf-editors] [Fwd: What does context-by-value mean ( was RE: [ws-caf] context block or one element per type)]

In some sense, my comments are a different take on the same problem that Peter is driving at. Here again is the suggestion that having more than one ALS for an activity model (or such a beasty as an ALS as understood from the perspective of WS-Context at all?) is problematic.

I think we need to come up with a satisfactory solution to this problem in the next few days.

Greg

-------- Original Message --------
Subject: What does context-by-value mean ( was RE: [ws-caf] context block or one element per type)
Date: Fri, 26 Mar 2004 18:32:21 -0000
From: Furniss, Peter <Peter.Furniss@choreology.com>
To: Mark Little <mark.little@arjuna.com>, Greg Pavlik <greg.pavlik@oracle.com>
CC: Newcomer, Eric <Eric.Newcomer@iona.com>, ws-caf <ws-caf@lists.oasis-open.org>


So understood. It was only that your preparedness to entertain the alternative seemed to indicate different implications on the use of Context in general to what I had assumed was meant. (have I ever written a more tangled sentence ?)
 
My email wasn't really concerened with the issue on format - so I've changed the subject now, which I probably should have done before. Of course, if we were to abolish context-by-value as a soap header, the question evaporates.
 
 
Peter
 
 
-----Original Message-----
From: Mark Little [mailto:mark.little@arjuna.com]
Sent: 26 March 2004 17:43
To: Furniss, Peter; Greg Pavlik
Cc: Newcomer, Eric; ws-caf
Subject: Re: [ws-caf] context block or one element per type

Peter, I haven't had time to read your email fully, but since this has come up a couple of times in other emails I just want to make something clear: in my email I wasn't proposing we go one way or another in terms of context format. What I was trying to lay out was the issues that the editors has come across (with input from the Paris f2f) and the different possible routes we could take.
 
Mark.
----- Original Message -----
Sent: Friday, March 26, 2004 5:10 PM
Subject: RE: [ws-caf] context block or one element per type

Interesting.
 
I had assumed the usual way of dealing with representing contexts and the protocol-specific information would be as Greg describes - each context is a soap header containing the stuff for its (combination of) protocol and there can be multiple headers of base type wsctx:ctx. :
 
Mark's proposal startled me, partly because it raises a question about context as a whole, at least context-by-value (this is partly a reprise of some of the Paris discussion)
 
If it is possible for a compound context to be broken up, with its protocol-specific elements travelling in their own right, and a context element to define the relationship, then presumably one could do the same with simple (one protocol) context. In which case, what semantic is being carried by the context in that case? Is it needed as a header at all ? And then the same argument applies to a simple context in the normal arrangement  - if the protocol-specific content is intelligible on its own, what has been gained by putting it inside a context, in addition to making it a header ? This was one of my points in Paris - context-by-value is not needed
 
Of course, there is a semantic in the multi-protocol case : the context wrapper (or references in the context) mean "these two are to be considered together, in accordance with the rules defined in uri ....",  the uri being that of the context-type ( aka ALS-configuration-identifier, I think)
 
But that raises another question with these multi-protocol contexts: who is supposed to implement the combination rules ? The Context Service is, as I understand it, unaware of what the different context types mean - it just goes round all its enlisted ALS's asking if they would like to make a contribution. If it is unaware of different types (i.e. one could take a Context Service implmentation and use it with ALSes and a context-type that were unknown when the Context Service was written), then it can only have a very simple combination rule - put the stuff from each ALS in the context in an arbitrary order.
 
If anything more sophisticated is needed (order the requests to the ALSes, structure the combining of their responses) then the Context Service has to implement the combination, and the Context : ALS relationship is no longer the use-agnostic interface it appeared. And is it really going to be common that independent ALSes can just be combined without modifying the ALSes themselves ? It seems much more likely that the Context+ALSes group will be the implementation unit - in which case, separating them out in an interoperable way isn't really worth it.
 
Which in turn means there is no such thing as a general multi-protocol <context> element.  There are contexts (in the sense of soap headers on application messages that contain information relevant to supporting protocols/mechanisms) but their internal content is specific to the combination, in the same way as the content of a single-protocol context is specific to the protocol. And it we are back to considering why:
 
    <wsctx:context>
        <wsctx:type>uri_for_foo_and_bar_combination</wsctx:type>
        <foo:contextinfo xmlns:foo="foo_schema_uri"> ... <foo:data>
        <bar:data xmlns:bar="bar_schema_uri"> ... <bar:data>
   </wsctx:context>
 
is easier to cope with as a header than
 
    <foobar:context xmlns:foobar="uri_for_foo_and_bar_combination">
        <foo:contextinfo xmlns:foo="foo_schema_uri"> ... <foo:data>
        <bar:data xmlns:bar="bar_schema_uri"> ... <bar:data>
   </foobar:context>
 
 
As I mentioned, some of this was raised in Paris, but I don't remember a clear answer, and it would be good have it on the archive if I've forgotten it/failed to understand it.
 
 
Peter
 
-----Original Message-----
From: Greg Pavlik [mailto:greg.pavlik@oracle.com]
Sent: 25 March 2004 23:00
To: Mark Little
Cc: Newcomer, Eric; ws-caf
Subject: Re: [ws-caf] context block or one element per type

Attached find response to original mail from Mark in RTF.

Mark Little wrote:
Agreed.
 
Mark.
----- Original Message -----
Sent: Tuesday, March 23, 2004 5:17 PM
Subject: Re: [ws-caf] context block or one element per type

I suggest we have a statement explaining why context is useful with this structuring approach.

Newcomer, Eric wrote:
It might be no harm to include the context wrapper as an optional element (ignored by those systems that don't want to deal with it but used by those that can) to indicate ordering - where one may want to define an order of header processing precedence.
-----Original Message-----
From: Mark Little [mailto:mark.little@arjuna.com]
Sent: Monday, March 22, 2004 5:37 AM
To: ws-caf
Subject: [ws-caf] 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:
 
    <wsctx:ctx>
        <security>
            ...
        </security>
        <transactions>
            ...
        </transactions>
    </wsctx:ctx>
 
whereas normally you'd expect (because this is how the relevant specs. would define it) the context to be:
 
    <security>
        ...
    </security>
    <transactions>
        ...
    </transactions>
 
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:
 
    <security>
        ...
    </security>
    <transactions>
        ...
    </transactions>
    <activity-service>
        ...
    </activity-service>
 
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:
 
    <wsctx:related-to>
        <security>
            ...
        </security>
        <transactions>
            ...
        </transactions>
    <wsctx:related-to>
 
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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]