ECF 1.2

ECF 1.2 has just been released. Highlights: lots of UI work (not all of it with zx's picture...is that a UI improvement? ;-), cool work on remote services, discovery API improvments, and a fair amount more. Lots of great community contributions via BugDay.

Remote OSGi Services: Questions of Transparency

Recently, I've been having discussions with various folks about whether network transparency for remote OSGi services is a 'good thing'.

I think a reasonable summary of the discussion is that under the right conditions, it can be a good thing, because it makes it possible to easily create distributed applications using consistent APIs...without learning network specific service APIs.

OTOH, under the wrong conditions and assumptions, too much network transparency can make it very hard or impossible to build reliable distributed components or applications (for details see the classic Note on Distributed Computing Paper).

With our own Remote Services API in ECF, we've tried to create an API so that it's easy to use either approach...and attempt to steer clear of the religious wars. So, for example, in ECF here's how you register a remote service (for the 'server' of that service) to be accessed ...either transparently or not-transparently:

IConcatService serviceImpl = new ServiceImpl();
Dictionary props = new Hashtable();
props.put(Constants.LOCAL_SERVICE_REGISTRATION, "true");
// Register serviceImpl
context.registerRemoteService(new String[] {IConcatService.class.getName()}, serviceImpl, props);

And then on the service client, you can access it like any other OSGi service...and underneath a proxy is created (this looks exactly the same whether the service is local or remote):

ServiceReference ref = bc.getServiceReference(IConcatService.class.getName());
IConcatService concatService = (IConcatService) bc.getService(ref);
concatService.call();
// call concatService...calls proxy and sends the call to remote serviceImpl

Alternatively, clients can also access a IRemoteService instance via a service property, and do things like send an asynchronous message to invoke the service...for example:

ServiceReference ref = bc.getServiceReference(IConcatService.class.getName());
IRemoteService remoteService = (IRemoteService) ref.getProperty(Constants.REMOTE_SERVICE);
// Call it with listener for return/result. This returns immediately and then later
// calls the remoteCallListener
remoteService.callAsynch(remoteCall, remoteCallListener);

Of course you could claim that is chickening out on the transparency battles, but I tend to think of it as simply recognizing that there are lots of distributed applications out there that can (and should and will) be implemented on OSGi runtimes, and they all differ in their needs...e.g. for synch vs. asynch, or handling of partial failure, or in their timing/performance requirements.

Messaging for Servers

Among some of the New and Noteworthy for ECF 1.1 are some new providers

ActiveMQ/Websphere CE (JMS)
BEA Weblogic (JMS)
JGroups

The first two depend upon/use commercial implementations of the Java Messaging Service (JMS) associated with Websphere Community Edition and BEA Weblogic, respectively. ActiveMQ is also an Apache open source project (activemq.apache.org). The third is an open source reliable multicast implementation used in JBoss called JavaGroups.

Included with each of these providers is an Eclipse IApplication that allows them to be run as a stand-alone OSGi/ECF-based server.

This also expands the set of providers that support the ECF remote services API: an API for invoking OSGi services remotely...via synchronous method call and/or asynchronous invocation. Each of these providers implements the ECF remote services API, showing that a single API for remoting really can (and does) run on multiple wire transports and multiple network topologies...an elusive goal for much of the web services world.

Remote OSGI over XMPP

In a previous post, I showed how real-time collaboration could be added to Eclipse/RCP apps using ECF datashare API running on the ECF XMPP provider.

One can also use ECF to make remote OSGi calls using the ECF remoteservices API.

For example, on an ECF XMPP peer that is to be the 'server' for a given service (a trivial IConcatService in this case):

  // Get ECF adapter for remote services
  IRemoteServiceContainerAdapter adapter =  ... (e.g. from contacts list)
  // Get targetID[] buddies who are to receive service registration
  ID [] targetIDs = ... (e.g. from contacts list)
  Dictionary props = new Hashtable();
  props.put(Constants.SERVICE_REGISTRATION_TARGETS,targetIDs);
  // Create service instance...this does the actual concatenate
  Object concatService = new IConcatService() {
          public String concat(String string1, String string2) {
              return string1.concat(string2);
          }
      };
  // Register service instance
  adapter.registerRemoteService(new String[] { "IConcatService" }, concatService, props);
  // Service now registered

And for clients to lookup and use the service:

   // Get adapter for accessing remote services
  IRemoteServiceContainerAdapter adapter =  ...
  // Get remote service reference
  IRemoteServiceReference[] refs = adapter.getRemoteServiceReferences(null, "IConcatService", null);
  // Get service for remote reference
  IRemoteService service = adapter.getRemoteService(refs[0]);
  // Create remote call
  IRemoteCall remoteCall =  new IRemoteCall() {
          public String getMethod() {
              return "concat";
          }
          public Object[] getParameters() {
              return new Object[] { "Eclipse", " is cool" };
          }

          public long getTimeout() {
              return 3000;
          }};
  // Call synchronously
  String result = (String) service.callSynch(remoteCall);
  System.out.println("concat result is: "+result);
  // prints out:  concat result is: Eclipse is cool

Further, note that the client can use any of the 'style's of remote invocation desired:

IRemoteService.callSynch(...)
IRemoteService.callAsynch(...)
IRemoteService.fireAsynch(...)
IRemoteService.getProxy()

With 'getProxy()' this returns an instance that implements IConcatService, and allows direct method invocation:

IConcatService concat = (IConcatService) remoteService.getProxy();
String result = concat.concat("OSGi"," is cool");
System.out.println("concat result is: "+result);
// prints out:  concat result is: OSGi is cool

There is more test and example code available here. Note that with the IRemoteService.callAsynch, callSynch, and fireAsynch methods it is not even necessary that the client have the service interface locally. All that is needed is the string identifying the desired class name.

The support for remote services on the ECF generic provider is already in ECF 1.0.0, and the support for doing remote services on XMPP will be available in ECF 1.0.2.

Real-time Collab Over plain 'ol XMPP

Something cool: real-time collaboration in Eclipse via XMPP. The point here is that with the ECF Datashare API, it's possible to send arbitrary messages to folks on your XMPP (or Google Talk, or soon Skype) buddy list, and with the new Eclipse 3.3 menuContribution API, it's very easy to create your own plugin, that uses ECF's MultiRosterView to add on your own actions (like making a Skype call, or sending an URL to team mate, or playing Sudoku with a buddy, etc). No need to understand XMPP, to use any of this, just send/receive data (byte []s).

Now available via dev/integration build. See here for links to latest download.

Here's a class which is responsible for sending/receiving the URL (most of it is UI code. See sendURL and handleMessage/showURL).

Skype Provider for ECF

ECF is soon going to make available a dev build for a Skype Provider. If you have some appropriate sounds, please consider donating them to us to use as a ring tone within Eclipse. See bug #182840.

ECF 1.0.0 milestone 6 released

ECF 1.0.0 milestone 6 released. Some cool new stuff...e.g.

1) A new 'bot' API/plugin (org.eclipse.ecf.presence.bot) to allow people to create IM and chat room robots that can respond to messages.
2) Committer Remy Suen has created a very cool Bot Framework Tutorial.
3) A history API for IM/chat room history.
4) Peer-to-peer file transfer over XMPP
5) Work on file transfer API to support the Equinox provisioning incubator effort.

Here's the download page: http://www.eclipse.org/ecf/downloads.php
New and Noteworthy: http://www.eclipse.org/ecf/NewAndNoteworthy.html

And we've done lots of work on making the ECF core and API plugins able to run on any/all Equinox runtimes (e.g. servers, RCP, Eclipse, etc). See this bug here for details: bug #176322.

Next Up: Implementation of ECF call API with Jingle (Google Talk), and Skype as well as support for Europa M7, further work on supporting Equinox provisioning as needed, a continuous build server for daily integration builds, and bug fixes (of course).

ECF 0.9.6 stable released

ECF is releasing 0.9.6 stable today (Jan 13, 2007). It has quite a few positive changes in the simplification of the presence API, the easier creation and customization of roster user interfaces via the new plugin: org.eclipse.ecf.presence.ui, use of the new connect and configuration wizard extension points, and lots of bug fixes. See here for the download, here for the New and Noteworthy, and here for the planned and completed fixes and enhancements.

ECF 0.9.4 Stable Released

ECF 0.9.4 stable released. Download here. New and Noteworthy here. Also created project milestone plan (tentative) and put here.

ECF 0.9.4 on 12/2/2006

ECF 0.9.4 stable will be available on 12/2/2006. The new things will be two UI extension points, to allow ECF providers to create custom configuration wizards and connect wizards. The extension points are org.eclipse.ecf.ui.configurationWizards and org.eclipse.ecf.ui.connectWizards. Both are in the org.eclipse.ecf.ui plugin.

Also, the UI/Example application refactoring has begun, with initial changes/refactoring of the RosterView. For the next few releases (0.9.4+) there will be many more changes to the UI and example application code as the focus has shifted from UI to application refactoring.

ECF 0.9.3 stable released

ECF 0.9.3 (the 'API refactoring' release) is available here. The new and noteworthy describes the changes made to the APIs. NOTE: This is a backward-compatibility breaking release, as some of the code moved out of existing packages and into new plugins and packages. The API refactoring was driven by requests and requirements described here.

OSGI components on server and ECF

There's an excellent article about the recent Equinox incubator
work.

One point that's not mentioned in the article: in addition to web servers, collaboration and messaging servers (e.g. IM, file sharing, voip/conferencing, Asterisk, etc., etc) can also
benefit tremendously from being able to run the Eclipse/OSGI component model on the server. For example, for ECF's 'generic server' we will be able to introduce
plugins dynamically on both clients and servers, using the same basic component model and the same
plugin development tools (Eclipse). This is a big deal for ECF.


Here is the Equinox incubator project

ECF 0.6.0 and 0.6.1

ECF 0.6.0 is available here
Here is the 0.6.0 New and Noteworthy.

We will be doing a 0.6.1 build during week of 1/23/06. The main new addition
for 0.6.1 will be a new API called 'datashare' that allows the easy
creation of various asynchronous channels that have different msg delivery
ordering semantics.

ECF 0.6.0

The ETA for ECF 0.6.0 is 1/15/06. This release will be mostly API changes and bug fixes
rather than new features. Specifically:

• SharedObjectFactory extension point (new) so that plugins can register themselves as implementers of shared object types


• Fixes for JmDNS hang issues (zeroconf/bonjour provider implementation)


• Revised API signature for ID and IContainer instance construction

Jingle

Some very exciting things coming out of Google Talk. Jingle for example.

Greetings

I (Scott Lewis) lead the Eclipse Communication Framework project