RE: Web Service Description and stateful services

> -----Original Message-----
> From: Newcomer, Eric [mailto:Eric.Newcomer@iona.com] 
> As Roger pointed out, we are often talking on this list about the same
> things using different terms, and about different things 
> using the same
> terms.  The normal case, I guess, without an agreed architecture...

> So all we have to work with is application state, and there are no
> standards for that yet.  But I think we should include this concept
> anyway in the WSA since as so many replies on this thread point out,
> it's something that will be necessary for many use cases.

why not approach this from a meta data point of view and define an xml language for defining state, that way we can use it when needed be it in the application, transport, or message level, instead of arguing 'where' state exists or doesnt exist....build ( define the xml ) and it will come ( be used ).....

also, I can already see many analogies with what has already been discussed with xml encryption and signature, with respect to embedding these types of tokens vie xml element encapsulation e.g. parts of an xml document may have a variety of 'states'...the soap header may contain tokens that are relevent to transport, the encapsulated message may hold state information on the 'document' state in the sense of workflow and business processes.

just my 2 pence.

cheers, jim fuller 






This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient please contact the sender immediately. Any disclosure, copying, distribution or any other use of this communication is strictly prohibitedand may be unlawful. Stuart Lawrence Marketing Communications Limited reserves the right to monitor and intercept communications for unlawful business purposes.

This also confirms that this message has been swept for viruses, although Stuart Lawrence Marketing Communications Limited accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this email or contents.

Received on Monday, 23 June 2003 12:28:30 UTC