Eclipse Community Forums: Eclipse Communications Framework (ECF) » Concrete problem but no experiences with ECF

Home » Archived » Eclipse Communications Framework (ECF) » Concrete problem but no experiences with ECF(Lack of related documentation for my problem)

Show: Today's Messages :: Show Polls :: Message Navigator

Concrete problem but no experiences with ECF [message #544082]

Thu, 01 July 2010 14:36

Thomas Kerle

Messages: 13
Registered: July 2009

Junior Member

Hello all,

I want to make a server application which polls in regular intervals some directories for new files. If a new file is detected the server application does some task with this file and sends a message about the task success to any connected client. This is the message part of the application.
If the client user find the message useful he is interested he should be able to remote control the server application by sending a request to do some further action with the file and to send for example the generated interface "IFileInfo" to the client.
Since I don't know how to implement the server and the client which does this purpose I ask you to give me some example (server code and client code) which some dummy classes to fulfill such an application. Any help is welcome!

Report message to a moderator

Re: Concrete problem but no experiences with ECF [message #544169 is a reply to message #544082]

Thu, 01 July 2010 21:23

Scott Lewis

Messages: 1038
Registered: July 2009

Senior Member

Hello Thomas,

Thomas Kerle wrote:
> Hello all,
>
> I want to make a server application which polls in regular intervals
> some directories for new files. If a new file is detected the server
> application does some task with this file and sends a message about the
> task success to any connected client. This is the message part of the
> application.

A couple of observations about these requirements: Your statement of
'any connected client' makes me think of the use of publish and
subscribe (pub/sub) groups...where asynchronous communication can be
initiated by any of the participants (e.g. server application in this
case), and received by n receivers (i.e. any connected clients).

ECF is has full support for pub/sub asynchronous communication (that's
where the framework started from)...and in fact also has a distributed
implementation of the OSGi standard EventAdmin service. See here:

http://wiki.eclipse.org/Distributed_EventAdmin_Service

And this example bundle/project: org.eclipse.ecf.examples.eventadmin.app

If you would rather get at the APIs underneath the eventadmin, you could
also possible use the ECF datashare API (asynchronous messaging
channels)...API in bundle org.eclipse.ecf.datashare, and an example app
in org.eclipse.ecf.examples.datashare.app.

There is also the ECF shared object API, underneath *both* the
distributed eventadmin and the datashare API. The API is in
org.eclipse.ecf.sharedobject, and there is example test code in
org.eclipse.ecf.tests.sharedobject. There are also other example usage
of the shared object API spread throughout ECF.

If the client user find the message useful he is interested
> he should be able to remote control the server application by sending a
> request to do some further action with the file and to send for example
> the generated interface "IFileInfo" to the client. Since I don't know
> how to implement the server and the client which does this purpose I ask
> you to give me some example (server code and client code) which some
> dummy classes to fulfill such an application. Any help is welcome!

You can/could also use the distributed EventAdmin and/or the ECF
datashare and sharedobject APIs to do this...but whether the
asynchronous pub/sub messaging would make sense for this sort of depends
upon what kind of 'remote control' you want to engage in. For example,
depending upon how/what you want to remote control on the server, and
whether that remote control can/has to be synchronous or asynchronous,
you might want to discover and use an OSGi 'remote service'...which
allows you to call methods on a local proxy, and have those method calls
result in server application method calls. This may or may not be
desirable...based upon what sort of interaction you are envisioning for
the remote control.

There is now (ECF 3.3) quite a lot of both info and examples WRT ECF's
impl of OSGi remote services...here are some references:

http://wiki.eclipse.org/Getting_Started_with_ECF%27s_OSGi_Re mote_Services_Implementation
http://wiki.eclipse.org/OSGi_4.2_Remote_Services_and_ECF
http://wiki.eclipse.org/Asynchronous_Proxies_for_Remote_Serv ices

And there are several 'hello world' remote service examples in the ECF
3.3 Target Components distribution.

Note that ECF's architecture allows you to select from a variety of
modules for the actual wire protocol...for both of the above
(EventAdmin) and OSGi remote services...for example, you could use one
of the following providers for either of the above: JMS/ActiveMQ, ECF
generic, REST-based providers, XMPP or others (of your own or someone
else's creation).

A caveat, however...we are not currently corporate supported, and so
have limited resources...and this admittedly shows in the incomplete
documentation, and limited ability to provide free support as well as
tutorials and examples. We would very much like to provide more in
these areas but are currently unable to do so (at least immediately...we
are adding to these areas as quickly as possible given our resource
limitations).

Thanks,

Scott

Report message to a moderator

Re: Concrete problem but no experiences with ECF [message #544186 is a reply to message #544169]

Thu, 01 July 2010 22:40

Thomas Kerle

Messages: 13
Registered: July 2009

Junior Member

Scott,

Thanks a lot for the time you give to answer to my problem. Tomorrow I will study the links for the ECF stuff closer and will post next week some more concrete questions in this post and hopefully some advices for novices like me in the ECF region.

1) Therefore I propose that I make a simple application (provided my problem) and give it to the community with a good documentation The server side should have a thread to poll a directory for data that delivers GPS text files for example:

MidlandRailways_07/01/2010_12.30.29-14.30.32.txt

This is a hypothetically vehicle of a English railway company that sends over WLAN the GPS information to our server:

The content of the file would look something like that:

Date Time Event Latitude Longitude Severity

-The event can be for simplicity a stop or a depart.
-The GPS fields (Latitude and Longitude)
-The severity (regular, irregular)

Therefore the poll thread waits for a new text file with this informations. Every subscriber for a vehicle gets a short message that data where delivered to the server with the information if some irregular (for example a stop on the railway line not at a station) event occurred. The client can send a request to the server to get a map (open street map) of the positions of the train in a interval around +- 10 minutes around the irregularity. The map data is created by the server and the client must be able to display them.

For donations contact me at Thomas.Kerle@haslerrail.com

Thomas

Report message to a moderator

Re: Concrete problem but no experiences with ECF [message #544359 is a reply to message #544186]

Fri, 02 July 2010 13:12

Thomas Kerle

Messages: 13
Registered: July 2009

Junior Member

Tutorial: The event admin service used in the Eclipse communication framework

A lot of applications must send and accept events to react on external or internal occurrences. If you use the OSGi service platform then you clearly need to send or accept events within a bundle but also over different bundles or over different OSGi platforms. On possible approach to reach this goal is to use the so called whiteboard pattern. To introduce this pattern we first consider the event-listener pattern which is well known in Java. Events are in this context messages, that are send from one object to another object, and encapsulate all needed data that are useful for the receiver. The event source is the object that fires the event and where event listeners can be attached or removed. The event listeners attached to the event source are normally interfaces (the concrete implementation is hidden to the event source) that expose some methods to which the events to fire will be attached. For example we show the fire event method in the event source object to clarify this fact:

protected void fireEvent (final MyEvent event) {
for (ListenerInterface li: listeners){
li.doSomeMethod (event);
}
}

The whole considerations we did till now are very local. We want now to use the event-listener pattern over different bundles (same OSGi service platform). For illustration purposes we create an OSGi bundle which polls a directory and generates events when the directory content has changed. To keep the things simple we only generate one event a "FileEvent" when a file was added, changed or removed. The "FileEvent" would look like this:

public FileEvent {
...
public enum Action {ADD, REMOVE, MODIFY};

public FileEvent (Object sender, File file, Action action);

public Object getSender();

public File getFile();

public Action getAction();

}

The interface we want to expose to the clients look like this:

public interface IDirectoryWatcher {
//adds a directory provider
public void addDirectoryProvider (IDirectoryProvicer provider);
//removes a directory provider
public void removeDirectoryProvider (IDirectoryProvider provider);

}

The interface IDirectoryProvider is specified below and must be implemented by any client that wants to use our bundle to observe directories.

public interface IDirectoryProvider {

public File getDirectory(); //the directory to observe

public void addFileEventListener (IFileEventListener listener);

public void removeFileEventListener(IFileEventListener listener);
}

The best approach to bundle the two interfaces and the event class is to put them in a separate bundle and to export them, so that the bundle who is responsible for observing the directory have access to it and any clients. We therefore have three bundles

1) com.tutorial.event.directory.watcher
2) com.tutorial.event.directory.client
3) com.tutorial.event.directory.common
Here we put the interface stuff.

Let's now go back to the Activator classes for the different bundles:

com.tutorial.event.directory.watcher

public class Activator implements BundleActivator {

public void start (BundleContext context) throws Exception {

IDirectoryWatcher service = new DirectoryWatcherImpl();

context.registerService (IDirectoryWatcher.class.getName(), service, null);

}
}

com.tutorial.event.directory.client

public class Activator implements BundleActivator {

private BundleContext context;

private IDirectoryWatcher service;

public void start (BundleContext context) throws Exception {

this.context = context;
ServiceReference reference = context.getServiceReference (IDirectoryWatcher.class.getName());
service = (IDirectoryWatcher) context.getService (reference);

//do something with the service

service.add (new DirectoryProviderImpl());
}

}

Since bundles can be registred or deregistered at any times we need a service tracker:

com.tutorial.event.directory.client:

public class DirectoryWatcherServiceTrackerCustomizer implements ServiceTrackerCustomizer {

private final BundleContext context;

private Thread

public DirectoryWatcherServiceTrackerCustomizer(BundleContext context) {
this.context = context;
}

@Override
public Object addingService (ServiceReference reference) {
IDirectoryWatcher service = (IDirectoryWatcher) context.getService (reference);
service.add (new DirectoryProviderImpl());
return service;
}

...
@Override
public Object removedService (ServiceReference, Object service) {
context.ungetService(reference);
}

}

The Activator looks then like this:

public class Activator {
private ServiceTracker serviceTracker;

public void start (BundleContext context) throws Exception {
DirectoryWatcherServiceTrackerCustomizer customer = new DirectoryWatcherServiceTrackerCustomizer(context);

serviceTracker = new ServiceTracker (context, IDirectoryWatcher.class.getName(), customer);

serviceTracker.open();
}
....
}

The class DirectoryProviderImpl is then regularly informed about events and can do some actions as long the DirectoryWatcher bundle is active and running.

We want now implement the same thing after the whiteboard pattern. The idea behind the whiteboard pattern is to use the OSGi service registry instead to use an own private registry:

com.tutorial.event.directory.client:

public class Activator implements BundleActivator {

public void start(BundleContext context) throws Exception {

IFileEventListener listener = new IFileEventListener() {

public void directoryEvent (final FileEvent event) {

// do something with the event

}
};

context.registerService (IFileEventListener.class.getName(), listener, null);
}
}

com.tutorial.event.directory.watcher:

public class DoSomethingOnDirectoryChange {

public void fireEvent (Event event) {

Object[] services = listenerTracker.getServices();

for (Object service:services) {
IFileEventListener listener = (IFileEventListener) service;
Listener.directoryEvent (event);
}
}
}

As we can see this approach is more elegant than the first one with the event listener pattern.
Let's go back to the event admin service:

The event admin service is part of the OSGi components and can be used for your own purposes. Instead to use some listeners we use a class for each directory which should be observed and make use of the event admin service:

com.tutorial.event.directory.watcher:

public class DirectoryWatcherComponent implements Runnable {

private EventAdmin eventAdmin;

private Thread thread; //thread where we poll the directory

public void setEventAdmin (EventAdmin eventAdmin) {
this.eventAdmin = eventAdmin;
}

public void unsetEventAdmin (EventAdmin eventAdmin) {
this.eventAdmin = null;
}

protected void activate (ComponentContext componentContext) {
thread = new Thread (this);
thread.start();
}

protected void deactivate (ComponentContext componentContext) {
thread.interrupt();
}

public void run() {

try {
File file = new File(path to directory);
File[] oldFiles = file.listFiles();
while (!isInterrupted()) {
//Get the directory information
sleep(1000);

File[] newFiles = file.listFiles();

IFileChangeProvider[] changes = getChanges (oldFiles, newFiles);
oldFiles = newFiles;

if (files==null || files.length ==0) {
continue();
}
for (IFileChangeProvider provider: changes ){

//HERE WE USE NOW THE EVENT ADMIN SERVICE

Directory<String, String> eventProperties =
new Hashtable<String,String>();

eventProperties.put ("Action", provider.getActionAsString());
eventProperties.put ("File", provider.getFilePath());

Event event = new Event (".../DirectoryWatcher", eventProperties);
eventAdmin.sendEvent(event);
}
}

} catch (InterruptedException e) {
//Thread terminates
}

}
}

Create now a file in the directory OSGI-INF called component-description.xml:

<?xml version = "1.0"?>
<component name="directoryWatcherComponent">
<implementation class = "....DirectoryWatcherComponent"/>
<reference name="eventAdmin"
interface="org.osgi.service.event.EventAdmin"
bind ="setEventAdmin"
unbind ="unsetEventAdmin"
/>
</component>

com.tutorial.event.directory.client

public class DirectoryObserverComponent implements EventHandler {

public void handleEvent(Event event) {
event.getProperty ("Action");
event.getProperty ("File");

//do some useful stuff with it
}
}

We need also in the client bundle the file component-description.xml
<?xml version = "1.0"?>
<component name="directoryObserverComponent">
<implementation class="...DirectoryObserverComponent"/>
<property name="event.topics"
<value=".../DirectoryWatcher"/> //see above in the run thread method
<service>
<provide interface="org.osgi.service.event.EventHandler"/>
</service>
</component>

With this information about handling events in OSGi bundles we can now go over to the ECF and the use of the "DistributedEventAdmin" class. Since we are interested in file changes in a directory on a server we have an OSGi platform running on a server. For this purpose we add an extension point of org.eclipse.runtime.applications. In the startup method we add the following code:

(This part will follow tomorrow)

Report message to a moderator