[Pgi-wg] OGF PGI Use Cases from Scientific Grid Portals and Workflow Engines (was Gridiron, or standardization gone backwards)

Etienne URBAH urbah at lal.in2p3.fr
Thu Jul 22 06:30:33 CDT 2010


Morris, Johannes, Oxana, Steven, David and all,


Concerning Use Cases for OGF PGI :

Lot of thanks to Oxana for raising fundamental issues and asking good 
questions !


Yesterday, I wrote :
> our problem is NOT 'computing', but 'providing middleware for a distributed infrastructure managed locally by separate administrative domains and authorizing users to submit activities on remote resources'.
>
> Who are able to understand this problem, and write down relevant Use Cases ?
> -  Surely the members of the teams having designed and now operating WLCG,
> -  Perhaps the members of OGF PGI-WG, if we accept professional Software Engineering.


Steven NEWHOUSE answered with EGI itself :
> EGI. Different NGIs wish to deploy different software and for their
> user communities to be able to access resources in different NGIs
> without worrying the software stack that is being run on the remote
> resources.
>
> This applies as much within Europe as between Europe and the USA and
> elsewhere in the world.
>


Thinking more about it, I now propose other professionals who have the 
best skills and experience to write down 'Use Cases where different 
systems must be brought together' :

-  Providers of Scientific Grid Portals
    GridSphere, PGRADE, GEMLCA, ...

-  Providers of Workflow Engines :
    Kepler, Taverna, Triana, P-GRADE, ...


Therefore, I suggest that OGF PGI :

-  Works in order to achieve internal agreement on the 'Use Case 
Template', for example http://forge.gridforum.org/sf/go/doc16024?nav=1

-  Establishes contact with the above described providers,

-  Present them the agreed OGF PGI 'Use Case template',

-  Ask them to provide 'Use Cases where different systems must be 
brought together', preferably using the template.


Best regards.

-----------------------------------------------------
Etienne URBAH         LAL, Univ Paris-Sud, IN2P3/CNRS
                       Bat 200   91898 ORSAY    France
Tel: +33 1 64 46 84 87      Skype: etienne.urbah
Mob: +33 6 22 30 53 27      mailto:urbah at lal.in2p3.fr
-----------------------------------------------------


On Tue, 20/07/2010 14:43, Oxana Smirnova wrote:
> Hi David,
>
> you actually bring me back to my first post about use cases, which said:
>
> *** use cases must be provided by users
>
> I still stand by it. Indeed, if we have a community that plays gridiron,
> they'll never agree to twist the existing rules in order to make it
> looking a bit like soccer. Yet, we are trying to do exactly this.
>
> I never claim that one technological solution is better than another,
> just like I never will dare to claim that soccer is better than gridiron
> :-) What I say, is that they are *different*.
>
> If anybody has a use case where these different systems must be brought
> together, I'd like to have *this* use case, described in details, what
> exactly is needed, what exactly has to be unified and standardised.
>
> Cheers,
> Oxana
>
>
> On 20.07.2010 11:52, David Wallom wrote:
>> Hello Oxana,
>>
>> Though I agree in the most parts with your analogy this does seem to
>> be in
>> one way or another the technologists again not getting what the user
>> community want. Take for example Structural Biologists, they are
>> collaborating across continental Europe, UK and US by at the moment
>> having
>> themselves to devise the translators/metalayers necessary to bridge
>> across
>> different infrastructures.
>>
>> We need to move beyond the 'my technical solution is better than
>> yours' and
>> realise that if we are not careful the user communities will just see
>> that
>> we are infighting and go their own way (or tell our funders that we are
>> inefficient and not worth continuing). We must move towards standards and
>> 'give' a little on all sides.
>>
>> The research community in the UK sees US collaboration as increasingly
>> important with small amounts of EU collaboration because of funding.
>> If we
>> are not careful they will go their own way totally and we will not get
>> them
>> back. To go back to your analogy, If the user community wants to play
>> gridiron you can shout until you are blue in the face about soccer but
>> they
>> will ignore you, it isn't suitable for them.
>>
>> David
>>
>>
>> On 18/07/2010 01:39, "Oxana Smirnova"<oxana.smirnova at hep.lu.se> wrote:
>>
>>> Hi all,
>>>
>>> I intended to comment on use cases, but feel like commenting on the
>>> very fact
>>> of their appearance.
>>>
>>> When the PGI founders first met in September 2008 (yes, 2008), they
>>> produced a
>>> very advanced draft, almost a ready-made specification. The only
>>> reason they
>>> could not call it a specification was that they were nobody - that
>>> is, OGF did
>>> not know of them.
>>>
>>> They didn't have to waste time on formalizing use cases and
>>> requirements,
>>> because all these were in their heads.
>>>
>>> In football terms, they played by similar rules, and didn't have to
>>> explain to
>>> each other the gory details. They were driven by the desire to
>>> produce common
>>> rules of the game for themselves, such that they can play in the same
>>> league.
>>>
>>> Then OGF kindly adopted the team, but at the cost of putting forward
>>> formal
>>> requirements. No forward movement happened since. First step
>>> backwards was to
>>> trim the specs to a "strawman". Second step backwards was to drop the
>>> strawman
>>> and collect requirements. The third step backwards was to go back to use
>>> cases. I dread to think what will be the next PGI decision? To create
>>> itself?
>>>
>>> In September 2008 we thought that by December same year we'll have
>>> the core
>>> specs. Two years later we are discussing what is the best template
>>> for use
>>> cases and which teleconferencing tool to use. This is, well,
>>> unbelievable.
>>>
>>> And Ithink I know the reason. We try to compare incomparable things.
>>>
>>> Imagine an international football federation that brings together
>>> association
>>> football, American football, rugby, Australian rules football and all
>>> such
>>> things. And imagine this federation introducing common rules. What
>>> would this
>>> rule be? Right, "the game is played on a large field by two teams".
>>> Is there
>>> any practical use of this rule? No, every league will have to keep own
>>> "extensions".
>>>
>>> Despite often looking brain-damaged, footballers are clever enough
>>> not to
>>> invent common football rules. They realize that the term is
>>> overloaded, and
>>> they manage to disambiguate it.
>>>
>>> Grids brought together by PGI are as different as gridiron is
>>> different from
>>> soccer. Let's face it. They still can be played on the same pitch -
>>> meaning,
>>> they can use same hardware - but attempts to device common
>>> rules/specifications so far lead nowhere. It is as if gridiron guys
>>> would be
>>> keeping insisting that soccer has to be played with a ball that
>>> doesn't even
>>> look like a ball, and rugby folks would be agreeing, and soccer guys
>>> would be
>>> scratching their heads and meekly saying that their use case is
>>> actually to
>>> kick it with feet, not carry in armpits.
>>>
>>> The analogy is probably not exactly accurate, but I am quite
>>> frustrated, as I
>>> can see no progress whatsoever. Of the original PGI "creators" only
>>> three are
>>> still attending the meetings - Johannes, Aleksandr and myself.
>>>
>>> Any suggestions are welcomed.
>>>
>>> Cheers,
>>> Oxana

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5073 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.ogf.org/pipermail/pgi-wg/attachments/20100722/3599e802/attachment.bin 


More information about the Pgi-wg mailing list