FoRKer questions on Web Services

Mark Baker distobj@acm.org
Tue, 07 Aug 2001 10:33:12 -0400


(oops, sorry Clay, forgot to CC FoRK)

Clay,

8/6/2001 11:02:30 AM, Clay Shirky <clay@shirky.com> wrote:

>#1 Possible Definitions of Web Services
>
>Below are three possible definitions for Web Services, ranging from
>the broad to the narrow. Do you agree or disagree with each of these
>definitions? How might you change them?
>
>  Web Services are an attempt to do for computing what the Web itself
>  did for publishing: to create a simple, loosely coupled method for
>  two arbitrary applications to communicate with one another.
>
>  Web Services are an attempt to define XML interfaces for
>  applications and business processes that can be exposed over the
>  internet.
>
>  Web Services are applications that have SOAP interfaces accessible
>  via http.

That seems a reasonable definition.  I like it because it doesn't exclude the non-RPC use of SOAP, though I'd still like to 
see SOAP optional because it isn't required in order to take advantage of HTTP.

The alternative definition, of spelling out Web Services == RPC, may be easier for many to grok.  It will also make my 
job easier later since I will only have to explain "Web Services failed", rather than "this type of Web Service" failed. 8-)

>-=-
>
>#2 Consensus Stack
>
>A "Consensus Stack" has arisen in much of the literature explaining
>web services to the public:
>
>    UDDI - Registry
>    WSDL - Description
>    SOAP - Encoding
>    http - Transport
>
>Obviously there are alternative technologies at every layer of the
>stack:
>
>    UDDI  -  ebXML
>    WSDL  -  ebXML  -  BPML
>    SOAP  -  SOAP with Attachments  -  XML-RPC
>    http  -  BEEP  -  SMTP  -  Instant Message
>
>as well as stacks with alternative layers, such as http/SOAP/ebXML.
>
>In your view, how prevalent will this consensus stack become?

Barely deployed.  Any stack built from the premise that custom interfaces are a good idea, is doomed to failure.

> Are
>there any layers at which alternative technologies will be able to
>co-exist better than others? Are there any layers where there will
>need to be a single industry-wide standard? Are there any layers still
>missing?

I like Aaron's stack.  WSDL & UDDI *may* have minor roles to play there.

>-=-
>
>#3 Programmer Interface vs Business Logic
>
>Much of the existing literature broadly addresses two different cases
>for Web Services. The first covers Web Services as RPC++, and
>concentrates on loose coupling, late binding, and application
>interoperability. The RPC++ Model is primarily addressed to
>programmers who may want to use Web Services as a tool for developing
>network applications.

I understand the desire for some to use RPC, but I cannot agree that RPC builds loosely coupled or late bound systems.  
Just the opposite in fact.

>The other case covers Web Services as EDI++, and concentrates on
>business logic, contractual specifications, and service descriptions
>and discovery. The EDI++ Model is primarily addressed to executives
>who would like to use the Web to automate some or all of their
>business processes.

Not sure what you're referring to here.

>Will these two models clash or complement one another?
>
>To take a specific example, the ebXML effort takes on some of the
>functions of WSDL and UDDI, as well as creating parts of the
>"Universal Service Interop Protocols" the UDDI group imagines will sit
>atop the current consensus stack. Will UDDI and ebXML co-exist, will
>they become different layers of a consensus stack, or will they clash,
>with Web Services efforts focused on application development adopting
>UDDI, and Web Services efforts focused on business process adopting
>ebXML?

I don't think that's a very interesting question, but I believe that UDDI and the ebXML registry work will find some way to 
work together.

>-=-
>
>#4 RPC: Nth Time's a Charm?
>
>The idea of using XML to define computing interfaces is the latest
>attempt to create a broadly supported standard for remote procedure
>calls, a computing idea primarily notable for its failure to become
>widely adopted in any previous version, such as COM, DCOM, CORBA, and
>RMI.
>
>Is RPC a good idea which has just been waiting for the appropriate
>technological incarnation, or will the difficulties which have stymied
>its general adoption remain true for Web Services as well? 
>
>If this is the advent of true, universally supported RPC, what effects
>will that have on the development environment? If Web Services will
>face the same problems that COM and CORBA did, what effect will this
>have on their adoption and deployment?

You know my answer to this one. 8-)

>
>-=-
>
>#5 Blue Sky
>
>For anyone thinking about the development of Web Services in the
>middle term -- 12 to 36 months -- what are the critical issues?

Scalability.

> What
>are the strengths and weaknesses of Web Services that will matter the
>most? What opportunities will Web Services be able to take advantage
>of in the coming years? What challenges will it face to its spread?

The biggest challenge will be for PR folks whose job will be to spin the "retreat" back to plain old HTTP, from XML-
RPC and SOAP/RPC, as one that was 100% expected and a good thing for their shareholders.

>And, perhaps most important of all, what do you know about Web
>Services that the rest of the world hasn't caught on to yet?

Muhahaha!

MB