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

RE: [wsdl] WSDL Interface Versioning and Overloaded Operations

Expand Messages
  • Aaron Skonnard
    ... It was there but completely undefined and unclear. ... Exactly. That s what the WG decided. ... It s up to the toolkit to do the right thing, which would
    Message 1 of 5 , Sep 24, 2002
    • 0 Attachment
      rjray@... [mailto:rjray@...] wrote:


      > But it was *already there*. They weren't FURTHER complicating
      > it by just leaving it in. They were removing functionality by
      > taking it out.

      It was there but completely undefined and unclear.

      > It seems to me that the responsibility should be on the
      > toolkit authors as to how to deal with overloading...

      Exactly. That's what the WG decided.

      > But if I can't specify overloaded methods in WSDL, how do I
      > express:
      >
      > func(Int, Int)
      > func(Some_Named_Struct)

      It's up to the toolkit to do the right thing, which would be to create
      distinct operation names.


      --
      Aaron Skonnard <http://skonnard.com>, DevelopMentor <http://develop.com>
      Essential XML Quick Reference available online in PDF format...
      <http://develop.com/books>


      History not used is nothing, for all intellectual life is action, like
      practical life, and if you don't use the stuff - well, it might as well
      be dead. - arnold toynbee
    • mglendin
      Bryon, I could not agree with you more! As the architect responsible for an extremely large commercial implementation of web services, and one that has been
      Message 2 of 5 , Sep 24, 2002
      • 0 Attachment
        Bryon,

        I could not agree with you more! As the architect responsible for an
        extremely large commercial implementation of web services, and one
        that has been in production use for over 12 months, I have become
        increasingly frustrated at the direction in which these technologies
        are moving.

        I tried unsuccessfully last year to convince one or two SOAP toolkit
        implementors to support overloading for exactly the kind of interface
        evolution problem you describe. But clearly the suppliers had never
        been responsible for building large-scale and highly distributed
        systems involving many separate business organisations, or they
        wouldn't have been so uninterested in creating any kind of solution!

        This is highly disappointing.

        There are at least two ways that a solution could be created: by
        allowing method name overloading as originally proposed in WSDL 1.1;
        or by taking advantage of XML Schema and supporting the <choice>
        element. Either technique would allow the creating of loosely
        coupled client/server interfaces, which I [perhaps naievely] thought
        was the whole purpose of web services!

        As it stands, the toolkit implementors and standards groups are
        effectively removing any advantage in using web services standards at
        all. Instead they are constraining the technology around their
        limited view of its applicability and attempting to create new
        solutions to old problems like wire message definition, naming &
        location, transactionality; ones that have been "solved" (to a
        greater or lesser degree) in things like CORBA and even ASN.1, OSI-TP
        etc.; and doing this badly [IMHO, of course!].

        Related to the WSDL name overloading issue, I really wonder whether
        any of them understand the distinction between a logical interface
        *definition*; it's *binding* in terms of a set of protocols and wire
        formats; and the way a particular toolkit allows code to be
        generated/used to implement either a client or server for that
        interface, and what API is then presented for this. Presently, I
        feel the standards group and most implementors are trying to combine
        these three aspects but are producing an overly rigid and inflexible
        system that forces tight coupling between clients and servers. We're
        reduced to what is pretty much ONC-RPC style distributed computing!
        This might be appropriate for small-scale deployments, or those
        within a single application or even enterprise; but in the larger
        domain - the one I thought web services were supposed to address -
        it's completely useless. We would probably be better going back to
        CORBA (much tighter semantics; transactional support; much more
        highly efficient wire message encoding; need I say more!).

        Anyway, enough of the rant, today we implement interface evolution by
        using separate XML namespaces, and separate service endpoints, with
        of course separate WSDL definitions. Rather crudely, we just
        incorporate the interface version number as a string in part of each
        of these elements (namespace, service endpoint). This works
        acceptably well from the client perspective, since a particular
        client will typically be built just to use a single version. But it
        creates rather a mess on the server side, where current toolkits do
        not allow us to easily construct a single implementation that can
        support multiple versions of interfaces that are only slightly
        different, for example through the addition of a single extra
        parameter or similar - you know the kinds of things you find out you
        need after the system has gone live! Rather than writing the whole
        server side from scratch, which would immediately negate many of the
        benefits of web services technology [namely, tool support], we use
        the toolkit to generate multiple versions of the top-level server
        implementations; which then act as simple adapters for a common lower
        level implementation.

        It works, but it's all rather inelegant, is hard-to-maintain and
        causes a profusion of service endpoints and XML Schema namespaces all
        over the place.

        I'd be interested in hearing if anybody has any better solutions that
        can be deployed with current web services technology.

        Regards,

        -Mike Glendinning, Independent Consultant (mikeg@...).

        P.S. My prediction is that the whole XML web services edifice will
        crumble or be swept away by something else within 2 years.

        --- In wsdl@y..., "bryondonahue" <bryondonahue@y...> wrote:
        > I appreciate the thoughtful comments on Operation overloading. But
        > operation overloading is a valuable interface versioning technique
        in
        > distributed systems. We often have servers, used by many clients,
        > that must, for example, add some new parameters to an existing
        > operation. In this case it impossible for all clients and servers
        to
        > simultaneously convert to the new interface. Operation overloading
        > allows the sever to deploy the new operation without impacting the
        > clients and allows the clients to use the new form of the operation
        > at a convenient time in the future.
        >
        > Overloading has been a valuable technique in CORBA systems.
        Interface
        > versioning has always been a significant problem in the CORBA
        world.
        > Does WSDL, particularly used in conjunction with JAX-RPC, offer any
        > interface versioning techniques over CORBA IDL? I'd love to hear
        your
        > thoughts on this topic.
        >
        > I know some schools of thought hold the view that when an interface
        > is changed it is a new interface and a new interface should be
        > created. I understand this view, but it is has a number of
        > operational disadvantages, new processes, URL, changes to builds
        and
        > code distribution, etc.
        >
        > Brryon
      Your message has been successfully submitted and would be delivered to recipients shortly.