Participants:
Emmanouil, Etienne, Steven, Morris, Luigi, Johannes

(i)
Debrief minutes of last PGI TelCon
nail down validation steps in ppt
have to write it down and agree on it

(ii)
Debrief PGI actions
Action: Johannes resend the action list

(iii)
Discuss regular change of telcon timeslot in 2010 instead of Friday afternoon
action for Johannes: set up a doodle

(iv)
Continue discussion animation ppt of PGI operation & state model
Focus: Waiting for a job-id until all validation steps have been performed is unrealistic from implementation view (e.g. 100 jobs in
submit array)

first spec: start with scientific gateway, no job id, no state
create JSDL
call createActivity
shpping JSDL 
first state submitted
maybe we should have valaidation process before
most implementation logic parsing of JSDL
going through XML, compliance checks
GLUE link, optional validation check
JSDL seems to be fine -> get job id
new state submitted validated
->SOAP response

when is submitted hold happening

Etienne:
submitted outgoing does not mean responding but sending the job to compute facility

Morris:
maybe change

Etienne:
because standard name

Morris:
we have SOAP response
PGI benefit> provide job id and staging info
staging info might not be there
certainly take some time
job id gets crucial

if we have really an array and submit job with 100 JSDLs
not really realistic
create activity = 1

Next slide:
lot of points but not a full list
crucial points

questions?
no

implementation issue if lot of JSDLs

three identified approaches

A. two operations in port type
we really give the different activities a different symantics
gives us a job id
may take a long time
second operation typical array, but does not guarantee
next iteration: query
unvalidated job ids

B. one operation in port type
give back job id before validating

C. one operation in port type
specify as part of JSDL

problem related to job directory problem

session directory: could be provided but must not be provided
query BES container and get a complete list

Steven:
combinations of approaches

WSRM provides a way ensuring getting message from one ep to another

Etienne:
strongly opposed to C
you cannot guarantee that a client is unique
enforced at the server level

Morris:
we should drop Option C.

Etienne:
yes

Steven:
client could provide an alias 
server could create a string which is unique for the server

Etienne:
server cannot reasonably believe that id is unique

Morris:
one server could be in workflow 
should not be allowed to create uuid

-> drop C

Etienne:
B is not acceptable by ARC

they want early staging
poll for the job status and get session directory afterwards

Morris:
UNICORE same feature request

Etienne:
Strongly in favor of option A 

Morris:
Approach A.

Etienne:
must have slightly differnet name

Morris:
createActivity
createValidatedActivity

Steven:
many times this was discussed
wanted to do
we returned job ids without any expectation of validation

createValidatedActivity
client takes the risk of validating 

ppt edited - approach A

Morris:
anything missed?
no

metting close
and need ARC guys for 

(v)
Debrief Steven Newhouse comments on the list (if time)

(vi)
Debrief Bernd Schuller comments on the list (if time)

(vii)
Interop demonstration Setups for OGF28

(viii)
Next meeting


(ix)
AOB

Etienne:
developing a BES client to be able to interoperate with ARC
will ask where we are on this subject

Emmanouil:
monitoring service DMON
Ilya Saverchenko could present this

Action for Emanouel: GIN list et of DEMOS cll for more demos
Action for Emanouel: get in touch with Ilia
 
Next week - if not agreed earlier on the doodle - Friday