Hi Nameer,


We think there is some misunderstanding in how SmartFrog operates.


There are, we think several aspects to your question.


  1. You can consider the components as the pieces that represent and are responsible to achieve the desired state for your system. The creation of a component can be seen as the intention for some state management to occur, managed by that component. Its termination normally indicates that this state is no longer required. So for example, you might create a component that manages the installation of some piece of software (and possibly the running of some Daemon) on a host. Creating the component may download and start the software and daemon, terminating the componen may stop the daemon and unload the software.
  2. The components are interpreters of the configuration parameters provided. Using this data, a component will usually wrap the "real" software (your software, apache, mysql, … and their installers). 
  3. There are times when the lifecycle of the component creation is not that of the state represented by that component. In this case you need to add ways of triggering a component to do more than simply be created and be terminated. You can add any extra remote methods (RMI interface) or other communication protocols to the components. So for example you could add an interface for you to be able to query the state of a component, to trigger it to update the version of the software it is managing, or indeed any other action you see as necessary. In this way you can add your own system lifecycle on top of that of the basic distributed component creation which SmartFrog provides.


So going back to your example, you can have a daemon management component that during sfDeploy reads its configuration attributes to know where the installation tar file is and where the tar file has to be copied and untared, and which daemon to start. It may also be given information as to which component (lets name it X) it should notify of any state change.  Then, during sfStart it makes use of this information to download, copy and untar the file, and start a thread to manage and monitor the daemon. Whenever a state change occurs, for example the daemon dies, it will notify X of the state change.


We would recommend you to have a look at the dynamic webserver example.


If you don’t mind, we will send a similar response to the support list with your name and some information removed to keep your question private. In this way others can use the list to answer similar questions without the need for an email.


If you need more information, just ask...


Julio Guijarro & Patrick Goldsack




From: smartfrog-support-admin@lists.sourceforge.net [mailto:smartfrog-support-admin@lists.sourceforge.net] On Behalf Of Nameer
Sent: 20 February 2006 17:32
To: smartfrog-support@lists.sourceforge.net
Subject: [Smartfrog-support] FW: SmartFrog questions.


From: Nameer

Sent: 17 February 2006 06:34
Subject: SmartFrog Questions


Hi all


We are currently in the development stage of an automated system for system configuration management and deployment.


We have chosen SmartFrog as our framework for system configuration and deployment of our software at different hosts. As we started the design and the development stage we are facing with some technical issues and I very much appreciate your feedback. It will be great if you could point me to the documentation.


  1. We are planning to deploy our software (SmartFrog component) from a centralized location to different hosts using SmartFrog methods like SfDeploy. One of the business requirements is the ability to return some values from the SmartFrog method. For example, from the centralized location will I be able to call a SmartFrog method to retrieve the last version of the software associated with component X deployed at host Y? So is the return value from SmartFrog methods is always true or false? Or will SmartFrog methods support returning some data?


  1. As described in the SmartFrog manual each component has it is own life cycle. Is the life cycle for each component non changeable? How can we customize the life cycle of the component?


  1. Currently I see that there are some standard methods provided with SmartFrog frame work like SFDeploy, SFStart etc. Will I be able to create my own method lets say SFTarFiles to tar all the files installed at host X for example? What is the process here?


Many thanks for your advice.