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.