It strikes me there are two levels of problems here -- operations for network interoperability, and operations for binding to code that understands the message.
From a network interop perspective, there's some use in differentiating a small number of operations (GET v. POST v. PUT v. DELETE), as intermediaries can understand the implications for caching, idempotence, state, etc.
From a code binding perspective, it's dead simple and efficient to use a 1:1 mapping between a GED or "Action", but I see many cases where some kind of content-based routing picks "what understands the message". An XPath or XQuery driven dispatch table, for example, is something I see often. Or is it too much overhead to be anything but a special case?
Cheers
Stu
----- Original Message ----
Eric just finished saying that SOAP is supposed to encapsulate all the
information necessary to understand the message, in the message.
Surely the operation is part of that information, no? And if the GED,
SOAPAction, or wsa:Action doesn't hold it, what does?
From a network interop perspective, there's some use in differentiating a small number of operations (GET v. POST v. PUT v. DELETE), as intermediaries can understand the implications for caching, idempotence, state, etc.
From a code binding perspective, it's dead simple and efficient to use a 1:1 mapping between a GED or "Action", but I see many cases where some kind of content-based routing picks "what understands the message". An XPath or XQuery driven dispatch table, for example, is something I see often. Or is it too much overhead to be anything but a special case?
Cheers
Stu
----- Original Message ----
Eric just finished saying that SOAP is supposed to encapsulate all the
information necessary to understand the message, in the message.
Surely the operation is part of that information, no? And if the GED,
SOAPAction, or wsa:Action doesn't hold it, what does?
SPONSORED LINKS
| Computer software | Computer aided design software | Computer job |
| Soa | Service-oriented architecture |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
