[ogsa-wg] OGSAInfo03July08

[Andreas Savva]

> [* Someone ought to do a profile of SOAP using XMPP as a transport,
>     since with that you *could* do real message push. ]

XEP-0072: SOAP Over XMPP
http://www.xmpp.org/extensions/xep-0072.html

On Fri, 04 Jul 2008 19:30:25 +0900, Donal K. Fellows  
<donal.k.fellows at manchester.ac.uk> wrote:

> Andre Merzky wrote:
>> A small comment to the pull/push question raised in the
>> meeting notes: why not support both models?  IMHO, there are
>> always use cases which are very unhappy if you support
>> either one, and not the other...  You can always allow for
>> _implementations_ to support only one model.
>
> Information bound for clients has to be pulled; you just can't rely on
> them being able to receive unsolicited SOAP messages due to firewalls
> and the like[*]. On the other hand, when building an information service
> you want the basic info pushed in from the collection points (e.g. the
> BES container publishes an advert locally that it exists). The tricky
> bit is working out where to switch from push to pull; my instinct is to
> put that at the boundary between service provider and service consumer
> (this is in the simple no-middlemen case).
>
> The project I'm working on is looking at using RDF/SPARQL for the
> information system. On the one hand it does mean that we'd have good
> expressibility, but on the other hand I worry about practicality and
> performance. The gripping hand is that this isn't done yet anyway, so
> it's pure speculation as to whether it is a good idea. :-)
>
>
> Thinking back to what Lawrence was saying, the thing that worried me
> about it was that he was describing a system that pulled a lot of data
> to the local system (well, it was actually to the job execution system
> but that's the local system from the perspective of the query) before
> taking a decision. That seems horribly inefficient. It's better IMHO to
> push a slightly more complex query to the info system and have that
> return a smaller set of results of higher quality (ideally, you'd get it
> down to a single message each way for the majority of cases). As a side
> advantage then is that it is possible to evaluate the query while taking
> into account information that you don't want to expose to the client;
> for example, you don't need to let them see the provisioning schedule of
> your (i.e. the provider's) disk arrays, as you can just tell them that
> the space they asked for will be there when the job completes. Similarly
> for jobs; you don't need to reveal whether an application is installed
> or whether you use virtualized images, just that the job can be executed
> when needed.
>
> [Hmmm, this message is already longer than I set out to write...]
>
> Donal.
> [* Someone ought to do a profile of SOAP using XMPP as a transport,
>     since with that you *could* do real message push. ]
> --
>   ogsa-wg mailing list
>   ogsa-wg at ogf.org
>   http://www.ogf.org/mailman/listinfo/ogsa-wg



-- 
Andreas Savva