Remote management

1. Remote management - an OSGi defined must-have feature

One of the required features of an OSGi service platform is the possibility to administer all deployed services remotely.

Why is this necessary? Think about the following situation: You deployed some components which features are not required all the time. Therefore you need a possibility to start the services on demand.

2. Solution

In order to enable remote administration the registry of the infrastructure delivers a WCF service (see picture below). Via this mechanism all operatiosn of the registry component can be executed remotely.

2.1 Sample management client - with IronPython

Application server like the JBoss deliver an integrated apache tomcat web container which delivers a web based management console. In .Net this is a bit more complicated - you need an IIS for pages...

Okay - now we can create some fancy WinForms (or WPF or SIlverlight) client application. But: I'm a very uncreative person. And all my GUI clients look dump! I prefer the black console with white letters HMI ;).

It's no problem to create a console client with an IRegistry WCF channel (IChannelFactory from WCF) and a quit keyword sensitive console reader for user commands, like
  • list all components
  • list all services in componentA
  • start service IService in componentA
  • ...

But then a grammar and an interpreter will be needed also - too complicated.

This is how I came to IronPython. With IronPython dedicated dlls can be used and their methods can be executed directly - perfect.

I created an assembly with a single class, the RegistryManagement.

The operation CreateRegistryChannel(hostName, portNumber):IRegistry creates a new channel to the http IRegistry WCF endpoint - and will be stored in the dictionary. The registry manager can store more then one channel (and returns an already created) for each given host name. With the dispose methods the channel will be closed.

The channel is typed to IRegistry but is a ClientChannel!

This dll and the kernel dll of the cOne application server can now be referenced and used directly. Here is a sample python script:

import sys
sys.path.append(r'c:\Program Files\ContainerOne - Remote Management')

import clr

from Harkon.AppServer.cOne.Client import *
rm = RegistryManagement()

from Harkon.AppServer.cOne.Registry import *
registryChannel = rm.CreateRegistryChannel('localhost', 12345)

from Harkon.AppServer.cOne.Service import *
comA = registryChannel.GetRegisteredComponentsForName('ComponentA')
print comA.Name

Okay - that's it.

Remark: The IRegistry WCF endpoint is http based and has the HTTP get flag set to true. Therefore it is no problem to create a service proxy with the tools of the visual studio.


Last edited Jun 6, 2010 at 3:48 PM by harkon, version 9


No comments yet.