Re: On why services may not have URIs

We have the exact same problem. It is much easier if the address of a 
service is defined using a more extensible framework that allows other 
addressing properties to be added, for example properties related to 
QoS, security, transport control, contexts, etc. In many cases the 
address may be nothing more than a URI, but defining the address as 
merely a URI will not allow such extended usage.

arkin

Jon Dart wrote:

>
> I would add that trying to coerce non-HTTP address information into 
> the format of a URI is often not easy.
>
> The WSIF WSDL extension to support JMS
> (http://ws.apache.org/wsif/providers/wsdl_extensions/jms_extension.html#N10017)
> uses a complex jms:address element to represent an address.
>
> You could munge this into a single URI somehow if you really wanted 
> to, but it wouldn't be pretty.
>
> --Jon
>
> Francis McCabe wrote:
>
>>
>> Just to throw more petrol on the fire, I need to bring the group's 
>> attention to another issue.
>>
>> A core principle seems to have always been that Web services are 
>> identified by URIs. So, one question that may be asked is
>>
>> "What resource is identified by this URI?"
>>
>> A simple answer might be the software agent that provides the 
>> service. Another possible answer includes the document describing the 
>> service.
>>
>> The utility of the first would be that the transport end-point for a 
>> message could be identified with the service being offered by the 
>> computational process lurking behind it.
>>
>> However, in the case of a composite service, there may not be a 
>> single transport end-point associated with it. Consider the 
>> Request/Subscribe/Publish model in which separate entities manage the 
>> subscriptions from the publications. It is all one service (from the 
>> POV of a requestor) but not from the provider's POV.
>>
>> In addition, a given agent may be offering several services; and 
>> requiring that the agent map those into different transport 
>> end-points imposes an architectural constraint on the implementation 
>> that doesn't necessarily reflect the customers requirements.
>>
>> The other possible answer is that the service URI points to the 
>> description of the service. However, we have always said that service 
>> descriptions MAY be formally expressed, not MUST be. I.e., there may 
>> not be anything to GET at the end of the service URI.
>>
>> In effect, we can say nothing about the resource identified by the 
>> URI. This is reminiscent of the XML namespace URI.
>>
>> Comments?
>>
>>
>>
>
>


-- 
"Those who can, do; those who can't, make screenshots"

----------------------------------------------------------------------
Assaf Arkin                                          arkin@intalio.com
Intalio Inc.                                           www.intalio.com
The Business Process Management Company                 (650) 577 4700


This message is intended only for the use of the Addressee and
may contain information that is PRIVILEGED and CONFIDENTIAL.
If you are not the intended recipient, dissemination of this
communication is prohibited. If you have received this communication
in error, please erase all copies of the message and its attachments
and notify us immediately.

Received on Monday, 21 April 2003 19:59:13 UTC