[
Lists Home |
Date Index |
Thread Index
]
Yes. As I said, I think it is more complicated than
just QOS at the level of fast servers. QOS is just a
number at one level made up of lots of different inputs
from different business functions. The negotiation of
business contracts will affect that, but even some high
level aspects of that are still amenable to web services.
I tossed that out because some people confuse the speed
of servers with the requirements to create desktop applications
that can share vocabularies loosely. A faster server
sending noisy information is still Crap At Light Speed.
Interestingly, it is how many portals, who uses which ones,
and what are the terms for granting use of a service by a
portal that are worth looking at. Should one, for example,
go to AOL to get public/government services? Should one
go to a government site? Both are probable solutions.
UDDI, WSFL, etc aren't orthogonal to the discussion of
models for web services. They are the models. They
take advantage of a natural human-derived architecture
for structuring the business processes of discovery,
engagement, negotiation, contracting, implementation
and performance to terms. They may not be the only
models, but I suspect they will dominate. The problem
at the moment is that just as this is starting, the
entire schema substructures are being reevaluated in
terms of a different layering at that level. While
technically a good thing, from the point of view
that some industries are on the verge of getting
down to serious work on shared vocabularies for
web service transactions, it pisses on the fire
and introduces hesitation.
Businesses are changing the way they do business
because of web services. It enables us to rethink
some of product strategies in a very fundamental
way, particularly, in the way we view competitors
and requirements for edge systems. It enables us
to rethink our data aggregation strategies, particularly,
the data warehousing architectures. It literally forces
us out of the foxholes into the no-man's land of
fast negotiations among loosely coupled business
agreements for single RFP bids. It will be a
bigger change than some might think. Marketing
and proposal processes have to evolve right up
front and some of the folks who are old hands
in the business are freakin'. Trust isn't their
strong suit.
UDDI is sort of a phonebook/businesscard/billboard.
len
-----Original Message-----
From: Michael Brennan [mailto:Michael_Brennan@Allegis.com]
Sent: Tuesday, February 05, 2002 5:39 PM
To: Bullard, Claude L (Len); 'Bill de hOra'; xml-dev@lists.xml.org
Subject: RE: [xml-dev] Categories of Web Service messages: data-oriented
v s action-oriented
> 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
|
