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

[Greg Pavlik <greg.pavlik@oracle.com>]

Green, Alastair J. wrote:

Eric,

You sometimes seem to be demanding an answer and a solution before the problem has been identified and analysed. From this end it can feel like a forced march, with a known endpoint, and a known timetable. I hope I’m wrong, because good outputs come from chewing over inputs, not just respraying them.

 

I think this is particularly important with WS-CAF because it is the third attempt (BTP, WS C+T) to deal with the cluster of questions involved in coordinating the behaviour of stateful application services – and if it is going to succeed, it has to have proven advantage and added capability.

 

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.

 

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.

Alastair, I can imagine many different kinds of REST inspired mechanisms re-cast into SOAP, some of which would give us capabilities that are at least suggested by WS-Context. But does the fact that we can imagine an alternative mechanism for doing similar, useful things really say much about the current proposal other than that it may have real utility? Or are you saying that the derefrencing mechanisms in WS-Context are insufficient to meet use cases you have in mind?

 

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.

 

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

 

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.

 

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