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

Bijan, Jeff:

> Suppose the PRINTADM has two operations, getPrinterInfo and 
> notifyPrinterRepairPersonOfProblem. The latter sends email to 
> a person. 
> What resource does PRITNADM manipulate? Is it the same as the PRINT 
> interface? Is it a printer?

This may seem an unsophisticated question, but from the point of view of the
service consumer, why do I care? I call getPrinterInfo(...) and I get info
based on the token I passd. I call notifyPrinterRepairPersonOfProblem(...)
and someone goes out and examines some hardware somewhere based on the token
I passed. I am puzzled because generally I don't want to know about the
service's back-end, since I'm not paid to look after it!

> Is this sort of grouping uncommon? Unlikely?

I suspect grouping of related methods to be quite common, and I suspect that
related interfaces will be grouped too. That's why multiple interfaces per
service was nice - it gave you the normal "print" interface and the
"management" interface at the same endpoint.

> Perhaps a more compelling example. We have PRINTADMforPrinterFoo, and 
> PRINTADMgeneric. Each contains one operation getPrinterInfo, 
> but in the 
> latter its parameterized to any of a dozen printers, 
> depending on which 
> id you pass it, but including printer Foo, Do these 
> interfaces have the 
> same targetResource? What is it? What exactly can we infer about them 
> sharing (or not sharing) a targetResource absent other information?

Again, from my point of view, I don't think it's relevant. Clearly I know
the right parameters to pass to get the info for a specific printer, so why
isn't this just a case of:

PRINTADMforPrinterFoo()
{
	PRINTADMgeneric("Foo");
}


PRINTADMgeneric(string param)
{
  if(param == "Bar")
  {
    ...
  }
  else if(param == "Foo")
  {

  }
  ...
}

So PRINTADMforPrinterFoo is just syntactic sugar. From an API perspective I
see two calls - one which matches the name of a printer that I know, and
another which allows me to specify from a list of printers. All this is
agreed at the application level where the printers are named. In that case I
see no need for targetResouce because I can capture the names of printers in
XML schema as part of the service interface.

> > So i'm afraid i'd vote to either keep targetResource as is (modulo
> > some wordsmithing which I don't think is needed since manipulate is 
> > adequately enough defined to be useful) or to remove serviceGroup.

Or rethink both if necessary. Does it make sense to expose the resources
from one administrative domain to another (which is how duffers like me are
bound to abuse targetResouce)? I have a real concern about sets of methods
which are somehow related, and I don't think it is nice to say they are
related because they manipulate the same "thingy" at the back end. 

I guess serviceGroup comes closest to this, but (perhaps naively) I always
liked they way that I could view the same component through different
interfaces. Is it just the case that the component view is too strong for
this environment?

Jim

Received on Tuesday, 15 July 2003 04:51:09 UTC