Someone quipped:
>>Yes, but because the data, in the end, defines the semantics of the
>>operation, HTTP is really immaterial. It doesn't provide a bit of
>>extra anything to the applications overall ability to "work."
>>
>>
To which Patrick Logan replied:
>Tell that to the people who use a browser every day. See, a browser is
>this application that... Oh, you probably know what a browser is.
>
>
And I say, +1 and here, here. :-)
To ignore the contributions that an appropriate transfer / transport
protocol selection makes to a distributed system is, well, ignorant. To
briefly shed light on some of the variations in force, consider the
following. Is a given protocol stateless or not? Is it extensible or
not, and in what ways (method, headers, payload, etc.)? How verbose are
the messages being exchanged between actors? How 'chatty' is the
protocol relative to other options? What are the failure modes for the
overall system? What about their recovery mechanisms? Can it be easy
integrated with existing network and service / resource associated
security infrastructures? What are the available QoS guarantees?
The coordination languages community makes a distiction between
computation (the 'work' mentioned above) and coordination. The language,
or protocol, chosen to address the coordination aspect of a distributed
application has a significant impact on the overall system, albeit
relative to a different set of concerns than those of computation and
data representation. Both computation and coordination are equally
important from a systems point of view.
Best,
Elias
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/
