Re: New Message: Comments on WSDL
- OK, first off there's no technical reason why dynamic languages can't
use WSDL (write and/or consume). I've seen pointers to solutions for
PHP and Perl, here's one for Python:
Note, most (maybe all?) of these languages already have mappings for
OMG IDL (CORBA). I know the Python mappings are pretty ugly, but they
do exist and can be used with CORBA and other ORBs, which are
significantly more hairy than WSDL.
WSDL and UDDI are basically attempts to strap on the infrastructure
that comes with CORBA. They're significantly easier to use than CORBA
(from dynamic OR static languages), but there's nothing really new or
earth-shattering about them (besides the Web Services(tm) meme...).
People have been doing RPC in various flavors for a long time now, and
XML can help with different aspects of that, which is cool.
Now, whether you *need* WSDL or UDDI is a matter of what you're doing
and what kind of tools you like to use. Like everything else in
computing the correct answer is "it depends." They are tools in the
toolbox and won't fit every problem. I'm not a big fan, but I know
they're there if I have a problem which fits.
A final point. Maybe Microsoft and IBM did create this in a smoke
filled room. That's how a lot of XML specs are getting written these
days. SAX was written by XML developers privy to the XML-DEV list
without consulting any standards bodies. These things all have their
place--if they're useful people will use them. Just don't believe the
hype (which applies to pretty much everything).
- Some completely personal opinions on some of the points mentioned.
I am not trying to be argumentative, but I am afraid I disagree
with many of the points you have made.
> It can only work in static environments such as Java and .Net and notThis one will always be a difficult area. There will always be
> in dynamic environments that are popular with Web developers, including
> but not limited to Perl, Python, PHP, and UserLand Frontier.
data impedence when trying to get dynamically typed languages
and non-dynamically typed languages working together. If you
make it all dynamic, then supporting staticlly typed languages
will be harder. Which is more important? Well, there is clearly
no single correct answer to that one!
I think you are trying to propose that instead of agreeing to the
type of data items being sent. Personally I think this is a very
bad model. It has the potential to greatly decrease interoperability.
It requires both the client and server to implement exactly the
same automatic type coercion rules or else undefined results may
occur. Eg: think about how many date formats there are. If its
sent as 1/2/01 from a US client to an Australian server, then
the US end may say its M/D/Y where as the Australia server will
say its D/M/Y. I think for interoperability its important that
at the protocol level, values are sent through with correct types.
Relying on the protocol to 'get it right' is dangerous when dealing
with multiple language implementations.
Note that the MS Soap toolkit dynamically loads a WSDL file from a
site then allows dynamically typed VBScript to talk to the site.
I have been using it without problem talking to a SOAP server I have
been developing. So I think your claim that "it can only work in static
environments" is incorrect. It may be that it works better in static
environments, but it is already working today in dynamic environments.
> Today WSDL is not a basis for interop. If there is interop it's onlyAgain, *I* belive this statement to be incorrect. There are many other
> between Java and .Net.
SOAP implementor tool kits using WSDL files. There is even a group
talking about doing some WSDL interoperability testing.
> There can be no significant support for this by independent developersAgain, I am not sure exactly who you are talking about, but there
> because it shuts them out.
are many SOAP implementors on the interop list who are using WSDL.
Its certainly not only IBM and Java. My toolkit for example
relies on WSDL files. I tried to do a purely dynamic approach,
but it failed (it was early on mind you) because not all SOAP
implementations sent adequate type information in the packets
(it was optional).
> Philosophically this faceoff is directly comparable to theAgain, I would have to disagree I am afraid. We develop large scale
> tightly-coupled and managed hypertext environments that were theorized
> before the loosely-coupled HTML-HTTP web came along, and wiped out all
> the theories.
web sites for organisations. We are not a big company - we are actually
a consulting group that is a part of a University.
We find the biggest problem that most sites have had is the loosely
coupled nature of HTML. The world is much better than it was here these
days, but we always strongly recommend against using HTML as your
native format for data where you have any reasonable sized site. We
always recommend using some format that can be rigerously cross checked
and managed. The loose nature of HTML is very bad for managing data.
Its great for user interfaces, but bad for data management. We always
recommend using some other rigourous, long-life mechanism for relating
information (IDs etc) and dynamically form the URLs from that.
So I am not sure what you mean by "wiped out all the theories". I agree
that the initial mad rush for the web ignored all the theoretical
background. However, I think most people developing large sites
acknowledge that using loosely coupled URLs directly is not the way
to go. It creates serious and real maintenance problems. So I would
use the analogy in the exact oposite way. To avoid all the problems
pepole have had with loosly coupled systmes such as HTML, put structure in from the beginning!
> SOAP alone, without the tight coupling promised by WSDL,Out of curiosity, who is 'widely deploying SOAP'? Its hard to keep
> is being widely deployed, without Microsoft and IBM. This must irk
> them. But don't thwart the spirit of the Web, it's still alive, in this
abreast of all the activities going on around the place. I am genuinely
interested in who is 'widely deploying' it, and what toolkits are
Personally, I find WSDL files horrible. I find them confusing,
difficult to understand, etc. However, the thing I like *is* the
static nature. Its a contract between the client and the server
about how to agree to communicate. You do not have to use a WSDL
file - but the static nature of data types is extremely valuable
as it stops all sorts of messy automatic data coercion problems
(eg: you sent me a float but I expected an integer, should I
round up or down or report an error?)