RE: [xml-dev] The Battle for Web Services

["Chris Wilper" <cwilper@cs.cornell.edu>]

Hmm..Hard to get specific without knowing the problem
they're trying to solve.  If you just want an opinion
on the kinds of technologies to go with in this kind of
situation, here's my current favorite list: WSDL for 
interface definitions, something XML-RPC'ish (as opposed 
to SOAPy) for messaging, probably a mixture of WXS and 
schematron for typing, shibboleth + pubcookie + ssl for 
enterprise authorization, authentication, and transport 
layer security, and something webdav-savvy for content
management.

-----Original Message-----
From: Bullard, Claude L (Len) [mailto:clbullar@ingr.com]
Sent: Tuesday, October 07, 2003 1:46 PM
To: Chris Wilper; xml-dev@lists.xml.org
Subject: RE: [xml-dev] The Battle for Web Services


You receive an RFP for a job to convert an existing 
enterprise of a type to an all services architecture. 

How do you respond (what do you propose)?

Open question to any takers.

len

From: Chris Wilper [mailto:cwilper@cs.cornell.edu]

> Is this article accurate? Is there any hope for the situation to improve?

Sure; people who make investments in new technologies are always gambling.

Companies interested in doing the WS-Thing would do well to limit the
investment to HTTP, XML, WSDL, and SOAP (in that order), steer 
clear of /WS-.*/ for a while and concentrate on what matters:
the *services*.

Take web data-mining.  Web scraping is alive and brittle in 2003.  
Not because of the adoption of or completion of UDDI, WS BPEL, 
WS-CAF, WSDM, WSDM, WSIA, WSRP, WSRM, WS-Security (or lack thereof).  
But for the simple reason that web-based data providers are still 
thinking only of one user-agent.  That's where the change needs to 
happen.

You know, Google and Amazon did some cool stuff.  XMethods has nice
listing of (mostly "toy") public web services.  But in large part, 
the useful "services" on the web are still HTML-only.