- From: Jacek Kopecky <jacek@systinet.com>
- Date: 21 Feb 2003 19:33:57 +0100
- To: "Amelia A. Lewis" <alewis@tibco.com>
- Cc: Martin Gudgin <mgudgin@microsoft.com>, Jeffrey Schlimmer <jeffsch@windows.microsoft.com>, WS Description WG <www-ws-desc@w3.org>
Amy, please see below. 8-) On Fri, 2003-02-21 at 18:44, Amelia A. Lewis wrote: > On 21 Feb 2003 18:20:05 +0100 > Jacek Kopecky <jacek@systinet.com> wrote: > > 1) Are WSDL MEPs from the point of view of the service? > > Everything in WSDL is from the point of view of the service, according > to Received Wisdom. In my opinion, the only thing that requires this > are MEP definitions. That's good, it's just unclear, what it means. 8-) > > SOAP MEPs (similar to what I would call abstract MEPs) are describing > > the message flow among a given set of nodes (two or more, usually). They > > Precisely two, according to the SOAP spec. AFAICS, the definition of SOAP MEPs doesn't say anything about the number of nodes: http://www.w3.org/TR/soap12-part1/#soapmep The two MEPs provided by SOAP spec do have precisely two nodes, but that is not a general constraint on SOAP MEPs. > > The attached image shows two options of what WSDL MEPs are. The SOAP MEP > > in the image (green/biggest box) has three nodes (to better demonstrate > > Not any SOAP MEP that I know of, and not legally by the SOAP spec, as > far as I know. I disagree, and I believe at least the intent is that SOAP MEPs be able to support more nodes than two. > > > my point), but the WSDL MEP can be understood to have the service and > > "the world" (blue/middle box) or only two communicating nodes > > (pink/small box). Now which ones were you doing? Which ones do we want > > to do? Which ones do we want abstract? > > I'm sorry. I realize that for most people, a picture is worth a > thousand words. To me, alas, a picture is just visual noise. In > other words, I can't make head or tails of a picture. Can you explain > it in words? The picture shows three kinds of notions, all of which contain message exchanges, so they could be named message exchange patterns. The biggest one (green) specifies a complex circular pattern with three nodes (one might call them roles, too). That's what SOAP MEPs are able to do (AFAICS). The middle MEP (blue) is a subset of the big one, and it's the subset of message exchange that a selected node is concerned about. It might be said that this MEP is the green one as seen from the point of view of the one node. The smallest MEP (pink) is a subset of the middle one, and it's the subset where one node (the client?) communicates with the node selected in the middle MEP (the service?). Both the middle and the smalles MEPs can be seen as having two roles - the service and the world for the middle MEP and the service and the client for the smallest MEP. I've heard in this WG before statements that seemed to say: why break up the middle MEP into two small MEPs if it's really just one MEP logically and since it's still from the point of view of the service? I can go both ways, but we have to choose one or the other. > > IMHO the smalles ones are interfaces, the middle ones are interactions, > > I dislike the term "interface", since it seems to imply RPC-ness, > which is only one of a number of network models that WSDL can (in > theory) describe. While interface does alude to RPC, I used the term as I believe it was initially conceived - the point where things connect. I don't know what else to use to describe the contract between exactly two roles (as interfaces do), so I guess I'll keep using it. > > > the big ones are systems. If we do interfaces, we do the smallest ones. > > Why does the term "operation" not fit somewhere in here? MEPs > describe operations, in the terminology to which I'm accustomed. The term 'operation' is applicable in all three: a system has operations, an interaction would be an operation, and interfaces also have operations. > > Also, I believe abstract MEPs should be the big ones; probably providing > > decomposition into both smaller types. WSDL MEPs would then reference > > the component MEPs, not just the whole big MEPs. > > Umm, a part of what the picture describes appears to be what I would > consider choreography. If the larger "MEPs" happen to contain control > flow, I think it falls irrevocably into the realm of choreography. I think my picture contains no more control flow than request/response contains. Is there anything else choreographish you'd ascribe to any of the "WSDL? MEP"s? > > 2) Was the Scottsdale decision meant to forbid more-than-two-nodes WSDL > > MEPs or was it just that this WG would not specify them? > > I don't know. I'd like to see a justification of a MEP with more than > two node roles, that doesn't include control flow (if/then). I > haven't seen one yet. > > I'll note that I consider several of the MEPs included in our document > insufficiently motivated. I'm in favor of attaching names, and > preferably providing example uses, for each MEP that we publish. > That's because I think doing so shows that the MEP represents a common > "idiom" in networking, and not just a for-the-sake-of-consistency > inclusion. Agree. > > > If such MEPs are forbidden, then surely we are doing the smallest MEPs. > > What you have written below seems to suggest this approach. > > > > If more-than-two-nodes MEPs are just out of scope, we would be doing the > > bigger (blue) MEPs. If so, cases with more than two nodes should still > > be considered so that we don't end up with something that makes > > describing/using such MEPs complex or impossible. > > *shrug* I haven't seen motivation for MEPs with more than two node roles. I think visible intermediaries should be describable with WSDL. A visible intermediary is a service, too, so you can't dismiss this again saying we decided WSDL is from the point of view of the service. 8-) But a visible intermediary does have the other side that logically belongs in the same operation but contains a third role. Again, I'm not saying WSDL must contain an intermediary MEP, but we must allow it. Best regards (and no hard feelings), Jacek Kopecky Senior Architect, Systinet Corporation http://www.systinet.com/
Received on Friday, 21 February 2003 13:34:01 UTC