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

Received on Thursday, 24 July 2003 20:38:48 UTC