- From: Francis McCabe <fgm@fla.fujitsu.com>
- Date: Wed, 2 Oct 2002 09:52:49 -0700
- To: "Cutler, Roger (RogerCutler)" <RogerCutler@ChevronTexaco.com>
- Cc: "Doug Bunting" <db134722@iplanet.com>, www-ws-arch@w3.org
- Message-Id: <62549FCE-D627-11D6-82F9-000393A3327C@fla.fujitsu.com>
On Wednesday, October 2, 2002, at 08:31 AM, Cutler, Roger (RogerCutler) wrote: > OK, I can buy the idea of looking toward the future. Here are some > thoughts > that use this diagram as a starting point. I am happy to engage on this. > > 1 - I think that SOAP belongs in the right column, not the left, and > that it > deserves another row. I believe that row might be something like: The motivation for the columns was the classical operations/data split. On that basis, SOAP can be interpreted both ways: as an on-the-wire format for messaging and as a way of denoting APIs. I leave it to others to decide which is the `real' view. > > Message Transmission ........ SOAP, GET, Reliable Messaging +1 > > The next row up might then be > > Service Description ........ WSDL, natural language Perhaps Service Description (at the level of WSDL anyway) is a specification of an operational element and SOAP is a protocol. > > 2 - I think that the right column might more usefully be labelled > "protocols" than "meta-data". Perhaps the left row is "Service > Description" > or "Service Category"? There might be a place for an additional column, but descriptions and data formats are not the same thing as protocols. Data is transmitted, protocols are the rules of the game; this does get difficult to keep a hold of when the rules of the game require sending a string with HTTP 1.0 GET at the front of it :-) (Aside: another, more abstract/obscure kind of vertical line could be drawn as the object-level/meta-level distinction. This could be what is really going on; I need a little more time to consider that.) > > 3 - UDDI should appear somewhere in the right column, I'm not quite > sure > where. Possibly on the top row, which is very interesting because it > seems > to indicate that there is a need for something, currently undefined, > between > UDDI and choreography. Actually, I think that this might be a pretty > useful > insight. UDDI is a mechanism and IMO belongs on the operational side: it is a means of publishing and discovering. Its real thrust (again IMO) is that it represents a mechanism whereby automatic parties can find each other. I too was somewhat surprised when I realized that UDDI was a top-row element: the lesson being that being `higher' up does not automatically require it to be more complex or `smarter'. BTW I appreciate your engagement in this conversation; I do not pretend to have all the answers. (As I tell my 6 yr old son, no-one knows everything, not even everyone in the world altogether know everything.) Frank
Attachments
- text/enriched attachment: stored
Received on Wednesday, 2 October 2002 12:52:58 UTC