[cddlm] Notes from the meeting on 11/19, the design options for the component model by Stuart Schaefer

[Milojicic, Dejan S]

Present: Kojo Takashi, Stuart Schafer, Jun Tatemura, Steve Loughran,
Vanish Talwar

Agenda: 
---------
1. Stuart's write-up

2. Hiro's comments on 
---------

Stuart: WS-Policy is simple and does not fit our needs for the
deployment.

Kojo: WS-policy is really more complex than presented

Stuart: Really only for decisions, if then else setting, but not rich
enough for CDDLM, which supports fundamental calculus and relationships.
Recommendations is not to use WS-Policy cause it is not of the same
nature

Stuart: Next I used simple syntax in the declarative CDL language. Add
constructs for declarative define relationships clearly in the run-time.
There are two extras: initiate and terminate. If it is a large system it
could be too much to manage. 

Steve: Add more complex options in the future.

Stuart: As we start to add complexity we will need either to punt some
things into the code or rethink more complex support.

Dejan: Are all options exclusive

Stuart: No they are not.

Kojo: Five is extension of number 3.

Stuart: Two and three are very related.

Stuart: Number 4 is SmartFrog way. You have a complete control over what
is happening, you can accommodate anything you want.

Steve: the question is how many times can you really take advantage of
this functionality.

Stuart: It is very tightly coupled, security implications, hard to
change, you need to change component itself. When we add WSRF, we'd need
to do some changes. It works very well but makes  implications into the
system. There is a rippling effect. If the user sits down and wants to
implement CDL, he would need to understand who this compound work.
Parent child relationship is really the most fearsome part. If one looks
at it as a graph v. hierarchy.

Kojo: Everything is hidden in the compound object. In policy object,
everything is declarative.

Stuart: Real power of compound is that you can do anything. With Policy,
we need to be careful about supporting future needs. Power of 

Stuart: 2, 3, and 5 are declarative. There are 5 approaches and we need
to make decision:

1. Declarative or not

2. Hierarchy of graph

3. Parent child or leave it to declarative

4. Notification propagation is fairly complex to do any way we do it.

Stuart: I really wanted to do 5, but it is complicated. Number 5 was to
make it rather than doing compound, declare objects that handle LC
events and deployment. Then invoke to policy object to do the right
thing at that point. If I am object, here are the events I want to hear
of. The lazy approach, here are the sources of events and syncs. I want
to know when something dies.

Steve: in practice you can not guarantee to receive notification when
something goes away. When component dies, the infrastructure can take
care of that. When you author a component, if something dies, that is a
failure.

Stuart 2 & 3 v. 4. and 5. 2&3 easy to implement. The hardest part is to
specify semantics and language well. 4 is straightforward, the hardest
part is that it makes parent child relationship and graph v. hierarchy.
Number 5 is very rich, however it has complications. The first time you
build it is very hard. Once you build it is easy. Very equivalent of
building SF objects, but there is an element of re-usability. 

Steve: is it still research?

Stuart: there is a lot of things that are not research and we can always
fix some things later 

Vanish: What about BPEL

Stuart: BPEL is a very rich syntax. (Steve: it was made for humans;
Stuart: it was also done for automation). BPEL has much more that is not
needed. 

Vanish: BPEL already provides many things in case 2, especially if you
want conditionals, parallel, sequence, etc.

Stuart: I can do an implementation in BPEL and check on Monday. I
already have a lot of infrastructure

Dejan: What is your inclination?

Stuart: Went into doing 5, still like it, very nervous about 4, I like
number 3, easy to do, number 2 easy. 3 was very easy 5 powerful but
complicated. Complications of 5 is relationship to infrastructure (and
deployment APIs). n general you need to build a few more things
(brokered notifications)

Kojo: extensions of the syntax in 5 would not be much complicated, very
generic. 

Stuart: Allows you dependencies without having to write

2 and 3, all notifications go to deployment API in 4 & 5 all gets
delegated to implementations of the infrastructure and propagation of
events.

In a summary, Stuart did a great job with the design options. 

Dejan suggested that we provide a list of high level requirements
(wide-area: decoupling, scalability, ease of use) and try to match them
against the design options (declarative v. object run-time, hierarchy v.
graph, parent-child v. declarative, notification propagation or leave it
to registration), and then against the implementation choices.

TOPIC 2
-------

Dejan addressed Hiro's comment about moving SF-based language spec from
the recommendation to community practice track. Stuart and Jun will
implement only CDL and not SF language based specs, which made it clear
that there would have been only one implementation and we shall move the
SF-based spec to the community practice track.