[
Lists Home |
Date Index |
Thread Index
]
> From: Bullard, Claude L (Len) [mailto:clbullar@ingr.com]
<snip/>
> Basically, virtual, yes? One doesn't care how it is done, just
> that the interface contract is understood.
At a purely technical level, yes. However, this interface contract will in
many cases also occur within the context of a real world business contract
that addresses things other than simply what XML messages fly back and
forth.
> After that, the worry
> is QOS. (See why Red Hat believes Linux will win on the Internet.
> http://dailynews.yahoo.com/h/zd/20020204/tc/q_a_red_hat_ceo_sa
> ys_linux_won_t_rule_1.html )
> If they are right, then using a QOS determinant, one could
> theoretically
> search for a service, hook up, test, and if the service QOS
> numbers are
> high enough, the Linux servers would win and in a matter of
> days or hours,
> all of the MS server lights would stop blinking (basically the
> same phenomenon as hits on an overbuilt slow web page).
For services just looking for a stock quote, or something similar, this
could work. Perhaps there will even be services engaging in one-shot
transactions in this manner. However, I strongly doubt that much involving
business transactions will work this way within the forseeable future. I
don't think the marketing and business development folks are going to stop
forging partnerships and making deals, and let their decision making
authority take a back seat to algorithms. Businesses are not going to
fundamentally change the way they do business because of web services, and
QOS will be a consideration but will typically take a back seat to other
business concerns (such as the advantages an agreement offers within the
context of larger business strategies). Web services become simply an
optimization. Eliminate the paper trail and automate business transactions.
But they will mostly (or at least often) occur within the context of
business agreements negotiated by humans.
> I'm mystified if there is a point to the thread.
> UDDI, WSFL, etc. are there so that web services
> can work like this over standard plumbing.
This thread seemed to me to start as just a discussion over categorizing
useful architectural models for web services. These models are conceptual
models that are orthogonal to things like WSDL, WSFL, etc., which focus on
the protocol layer and syntax of messages -- or even UDDI which starts to
introduce taxonomies (though I haven't delved very deeply into UDDI, so I'm
trying to avoid making too much comment on it). They are the antecedents to
design patterns for developers who must make decisions on how to design and
implement a web service. That's how I've viewed it.
Of course, like most threads on this list, the discussion has journeyed
pretty far afield.
> The trick is simply knowing a target that does what you expect it to:
> ontological commitment, as the AI guys say. Hook up and if the
> other side defects, defect as well. If it really works like
> the Red Hat CEO claims, ecological effects will kill off the
> slowest runners.
>
> I don't think it works quite as he describes, but that is a
> different issue. There are few pure plays in business.
>
> len
|
