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

[snip]
> 
> I'm a bit surprised that @groups isn't getting trashed like
> @targetResource was. To me @groups is even worse at supporting the
> multiple interface scenario ..
> 

Since you are looking for people to object to the @groups idea :-)

I agree with Sanjiva that service groups are dynamic in nature and
shouldn't be part of an interface. Higher-level services and/or
specifications can do any kind of association between services. The
ontology people would argue that they are working on this.

Having said that, I don't believe that @targetResource is appropriate
for a service either. I believe it breaks encapsulation. Surely, an
organisation does not wish to expose one or more resources being used,
even if it's just URIs.

The problem is currently solved through multiple interfaces per service
and, I know I am being controversial here since so many people don't
like them, I think that this feature should not be removed.

I will bring the printer service example back into the discussions.

My printer service supports two interfaces. A print interface and a
management interface. Decorated with the appropriate policies the
interfaces are available only to the appropriate consumers (an
orthogonal issue).

Printer.com does not want:

1. Expose the printers being used (@targetResource).
2. Have different services (one for the print interface and one for the
management interface).
3. Have different services for every possible printer.
4. Predetermine the service groups in which the print service is going
to be a member of. That would be application specific. PrinterBroker.com
may wish to group all the services offering print facilities but
ManagementBroker.com may wish to group all the services offering
management facilities. Or, PrinterAnarchy.com may wish to group all the
services that DO NOT offer printer or management facilities.

Regards,
.savas.

Received on Monday, 14 July 2003 09:04:07 UTC