[
Lists Home |
Date Index |
Thread Index
]
>But, I still don't understand the key driver for the web services initiative.
It may be that some people prefer the idea of a tightly coupled, limited
access Internet application. Let's not call that "the Web" because
however we define that, I think it is clear to anyone who reads TimBL's
or Fielding's work, that is NOT what they have in mind. I brought up
the Dexter model to point to where some of these terms originate and
to point out that these folks also had things in mind. So we can't just
point backward wistfully and say, "ah the Torah says" because it is
interpreted for its time. We have to know what we need in this time.
>The REST folks have made a good case, IMO for one kind of 'web service'.
Absolutely. The document-as-linked-resource with named links, a functional
resolver, all of that, supported by a global namespace makes all kinds of
sense for globally associating all potential resources.
As Paul says, I am an old hypertext guy and this is the model
I know best how to use. But do you think that the definition of hypertext
is "controls in content" and that hypermedia only adds "multiple content
types" and distributed means "on a network"? If so, we still can't get
around in either approach, the gruntwork of standard vocabularies.
Whether we call a function or send a URI, we still need that, don't we?
>Published articles/tutorials discuss 'web services' which are very simple in
>scope. Maybe these stockquote examples are simple helloWorld with a different
>name, are a red herring, and the *real* requirement is for automated, orchestrated
>business processes across the 'net. Another kind of 'web service'
When I went to my first Hytime meetings, it was to get a synchronization model for
orchestrating business events. I thought it would be done both gesturally and
by a common clock model. Only as I got deeper into the problem did I truly
understand the scattering effect of latency on real-time and begin to see that
only the gestural model is workable at scale and in the face of unlimited amounts
of noise. So yeah, I think those are overly simplistic models and that web
services for large scale enterprise processes are driven by coarse-grained
gestural documents (speech acts if you like). To me, a getRFP isn't too
much different from http://mything/getRFP (except that as I type it, my editor
turns the second one blue and makes it clickable (is hypertext "Controls in content"))
as long as I can map one into the other without loss of information.
Again, is identity an intrinsic property or one derived by resolution? It
seems like phil and I think it actually is. They are both functions when
being resolved and properties when being described.
>If so, are limitations in HTTP really the main barrier to seeing those get deployed?
I don't think so. I think creating and sustaining two way pipes may affect some
applications that need stateful persistence. What would these be? Command and
Control in near real time?
>Here's a thought experiment. Lets say that Amazon decided to do away with
>its HTML user interface, and produce an XML one. (I read somewhere they'd
>turned a profit, so they must have some cash :). Exactly the same site structure,
>pages, facilities, etc. Just an XML interface. Is this a web service?
I don't think so but a service is as a service does.
>If, as I suspect -- and I think you've said as much recently -- the devil
>is in the orchestration, then where does all this effort on WSDL, SOAP, etc, etc.
>help? The cynic in me says it doesn't[*]. The technology people are doing
>what they do best -- make technology -- while the business people are wondering
>how/if they want to revolutionise their working practices.
They will not revolutionize anything until they agree to an interface and
a message. We can't get away from standard vocabularies or can we? It may be that
all the RPC does is make it less standard, more specific, and the interface more private.
Some folks do want that. Consider that standards have a way of flattening
out performance gains, opportunities to be just a bit more responsive than
a competitor, and profit. Remember: while everyone remarks on how HTML made browsers
ubiquitous, it also made them unprofitable to design and sell. The "Net"
effect of that was to deliver them into the control of the only company
that could afford to do that. That Mosaic would be relegated to a curiosity
and Netscape, a division of a major was so blindingly obvious only their
inventors couldn't see it. The experienced people did.
len
|
