Folks at the F2F,
Attached is the proposed time table for tomorrow and minutes for today.
We will start tomorrow's discussion with the review of the minutes.
-Keisuke
=======================================================================
ACS F2F DAY 1
-----------------------------------------------------------------------
Date and Time: Aug 1 9:00-18:30 EDT 2005
Location: IBM, Durham RTP.
Participants:
Keisuke Fukui (Fujitsu)
Peter Ziu (Northrop)
Thomas Studwell (IBM)
Michael Behrens (R2AD)
Sachiko Wada (ASCADE) - minutes
-----------------------------------------------------------------------
* 9:15 Agenda bashing, role call, note taker & time keeper.
* 9:30 AA Creation use case
Material: (from Tom)
There are two representations of AA: AA on the wire and AA in the
repository. Both are logically equivalent.
We agreed to call the former as AA Document and the latter as AA Instance.
To create an AA Instance, the client sends an AA Document and optional
administrative information to the repository. The administrative
information is used to add or overwrite information in the AA Document.
* 10:45 break
* 11:00 AA Creation use case (continued)
We discussed five scenarios.
Z) Non-ACS IDE, which doesn't know about AA Document, sends
administrative information and a collection of Application Content
files to the repository in order to create a new AA Instance.
1) ACS IDE, which knows about AA Document, sends an AA Document and
optional administrative information to the repository in order to
create the corresponding AA Instance.
2) The client uploads files to the portal service, then the service sends
an AA Document and optional administrative information on behalf of
the client to the repository in order to create the corresponding AA
Instance. This scenario is exactly the same as scenario 1 from ARI view.
3) The client uploads files to the repository in order to add or update
Application Contents in an existing AA Instance. This is a scenario of
AA Updating.
4) The repository (ACS service) sends an AA Document and optional
administrative information to another repository to replicate the AA.
This is a scenario of AA Replication.
We agreed to drop off scenario Z.
We agreed to call the operation for scenario 1 and 2 as "Create" instead
of "Register".
The detailed message exchange format for AA creation (scenario 1 and 2),
AA Updating (scenario 3) and AA Replication (scenario 4) will be
discussed tomorrow.
* 11:45 Lunch
* 13:20 Data Transport
Material: (from Keisuke and Sachiko)
** Baseline discussion
We agreed that ACS (ARI) exposes a list of supported protocols as resource
properties.
** Discussion on slide 3:
We discussed six scenarios for Create and GetContents operations.
A) Create using SwA.
B) Create using soap message but with out of band transport for a (part
of) the AA document and the uri is provided by the ACS (the ACS
acts as a file server).
C) Create using soap message but with out of band transport for a (part
of) the AA document and the uri is provided by the ACS (the ACS
client acts as a file server).
D) GetContents using SwA.
E) GetContents using soap message but with out of band transport for the
AA contents and the uri is provided by the ACS (the ACS acts as a file
server).
F) GetContents using soap message but with out of band transport for the
AA contents and the uri is provided by the ACS client (the ACS client
acts as a file server).
We agreed that A and D should be supported by default.
B: Pros - Client needs not prepare storage.
Cons - Message exchange becomes complicated.
(At least 3 stages are required to complete transaction)
'Put' is difficult in respect of access control.
C: Pros - ACS can select whether ACS stores actual files or references.
Message exchange is simple.
On-demand expansion of the storage can be explored easier.
Cons - The client needs prepare storage.
E: Pros - Client needs not prepare storage.
This is what we discussed with CDDLM-WG at GGF14.
Cons - Message exchange becomes complicated. It may need 3 stages.
F: Pros - The operation can be done in 1 stage.
Cons - 'Put' is difficult in respect of access control.
How do ACS put multiple contents?
** Conclusion
Which pattern ACS supports is:
Required - A, D
Optional - B, C, E(recommended)
Not supported - F
* 15:10 break
* 15:25 Security and signature on ACS
Material: (prepared by Sachiko)
Keisuke explained the material.
We agreed that ACS may not specify what the other standards including
OGSA basic profile cover as for the ARI, since they should be treated
common to all OGSA services. We need to clarify to what extent OGSA and
other standards specify, especially concerning with authorization.
Mike will get comments from the OGSA AuthZ co-chair.
Action: Mike to report the feedback of the OGSA meeting next Wednesday (US
EDT).
* 16:30 OGSA F2F presentation
The presentation is for EMS team and other OGSA people who may not know
much about ACS. The presentation should take less than 10 - 15 minutes.
We review the proposed material in the regular teleconference next week.
Action: Pete to make the draft presentation by coming Friday.
* 17:00 break
* 17:15 ACS use case for SDD TC and update
** Updates
SDD TC is now collecting use cases and as an input to the TC. Those are
available from the TC WWW site. Sun and IBM had already posted their use
cases. ACS and CDDLM are requested to input grid related use cases.
** ACS use case
Extracted requirements which are relevant to SDD from current ACS
requirements.
Action: Keisuke to send the ACS requirements document with highlits on those
that may apply to the SDD (green: yes, yellow: possibly) to the ml.
Action; All to review it and send comments if any.
* 18:00 Warp up for day 1
