Re: Separate concepts for "service" and "targetResource?" (was RE: /service/@targetResource ?)

Thus quoth Walden Mathews (~ 21-May-03 5:32 PM ~)...
>>Thus quoth Fred Carter
>>If the resource is "print what I want within some timeframe in the 
>>cheapest way available to my company", that's a resource all together. 
>>You get to select which resource/printer-service you want.
> 
> 
> Does your intuition support the notion that "print what I want" could
> be a resource?  Mine doesn't, unless I stretch too far.  How do you
> give identity to "print what I want"?  How do you think about the state
> of that?
> 
> This was a stumbling block for me in trying to understand your
> point.
> 
Perhaps this is phrased a bit informally.  In the ATM case, I know that 
I can use ATM's which are identified by "urn:mybank.com" or, because of 
other agreements (logos on the back of my card :-), 
"urn:cirrusNetwork.com", "urn:STARAtmNetwork.com", etc.

Similarly, if I connect to the some printer as 
"urn:mycompany.com:mybuilding:myfloor:laser" (or something), that's the 
one "right over there" (imagine me pointing :-).  However, if I use the 
service identified by "urn:mycompany.com:efficientPrinting", I get 
something else.  The interface is the same, but it routes differently. 
    In the middle is some farm (> 1) of printers that one system "round 
robins" between.  I don't really care which printer prints it, I just 
want some dead trees with ink on them.

So, just as I can uniquely identify things using namespaces in XML, 
namespaces being URI's which uniquely describe the "concept" embodied in 
the entity so tagged, I see little reason why the same notion could not 
be used to tag service's with what they do.

Thus far, WSDL has focussed primarily on identifying the mechanism for 
talking with a service.  The means for choosing the appropriate service 
is "left as an exercise for the reader".  UDDI may fill this bill in 
some cases;  establishing UDDI and formally grounding how WSDL & UDDI 
will cooperate may move us in that direction (there are, for instance, 
the /best practice/ of using only the "interface WSDL" and get the 
service/endpoint's from UDDI).  However, it seems desirable to formalize 
how a system should identify or associate /real world/ services with 
those things identified in a WSDL file.  Having a formal interface for 
the HR system is great.  Having a standard way to describe it is even 
better.  But, 'twould seem that with a small step, we would have a the 
ability to identify the collection of endpoints that should be used for 
HR requests for folks that live in, say, Europe, as opposed to folks in 
the US.  And having some ability to associate service/endpoints with 
"the real world" seems like a good addition.  At least to me...
> Walden
> 

/fred

-- 
Fred Carter / AmberPoint, Inc.

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

Received on Thursday, 22 May 2003 12:46:38 UTC