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

On Tuesday, July 15, 2003, at 04:51 AM, Jim Webber wrote:

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

If if so, it seems to me like a right question.

>  but from the point of view of the
> service consumer, why do I care?

I don't think you should :) I *think* targetResource encourages you 
too. Certainly the service description author ought to. And if it's in 
the WSDL, it seems like the service consumer *should*, at least some of 
the time, at least want to care :)

> I call getPrinterInfo(...) and I get info
> based on the token I passd.

Whoops. getPrinterInfo has no parameters. So, callit 
getPrinterFooInfo(). That way, PRINTADM does have a definite printer it 
targets.

>  I call notifyPrinterRepairPersonOfProblem(...)
> and someone goes out and examines some hardware somewhere based on the 
> token
> I passed.

Only thing you pass here is the problem description.

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

The question is, as I understand it, imagine you have 40 printers, all 
web/web services ready. Each has a pair of WSDL files with operations 
hardcoded for their specific printer. How do you relate the two files 
corresponding to each printer?

(There has to be a better description for the problem.)

>> Is this sort of grouping uncommon? Unlikely?
>
> I suspect grouping of related methods to be quite common,

E.g., A Service! :)

>  and I suspect that
> related interfaces will be grouped too.

In this particular targetResourcey way? Or in various sorts of groups?

>  That's why multiple interfaces per
> service was nice - it gave you the normal "print" interface and the
> "management" interface at the same endpoint.

Well, and it can give you completely unrelated interfaces (say, the 
"print" and the "post to my weblog" interfaces).

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

You do? Say you've been using PRITNADMforPrinterFoo (eek, sorry for the 
icky names) all along. There's nothing that would necessarily give you 
the id that PRITNADMgeneric would consume.

>  so why
> isn't this just a case of:
[snip code]

It might well be, but it doesn't have to be. I guess the point would be 
is that you might want to know that these two interfaces talk to the 
same printer? You keep starting from the pov of *knowing*. So I have 
one of the WSDL files, how do I (automatically?) tell that the other is 
relevantly similar?

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

I think I agree.

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

I think someone like Jeff would argue that this is too arbitrary or 
tedious compared to just comparing targetResources. If the case is 
common enough, the a little extra support *doesn't* seem unreasonable.

>>> 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 worry strongly about this ;)

> 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 share that concern and worry. I'll note again, that afaict there's a 
problems about the relationship between operations in the same service.

I mean, is a Service supposed to be more like an object or a library, 
with the intuition that methods associated with an object are primarily 
concerned with manipulating the state of that object (or the state of 
other objects access through my home object). This doesn't really get 
strong semantic coherence, but ok, we can explain this. With a library, 
I'm just grouping a bunch of functions in a convenient package.

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

You could, but that semantics was entirely extra-WSDL. See: 
http://www.w3.org/TR/2001/NOTE-wsdl-20010315#_services

You get to see multiple ports of the same portType as semantically 
equivalent, but that doesn't entail that the operations therein 
manipulate the same components (imagine a grab bag utility library 
which has a Pascal and a C implementation). Multiple portTypes don't, 
themselves, have any suggested relationship, it's just noted that it's 
handy when they *are* related in certain ways.

If we kept multiple interfaces, we'd have the same problem. One thing 
for targetResource, it does seem intended to address this gap. One 
thing for serviceGroup, its intended to make this gap explicit, and 
provide a hook for filling it in an flexible way.

Cheers,
Bijan Parsia.

Received on Tuesday, 15 July 2003 09:10:20 UTC