[Pgi-wg] EMI Execution Service Specification

[Morris Riedel]

Hi Mark,

 thanks for your feedback that I will bring into EMI and discuss within PGI at the next call.

Take care,
Morris

>-- -----Ursprüngliche Nachricht-----
>-- Von: pgi-wg-bounces at ogf.org [mailto:pgi-wg-bounces at ogf.org] Im Auftrag von Mark Morgan
>-- Gesendet: Donnerstag, 5. Mai 2011 16:19
>-- An: pgi-wg at ogf.org
>-- Betreff: [Pgi-wg] EMI Execution Service Specification
>-- 
>-- As promised, please find included my comments from a brief read-through of the EMI Service Specification
>-- document.  I'm afraid I don't have too much time to do anything particularly cogent and so I'm just going to
>-- type in thoughts as they occur to me while I read the document.
>-- 
>-- 
>-- Section 1.2:  I fear a one-off solution for delegation when, as a Grid primitive, it would be so much more
>-- useful to have a technique for delegation that crossed service functionality boundaries.
>-- 
>-- Why do both the ActivityManager and ActivityInfo port-types have GetActivityStatus/GetActivityInfo operations?
>-- What is the difference between them?
>-- 
>-- Page 6/45:  I like the definitions of what happens regarding data staging for various types and times of
>-- failures -- this was definitely missing in the original BES and caused some pain for Genesis II.
>-- 
>-- Section 1.4:  You have a typo in the first paragraph '"server data pull" and "server data pull"' should be pull
>-- and push.
>-- 
>-- Section 1.4:  Why limit the spec. to two types of delegation tokens rather than make it extensible?
>-- 
>-- Page 8/45:  I don't know yet what your "activity description document" is, but if it's like JSDL, a vector of
>-- them gets big quick (we had a lot of trouble with this in Genesis II and is the reason why we eventually
>-- implemented the ParameterSweep extensions).
>-- 
>-- Page 8/45:  Ditto for the response vector.  My guess is that you are not returning EPRs which will help a bit
>-- (though I don't agree with the practice), but I would suggest that you consider the WS-Iterator 1.0
>-- specification or an equivalent.
>-- 
>-- Ongoing:  I continue to see "vectors" of things given or returned -- Again, I strongly encourage you consider
>-- some type of iteration context like WS-Iterator.
>-- 
>-- Section 4.5:  Personally I find the operation name "NotifyService" misleading
>-- 
>-- Page 26/45:  A rough, high level glance at the Activity Description Document structure leads me to believe that
>-- it is JSDL with a different name (and some extensions).  Why go to all the effort to re-write JSDL when you
>-- could simply extend it?  If you are going to do that, at the very least you need to motivate the decision.  To
>-- me, it seems unnecessary.  I understand that you want to use GLUE2, but couldn't that have been done without re-
>-- doing JSDL from scratch?
>-- 
>-- -Mark
>-- 
>-- 
>-- 
>-- _______________________________________________
>-- 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: smime.p7s
Type: application/x-pkcs7-signature
Size: 3550 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/pgi-wg/attachments/20110505/167c1d5f/attachment.bin