Re: Asynchronous Web Services

"Newcomer, Eric" wrote:
> 
> Paul,
> 
> Actually I'm only looking to Web services to provide the technology 
> that allows the application level solution to be constructed.  
> It's enough that the XML applications in Web services provide a 
> technical solution to basic interoperability requirements.  
> I don't see any requirement to bridge application level 
> semantics, as perhaps there might be in the semantic Web activity.

We must not make choices that will later prevent the semantic web
activity from applying to web services. For example, SW statements apply
to objects with URIs, therefore the ws-arch should apply a policy of
naming all objects with URIs (as opposed to UUIDs as in UDDI or the
conversation IDs that I objected to in David Orchard's proposal).

Nevertheless, at a higher level, I want to see if I understand
the two different positions.

Door #1: Web Services are about lowering the cost of constructing
software systems very much like the ones we have today by standardizing
the protocol spoken by existing tools like databases, ORBs, MOM and
other back-end and middleware tools. I would say that in this view, WS
are essentially "DCOM done right" or "CORBA if we could just get
everyone to agree to use it."

Door #2: Web Services are about allowing individuals and organizations
(from departments of a single company to separate companies to
non-profits) to expose domain-specific functionality (typically business
logic) on the Internet or Intranet for automated consumption by 
customers, partners or related business units. I would say that in this
view, WS are essentially "the Web but for machine processing, rather
than eyeballs" or even "EDI done right."

Which door?

There is a strong tendency in the Web Services world to say "Yes" to
everything because at some level all of these problems are about
interoperability, networking and protocols. But many issues are
completely different in the two cases. If we have to pick one to
prioritize over the other, which will we pick?

I suggest Door #2. Web services should be a minimal extension of the Web
to automated processes.

The Web-as-we-know it is clearly about integrating organizations, not
gluing together components. Oracle (for example) is most often used as a
Web technology NOT through Oracle's web features but through their
traditional, historical SQL API/protocol interfaces. Many people use
Oracle for web systems without using the database as an HTTP server, and
I think that this is absolutely fine. The relational model is not the
same as the Web model because they are solving different problems. Vive
le difference. 

The same should hold for web services. If Oracle never implemented web
services in their database products, I would not care. If they did not
implement them in their "business software" (accounting, CRM, HR, etc.)
that would be a serious problem.

If one of the primary virtues of "web services" is "loose coupling" then
I cannot see how that advantage applies to the interface between a
program
and its database or TPM or ORB. Loose coupling to such a fundamental
implementation technology strikes me as almost contradictory. Business
systems are necessarily tightly coupled with the software used to
implement them!

Opinions?
-- 
Come discuss XML and REST web services at:
  Open Source Conference: July 22-26, 2002, conferences.oreillynet.com
  Extreme Markup: Aug 4-9, 2002,  www.extrememarkup.com/extreme/

Received on Tuesday, 23 July 2002 12:07:03 UTC