[cddlm] Questions on the component model

[Stuart Schaefer]

Sandro Rafaeli has had many good questions concerning the Component Model. I will forward them to the mailing list to help others clarify questions they may have.
 
Stuart

		----- Original Message ----- 
		From: Stuart Schaefer <mailto:Sschaefer at softricity.com>  
		To: Sandro Rafaeli <mailto:sandro.rafaeli at hp.com>  
		Sent: Tuesday, May 17, 2005 9:34 AM
		Subject: RE: Latest version of the component model

		Sandro,
		 
		These are good questions.  If you don't mind I will be posting some of them to the CDDLM mailing list, since I think that they will help a lot of other people clarify similar issues.
		 
		To answer your question, the component model does NOT require you to create a delegate to do what you want, nor do you have to create a set of separate undeploy components.  In your example, you have defined the <cmp:sequence> to have the deployment scope of the initialization phase.  You could add a separate tag such as <cmp:reverse> to make the termination proceed in reverse order.
		 
		<cdl:system>
		    <cmp:sequence lifecycle="initialization">
		    <cmp:reverse lifecycle="termination">
		        <mysql/>
		       <confLanguage/>
		        <tomcat/>
		        <jpetstore/>
		    </cmp:reverse>
		    </cmp:sequence>
		</cdl:system>
		 
		If you want to have more precise control over the order of the termination sequence, as you defined it below, instead you could use a deployment event to enforce the desired order.  An event such as <cmp:OnTerminated> will allow you to define exact sequences or simplify notify other components of events.
		 
		<cdl:system>
		    <cmp:sequence lifecycle="initialization">
		        <mysql/>
		        <confLanguage>
		             <cmp:OnTerminated process="terminate" target="/mysql"/>
		        </confLanguage>
		        <tomcat/>
		        <jpetstore>
		             <cmp:OnTerminated process="terminate" target="/tomcat"/>
		        </jpetstore>
		    </cmp:sequence>
		</cdl:system>
		 
		This CDL will indicate to CDDLM that the initialization should occur sequentially, but the termination has dependencies.  confLanguage and jpetstore can be terminated in whatever order, but the system should wait for confLanguage to notify the mysql component when it has successfully terminated, and wait for jpetstore to notify tomcat.  If either jpetstore or confLanguage fail to terminate, the CDDLM system should take action to resolve the failure.
		 
		HOpefully this answers your question.
		 
		Stuart
		 
		 
		 
		 
		 
		 
		
		-----Original Message----- 
		From: Sandro Rafaeli [mailto:sandro.rafaeli at hp.com] 
		Sent: Tue 5/17/2005 8:17 AM 
		To: Stuart Schaefer 
		Cc: 
		Subject: Re: Latest version of the component model
		
		
		Hi Stuart,
		
		I'm discussing some details of CDDLM with a team in Brazil, and we come about a new problem. Please, consider the following example:
		
		<cdl:system>
		    <cmp:sequence lifecycle="initialization">
		        <mysql/>
		       <confLanguage/>
		        <tomcat/>
		        <jpetstore/>
		    </cmp:sequence>
		</cdl:system>
		
		In this example, confLanguage configures the language used in some myslq database and jpetstore is a webapp of tomcat.
		
		The "sequence" tag deploys the four components in the declared order. That's plain.
		
		Now, when I send a Terminate and Destroy to system EPR, it will execute terminate and destroy in the exact same order as the deployment (since it has to obey "sequence"), but I really need to destroy confLanguage before mysql and jpetstore before tomcat. Should I actually create a DELEGATE component to be parent of my four components and the DELEGATE componet should be aware of the reverse order when a terminate/destroy is requested?
		
		Would it be acceptable to execute the CDL above (without the DELEGATE) to run my resources and then destroy the deployment components without destroying my applications (resources) so that my apps are still running after I have destroy my System EPR and then later on when I want to really destroy the apps I execute a new CDL where my deployment components are actually not deploying a resource but rather destroying (erasing it)? This is something I would do with smartfrog.
		
		I know the state of a deployment component should reflect the current state of my resource, but it seems to be easier to implement the latter.
		
		Thanks for your time,
		Sandro.