Re: targetResource wording

I don't think I agree....

(But this is my impression of what everyone means, so...)
(read on -- comments embedded)

Thus quoth Savas Parastatidis (~ 20-Jun-03 12:56 PM ~)...
>>Suppose there are two interfaces, printing & printermgmt. Printing
>>contains the operation "print" which returns a job id.  printermgmt
>>contains, amongst others, the cancelJob operation.
>>
>>If I print to some print endpiing with a targetResource and later
> 
> decide
> 
>>to cancel it, I need to know which thing on which to perform the
>>cancelJob operation. In  this case, the 'targetResource' identifies
> 
> the
> 
>>printing subsystem.  Depending upon the enterprise's choices, this may
>>be a server, a printer, a farm of printers in some room with a common
>>manager or spooler, whatever -- we don't know.  We just know that two
>>endpoints employing these interfaces refer to the same 'collected
> 
> stuff'
> 
>>-- that identified by the 'targetResource'.
>>
> 
> 
> I don't think the targetResource is what you need here. The jobId you
> got back as the result of the print operation should contain enough
> information for you to cancel your print job through the printermgmt
> interface by giving the jobId.
Here's the problem.

So I have in my had a jobId.  Let's assume it contains "enough 
information" to perform a cancel.

Now, suppose I have, borrowing from your encodings below:
>> <interface name="PrintInterface">
>>    <operation name="print">
>>       ...
>>    </operation>
>> </interface>
>> 
>> <interface name="PrintManagementInterface">
>>    <operation name="cancelJob">
>>       ...
>>    </operation>
>> </interface>
>> 
>> <service name="PrintService"
>>          interface="PrintInterface"
>>          targetResource="http://print.com/printerA">
>>    ...
>> </service>
>> 
>> <service name="PrintManagementService"
>>          interface="PrintManagementInterface"
>>          targetResource="http://print.com/printerA">
>>    ...
>> </service>
(augmented with)
    <service name="PrintServiceForMoney"
             interface="PrintInterface"
             targetResource="http://printservice.com/printForAFee">
   ...
    </service>

    <service name="PrintManagementServiceForMoney"
             interface="PrintManagementInterface"
             targetResource="http://printservice.com/printForAFee">
       ...
    </service>

If originally print to service PrintService, but then cancel through 
PrintManagementServiceForMoney, if the implementation is "good", it will 
reject my request (since the jobId won't be valid).  But my job won't 
get cancelled.

> 
> I think targetResource attempts to expose implementation-specific
> information through a web service interface (just my limited
> understanding).
My understanding differs -- my understanding was that targetResource was 
used to correlate services which affect the same collection of 
underlying stuff (without using the loaded term /resource/ :-/ ).
> 
> In your example, the idea of targetResource causes really big
> problems... (again, according to my understanding).
> 
> <interface name="PrintInterface">
>    <operation name="print">
>       ...
>    </operation>
> </interface>
> 
> <interface name="PrintManagementInterface">
>    <operation name="cancelJob">
>       ...
>    </operation>
> </interface>
> 
> <service name="PrintService"
>          interface="PrintInterface"
>          targetResource="http://print.com/printerA">
>    ...
> </service>
> 
> <service name="PrintManagementService"
>          interface="PrintManagementInterface"
>          targetResource="http://print.com/printerA">
>    ...
> </service>
> 
> Can you see the problem here?
> 
> If my printerA breaks down and I want to replace it with printerB, or if
> I want to use a pool of printers, I will have to change the interfaces
> of my two web services. That shouldn't have to be the case.
True enough.  However, had your /enterprise/ built a correct set of 
services (a value judgement, to be sure!)...

Alternatively, replacing things in service implementation (i.e. if a 
request arrives for "printerA", internally I'll redirect it to 
"printerB") is fine.  The targetResource probably shouldn't be 
interpreted as an physical thing.  I think of them as unique names for 
some, potentially abstract, thing/resource/whatever.  If it starts out 
meaning a physical thing but /migrates/ over time, that's a policy not 
mechanism issue.  I think.

(similar to an XML namespace -- the indicated URI needn't really exist 
-- it's /handy/ if it points to the associated schema, and that might 
even be a good idea -- but it's the namespace itself which identifies 
the interpretation.  In this case, the URI of the targetResource 
identifies the 'stuff' that the associated endpoints manipulate.

> 
> If, however, my jobId contained the name of the printer (which is an
> application specific decision) then I could get exactly the behaviour
> you suggested. 
>
> No?
depends alot on the implementation. (weasly answer, but I think I really 
answered above :-)
> 
> Regards,
> .savas.
> 
> 


-- 
Fred Carter / AmberPoint, Inc.

mailto:fred.carter@amberpoint.com
tel:+1.510.433.6525 fax:+1.510.663.6301

Received on Friday, 20 June 2003 17:08:45 UTC