Re: How to talk to a SmartFrog component from the outside?

Hi Xavier,

Sorry for the late reply. I was on holidays and I am catching up with
email :-)

I will complement Steve notes with the RMI solution.
 
> > How does an external java object tell a smartfrog component instance
to
> > invoque one of its (the smartfrog component's) methods?
> > In my question the Java object would not be a sf component and would
> > live in
> > a different jvm than the smartfrog component.


As Steve mentioned you would need to find the RMI reference to that
component and then you will be able to invoke any method exported by
that component using RMI (create a remote interface and export the
interface using RMI).

To locate a SmartFrog component from a java application you can use the
SmartFrog locator to find a ProcessCompound and then use the
ProcessCompound to find the final component.

You can do something similar to:
// Init system (if using security you will need to have all the right
// environment data pre-set
        try {
            org.smartfrog.SFSystem.initSystem();
        } catch (Exception ex) {
            throw SmartFrogException.forward(ex);
        }

//Find the daemon
ProcessCompound targetP =
SFProcess.sfSelectTargetProcess(host,subProcess)

//Use name of component to create ref (This validates if the 
// name syntax is correct. The string could be used directly with
// sfResolve()
//
try {
    Reference  ref = Reference.fromString(componentName);
} catch (SmartFrogResolutionException ex) {
      throw new SmartFrogResolutionException(...);
}
//Find target component using ref 
Prim myComponent = (Prim)targetP.sfResolve(ref);

And then you could call any remote method on that component.

prim.pauseMethod();



Other alternative is to have a set of simple action components just to
invoke those methods. And deploy those components in the traditional
way. This components could also be used in the future in workflows.

You could have a component that calls the Pause method and then
terminates for example and this component would be started use a
pause.sf description or similar. These component would be deployed as
children of the VM component and therefore would try to invoke the
"action method" on their parent.

The component would use sfResolve to find the targeted component that
manages your VM and then call the remote method.

smartfrog AppEx1:DEPLOY:ch/cern/pauseXenApp.sf:"VM1":localhost:

In this case, AppEx1 is deployed as a child for VM1 in localhost using
description pauseXenApp. That component would then call the pause method
in VM1 and terminate either normally if successful or abnormally if it
failed.


Let me know if you encounter problems with any of this.


Regards,

Julio G



> -----Original Message-----
> From: smartfrog-developer-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
[mailto:smartfrog-
> developer-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of Steve Loughran
> Sent: 14 June 2006 14:37
> Cc: smartfrog-developer
> Subject: Re: [Smartfrog-developer] How to talk to a SmartFrog
component
> from the outside?
> 
> Xavier Grehant wrote:
> > Hi all,
> >
> > How does an external java object tell a smartfrog component instance
to
> > invoque one of its (the smartfrog component's) methods?
> > In my question the Java object would not be a sf component and would
> > live in
> > a different jvm than the smartfrog component. The smartfrog
component
> would
> > be an instance of a Prim java implementation, constructed by the
> smartfrog
> > engine upon a smartfrog description, and already started.
> >
> > For instance we have a smartfrog component representing a Xen
virtual
> > machine. It would configure the image in sfDeploy, create it in
sfStart
> and
> > shut it down in sfTerminateWith using an interface to Xen commands.
It
> > would
> > be clean if an external java object or a script could also tell this
> > smartfrog component instance to pause the virtual machine, unpause
it,
> save
> > its state, etc., instead of having the external java object or
script
> talk
> > directly to the Xen virtual machine interface. Do we have to use raw
RMI
> > for
> > this or can we re-use a mechanism already in SmartFrog?
> >
> >
> > On the command line it would look like this: SFSystem could(?) be
run
> given
> > an Action Descriptor where ACTION is a custom reference to a
> > component-specific method, sfPause()...
> >
> > java -D... org.smartfrog.SFSystem VmEx1:PAUSE:::localhost:
> > where VmEx1 is the name of a deployed and running smartfrog
component
> > representing a Xen virtual machine and whose java implementation
defines
> a
> > sfPause method in addition to sfDeploy, sfStart and sfTerminateWith,
> etc.
> >
> > or java -D...
> >
>
org.smartfrog.SFSystemAppEx1:PAUSE:ch/cern/openlab/smartfrog/xen/xenApp.
sf
> :"VM1":localhost:
> >
> > where VM1 is the sf path to the running sf component representing
the
> Xen
> > virtual machine we want to pause, from the deployed component
> description
> > defined in ch/cern/openlab/smartfrog/xen/xenApp.sf
> >
> > or java -D... org.smartfrog.SFSystem "AppEx1:VM1":PAUSE:::localhost:
> >
> > Thanks in advance for your help,
> > Xavier
> 
> Nobody else has replied so I'll come up with my comments
> 
> The normal way to talk to smartfrog is via RMI. The shell scripts and
> the ant tasks exec smartfrog with the right classpath to parse the .sf
> files and imports, the client program parses everything to build the
big
> descriptor, then it sends the big descriptor graph off to the remote
> system to deploy.
> 
> This works ok in non-secure mode, because you dont need all the trust
> between things. Once your daemon is secured, you have to talk
> RMI-over-SSL to it. Your code does not need all the restrictions of
> signed JARs and secure classloader, it just needs to be mutually
> authenticated with the daemon (i.e they have SSL certificates that
they
> each trust).
> 
> If you are interested in this, Antonio promises some support :)
> 
> The other way to do it is over HTTP with a servlet. Run the jetty
> component to start a servlet engine in the same process, then wait for
> incoming operations. You could be RESTy or SOAPy from there on.
> 
> The CDDLM deployment API is an extended SOAP service for deployment,
> though its still pretty immature and utterly lacking in security right
> now (which is why our public endpoint is not located on the HP
subnet).
> SSL and basic or digest auth are possible through jetty, but the other
> people in the interop testing arent ready for it.
> 
> The CDDLM API is designed to support  (with status on the HP
> implementation in brackets)
>   -long haul deployment over HTTP  (status: working; tested)
>   -deployment language neutral; (status CDL and .SF supported)
>   -create, run, ping and terminate applications.
>   -upload of files (status: inline bae64 working on, needs SwA in
Alpine
> for binary attachments)
>   -ability to resolve attributes of deployed things (status: untested,
> therefore it doesnt exist)
>   -ability to subscribe to notifications of state change with WS
> Notification (status, not even started implementing it)
>   -read only listing of running applications; ability to get a
reference
> for other operations.
>   -interoperability with other implementations (status: being tested)
>   -client APIs in java, .net, other languages (status: one exists, but
> more work needed, especially for a good model for long-haul comms)
> 
> attribute resolution is on my todo list after I get a bit more interop
> done. I dont really want to do WS-Notification as it is complex, hard
to
> test and wont actually call back through firewalls, so is of limited
> value. I'd be much happier supporting BEEP as the notification
protocol.
> the API is designed to support multiple notification protocols,
> incidentally.
> 
> I am not convinced what we have here is stable enough for production
> use, but it would be an interesting experiment to use it, and would
> happily get involved. There is also the mygrid implementation of CDL,
> who have an alternate java client API build on Apache Axis+Apache
Muse,
> and a server that supports CDL. This is probably a more stable client
> API than mine.
> 
> -steve
> 
> 
> _______________________________________________
> Smartfrog-developer mailing list
> Smartfrog-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/smartfrog-developer