Re: Can someone recap the differences between @serviceGroup vs. definitions-targetNamespace ?

Thus quoth Sergey Beryozkin (~ 25-Jul-03 2:36 AM ~)...
> Hello,
> 
> Fred Carter wrote :
> 
>>Alternatively, one might wonder what the value of the <service> element
>>is?  It "groups" endpoints, but why?  The official reason for grouping
>>is left vague -- in WSDL 1.1, things with the same interface (nee
>>portType) where considered 'alternatives' (which I'd argue meant they
>>shared the same targetResource -- before it was an official concept);
>>in WSDL 1.2, they /must/ be alternatives [presumably] since they have to
>>have the same interface.
> 
> 
> So why don't have both multiple interfaces per service and @targetResource
> enabled ?
> @targetResource has been shown to have some useful practical applications,
> especially when used to associate alternative (probably independently
> developed) services.
> However, as a printer/admin example has shown, @targetResource can be
> overloaded, that is it can serve to group non-alternative services and
> express the fact that those services refer to the same resource.
> IMHO, multiple interfaces per service and @targetResource can nicely
> complement each other. Multiple interfaces per service can take care of
> grouping, while @targetResource can
> be used to provide alternative routes, in which case its value (URI) would
> very little to do with an underlying resource.
> I think that your examples (dental service for small/big compamnies,
> printing free of charge/for a fee) show where @targetResource can be
> practically applied. But they're really different from a printer/admin
> example, where a pair of service descriptions would have to be created per
> each individual printer. and where @targetResource would be used just as a
> means to create that kind of solution.

I don't particularly disagree.  As noted in earlier discussions, 
@targetResource would be useful in WSDL 1.1 (where >1 interface/service 
is allowed) to associate ports/services in different WSDL files.

> 
> 
> Thanks
> Sergey Beryozkin
> 
> 
> ----- Original Message -----
> From: "Fred Carter" <fred.carter@amberpoint.com>
> To: "Savas Parastatidis" <Savas.Parastatidis@newcastle.ac.uk>
> Cc: <www-ws-desc@w3.org>
> Sent: Friday, July 25, 2003 1:38 AM
> Subject: Re: Can someone recap the differences between @serviceGroup vs.
> definitions-targetNamespace ?
> 
> 
> 
>>Thus quoth Savas Parastatidis (~ 24-Jul-03 5:08 PM ~)...
>>
>>>Fred,
>>>
>>>
>>>
>>>>I agree completely.  While the serviceGroup is "more general," it
>>>
>>>misses
>>>
>>>
>>>>completely in providing the ability to express that some collection of
>>>>endpoints "manipulates" (works with, shares state with, etc.) some
>>>>underlying thing.  Having the ability to find an interface but be
>>>
>>>unable
>>>
>>>
>>>>to figure out which one to use seems to me to considerably lessen the
>>>>power of the standard.
>>>>
>>>>Amongst the points of Web services is to create interoperable systems
>>>>which can be assembled regardless of implementation technology.  Such
>>>>assembly requires the ability to determine interfaces, points of
>>>
>>>access,
>>>
>>>
>>>>*and* an ability to determine which of the alternatives with which to
>>>>work.  The ability to indicate this as part of a service's definition
>>>>seems critical.
>>>>
>>>>The general notion, separately, of serviceGroups is also powerful.
>>>
>>>*If*
>>>
>>>
>>>>there were a means (perhaps an extensible collection of @purpose
>>>>attributes, at least one of which is something like /underlying
>>>>entity/), then that mechansim would work as well.  But losing the
>>>
>>>means
>>>
>>>
>>>>to link endpoints (or collections thereof) to some named underlying
>>>>thing seems like a loss to me.
>>>>
>>>
>>>
>>>If we see a Web Service as a set of actions that represent the
>>>functionality an organisation wishes to expose to the world and those
>>>actions are performed on a consumer's request via a message, why would
>>>that organisation wish to expose any kind of information about the
>>>underlying infrastructure/resources used?
>>
>>I'm not sure it will necessarily wish to expose such a thing.  However,
>>1) it may, and 2) web services are not being used _exclusively_
>>externally.  Internal usage may need/want to be able to distinguish more
>>general interfaces from specific instances.
>>
>> >                                          Why would a service interface
>>
>>>be closely associated with a specific resource?
>>
>>I think it would not.  Thus, there are likely to be general interfaces
>>and (think /class/) and more specific resources (/instances/).  This is
>>precisely why, IMHO, some means for achieving this identification is
> 
> useful.
> 
>>>When I consume a service I am interested in the results of the
>>>operations rather than the underlying resources used to achieve those
>>>results. Interfaces that are coupled with specific resources, internal
>>>to an organisation, will result into tightly coupled distributed
>>>applications. Granted, interoperability will be possible because of XML,
>>>WSDL, and SOAP but the architecture will encourage light-weight
>>>components, tightly integrated instead of loosely coupled coarse
>>>components that I believe services should be.
>>
>>I don't think I disagree.  I don't think I'm suggesting that an
>>interface be specific to a resource.  Rather, I think that the ability
>>to link some collection of endpoints to a common underlying set of stuff
>>is useful.
>>
>>The printer/admin example has been done.  Personally, I haven't seen
>>anything persuasively arguing that the targetResource (or moral
>>equivalent) is not helpful.  Reasonable folks may (and, apparently, are)
>>disagree.
>>
>>For another, suppose there's some collection of interfaces to manipulate
>>dental insurance. There's one interface that is used to submit requests
>>for payment. There's another set used to perform audits, another for
>>patient inquiries, etc.  Now, my insurance company [appears to] have two
>>different systems -- one for little companies and another for big ones.
>>  The two are not linked.  [Reasonable software designers will point out
>>that this is suboptimal.  However, it's a fact, so it doesn't really
>>matter.]  Consequently, users have to know whether they should use
>>endpoints associated with urn:fredsdental:littleCompanies or
>>urn:fredsdental:bigCompanies.
>>
>>One can make an argument that they should design better software, but...
>>
>>>Also, for any kind of association between service interfaces or between
>>>a service interface and a resource we have RDF.
>>
>>That might be true.  However, I still think that there should be an
>>"official" mechanism for linking things up in the WSDL.
>>
>>Alternatively, one might wonder what the value of the <service> element
>>is?  It "groups" endpoints, but why?  The official reason for grouping
>>is left vague -- in WSDL 1.1, things with the same interface (nee
>>portType) where considered 'alternatives' (which I'd argue meant they
>>shared the same targetResource -- before it was an official concept);
>>in WSDL 1.2, they /must/ be alternatives [presumably] since they have to
>>have the same interface.
>>
>>>Just my 2c.
>>
>>I'll add another penny...
>>
>>
>>>Regards,
>>>.savas.
>>>
>>
>>Thanx/fred
>>
>>
>>--
>>Fred Carter / AmberPoint, Inc.
>>
>>mailto:fred.carter@amberpoint.com
>>tel:+1.510.433.6525 fax:+1.510.663.6301
>>
>>
>>
> 
> 


-- 
Fred Carter / AmberPoint, Inc.

mailto:fred.carter@amberpoint.com
tel:+1.510.433.6525 fax:+1.510.663.6301

Received on Friday, 25 July 2003 12:52:14 UTC