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

Bijan Parsia wrote:

>
> On Monday, July 14, 2003, at 05:36  PM, Jeff Mischkinsky wrote:
> [snip]
>
>> It was not to introduce a general grouping relationship.
>
>
> Without more definition (e.g., ANY definition) it certainly doesn't do 
> *more* than introduce a general grouping relationship. And it might 
> not introduce the relationship desired, given certain definitions.
>
> (I, for one, advocated considering serviceGroup precisely because, 
> afaict, no one wants to specify the semantics of targetResource 
> *beyond* "these interfaces relate somehow left to applications or 
> other specs to determine". If that's it, then lets call it what it is.)
>
>> The question that targetResource was intended to *help* answer was 
>> typified by the example of having a printer PRINT interface and a 
>> printer PRINTADM interface. The question was how can i tell when an 
>> instance of the PRINT interface and an instance of the PRINTADM 
>> interface are operating on the "same" printer.
>
>
> 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?
>
> Is this sort of grouping uncommon? Unlikely?
>
> 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? 

In this case, the resource shared is probably a printerdatabase. The 
representation of the id of an individual printer is left to the web 
service, but you still have a way to infer that these two services share 
the resource, namely the printer database, not the printer.  So even if 
you were dealing with an id mechanism for the individual printer, the 
"id" for the target resource, namely, the printer database would be the 
URI. If I were to use the printerid (which is application specific) for 
the printer in one web service and I may be updating the resource, the 
printer database, by using the service is shared. Therefore, in the 
other web service, you may access the same printer again in an 
application specific way and see that the information has 
changed/updated if those two services were sharing a printerdatabase. 
So, the targetResource accomodates both cases, whether the 
targetResource refers to an individual printer or the printerdatabase. 
In your example, the individual printer's  "ID"s are modelled in a web 
service/application specific way, however it does not change the fact 
that both services manipulating the same thing, the printer database.

>
>
> [snip]
>
>> The issue I have with changing the notion to group membership is that 
>> there is no definition, even a loosey/goosey one, of what said 
>> membership means.
>
>
> It explicitly is silent on the *further significance* of the 
> membership, but WSDL 1.2, as it stands, is silent about the 
> significance of the relationship indicated by targetResource. I'd 
> rather have something I can hang more specific information on, than 
> try to rely on something that has some intuited meaning to some folks, 
> but not to others.
>
>>  Take my example above of PRINT and PRINTADM. I don't think I can 
>> infer anything useful about the fact that 2 instances have the same 
>> group id. It might mean they manipulate the same printer, but it 
>> might just as well mean that they manipulate printers made by the 
>> same manufacturer, possibly the same printer model, or maybe the 
>> printers they manipulate are owned by the same company, or are 
>> located in the same building.
>
>
> Fairly reasonable set of groups with varying purposes. At the moment, 
> on can bend targetResource, afaict, to cover all of these. The 
> relationship is undefined! 


The relationship is defined based on the word manipulate, no more, no 
less :-)

>
>
>> Personally, I thought the notion that we have of targetResouce served 
>> a useful purpose in many, many cases. I can't see any real world 
>> useful purpose in this notion of service group. as currently defined.
>
>
> Hmm. It's a hint that someone, probably the service authors, thought 
> they bore some interesting relationship, and you may want to find out 
> more about it? What more does targetResource give you, currently? Even 
> with the "manipulates" definition (note that "manipulates" isn't in 
> the current WD)? 

For those of us who consider state to be related to an entity's id, the 
targetResource provides the necessary relationship, namely the "id" of 
the underlying entity that is shared by various services.

>
>
>> 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.
>
>
> It seems especially fraught when the implied type of the target can 
> shift dramatically given reasonable changes to the interface. 

I am not clear about what you mean, but if I understood it correctly I 
would say that the interface changes do not affect that the entity 
behind the covers (meaning multiple web services) is the same and it has 
an ID.

>
>
<stuff deleted/>

>
>
As long as the serviceGroup construct  makes multiple groupings possible 
AND ALSO allows identifies the targetResource grouping in a special way, 
wouldn't that outcome be acceptable for everybody?

All the best,

--umit

-- 
Umit Yalcinalp                                  
Consulting Member of Technical Staff
ORACLE
Phone: +1 650 607 6154                          
Email: umit.yalcinalp@oracle.com

Received on Tuesday, 15 July 2003 16:44:38 UTC