[cddlm] Notes from the GGF13

[Milojicic, Dejan S]

Hi,

Please find attached notes from all four meetings held at GGF13. I have started the process of individually talking to each owner of the remaining specs. Plan is to hold the meeting next week at 6am PST.

Thanks,

Dejan.


Notes from the first CDDLM meeting (component model), taken by Kojo
----------------------------------
CDDLM-WG Session 1: Component Model
3pm - 4:30pm, March 14, 2005 at GGF13, Seoul
Chair: Dejan Milojicic, Present: Stuart Schaefer, Note take: Takashi Kojo

Stuart described Component Model with ppt slides.

Following is Q&A during the presentation.

Q: Regarding with aggregating component status,
what does "coordinated" means, if the status synchronization
is not "MUST". 
A: We can still define clearly "coordinated" status.

Q: Regarding with flow control, would it be good to have
Reverse-Sequence?
A: Reverse-Sequence is very difficult to implement, when you
think about recursive tree traverse.

Q: Why do you call it "Flow" instead of "Concurrent"?
A: The term is from BPEL.

Q: Is "Switch" declarative?
A: Yes, I think so.

Q: What is your implementation experience?
A: The hardest part is to deal with multiple versions of
on going standards. WSDM refers WS-RF which goes down to
13 standard components.

Q: What is the scale of test implementation?
A: SmartFrog has large scale application deployment. It is
used for large scale network control systems, for example,
which has more than thousand nodes.

Q: Why don't we just use WSBPEL?
A: WSBPEL is universal, but there is much simpler declarative
way to define most of typical deployment.

Q: When would the reference implementation?
A: Next GGF.

Q: When will you complete Spec?
A: Next week(?)

Q: Have you discuss on message traffic of error event?
A: Yes, somewhat. We are trying to look at that.

Q: Which WS-RF do you use?
A: For reference implementation at next GGF, it will be
realistic to use own implementation of WS-RF.
CDDLM spec doesn't require full spec of WS-RF.

Notes from the second CDDLM meeting (Deployment APIs), taken by Dejan Milojicic
-----------------------------------
Dejan: Why are we required to invoke "run" on the system. Stuart: it may be possible to come up with a thin client at the portal who could replace naïve users and invoke sequences of these calls.

Can we have examples of applications? Stuart, yes, we can create one, for the time being, there is everything on the GridForge, hopefully we'll be able to demonstrate implementations in June in Chicago.

Dejan: there is a different state diagram for system and for component model. Stuart, yes, this is required because of the WSRF and not exposing faults to outside world. Dejan: Can you please introduce a few sentences describing your reasoning why there is a difference.

Audience: why is thee state diagram pessimistic. Stuart because of WSRF, resource needs to have a lifetime, it would have to have the same URL.

Stuart: WS component or endpoint reference should be instead of xsd:any for system epr resolveRequest.sic services, 

Dejan: there will be testing suites for WSDM, do you plan on using it. Stuart: Yes.

Stuart, we intentionally minimized 

A long discussion on basic services v. component model. A quick summary is that because we are lacking basic services, we again needed to put a lot of intelligence into component models. This way, it may not work quite well in cases when the component models are naïve.

Discussion on the ease of use, automation

Audience: it would be useful to have examples of very centralized/hierarchical communication, then completely distributed, and something in between. Stuart: the system already supports it. Dejan: maybe we can introduce it in the some subsequent documents that will accompany the reference implementations. Maybe tutorial (agreement by audience and Stuart).

Fukui Keisuke: I expected some resource management to interact with CDDLM. Stuart: showed the Foundation document, figure 7.

Fukui Keisuke and Stuart started discussions on the interactions between ACS and CDDLM.

Notes from the third CDDLM meeting (XML-based language), taken by Stuart Schaefer
----------------------------------
CDDLM Configuration Language Description - GGF 13

CDL Introduction

CDL FAQ
-	Inheritance (prototype references)
-	Value references
-	Data types

Question (Dejan) : What about CDL across multiple deployment engines?

Question : What is the difference between lazy property and lazy reference?

Question (Dejan) : Can SmartFrog be translated into CDL?

Question (Dejan) : Can you envision GUIs for writing CDL?

Question (Dejan) : Will we provide verification tools?

Question : How difficult is it to implement this?

Notes from the fourth CDDLM meeting, taken by Jun Tatemura
-----------------------------------
comments from Keisuke Fukui (ACS Chair)
- people from Naregi will a driving force
- ACS and CDDLM have tight relationship
-- especially: addfile operation, deployment API

Kojo
- 4 sessions are successful. I think the component model and cdl have matured.

Jun
- we will be able to show a demo by Jun to demonstrate reference implementation although it may not be perfect conformance.
- example scenario should be discussed.

Stuart
- lots of work should be coordinated towards interoperability. (e.g., test case)
- planning on action items in the next telecon

Dejan
- would Naregi team give example scenario, code, etc?
-- Naregi will explore possibility.
comment from Dejan
- I am pleased of our progress.

-----
Relationship with other groups
- JSDL, IUDD, ACS, OGSA

OGSA
(Kojo) they are discussing Execution Management profile
(Dejan) suggests that we can send our documents to them
(Dejan) following every changes in OGSA is tough. We could wait until documents come out.

Action item: Dejan talks to andrew/hiro today.
to have a special session with CDDLM+OGSA

IUDD
(Dejan) there is a lot of value (politically). (technically) taking pieces of CDDLM to OASIS in the future..
(Stuart) it will take time -- companies with different priority/motivation
(Keisuke) the current document is too huge and detail.
their scope does not consider Grid.

Action: do our business as usual.
-----

Next Step. Demo scenarios, etc.

- Action: Dejan, Jun, Kojo + Keisuke (ACS) will review Component Model document
- Deployment API

- reference implementation. NEC will provide a reference implementation.
- Jun will be responsible of the reference implementation. Stuart will have another language parser.

Action: to create a list of conformance requirements (features) and draw a line where we should achieve by June. test cases will be created based on the list (for each specs)

- Scenario
- simple application / complex application
- simple service / complex service

---
next telecon 2 weeks from now