RE: "Uh, what do I need this for" (was RE: XML.COM: How I Learne d to Love daBomb)

[Michael Brennan <Michael_Brennan@allegis.com>]

> From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com]

<snip/>

> Also sprach Edd:  'Following the standard YAP pattern, acronyms and
> consortia
> followed: DISCO, WSDL, UDDI. Suddenly we're in the middle of a new
> wave of technology, another set of features, and nobody really seems
> to have asked, to say nothing of answered sensibly, the question: "Uh,
> what do I need this for?"'
> 
> In other words, Edd's critique (as I interpret it) is that 
> "standards" were
> proposed to solve problems before they were understood, and 
> people jumped on
> the bandwagon for these "standards" simply because everyone 
> else was.

I guess I'm looking at it a bit differently. I don't see DISCO, WSDL, or
UDDI as standards. They are open specifications being developed and pursued
outside of standards bodies as the parties involved try to understand the
problems better and validate that these proposals offer solutions of real
value. True, there is much marketing hype around them. But I think that's
difficult to avoid when you have these things being proposed and developed
in a very public fashion by vendors that are not only collaborating on these
technologies, but also competing with each other for developer mindshare.

> If there is a real need for machine-readable calling 
> information, maybe RDDL
> or something like it could be leveraged.  

That would be cool, although there are some gaps that would need to be
filled going this route. However, I would think an XLink-based mechanism
could conceivably be developed that could do everything WSDL does (at the
cost of far greater abstraction and generality that is likely to create a
steeper learning curve for developers not already versed in XLink).

> Or if WSDL needs to be invented,
> base it on concrete experience rather than conjecture about 
> what people might possibly need someday.

WSDL was motivated by concrete experience with early SOAP implementations.
For those who tried to develop tools that supported creating client side
interfaces that map to a specific service -- as any developer using CORBA,
EJBs, or COM is accustomed to -- it was clear that something like this was
needed. For the business developer who wants to write code dealing with
PurchaseOrders, Invoices, InventoryItems, etc., this offers obvious
benefits. Forgoing such domain-specific classes/structs/interfaces (or
whatever) in favor of generic DOM structures means less productivity, more
bugs, and no business benefit. That is a retrograde step. Forgoing these
domain-specific constructs in favor of dealing with DOM APIs to model this
information is like tossing away power tools in favor of the stone axe.

That's what's driving WSDL. As web services mature, very few programmers
using web services tools will be dealing with XML APIs (unless they want
to).