Re: [ws-caf] Why WS-Context-Simple? (was: RE: [ws-caf] Agenda for the demo application)

["Mark Little" <mark.little@arjuna.com>]

 

We in Choreology have spent a lot of time trying to figure out what is novel and useful in WS-CAF, i.e. what is necessary. Our fear is: that the context part is either trivial, or under-specified, or over-infected by the higher goals, and that the higher aspect of coordination is overly complex and subdivided.

 

This issue of the extra wrapper is a real, basic question, in our view.

See my latest response to Dale, which basically boils down to wrapper-versus-individual context elements (at least that's my intent).

I think that the pass-by-ref / keep-it-in-a-service seems useful, and I wonder whether a WSDL-defined form of the REST verbs would make that feasible in a WS world. This could be a useful outgrowth of this discussion.

Whilst I agree to a certain extent, I think that the timescales that we have given ourselves won't really allow us to examine this sufficiently. You only have to take a look at the now-closed WS-Architecture working group an W3C to see that pretty much annually there'd be a discussion about REST-versus-the rest of the world. If you really think we should go down this route then maybe there should be a separate issue about extending the deadlines?

 

I think that the idea of keeping shared context in a service (which seems useful) raises concurrency control issues in terms of updates, and I would like to examine those problems. The problem, taken to the limit, might invalidate the seeming utility of the idea itself.

Again I agree, but as I said in a much earlier email about that very subject, I'm not sure we have enough experience to confidently address the concurrency control issue in a 1.0 release. I'd prefer to see what kind of feedback implementing companies get from their users and feed that into a 1.x release, which more correctly addresses this issue. Obviously we can continue the discussion in this TC at any time, and maybe we're allowed to update WS-Context once it's "accepted" anyway, i.e., while we're working on WS-CF or WS-TXM. But I'd hate to see WS-Context delayed while we do, because that naturally has a knock-on effect on WS-CFand WS-TXM.

 

I think that the idea of a context having to have a lifecycle of states, and an outcome status, is interesting, and a potential justification for the separation of WS-Context, but I wonder if those states/statuses are so trivial (alive/dead, good/bad), that they will always either be ignored, or overwritten by more complex states and outcomes (as in the case of transactional outcomes).

That is a possibility, but I think they are tied closely into the model of activity=context, and to separate them or punt them up to a higher level would be difficult. However, this is definitely part of an already registered issue, so let's not confuse this one.

 I think that the idea of ALS registration possibly belongs “higher in the stack”: can we usefully factor out a general multi-phase protocol where the semantics (purpose) of the multiphase exchange are/is unknown? How much do ALS and WS-CF overlap in functionality (i.e. is there redundancy)?

 

You could put some of my thinking under the general heading: “artificial inheritance?”

 

I don’t feel certain or adamant about much of this, and I think these are real questions worthy of exploration. I think your thought-provoking work will be better served if you engage with questions or criticisms without being so urgent for issue-level solutions.

 

Unfortunately my plans to come to Paris for the F2F look like being derailed by the necessity to attend the WS Transactions workshop in Seattle, which has been unhelpfully scheduled for the same week. Otherwise, I would have welcomed the opportunity to discuss face to face. There is always the dead medium of e-mail, through which misunderstanding is so easy.

Yes, there has been some consternation surrounding this conflict, but let's wait and see how things fall out.

 

Mark.

 

Yours,

 

Alastair

 

 

 

-----Original Message-----
From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com]
Sent: 13 February 2004 13:57
To: Green, Alastair J.; Jim Webber; Furniss, Peter; ws-caf@lists.oasis-open.org
Subject: RE: [ws-caf] Why WS-Context-Simple? (was: RE: [ws-caf] Agenda for the demo application)

 

Alistair,

 

I have to say I have the same confusion and question for you after reading your email that I had for Peter. 

 

Could you please clarify a bit better what your helpful proposal is for improving the WS-Context spec?  I am having some trouble understanding it very clearly.

 

Thanks again,

Eric

-----Original Message-----
From: Green, Alastair J. [mailto:Alastair.Green@choreology.com]
Sent: Friday, February 13, 2004 8:53 AM
To: Jim Webber; Furniss, Peter; ws-caf@lists.oasis-open.org
Subject: [ws-caf] Why WS-Context-Simple? (was: RE: [ws-caf] Agenda for the demo application)

Jim,

 

I think you corner one of the issues being discussed very nicely. But I am not sure your answer to the issue is correct.

 

Your applications (chains of XML processors) do have to be "aware of every possible type of context that they might encounter". Have to be, in order to be able to usefully work (on security, on transactional control, on sessional data etc etc). There is no way round that “right royal pain”. It’s an irreducible part of the overall problem, and WS-Context doesn’t make it go away.

 

Here (reduced to its essentials) is one key benefit currently being described for what I think of as “WS-Context-Simple” (no ALS):

 

<SOAP-ENV:Header>

    <wsctx:Context>

    ...

        </myprot:MyContext>

    </wsctx:Context>

</SOAP-ENV:Header>

 

versus

 

<SOAP-ENV:Header>

    </myprot:MyContext>

</SOAP-ENV:Header>

 

So, as Mark points out in his thread with Peter, it comes down to the following:

 

Do I like to look first for the SOAP header, then for the contexts bucket, then for a context wrapper, and then for the specific context (i.e. I have a context processing "stream", even though it will have to despatch off to security, and transactions, and replication [if we actually have multiple concurrent contexts])?

 

Or am I happy to look first for the SOAP header, and then for the specific context element(s)? I.e. I have a SOAP Header processing “stream” which dispatches off to security etc etc.

 

The answer to this question derives either from taste, or from objective considerations. On grounds of taste, I don’t like the syntactic salt that these extra wrappers put in the way.

 

The only objective consideration being raised here is speed/convenience. It's faster/easier to track the contexts if I know where to find them. (Similar argument to SOAP headers: better to get the header stuff processed early, because it might vitiate processing the body).

 

In my view, there's a limit to the amount of header information I am typically going to have. It seems like a very fine foundation upon which to erect an edifice of standardization.

 

I have to have a security context processor anyway, I have to have a transaction context processor anyway, each of them is capable of parsing the Header, so why have a context processor get in the way by handing off one part of the header to the security context processor and the transaction context processor?

 

* * *

 

I do believe there is real value in the idea of passing-by-reference. I accept that the social fact of SOAP and WSDL means that the RESTful notion of operating on a naked URI is via the HTTP verbs is not a viable approach.

 

However, I wonder whether we would be better off creating a standard called WS-REST, which defined inserting, amending, reading and deleting any old document, at any old endpoint?

 

The absence of such a simple general facility doesn’t seem to me to justify creating an interoperable standard called WS-Context[-Simple], which is overloaded or narrowed by its association with the idea of “context”.

 

* * *

 

My final point is: there is more to say, because there is also something I think of as WS-Context-Advanced, which brings in ALS registration etc. I would like to address this in subsequent posts.

 

Alastair

 

 

-----Original Message-----
From: Jim Webber [mailto:Jim.Webber@newcastle.ac.uk]
Sent: 13 February 2004 03:35
To: Furniss, Peter; ws-caf@lists.oasis-open.org
Subject: RE: [ws-caf] Agenda for the demo application

 

Peter:

 

The WS-GAF proposal used WS-Context because it enables us to link

together services in an ad-hoc way withouth having to resort to ad-hoc

methods to do it. Sure we use SOAP headers (that's what the spec tells

us), but our services are all aware of the format of WS-Context

contexts, whereas it would be a right royal pain if we had to make them

aware of every possible type of context that they might encounter.

 

Perhaps therefore it is the demo application which should be altered?

There is little value in showcasing WS-Context for a single service,

since WS-RF is already optimised for that use case ;-)

 

Any thoughts Malik?

 

Jim