I never said a message broker was SOAP specific.
a message broker that looks at a SOAPAction header isn't SOAP specific?
SOAPAction is a HTTP header - message brokers are HTTP/MIME aware,
including the ability to deal with HTTP/MIME extension headers, such
as SOAPAction.
HTTP and MIME are not the same thing. They do not have the same set
of extension headers, nor the same extension mechanisms, even if some
of the protocol elements have the same names between the two.
(this has caused a fair amount of confusion when MIME header names
were borrowed for HTTP but used with slightly different semantics)
They share a common set of media types, and not much more than that.
A message broker is not required to understand the
structure and semantics of a SOAP document.
I get that. But you're requiring it to understand HTTP headers, which
is worse.
what you are saying is that there are people out there who do not
understand
the value of clean separation of function between layers. how is that a
justification for a standards-setting organization to propagate that
misunderstanding?
Or perhaps there are people who don't understand message broker concepts.
How is what I've described all that different from inetd? Consider:
inetd dispatches on destination port number. destination port number
is *defined* as a dispatching mechanism for TCP and UDP.
what you're describing is like adding an IP option to provide an additional
means of dispatching incoming IP messages, when port numbers already exist
for this purpose. in the HTTP world, URIs already exist for the purpose
of dispatching incoming HTTP requests. to change this is to break HTTP.
What's unclean about this approach, it enables centralized administration,
single security domains, workflow management, a single "choke point" for
security purposes. The "handlers" are in fact separate and distinct layers
from the message broker.
it breaks compatibility with HTTP, it forces SOAP implementations to depend
on non-portable features of HTTP client libraries and proxies, it is not
portable across SOAP substrates, it is not reliable as a filtering mechanism
(meaning it's inherently insecure), and it doesn't work with encryption.
what's more, you haven't provided a single justification for making this
external to the SOAP protocol. if the SOAP protocol can't provide some
easily accessible tagging to facilitate dispatching within the SOAP world,
perhaps this is because some basic idea behind SOAP is inhernetly flawed -
such as that it's a good idea to use XML for everything, or that it's a good
idea to layer new protocols on top of HTTP.
Keith