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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-caf message

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


Subject: Re: [ws-caf] Agenda for the demo application


Title: Message
Peter, I think you missed the point. I realise you weren't at the first face-to-face, (and I've no idea if you'll be at the next one where I'm sure the demo app will be described), but this kind of discussion came up in Boston. It was also one of the original FAQ questions (can't say for sure if it's on the current TC FAQ though). One of the intentions of WS-Context is to try to provide a standard way of approaching context, rather than the ad hoc mechanisms that currently exist. For example, it would be great if WS-Security adopted WS-Context, for example; though whether that actually happens is a different issue entirely. WS-RF as another example may be able to utilise WS-Context.
 
An aim would be to provide a standard that allows existing and new uses of context to be more easily created and to work collectively. I find it strange to be going back over what the aims of this TC is, since we're 4+ (?) months into it, but: we'll define a standard context representation that all users will agree upon and can augment if required; the location of context will also be precisely defined such that it is no longer a hit-and-miss thing to be able to identify pertinent "context" information in a header or body. I don't think this is a waste of time and effort, and just looking outside of this TC neither do the various companies that we have talked to.
 
And with regard to my comments on the demo. application: as I said, I can see how context could be used in the way currently described, I just think that an alternative approach may well be easier to describe and understand.
 
Oh, and WS-Context can be used entirely by itself, i.e., without any ALS-es. It was designed to. Check out http://www.arjuna.com/library/reports/2003-08-12-GAF-v1_0.pdf for example.
 
All the best,
 
Mark.
 
P.S. If we're going to discuss the demo. specifically then let's take it to the separate working group.
 
----
Mark Little,
Chief Architect, Transactions,
Arjuna Technologies Ltd.
 
www.arjuna.com
----- Original Message -----
Sent: Thursday, February 12, 2004 1:46 PM
Subject: RE: [ws-caf] Agenda for the demo application

WS-CAFites,
 
The proposed demo application, and Mark's comments on it are very interesting as showing two different approaches by the author companies (who are to be congratulated on having such discussions in the open, rather than huddling away in a corner :-). But they raise a query I've had in my mind about WS-Context.
 
By design WS-Context can't be used completely alone - there has to be some additional specification known to the various parties - so in the demo application, the client and the retailers all know of the shopping cart application. Exactly what behaviour is required of them differs slightly between the demo as written and Mark's suggestions - but the client has at least to know that it has to put the context on the messages to the retailers, and the retailers to know they must make their supplying part of the cart.
 
The problem I have is that I can't quite work out what WS-Context adds that isn't already available in SOAP headers. The WS-Context-using shopping cart specification will be identified by a URI (the "type" in the context -this is probably the same as, or related to, the ALS-context identifier). A service receiving a context with that uri (or finding it after dereferencing a pass-by-reference context) will thus know what it has to do, as specified by the shopping cart spec: but that's all part of the shopping cart spec, and not WS-Context (especially if, as Mark suggests the shopping cart ALS offers its own service, with addToCart, removeFromCart).
 
Compare that with exactly the same shopping cart service specified using SOAP header, and able to generate a unique shopping cart identifier. The shopping cart specification defines a soap header, using the namespace uri to identify it's headers among all the other that exist. The header includes the URI of the shopping cart service and any other identifiers - in fact exactly the same information that it would need to specify as being contained in the context had it used WS-Context. A service receiving a shopping cart header does exactly the same things as one receiving a shopping cart context.
 
The demo app as described does have the Context Service doing more, but that seems to be what can be done with http anyway - the context identification URI labels a resource that can be fetched (get) or changed (put) (but no equivalent of post at ctx level).
 
The shopping-cart service is using the Context-service to generate the unique identifier, but that isn't difficult to do itself (and might well be counter-productive to take one in from the Ctx service, since if the shopping cart chose its own URI's it could put locally-meaningful (but externally opaque) information in them, whereas if the URI is given to it by a Context Service the cart service must indirect through a hash or whatever.)
 
To summarise:
 
What gain does a WS-Context-using specification gain from WS-Context that it could not have got from the combination of:
 
    - SOAP Headers, which identify, by the namespace URI which specification they refer to and can contain elements and attributes of use to that specification
 
    - HTTP Get, Put and Post which can fetch, set and modify a remotely-held body of information unambiguously identified by a URI
 
Good grief, I've turned into a RESTafarian !  
  
 
This isn't to say there might not be something in the higher levels of WS-CAF (I have thoughts on that too :-), but I have a suspicion that by the time you've generalised the context-layer sufficiently to make it general (i.e. to justify ws-context as a separate spec), there isn't anything left worth specifying. Yes, several things need to pass around identifications, and associated information and there are some protocol design issues that are worthy of summarising (e.g. rules about unambiguity must be precise, implications of id exchange) but there isn't anything worth making into a distinct protocol.
 
Peter
 
------------------------------------------
Peter Furniss
Chief Scientist, Choreology Ltd
web: http://www.choreology.com
email: peter.furniss@choreology.com
phone: +44 870 739 0066
mobile: +44 7951 536168
 
-----Original Message-----
From: Mark Little [mailto:mark.little@arjuna.com]
Sent: 11 February 2004 11:53
To: malik saheb; ws-caf@lists.oasis-open.org
Subject: Re: [ws-caf] Agenda for the demo application

I've attached comments to the document. As far as I can see, this still needs work. The architecture of the application seems to be a very strange use of context in general, and WS-Context specifically. Maybe this is a carry-over from the WS-I demo?
 
Mark.
 
----
Mark Little,
Chief Architect, Transactions,
Arjuna Technologies Ltd.
 
www.arjuna.com
----- Original Message -----
Sent: Monday, February 09, 2004 7:00 PM
Subject: [ws-caf] Agenda for the demo application

Hi All

 

I have attached the document explaining how the demo application can use the WS-Context.

The way the demo will use the other specifications will be provided later according to the schedule described below and that follow the following steps.

 

- Before a meeting we will produce a document describing the demo application using a particular specification (deadline 1 week before the meeting)

- During a meeting the document made previously available will be discussed

- Show a demo application with a particular specification (no demo for the Paris meeting)

 

In other words:

2nd meeting - Paris

- Before the meeting – we provide the demo application with the WS-CTX.

- During the meeting – Discuss the demo application with WS-CTX

 

3rd meeting New Orleans

- Before the meeting – produce a document of the demo application with WS-CF

- Discuss of the application with WS-CF

- Show the Demo Application with the WS-Context (described in the previous meeting)

 

4th F2F meeting (date to be determined) –

- Before the meeting – produce a document of the demo application with WS-TXM

- Discuss of the application with WS-TXM

- Show the Demo Application with the WS-CF (described in the previous meeting)

 

5th F2F meeting (date to be determined) –

- Show the Demo Application with the WS-TXM (described in the previous meeting)

 

Malik

 



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