Re: Raising an ugly issue again

Hi Anne,

I agree with you that a service is more than a single interface. To me
the best definition of a service is defined by a BPEL process:
    - it offers one or more interfaces to "clients" (partners, in BPEL
      speak)
        - some of those interfaces may be callback interfaces offered
          to certain clients (and BPEL allows one to indicate so)
    - it expects zero or more service to be made available to it,
      including some by the clients themselves

Unfortunately it was not possible to get such a rich description into
WSDL. While that may seem like a tragedy, I personally feel that's
ok .. the thing any given client/partner cares about is the
interface that that guy will interact with the service over. It
will of course care about callback interfaces etc. that it has to
offer to the service, but we'll have to resort to documentation to
indicate that in the WSDL at this point.

Part of the problem of course is that to implement many of these
scenarios you need WS-Addressing (or similar .. WS-MD). As you
know that WG has just started .. so it wasn't possible for us
to burn in a dependency on that yet.

I have been totally against continuing this WG as I would prefer
to see fundamental specs like XML, SOAP, WSDL not be revised.
(Yes errata is fine, of course.)  Otherwise the whole damned
stack has to be revisited .. witness the XML 1.1 and XSD 1.1
impact!

Would it make sense for WSDL 3.0 (gasp!) to consider a major
revision like a full fidelity service description capability?
Maybe .. but we'd need a hell of a lot more experience with
what that would need to look like first. In the on-going Axis2
efforts I'd like to try to incorporate some of these thoughts
into the deployment descriptors .. as that info is critical
to allow the runtime to do the right thing. Maybe in the future
that stuff will be ready for standardization. (No not the
deployment descriptor but the service description part of it.)

Sanjiva.

----- Original Message ----- 
From: Anne Thomas Manes
To: www-ws-desc@w3.org
Sent: Monday, November 01, 2004 4:44 AM
Subject: RE: Raising an ugly issue again


I respectively disagree. In case #1, how do I distinguish one "autonomous
system" (i.e. service)  from another "autonomous system"? I hope you're not
implying that I can deploy only one service per system. In case #2, I have a
clear way to distinguish one service from another.

An architecture is supposed to support use cases. I don't think the WSDL 2.0
data model supports identified use cases.

One use case is as follows - A developer wants to use a service. The service
exposes multiple interfaces: a couple of versions of its functional
interface, a management interface, and a metadata interface. As a developer
planning to use the service, he's only interested in using the latest
version of its functional interface. He doesn't need to interact with the
management interface or the metadata interface, or the older functional
interface. Therefore he needs a way to get the description of that specific
interface, and he wants to generate a client proxy that deals only with that
interface. Meanwhile, there's a distributed management system that wants to
manage this service - it wants access to the management interface, and not
to the functional interfaces. It wants to query the service using its
metadata interface to discover the management interface. It needs to have
some mechanism to associate the metadata interface with the management
interface. It may also need to interact with the functional interface,
depending on the constraints and capabilities associated with the interface.

The architecture needs a way to group related operations into an interface,
and a way to describe all of the interfaces supported by a service.

The "one interface per service" constraint tells me that WSDL 2.0 is an
"interface" description language, not a "service" description language. And
perhaps that's a reasonable approach. But we should call it WIDL rather than
WSDL.

Perhaps we need to take a step back and redesign the metadata description
model. Perhaps we need a higher-level service description language that ties
together all the metadata about a service - message descriptions (schema),
interface descriptions (WIDL), constraints and capabilities descriptions
(WSPL?), semantic descriptions (OWL-S/RDF), etc.

Anne




From: Peter Madziak [mailto:peter.madziak@agfa.com]
Sent: Thursday, October 28, 2004 2:35 PM
To: anne@manes.net
Cc: www-ws-desc@w3.org; www-ws-desc-request@w3.org
Subject: Re: Raising an ugly issue again


Anne:

>From an architectural perspective it seems to me that it is by no means a
clear cut decision between the following cases:

1.) Having one autonomous system that is exposing multiple services, one for
each of the aspects you refer to in your list, versus

2.) Having one autonomous system that exposes one service comprised of
multiple interfaces, one for each of the said aspects.

Also, a couple of points with respect to the versioning issue:

1.) The obvious ideal is to "extend" an interface as it evolves in a fashion
that does not break clients that are still "speaking to" the old version.
Although difficult, this can work with well-defined schemas (with
appropriate extension points, good usage of min/maxOccurrs, etc...) for your
request and response messages. In fact, this is the essence of the power of
loose-coupling that is at the heart of SOA.

2.) Since the previous "ideal" case doesn't always work, or is not always
done for a variety of reasons in practice, what I have found to work best in
practice is to point consumers at a completely new service for new versions
that are incompatible with previous ones. The real key is to make sure that
there is only one "autonomous system" behind the two services.

Peter

-------
Peter Madziak
Software Architect
Agfa HealthCare
ph: 519-746-6210 (2577)


 "Anne Thomas Manes" <anne@manes.net>
Sent by: www-ws-desc-request@w3.org
10/28/2004 10:59 AM
        To:        <www-ws-desc@w3.org>
        cc:        (bcc: Peter Madziak/AMIMQ/CAN/AGFA/CA/BAYER)
        Subject:        Raising an ugly issue again





I apologize in advance for raising this ugly issue again. Perhaps I just
don't understand the model well enough, and maybe you can explain it to me,
but I'm really concerned about the "one interface per service" constraint.

The SOA architecture requires that a web service expose multiple interfaces:
- its functional interface
- a management interface (WSDM, WS-Management, etc)
- a metadata discovery interface (WS-MetadataExchange, etc)
- an interactive interface (WSRP, etc)
- potentially others

I have clients that also require that a web service support versioning, in
which case the service will expose multiple versions of its functional
interface.

How does WSDL 2.0 support these basic SOA requirements if a service
definition is constrained such that it implements at most one interface?

Thanks,
Anne

Received on Tuesday, 2 November 2004 04:32:22 UTC