Hi Jan,
[...]
>
> On Sep 22, 2005, at 4:27 PM, Spork, Murray wrote:
>
> > OTOH I share concerns that the REST coordination model ("hypertext
> > as the engine of application state") will not be sufficient for
> > complex process-oriented business transactions (as stated by Keith
> > Below)
>
> [this is a real question, not an attempt to be difficult]
>
> What do you have in mind when you say 'complex process-oriented
> business transactions'?
Good question - have a look at the "service interaction patterns" at
http://www.serviceinteraction.com/
> To me a transaction means (in the context of these discussions) a
> sequence of operations that somehow belong together. IMHO a
> transaction is essentially allways procedural (even if you call it
> workflow and express it in any of the BPxx languages). I
> think it is
> allways about doing this and that in such and such sequence.
> Having said that, what does the 'process oriented' add in your
> sentence? Are there transactions that are not processes (or parts of
> processes)?
At least what I mean by "process oriented" is that we make the process
explicit rather than implicit (which is what you get with REST,
tuplespaces etc.).
I think Keiths point about "long-running business transactions" is also
important.
> Regarding REST and its coordination model: I do not think that a
> networked system that follows the REST style does not allow
> procedural code to achieve certain sequences of HTTP method
> invocations - somewhere you gotta put your application logic. I see
> no contradiction between REST being an architectural style that
> constrains the interface of the components of the system and
> the fact
> that you have to have sequences of operations between the components.
Well - it boils down to "fitness of purpose" - we want to make it as
easy and as intuitive as possible for analysts/consultants/developers
etc. to express those patterns we commonly find in b2b collaboration.
Whether such a protocol (or language - what ever you want to call it)
could be implemented (layered) on top of REST is an very important
question because that will give us the anwser as to whether the current
web infrastructure can be leveraged to support b2b and networked
organisations.
> What REST's coordination model does is to decouple client and server
> in a way that they need to make no assumptions about each other than
> to agree on the same message type. They especially need not make
> assumptions about each other's state machine, because the
> server will
> communicate the next possible states that the client can proceed to
> AT RUNTIME via hypermedia links.
But they *do* make an assumption about each other's state machine do
they not? "Hypertext is the engine of application state". The question
is if those assumptions are sufficient for B2B coordination.
>
> Does your statement which I quoted above mean that you think
> that for
> complex transactions the components must know about each other's
> state machines before they engage in the transaction?
They must be able to coordinate their shared state - REST and
Tuplespaces encompass coordination models for doing just that. Those
coordination models are designed to meet explicit objectives - well at
least this is true in the case of REST. This is the "rationale" (or what
Fielding calls "properties") of the REST architectural style. The
question I want to answer is whether these properties are sufficient for
B2B. (I do not have an answer yet - only an intuition).
Murray
> ______________________________________________________________
> __________
> _______________
> Jan Algermissen, Consultant & Programmer
> http://jalgermissen.com
> Tugboat Consulting, 'Applying Web technology to enterprise IT'
> http://www.tugboat.de
>
>
>
>
>
>
>
>
>
> ------------------------ Yahoo! Groups Sponsor
> --------------------~-->
> Fair play? Video games influencing politics. Click and talk back!
> http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/NhFolB/TM
> --------------------------------------------------------------
> ------~->
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
------------------------ Yahoo! Groups Sponsor --------------------~-->
Most low income households are not online. Help bridge the digital divide today!
http://us.click.yahoo.com/cd_AJB/QnQLAA/TtwFAA/NhFolB/TM
--------------------------------------------------------------------~->
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
