[ogsa-rss-wg] The Difference between Abstract and Concrete APIs

[Donal K. Fellows]

Hi everyone!

As many of you will be aware, it is becoming common practice for people
writing service specs in the GGF to do so in terms of an abstract
specification and a concrete representation of that specification in
terms of underlying technology (such as WSRF). I'd like to argue that we
should be doing this ourselves, and that it carries some distinct
advantages.

The thing is, when it comes to the candidate set generator, it is quite
clear from what people have said at OGSA F2F meetings and at the last
GGF that what they are looking for is for the service to reply with just
the "best" offers, though they do not seem to want to define what that
means. Thinking about this, it seems to me that the most sensible way is
for the abstract interface to be written so that the caller supplies an
ordering function over offers, and that the CSG should respond with the
full set of offers ordered by that function.

"But wait! Won't that be horribly inefficient when there are thousands
of offers?"

Well, not really (I am assuming the CSG itself can do the ordering
efficiently). The thing is, what I am talking about is the abstract
service. The concrete service API can do something more efficient,
perhaps through something like WS-Enumeration. (I do not know what the
best way to do that sort of thing in the WSRF world is, but I'm sure
either that it exists or could be made to exist without great problems.)
The advantage of that API is that the consuming services could take as
few or as many offers as they actually want; if someone just wants the
cheapest offer, they can use a simple metric and just take the first
response, but if they're doing advance reservation they can take a whole
bunch of offers and use more complex metrics. And this allows us to
satisfy many different use-cases without difficulty, while also allowing
for CSGs that delegate offer generation to other CSGs (to pick another
possible usage scenario). It also helps us play the "politics of GGF"
game right. All in all, a win for us!

The same things apply to the EPS, of course.

This still leaves us having to describe the language for the metric
functions, how to represent the returned offers (perhaps using WS-Ag
Templates?) and how to describe any extra terms that need to be added to
the JSDL documents we accept in order to support the functionality we
desire (e.g. to support advance reservation?)

Any feedback?

Donal.