W3C home > Mailing lists > Public > www-ws-desc@w3.org > February 2005

Proposal for LC73/LC75n (multiple interfaces for a service)

From: Richard Hopkins <rph@nesc.ac.uk>
Date: Mon, 31 Jan 2005 12:19:58 +0000
Message-ID: <5D8E46F5AA2D8A428667B8787DEF216CB088AD@hendrix.nesc.ed.ac.uk>
To: "David Booth" <dbooth@w3.org>
Cc: <www-ws-desc@w3.org>, <paul.downey@bt.com>




Thanks, 

>From the draft minutes, it would seem that the issue is closed.

I'm sufficiently new to all this to not really have an opinion on
whether multiple interfaces is neeeded or whether the various propsed
"work arounds" are better.

What I would add, having scanned Roberto's proposal, is a use case in
addition to those he mentions of management interface and versioning.
It sounds like this issue is going to be discussed in the WSDSL 2.0
primer. 
Perhaps this third use-case might be mentioned.

This use case is pertaining to the proposed WSRF standards.
An application which provides two, intimately related, resource types,
e.g. files and directories.
A file has a different set of  resource properties than does a
directory, and a different set of operations.
Therefore there should be a file interface and a directory interface
supported by the application (since a port-type/interface has at most
one resource properties document).
(**By the end of writing this I have changed my mind on this use case. 
EPR-overloading, if that is recognised as not being an abuse of WSDL, is
probably as good as multiple-interfaces-for-a-service)

This use case is similar to the management/ordinary-use interfaces use
case, but sufficiently different to be worth mentioning explicitly.
A significant difference is that here the two interfaces could in
principle have the same operation name for what are syntactically
different operations (different logical message formats), since in
principle the resource-qualifier in an endpoint reference will
diss-ambiguate.

(My specific concern is that in a few weeks I teach a short course
"webservices and WSRF", and would appreciate any help in formulating a
story around these issues which is at least true and preferably
coherent.)
(I realise that the following is partly just part of my process of
thinking through the issue for myself)

Given that one service cannot have multiple interfaces, this
file/directory use case can be achieved by either - 
    1. defining multiple services with the same endpoint address (EPR
overloading)
    2. multiple services with different endpoint addresses, put into a
service group
    ........... ???

Amongst the problems with 2, if we take the WS-ServiceGroup draft as
being how we should do it, are -
The concepts of WS-ServiceGroup would seem to only make sense for
dynamic groupings, whereas here we have an entirely static grouping.
For (e.g. a registry) providing an endpoint reference to be used by a
client to invoke the application.
This EPR must point to the service group. A ServiceGroup itself is a
WS-Resource, so in theory this EPR should be a resource-qualified EPR!
That EPR then has to be used by the client to obtain two EPRs - one for
the catalaogue service and one for the file service. This can be via a
standard operation. The client is then carrying around these two EPRs.

For 1 (EPR-overaloading).
There are 3 interfaces (services) provided by the application, all at
the same network address -
fileSystem, file, directory.
As a collection of name/
A registry would return an EPR for the fileSystem service. 
This provides operations like "getRoot" which returns a
resource-qualified EPR pointing to the directory service (and possibly
its first-level structure as a set of name/resource-qualified-EPR
pairs). 
I.e only operations which do not depend on identifiying a particular
rsource instance. 

This would seem a generally applicable approach to the
multiple-resource-type scenario.
One System service, not resource-qualified.
Several resource-qualified services, one for each resource-type.
Arguably should apply this pattern to cases where (so far!) there is
only one resource type. 

 

Richard

> -----Original Message-----
> From: David Booth [mailto:dbooth@w3.org] 
> Sent: 28 January 2005 21:31
> To: Richard Hopkins
> Cc: www-ws-desc@w3.org; paul.downey@bt.com
> Subject: RE: Two logical WSDL documents describing the same service
> 
> (Thanks Paul, you beat me to it!)
> 
> Richard,
> 
> Though not official, draft minutes of last week's F2F are at:
> http://www.w3.org/2005/01/19-ws-desc-minutes.html#item02
> 
> Also, if you have an opinion about what you think the Working 
> Group should do, please speak up!
> 
> 
> 
> On Fri, 2005-01-28 at 12:04, paul.downey@bt.com wrote:
> > Richard
> > 
> > this issue has been the subject of much debate during the 
> life of the 
> > WG, and was discussed during last week's F2F:
> > 
> > [[
> > Single interface per service issues:
> >     - Issue LC73: WSDL Last Call issue [2]
> >     - Issue LC75n: WSDL 2.0 Last Call Comments [3]
> >     - Issue LC89k: Comments [4]
> >     - Roberto's proposal [5]
> >       Majority in favour of reopening?
> > 
> >  [2] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC73
> >  [3] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC75n
> >  [4] http://www.w3.org/2002/ws/desc/4/lc-issues/#LC89k
> >  [5] 
> http://lists.w3.org/Archives/Public/www-ws-desc/2004Nov/0094.html
> > ]]
> > 
> > I suggest you observe the outcome of this discussion (the 
> minutes have 
> > yet to be published) and if you have new information, 
> consider raising 
> > a separate Last Call comment (though officially the deadline has 
> > expired).
> > 
> > Paul
> > 
> > 
> > 
> > -----Original Message-----
> > From: Richard Hopkins [mailto:rph@nesc.ac.uk]
> > Sent: 28 January 2005 13:32
> > To: dbooth@w3.org
> > Cc: www-ws-desc@w3.org; alewis@tibco.com; 
> > Mike.Champion@SoftwareAG-USA.com; Downey,PS,Paul,XAGA C
> > Subject: RE: Two logical WSDL documents describing the same service
> > 
> > 
> > Hello,
> > 
> > I picked up on this thread from the document WSDL 2.0 
> Primer, 21 Dec 
> > 2004.
> > 
> > I was particularly coming from looking at WSRF proposal.
> > 
> > One would expect a service (in a loose sense) to manage 
> more than one 
> > resource-type.
> > E.g a file repository managing a file resource-type and a directory 
> > resource-type.
> > But a resource type is characterised by a resource-property 
> document 
> > An interface/port-type can identify a resource-property 
> document, but 
> > only one A service can have only one interface, and thus can manage 
> > only mange one-resource type.
> > Unless our repository service end-point has two WSDLs, defining a 
> > service for files and a service for directories.
> > 
> > Any comments on this?
> > 
> > Richard
> > 
> > ____________________________________________
> > Richard    Hopkins
> > Trainer    National e-Science Centre (Edinburgh)
> >            13-15 South College Street, Edinburgh EH8 9AA 
> > Email:     rph@nesc.ac.uk 
> > Tel:       +44 (0)131 651 4290
> > Fax:       +44 (0)131 650 9819
> > Mobile:    0788 7721 964
> > Home Tel:  +44 (0)131 555 3065
> > ____________________________________________
> > -------------------
> >  
> -- 
> 
> David Booth
> W3C Fellow / Hewlett-Packard
> 
> 
Received on Thursday, 3 February 2005 18:39:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:34 GMT