MHonArc v2.5.2 -->
wsia message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Subject: [wsia] Viewpoints on Requirements from Two TCs
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [Elist Home]
Powered by eList eXpress LLC