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

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.


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
>
>
>

Received on Friday, 25 July 2003 06:06:40 UTC