Re: 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