RE: [wsdl] WSDL Interface Versioning and Overloaded Operations
- rjray@... [mailto:rjray@...] wrote:
> But it was *already there*. They weren't FURTHER complicatingIt was there but completely undefined and unclear.
> it by just leaving it in. They were removing functionality by
> taking it out.
> It seems to me that the responsibility should be on theExactly. That's what the WG decided.
> toolkit authors as to how to deal with overloading...
> But if I can't specify overloaded methods in WSDL, how do IIt's up to the toolkit to do the right thing, which would be to create
> func(Int, Int)
distinct operation names.
Aaron Skonnard <http://skonnard.com>, DevelopMentor <http://develop.com>
Essential XML Quick Reference available online in PDF format...
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
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
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
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.
-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
> 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
> 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.
> versioning has always been a significant problem in the CORBA
> Does WSDL, particularly used in conjunction with JAX-RPC, offer any
> interface versioning techniques over CORBA IDL? I'd love to hear
> 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
> code distribution, etc.