RE: XP Service URIs

> Isn't it a use case to have a single XP listener at a single
> well defined
> URL handle more than one service request? I feel the request
> URI should be
> irrelevent to processing the message. Under your definition,
> would the same
> service on different hosts be defined as being different?
> What if I sell
> software for a service I defined to different web sites to
> use. By your
> definition, they would all be different services, not the
> same service from
> different providers.

Yes it is a useful use case. One reason for the confusion may be that there
really are two cases depending on the <xp binding>:

1) bindings to protocols like HTTP or SMTP which
   already has a destination URI of some sort

2) bindings to protocols like TCP which doesn't
   have a destination URI (because it is a transport)

From an implementation point of view, in the case of 1), an <xp
receiver> effectively works like a CGI script or similar in that it is
what is behind the HTTP request-URI. Exactly as with CGI scripts, you
can make a <xp receiver> appear at any URI you like exposing the same of
different services.

Also from an implementation point of view, in the case of 2), the <xp
receiver> becomes a server in its own right. This works just like an HTTP
server where you connect to it and indicate what resource serviced by that
server you want using the request URI. However, the processing rules for the
message are the same regardless of this URI.

Note that none of the above is apparent at the protocol level just as
well as it is not apparent that you are talking to a CGI script on the
server. All you know is the URI of where the message is going.

The difference in the XP model is that <xp intermediaries> work as first
class services as well as the <ultimate xp receiver>. This is because an
<xp intermediary> also is identified by a URI. An HTTP intermediary does
not its own URI.

Henrik

Received on Wednesday, 22 November 2000 11:23:47 UTC