[wsia-comment] Viewpoints on Requirements from Two TCs

[Rex Brooks <rexb@starbourne.com>]

Title: Viewpoints on Requirements from Two TCs

Hi Everyone,

Please try to bear with me in this message. It is going to be lengthy. The object of this message is to examine the process of determining requirements from more than one viewpoint because I am leveraging the larger corporate base of participation in the WSIA to help me with the same process in the HumanMarkup TC.

I'll try not to ramble too much, but I think in a conversational manner or style, so it is somewhat unavoidable as a means both of explaining and focusing my thoughts. So much for excuses and disclaimers.

I am trying to arrive at an idea of where HumanMarkup ought to fit in the processes for which we are developing Use-Cases. And, more importantly, since it is shared with this TC, how HumanMarkup is going to be reliably delivered and updates will be delivered. As background, I suggest familiarizing yourselves with REST,  Representational State Transfer:  An Architectural Style for Distributed Hypermedia Interaction:

http://www.ics.uci.edu/~fielding/talks/webarch_9805/index.htm

And for a discussion from a source on the xml-dev list:

http://www.xml.com/pub/a/2002/02/20/rest.html

Now to catch up on the underlying issues:

I attended a local (West Coast) IBM PartnerWorld Solutions Center "Web Service Briefing Days" Seminar/Workshop last Monday, 2/25/02. I mentioned this in passing in the WSIA working session last Wednesday, 2/27/02, but did not follow up on the observations I made as a result of that seminar. It was not a part of the focused working session and I could only stay on the line for half an hour that day, so I was distracted and we were busy, but there actually was a point I wanted to make.

In regard to our work, what I learned in the seminar is that Web Services, as this set of tools are being presented to the developer community today, is concerned primarily with what amounts to our simplest Use-Case, Aggregation. Understandably, there is little thought to larger surrounding issues (understandable since we are busy inventing the tools to handle those larger issues here).

As currently configured, Web Services don't go much beyond a UDDI lookup with a resulting WSDL description, and some SOAP script to ask for a resource or data packet. That is the baseline we need to keep in mind, and address, as we move forward in depicting our Use Cases. The reason why I think this is important to keep in front of us is that there are processes and applications being developed at the usual breakneck pace in the rush to market using these current protocols now, in spite of, or in an attempt to capitalize upon, the current recessionary economic situation.

What this means is that the workhorse of the operation, SOAP, is being overloaded, and changed even as we carry on with our work. In case anyone here is not aware of it, SOAP, the acronym, has a new meaning, Services-Oriented Access Protocol, not Simple Object Access Protocol. So what? Acronyms come and go, but the point is, using a fairly apt metaphor,  the plumbing is being reworked even while we are trying to connect ever larger and more complex reservoirs into these pipelines. So:

Issue1: Do we need to take the ongoing development of Transport/Transfer Protocols into account in our Requirements? If so, how?

I ask you to think back to TV Raman's presentation on the Web Services Stack. It's been a whole month now, and the sand is shifting under us. That's another metaphor, of course, but I think we need to consider specifying our requirements in relation the two poles of the current situation with regard to the major protocols upon which our work must depend:

Pole +: our vocabulary MUST be independent of Transport Protocol so that it will work with anything; or,

Pole - : our vocabulary REQUIRES SOAP and HTTP as currently understood.

If you are following the discussions on xml-dev concerning REST, and you have followed the recent discussions on xml-dev and at large about HTTP you may have an inkling that the sands under us are capable of shifting even further.

Part of the reason why I framed this issue as the relationship with Transport/Transfer Protocol is contained in this article:

http://zdnet.com.com/2100-1105-845220.html

Since Don Box is one of the author's of SOAP, his assessment that HTTP is reaching the end of its useful life is not an opinion that can be easily disregarded. I mention this because it adds some spice to the mix.

Issue 2: Do we need to divorce our work from from the conventional RPC model for Web Services Transactions? If so, what mechanism or model should we adopt? We have EDI, and it works, but it is limited. It is,however, somewhat protocol independent.

I am not seriously suggesting that we abandon SOAP-RPC, but that we may not want to write our specification in a way that depends on it, or that can't survive a major shift away from it.

In addition, I think we need to have a liaison with the Topic Maps TCs in order to keep apprised of how these overlapping specifications will, or may, impact lookup for Web Services, since UDDI may, in fact, either end by using Topic Maps, or be superceded by Topic Maps.

This, of course, does not address what, if anything we ought to do about it just that we need to be aware of it.

I originally intended to include an Activity Diagram from Rational Rose that approximates some of what the WSRP presentation used, but it is unreadably small, and I am waiting for a copy of Visio to be delivered so that any diagrams I produce will use the same visual graphic notation as the rest of the TC's work.

Sorry for any excess verbiage. Obviously, I think it is important.

Ciao,

Rex

-- 

Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request