Re: What it means to "get rid of MEPs"

David Hull writes:

> I think the main impetus behind wanting to "get rid of MEPs" is a desire 
to avoid redundancy between the WSDL notion of MEP and the SOAP notion.

I think it's crucial in all of this to consider how WSDL and SOAP work 
separately as well as together.  Whether WSDL will often be used without 
SOAP seems to be a subject of some debate, but there's no question that 
SOAP needs to stand on its own without WSDL.

The SOAP recommendation says:  here's what you have to do to be a 
conformant sender/receiver/processor of SOAP messages.  Basically it says 
that to network using SOAP you must:

a) Choose a binding and read the specification for that binding  -- 
implement what the binding says.  By the way, most bindings assert that 
they implement one or more MEPs, but that's not required.  The binding 
does what the binding does.  Maybe it does it in a way conformant to a 
SOAP MEP, maybe not.  Of course, if it says it implements an MEP it must 
do so properly. 

b) At any point where the binding receives a SOAP message, you must 
determine your role(s) as an intermediary or ultimate receiver and use the 
SOAP processing model on the message.  The binding may support a pattern 
that allows you to send dependent messages such as faults or responses. If 
so, you must use the binding as specified.  Typically, the binding spec 
defers to the MEP spec for these details.

Note that WSDL doesn't appear in this story.  It doesn't even matter if 
the software at the other end of the connection is WSDL driven.   All I 
need to know to network successfully is how to faithfully implement the 
binding, and to be sure I'm honest about which headers I claim to 
understand.

This is not an abstract concern.  While many of the organizations 
represented in the WG (including my employer) are building big, WSDL-based 
WS* implementations, those should in simple cases interoperate with much 
thinner implementations built in scripting languages, etc.  The latter 
need not and in some cases should not be WSDL-based.  Note that strongly 
typed interfaces like WSDL can be a bit unnatural when you have a 
dynamically typed scripting language.  This discussion has been going on a 
long, long time.  There was an interview that Steve Gillmor did with some 
of us in 2001 where this was discussed in detail.  Unfortunately, the 
original seems no longer to be on the Web, but Google found a copy in 
someone's email at [1].  Look for the line where Steve asks us about the 
Don Box "Brief History of SOAP" (you can just search for the word "Box) 
and read from there.   There's a great quote from Dave Winer where he 
says:

"If there's a difference between what the IDL says and what the app does, 
there's absolutely no question which way you do it--you do it the way the 
app
requires it. "

SOAP is an enabling layer for WSDL patterns in somewhat the same way that 
IP is an enabling datagram service for TCP streams and UDP datagrams.  The 
IP layer is one-way fire & forget.  UDP happens to duplicate that pattern 
at the next level up, and it is almost trivial in its restatement of IPs 
MEPs and mechanisms.  Nobody objects to the duplication because they 
understand the separation of concerns.  TCP is a much richer service, 
implementing its own MEP that is only indirectly related to, but very 
cleanly built on IP's.   Again, the fact that there are effectively MEPs 
at both levels is not a problem, unless you try to scramble them together. 
 One uses the other.  Period.

I think the analogy holds reasonably well.  You certainly should never 
need to read a TCP or UDP specification to implement IP, just as you 
>don't rely on the WSDL specification for implementing SOAP<.  Of course, 
if you know that some richer services will be built at the higher level 
(ReplyTo in the case of SOAP, streams in the case of TCP), you don't have 
to build them in the core.  Presuming that WSDL-based patterns are 
properly reflected in mustUnderstand headers in the SOAP messages (e.g. 
wsa:ReplyTo), then even software that is completely oblivious to WSDL will 
make safe decisions when receiving a message with the (e.g. ReplyTo) 
header.

Bottom line: let's make sure SOAP 

Noah

[1] http://www.xent.com/pipermail/fork/2001-July/002668.html

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Received on Thursday, 22 December 2005 00:42:17 UTC