Loading ...
Sorry, an error occurred while loading the content.

Re: New Message: Comments on WSDL

Expand Messages
  • delza@alliances.org
    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,
    Message 1 of 25 , Nov 6, 2001
    • 0 Attachment
      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:

      http://www-105.ibm.com/developerworks/education.nsf/webservices-onlinecourse-bytitle/D092605075D1D67D86256A7E0042432D?OpenDocument

      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).

      --Dethe
    • Alan Kent
      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
      Message 2 of 25 , Nov 6, 2001
      • 0 Attachment
        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 not
        > in dynamic environments that are popular with Web developers, including
        > but not limited to Perl, Python, PHP, and UserLand Frontier.

        This one will always be a difficult area. There will always be
        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 only
        > between Java and .Net.

        Again, *I* belive this statement to be incorrect. There are many other
        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 developers
        > because it shuts them out.

        Again, I am not sure exactly who you are talking about, but there
        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 the
        > tightly-coupled and managed hypertext environments that were theorized
        > before the loosely-coupled HTML-HTTP web came along, and wiped out all
        > the theories.

        Again, I would have to disagree I am afraid. We develop large scale
        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,
        > 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
        > venue.

        Out of curiosity, who is 'widely deploying SOAP'? Its hard to keep
        abreast of all the activities going on around the place. I am genuinely
        interested in who is 'widely deploying' it, and what toolkits are
        being used.

        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?)

        Alan
      Your message has been successfully submitted and would be delivered to recipients shortly.