Lifecycle of the Services Managed by WLOC

Bookmark Blog Post

	del.icio.us
	Digg
	DZone
	Furl
	Reddit

Lina Xu's Blog | April 10, 2008   7:48 AM | Comments (2)

In the first blog, I mentioned service transitioning states such as starting, stopping, staging and destroying in deployment-state-constraint description. I realized the service lifecycle could be confusing for new users, hopefully this blog entry could be helpful :)

Service Lifecycles

The diagram above demonstrates the service lifecycles in WLOC, as we can see, each service has 3 lifecycle states "undeployed", "staged", "deployed", and 4 transitioning states "staging", "starting", "stopping" and "destroying".

• undeployed: Services in this state has nothing created or running, that's the initial state after the service is created.
• staged: This stage is created mainly for WLS-VE instances that are running on VMware ESX server. For WLS-VE1.1 instances, the VMs can be created on virtual disk on ESXServer, and the virtual hard disk is a .vmdk file. When a WLS-VE1.1 instance starts, a two-step process is involved. First, a .vmdk file is created and allocated to the virtual machine, then we can populate the virtual disk and start the virtual machine. Similarly, when shutting down the virtual machine, first the virtual machine is stopped, and then we can destroy the virtual machine meaning removing the .vmdk file. Having "staged" as an interim state is important as it allows us to keep the .vmdk file in scenarios such as populating the virtual disk by copying file from other places before virtual machine's initial boot, or having runtime information of the virtual machines that could be modified and reused when later the virtual machine is restarted.
• deployed: Services in this state has all the required instances created and running.

I don't think I need to explain more about the other "staging", "starting", "stopping" and "destroying" states, they reflect the states of the services transitioning between lifecycle states, the above diagram clearly says it.

deployment-state-constraint

So here is a re-visit of the deployment-state-constraint described before, we can define deployment-state-constraint with different transitioning states and bind it with different service action. So for example, I have the following constraint bindings defined for LOC-service1 which is in "undeployed" state:

<ns2:constraint-binding>
    <ns2:constraint-key>LOC-service1stage-constraint-key</ns2:constraint-key>
    <ns2:action-key>service-stage-action</ns2:action-key>
</ns2:constraint-binding> 
<ns2:constraint-binding>
    <ns2:constraint-key>LOC-service1deploy-key</ns2:constraint-key>
    <ns2:action-key>LOC-service1startserviceaction</ns2:action-key>
</ns2:constraint-binding> 
<ns2:deployment-state-constraint>
    <ns2:name>LOC-service1stage-constraint</ns2:name>
    <ns2:key>LOC-service1stage-constraint-key</ns2:key>
    <ns2:priority>0</ns2:priority>
    <ns2:state>staging</ns2:state>
    <ns2:evaluation-period>0</ns2:evaluation-period>
</ns2:deployment-state-constraint>
<ns2:deployment-state-constraint>
    <ns2:name>LOC-service1-service-deploy</ns2:name>
    <ns2:key>LOC-service1deploy-key</ns2:key>
    <ns2:priority>0</ns2:priority>
    <ns2:state>starting</ns2:state>
    <ns2:evaluation-period>0</ns2:evaluation-period>
</ns2:deployment-state-constraint> 
<ns2:action>
    <ns2:name>service-stage-action</ns2:name>
    <ns2:key>service-stage-action</ns2:key>
    <ns2:impl-class>com.bea.adaptive.actions.internal.StageServiceAction</ns2:impl-class>
    <ns2:adjudicate>false</ns2:adjudicate>
    <ns2:properties/>
</ns2:action> 
<ns2:action>
    <ns2:name>LOC-service1startserviceaction</ns2:name>
    <ns2:key>LOC-service1startserviceaction</ns2:key>
    <ns2:impl-class>com.bea.adaptive.actions.internal.StartServiceAction</ns2:impl-class>
    <ns2:adjudicate>false</ns2:adjudicate>
    <ns2:properties/>
</ns2:action> 

When WLOC receives a command to start this LOC-service1, it first executes the StageServiceAction to transition the service from "undeployed" state to "staged" state; and then it executes StartServiceAction to transition the service from "staged" state to "deployed" state.

Remember these constraints are not required, if they are not defined, WLOC will implicitly execute the actions. So in the above example, if there is no deployment-state-constraint, WLOC will first execute the StageServiceAction and then StartServiceAction just like they were defined. In fact, most of the time you don't define those constraints, the scenarios where you want to explicitly define those constraints are when you want to override the default actions such as StageServiceAction/StartServiceAction with a custom pipeline or when you want to set a property on those actions.

Console Deployment

From the service table in WLOC console, there are four operations that can be applied to each service to move service into a different state:

• Stage: WLOC will create .vmdk file for the WLS-VE instances, and put the service from "undeployed" to "staged" state; for the plain WLS instances, this is a noop, WLOC simply puts the service into "staged" and does nothing else.
• Start: WLOC will try to put the service into "deployed" state.
  • If the service is in "staged" state, WLOC will directly start the required instances in the service and put it into target "deployed" state.
  • If the service is in "undeployed" state initially, WLOC will implicitly run the StageServiceAction to put the service into "staged" state first, and then start all the required instances in the service and put it into target "deployed" state.
• Stop: WLOC will stop all the instances in the service that's in "deployed" state, and put the service into a "staged" state. Note that for WLS-VE instances that on virtual disk, the .vmdk files will be kept.
• Unstage: WLOC will try to put the service into the initial "undeployed" state
  • If the service is in "staged" state, for WLS-VE instances, WLOC will run the DestroyServiceAction to remove the .vmdk file and put the service into "undeployed" state. For the plain WLS instances, this is a noop, WLOC simply puts the service back into "undeployed" state and does nothing else.
  • If the serivce is in "deployed" state, WLOC will implicitly run the StopServiceAction to shutdown all the instances and put the service into "staged" state first, and then run the DestroyServiceAction to remove the .vmdk file if necessary.

Comments

• Conference and Workshop on Java Enterprise, Agile, JDK, Mobile, Spring, BPEL, EJB 3, Eclipse, Java EE, Cloud Computing and more.. If you work on Java there's no way you can afford to miss the Daring Java Conference @ Developer Summit 2008, being held May 22-23 in Bangalore. And there's no reason to either. The first-of-its-kind conference offers the ultimate value of leading-edge skills and luminary speakers from the works over. From frameworks and middleware technologies to Open Source Java, Java Mobile, and real time technologies, you will come back to work more productive and valuable to your company. So if you're keen on taking your knowledge and your capabilities beyond mere industry standards, you know where you need to be! To know more about the benefits and the registration procedure visit the summit on the Web http://developersummit.com/conference.html#java. On May 23 2008, Java technology transitions into teenage years. Celebrate this achievement at the 'Java Teenage Party' on the evening May 23, which will conclude the Daring Java conference. You will not find talks of this caliber at other events. Some very good speakers are already lined up (http://developersummit.com/speakers.html) • The Future of Enterprise Java by Jim Farley • Building Java-based Cloud Architectures by Amazon's Jinesh Varia • Using Persistent Java Objects in Multiple Tiers by Craig Russell • Enterprise Mashups Using Java by Greg Murray • Java Performance Tooling by Holly Cummins • Beginning Drools - Rule Engines in Java by Brian Sam-Bodden • Develop Secured Ajax Applications by Olivier Poupeney • Leveraging Open Source in Java EE Projects by Peter Thomas • Web Services Development in Java without JEE by Sanjaya Karunasena • Ajax and Comet: Implementing the Real-Time Web by Alessandro Alinone • EJB 3 Java Persistence API in Action by Deb Panda The workshops include: • Workshop: Rich Internet Applications with Flex and Java • Workshop: Master Class: The Elements of User Experience • Workshop: SQL Server 2008 Deep Dive • Workshop: Java Data Objects Tutorial • Workshop: Wicket, Spring and Hibernate: Putting It all Together • Workshop: Harnessing Domain-Specific Languages (DSLs) • Workshop: Parachuting Into Brownfields • Workshop: Acceptance Test-Driven Development You can register online: http://developersummit.com/registration.html Thanks, #3/18, Corporation Buildiing, Residency Road, Bangalore - 560 025 ph +91 80 4005 1000 Fax: +91 80 2221 0148 Email: info@saltmarchmedia.com Conference venue: J N Tata Auditorium IIsc, Bangalore- 560025

  Posted by: Shaguf on April 15, 2008 at 4:32 AM

• Good entry, some useful information here.

  Posted by: hoos on April 10, 2008 at 2:38 PM