OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] Categories of Web Service messages: data-oriented v s acti

[ 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.  


-----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]


> 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

> 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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS