Well at I'm not the only one. ;-)
Traditionally I think I've used the term "application level transport", I think, for things like SMTP or HTTP.
Thinking in terms of end-to-end operations is a very useful approach, it's similar to the canonical data modeling we do to ensure safe interop between disparate services, but this time it's modeling for uniform (or governed) "intent". And I've been doing it for a while without really recognizing the theory and reasoning behind it (not having read Roy's thesis in depth until recently). In hindsight, I've wound up developing a company-specific WS-Transfer like coordination language on a number of projects over the years when using SOAP/XML (primarily GET, but once I also did "Update" and "Replace" which is similar to the distinction between POST v. PUT, to represent non-idempotent v. idempotent side-effects).
I'm also trying to apply this to how our (BEA's) AquaLogic Service Bus differentiates application-level operations, and it turns out that while we confused the term "transfer vs. transport", it still recognizes these are "application level" transports with implicit or explicit general operations. But we also do allow the more common operation selection algorithms to allow WSDL / SOAP Actions / WS-Addressing actions / custom headers to change the operation to a more specific operation and tunnel this through the underlying transfer protocol.
Stu
----- Original Message ----
From: Mark Baker <[EMAIL PROTECTED]>
To: [email protected]
Sent: Saturday, May 13, 2006 8:27:09 AM
Subject: Re: [service-orientated-architecture] Re: MQSeries vs. ESB
No, you're bang on. Certainly within the IT industry as a whole,
that's the case. But even within parts of the IETF, the terms are, on
occasion, used interchangably. That's the exception though, luckily.
(I'm reminded of a Jim Getty's - an HTTP/1.1 editor - presentation on
HTTP, where he referred to it as the "Hypertext Transport Protocol").
Ah, here it is;
http://www.w3.org/Talks/9608HTTP/
Unfortunately, despite the differences being widely misunderstood
(outside of the IETF), those difference are also essential to building
a loosely coupled system that can scale. It's no mistake, IMO, that
all the systems that have seen widespread use on the Internet have
used transfer protocols *as* transfer protocols.
Mark.
Traditionally I think I've used the term "application level transport", I think, for things like SMTP or HTTP.
Thinking in terms of end-to-end operations is a very useful approach, it's similar to the canonical data modeling we do to ensure safe interop between disparate services, but this time it's modeling for uniform (or governed) "intent". And I've been doing it for a while without really recognizing the theory and reasoning behind it (not having read Roy's thesis in depth until recently). In hindsight, I've wound up developing a company-specific WS-Transfer like coordination language on a number of projects over the years when using SOAP/XML (primarily GET, but once I also did "Update" and "Replace" which is similar to the distinction between POST v. PUT, to represent non-idempotent v. idempotent side-effects).
I'm also trying to apply this to how our (BEA's) AquaLogic Service Bus differentiates application-level operations, and it turns out that while we confused the term "transfer vs. transport", it still recognizes these are "application level" transports with implicit or explicit general operations. But we also do allow the more common operation selection algorithms to allow WSDL / SOAP Actions / WS-Addressing actions / custom headers to change the operation to a more specific operation and tunnel this through the underlying transfer protocol.
Stu
----- Original Message ----
From: Mark Baker <[EMAIL PROTECTED]>
To: [email protected]
Sent: Saturday, May 13, 2006 8:27:09 AM
Subject: Re: [service-orientated-architecture] Re: MQSeries vs. ESB
No, you're bang on. Certainly within the IT industry as a whole,
that's the case. But even within parts of the IETF, the terms are, on
occasion, used interchangably. That's the exception though, luckily.
(I'm reminded of a Jim Getty's - an HTTP/1.1 editor - presentation on
HTTP, where he referred to it as the "Hypertext Transport Protocol").
Ah, here it is;
http://www.w3.org/Talks/9608HTTP/
Unfortunately, despite the differences being widely misunderstood
(outside of the IETF), those difference are also essential to building
a loosely coupled system that can scale. It's no mistake, IMO, that
all the systems that have seen widespread use on the Internet have
used transfer protocols *as* transfer protocols.
Mark.
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.
