Steve, Here are some thoughts on your comments on the Component Model. 1) Each component object is a new instantiation of a component. Are you asking whether the component model is smart enough to recognize that another instance already exists, and not create a new instance? That seems to me to be a higher level primitive than the component model, but could be handled if necessary. 2) I will try to add language to define that we are deploying anything. The point of the services assumption is that this is Grid Forum, and we are trying to deploy grid services somewhere. 3) Resource responsible vs. hosting. I received feedback on that before. WS-RF and WSDM define logical vs. physical resource in such a way that does not require hosting. 4) All internal use of documents is supposed to be CDL. it is specified that way in the Foundation document and in the CDL language document. There is a uniform resolution process. There is also a means to pass the CDL document to a component. In that way, components don't have to be written to read multiple languages. They are parsed by front-end parsers. 5) The lifecycle diagram does not match yours. You do allow termination from initialized. SmartFrog does not. My presumption has been that you can accept the terminate, and march the commponents through their lifecycle. 6) If the code base of an object is a remote URL, does the component have to load the object itself? Who is going to do the fetch or upload operation? 7) Synchronous vs. asynchronous state transition operations. There will be lots of extra code and failure handling for asynchronous, event driven state transitions. I am fearful of either approach. Synchronous is easier to define :) I will look at the Deployment API and see how it is at odds. 8) I am very confused by your "very, very, very slow" comment. It seems you are agreeing with me, and showing how you handle this case with SmartFrog. is that right? 9) Why shouldn't external components declare dependencies on children of delegates? A delegate is defined to manage the lifecycle of a child component. Thus, a delegate is free to manage that lifecycle in any way it sees fit. If you declare a dependency on the child component, the delegate is no longer free. It must be careful not to violate that dependency. I don't think you can have it both ways. 10) Read-on-run vs. read-on-initialized. My intention with the statement was to remind implementers that resolution is not instantaneous. Thus, if you wait until you need it, your deployment operation may slow down. However, I see your point as well. I will change the language, but add the reminder.