[Pgi-wg] Next teleconference: tomorrow, wednesday july 15th

[Oxana Smirnova]

Hi all,

FWIW, I have mixed feelings on this issue. 4 years ago I thought it would be just great to have exactly the same interface and end-point for job submission/management, for information query, and for file management. We even do have the same interface for job and file management: job is largely characterized by a set of files, after all. And information persistency may well be realized as a set of files, too - why not. But then I killed a job by accident, being sure I deleted a file. So now I think a clear separation is a good think to do.

Cheers,
Oxana

2009-07-15 00:10, Laurence Field пишет:
> Hi Andrew,
>
> With the diverse types of services that we deal with in our
> infrastructure, I can't imagine a situation where they have all
> implemented an interface using the same technology. This is due to many
> factors including but not limited to: legacy, time scales, priories,
> ideologies, trends, fads etc.
> However, we have to somehow link all these services together, which is
> why I believe that a parallel system is the most flexible option. If an
> agreed information interface emerges, the exiting interfaces could be
> extended to provide this but the only advantage I see is aesthetics
> rather than function.
>
> Having said that, one of the advantages that I would see by having this
> added to BES is that developers of the interface would also have to
> worry about providing the information, which would save us the trouble
> :)   We could then create a simple adaptor to extract the information
> and pull it into the parallel information system.
> In order to achieve this, a simple interface such as an XML document
> would suffice. Examples of such documents can be found on the GLUE 2.0
> wiki page.
>
> http://forge.gridforum.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/GLUE2XMLSchema
>
> Laurence
>
> Andrew Grimshaw wrote:
>> Laurence,
>>
>> I agree completely. During the BES discussion we came to an impasse over
>> this: some arguing that that we could use WS-RF resource properties ... and
>> then have a single mechanism for all types of resources. Others, including
>> but not limited to Microsoft, would have nothing to do with WS-RF. In the
>> end to get consensus the WG decided on a separate function - very ugly. We
>> in Genesis II support both the WS-RF mechanism and the OGSA-BES mechanism.
>> The same thing by the way happened over notification, except in the end the
>> WG basically punted.
>>
>> I personally think that the BES endpoint should provide a mechanism to get
>> the information, but that the spec should be mute on how that information is
>> aggregated or used.
>>
>> A
>>
>
> _______________________________________________
> Pgi-wg mailing list
> Pgi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/pgi-wg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oxana_smirnova.vcf
Type: text/x-vcard
Size: 270 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/pgi-wg/attachments/20090715/32a86243/attachment.vcf 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.ogf.org/pipermail/pgi-wg/attachments/20090715/32a86243/attachment.bin