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