Mark,
Sorry if that wasn't clearly stated. What I meant is that transport specific stuff is ruled out of the specifications by definition since they are intended to be transport neutral. It is true that the specifications also mention the possibility of taking advantage of transport-specific features, but this is at the implementation level, not the specification level. This is why SOAP Action was removed from the SOAP 1.1 spec for example, to ensure the specifications do not include transport-specific features. Can you use those features in your implementation? Sure, but the specs remain transport-independent, and therefore HTTP independent (etc.).
Eric
----- Original Message ----
From: Mark Baker <[EMAIL PROTECTED]>
To: [email protected]
Sent: Tuesday, June 27, 2006 3:58:27 PM
Subject: Re: [service-orientated-architecture] Re: SOA Reference Architecture
From: Mark Baker <[EMAIL PROTECTED]>
To: [email protected]
Sent: Tuesday, June 27, 2006 3:58:27 PM
Subject: Re: [service-orientated-architecture] Re: SOA Reference Architecture
> Anyway the point is that all Web services specifications are designed for use over multiple communications protocols. So HTTP specific stuff is ruled out by definition.
That's not true, Eric.
Supporting multiple protocols does not necessarily mean treating them
all the same (as if they were transports). It can also mean
supporting each one where it makes sense.
That, right there, is how the industry got itself into this mess. The
former approach fights an uphill battle against millions of deployed
software components (servers, firewalls, caches), while the latter
works *with* that infrastructure. This fight was over before it
began.
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.
