Resilient References? (Re: [ogsa-wg] ogsa London f2f minutes uploaded)

[Mark McKeown]

Hi Savas,

"Use a good idea again instead of generalizing it. A specialized
implementation of the idea may be much more effective than a
general one."
                   (Lampson, "Hints for Computer System Design")

or as he put it more bluntly in the same paper -

"Don't generalize; generalizations are generally wrong."


> You are assuming HTTP here while most (if not all) of WS-* specs do
> not make that assumption. While what you are describing with
> HTTP headers may work indeed, they are all tied to HTTP.

WS-I Basic Profile does mandate HTTP, though it may not be regarded
as a WS-* spec. ATOM is another example of a spec that does assume
HTTP - perhaps specs that do assume HTTP don't want the WS- association.

I recognise that HTTP is not the solution to every distributed
computing problem but I think it fits this problem well. I do think
SOAP services and RESTful services can work together, particularly
in this case were the lower level protocol can be used to bootstrap
the higher level protocol.

>
> We are now seeing SOAP processors supporting other transport protocols
> as well (e.g. Indigo and Axis 2 support SOAP over TCP/IP). (note that I
> am treating HTTP as a transport protocol here and now as an application
> protocol :-)

When can we expect a WS-I profile that includes a transport protocol
other than HTTP? What would be the first one?

The solution I suggested would mean that all clients that want to
resolve "handles" must support the HTTP protocol - this could be seen
as a restriction but if you look at the alternative....

The cost of supporting other transport protocols.

*) Now a client has to support mutliple transport protocols,
increasing client complexity - a resolver service provider is
free to chose whatever protocol he wants, clients have to handle
it. At a minium the client will have to support HTTP as it will
be the most common transport protocol. (So forcing clients to
support HTTP in the HTTP only case above is not such a big deal)

*) Given a Resolver EPR that uses TCP embeded inside another EPR
how do I use it. I open a connection send the message,
do I wait for a response out of the same connection or do
I close the connection and wait for the server to respond to me
asychronously. HTTP has a well defined and understand
request/response pattern. For some tranpsort protocols you will
need policy to declare how to use them.

*) You have spec up your faults equivalent to HTTP 404 (EPR not
found), 410 (EPR gone) etc. You still have to deal with HTTP 404
etc. if you use HTTP as the underlying transport protocol...

*) You have to spec up and implement the caching and last-modified
features provided by HTTP if you want the nice support they provide.

*) Some transport protocols may not support TLS, given a resolver
EPR embeded in another EPR - how does a client know the security
policy of the resolver service, (eg what should be signed,
encrypted, username/passwd or X509 etc...)

It seems to me the complexity is getting out of hand - the WS-*
answer is to build profiles, profiles which mandate transport
protocols etc...

cheers
Mark

>
> Regards,
> --
> Savas Parastatidis
> http://savas.parastatidis.name
>
> > -----Original Message-----
> > From: owner-ogsa-wg at ggf.org [mailto:owner-ogsa-wg at ggf.org] On Behalf Of
> > Mark McKeown
> > Sent: Friday, June 10, 2005 4:32 PM
> > To: Mark Morgan
> > Cc: ogsa-wg at ggf.org
> > Subject: RE: Resilient References? (Re: [ogsa-wg] ogsa London f2f minutes
> > uploaded)
> >
> >
> > Hi folks,
> >          I have read the WS-Naming strawman and been trying to follow
> > the discussion on resilient references on the list. Putting EPRs inside
> > EPRs seems a bit strange to me - the following seems simpler (the
> > obvious inspiration is tinyurl)  ...
> >
> > <wsa:EndpointReference>
> >   <wsa:Address>mailto:mark.mckeown at manchester.ac.uk</wsa:Address>
> >   <ws-name:Handle>http://www.thegrid.com/a4dfg</ws-name:Handle>
> > </wsa:EndpointReference>
> >
> > Where "Handle" is used as an identifier/name and is mandated to be
> > a HTTP/S URI. To resolve the Handle a client does a HTTP GET on the
> > URI to get a new EPR, (client gets 404 if resolution is not supported,
> > 410 if the service/resource is gone/terminated).
> >
> > I can see a number of advantages to this:
> >
> > *) It is simple and easy to implement.
> >
> > *) The Cache-Control headers in HTTP can be used to pass on information
> >    to the client to indicate how long it can cache an EPR for - this
> >    is an optional optimization.
> >
> > *) If-Modified-Since HTTP header could be supported so a client will only
> >    retieve a new EPR if the one it has is stale - again an optional
> >    optimization.
> >
> > *) The "Handle" is easy to pass around between users - it can be pasted
> >    into a mail message and the reciever can use HTTP GET to retrieve the
> >    EPR.
> >
> > *) HTTPS can be used when trust is important.
> >
> > *) The service developer can make his EPRs "resilient" whenever he wants,
> >    ie he creates an EPR with a "Handle" but only later makes the "Handle"
> >    URI live.
> >
> > Effectively the low level HTTP protocol could be used to bootstrap the
> > higher level SOAP protocol. Perhaps there are strong reasons why this
> > approach was not considered?
> >
> > cheers
> > Mark
> >
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Mark Mc Keown                            RSS
> > Mark.McKeown at man.ac.uk 	                 Manchester Computing
> > +44 161 275 0601     		         University of Manchester
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > On Fri, 10 Jun 2005, Mark Morgan wrote:
> >
> > > > when Mark writes: "...the general idea we have is to in fact
> > > > possibly have a method who's signature is EPR resolve( [EPR]
> > > > ) Where the parameter EPR is optional..."
> > > >
> > > > Does this "optional" mean that the schema for the input
> > > > message parameter of the resolve operation will have an
> > > > optional "EPR"; it should either be empty or consist of a single EPR?
> > >
> > > Borrowing the pseudo syntax used in the "Web Services Base Notification
> > 1.2
> > > Working Draft 03, 21 June 2004" and replacing the given template for the
> > > NotificationMessage syntax with appropriate naming elements, what I mean
> > is
> > > this:
> > >
> > >
> > > 	<ogsa-naming:Resolve>
> > > 		<ogsa-naming:ResolutionMessage>
> > > 			<ogsa-naming:TargetEPRHint>?
> > > 				wsa:EndpointReference
> > > 			</ogsa-naming:TargetEPRHint>
> > > 		</ogsa-naming:ResolutionMessage>
> > > 	</ogsa-naming:Resolve>
> > >
> > > > If so, what does the "optional" mean for the implementors of
> > > > that porttype/operation "EPR resolve( [EPR] )"?
> > > > Does the service implementation have to cater for both options?
> > >
> > > No, it doesn'.  It can implement the empty parameter one, or both the
> > empty
> > > parameter one and the one that takes an EPR as a parameter.  See below
> > for
> > > explanation.
> > >
> > > > Or can it just return an error for the one it doesn't implement?
> > >
> > > No, this would not be correct I don't believe.
> > >
> > > > And then what does the "optional" mean for the client's processing?
> > > > If the schema indicates that the client could either call the
> > > > resolve operation with or without the original EPR, how does
> > > > it know which option to choose? Should it just try the one it likes?
> > >
> > > The important points to recall here are:
> > > 	1) There are two EPRs involved in this communication conversation.
> > > One is the obvious one listed as an optional parameter.  For clarity,
> > let's
> > > call that parameter the "Hint EPR".  The other EPR is the implicit one
> > which
> > > would be indicated in the SOAP headers to which the communication is
> > taking
> > > place.  Let's call that EPR the "Resolver EPR".
> > > 	2) The Resolver EPR is created with whatever information the
> > > implementor of the resolution services feels is appropriate.  It's up to
> > > that service to generate an EPR with enough information to do the
> > > resolution.
> > > 	3) The Hint EPR is just that -- a hint.  It should not be considered
> > > the end all source of information for resolution.
> > >
> > > What we imply by all of this is that a resolution service should be able
> > to
> > > deal with a resolution message that does not include any EPR as a
> > parameter
> > > by virtue of the fact that the Resolution EPR to which the resolution
> > > messages are addressed is created by that service with enough
> > information to
> > > completely carry out the resolution.  If an EPR is given as a parameter
> > to
> > > that resolution service, the service MAY choose to use that hint to more
> > > efficiently resolve the endpoint in question, but is not required to do
> > so.
> > > In otherwords, a resolution service implementor may choose to implement
> > code
> > > that uses the optional EPR parameter if available, but MAY also choose
> > to
> > > ignore it.
> > >
> > > >From the client perspective, it should be the case that the client may
> > > equally choose to send either an empty message (since this is guaranteed
> > to
> > > work), or one with an EPR (since a service may choose to ignore this
> > > parameter).  In this way the client is free to pick either one -- the
> > > parameterless one if it feels inclined to go with no hints, or the
> > message
> > > with an EPR if the client feels like this extra hint may be useful.
> > >
> > > So, in what cases would the EPR parameter be useful should the client
> > decide
> > > to send it and should the service decide to use it?  Well, in the
> > general
> > > case, we have found that it is tremendously useful (bordering on
> > necessary)
> > > sometimes for a client to indicate to a resolution service that that
> > client
> > > has already tried to communicate with a given binding (EPR) and that the
> > > resolution service might want to go to extra efforts (i.e., instead of
> > just
> > > looking the binding up in a cache or table) to determine whether or not
> > a
> > > more suitable EPR exists.
> > >
> > > -Mark
> > >
> > > > Thanks, Frank.
> > >
> > >
>
>