Participants:
Luigi, Balazs, Balazs, Morris, Aleksander, Etienne, Emmanouil Paisos, Oxana

Emmanouil Paisos
short introduction:
working at LRZ in the group of Helmut Heller
Globus, Grid services, ...

debrief the minutes (updated version by Etienne)

state model from Etienne - agreed

submitted state - incoming, validated?

Validation aspects

preprocessing -> next year

Luigi:
please explain why we need the hold state?

Etienne:
Why do we need to add the hold substate?
Inside the submitted state the ARC middleware can send back not only id but also staging information

Balazs:
in the draft the submitted hold is explained

Luigi:
If I put the job state in hold, I have to unlock to assume.

Morris:
Only if a hold point is set in AGU-JSDL document

Balazs:
for manual changes

Morris:
next point in the agenda

go through action items
some administrative things

agreed on changing the title of the strawman document to
PGI Execution Service Draft Specification 

filename:
PGI_ExecutionService_Draft.doc

joint session at OGF28?

session request
for interoperability day
3 PGI, 2 GIN
open floor for presentations

action tracking on the mailing list

Luigi:
discussion about the job lease in CREAM
awaiting more email answers for discussion

Morris:
please resend


OGF28

Morris:
is there from gLite at OGF28?

Luigi:
can participate

Morris:
someone from ARC?

Balazs:
yes
the interoperability day is this also at the OGF?

Morris:
at OGF

action for Morris: ask Nils about the date of the interoperability day


discuss the submitted state
going through the animation

"step-wise animation submitted"

Balazs:
only if the JSDL is correct, a jobid is created 

Morris:
if JSDL description is wrong, then there is no job

everybody agrees?
-> yes

Etienne:
would like at this moment there is an error from the execution service to the scientific gateway

Balazs:
how long does it take to go through the createActivity operation?

Morris:
XML evaluation is very fast
can throw back a fault as a SOAP response

Balazs:
vector operation?

Etienne:
some statistics about jobs sent 

5 to 10 seconds for a job to be accepted by the execution service
1 min before the brokering

Luigi:
we can provide the same interface to the WMS

Morris:
can we do that?

Etienne:
the job is in the accepted status with its job id which is matched to the computing element

Morris:
should we/can we do a brokering interface here

Etienne:
brokering should be possible but is out of scope
match requirements described in the JSDL to a computing element

Balazs:
we should try to keep this interface open enough that a broker is possible

Morris:
early enough?
could be a long time thinking of 2-3 sec/JSDL

Balazs:
job id and data staging information

Oxana:
why worry about how long it takes?

Morris:
the only appearence after the validation steps -> chance to respond something

adding responses

Etienne:
if we have to wait for an hour to get the job ids for 100 jobs
we have to accept that or we have to reduce the number of JSDLs sent together
or use completely other method (parameter sweep?)

if there are a lot of jobs we have to wait long

Luigi:
if http connection breaks, SOAP breaks

Morris:
produces ghost JSDLs

Aleksander:
the service will detect, that the respose was not submitted to the client

Etienne:
this has a great impact - should take care of it

Aleksander:
responses are sent after JSDL processing
no cancelling involved

Morris:
question if we can have here a job id creation before the validation steps

Aleksander:
job ide could be assigned by the client

Luigi:
no because it cannot be unique