Eclipse Communication Framework

ECF Documentation

 ECF Documentation

   Note: standalone bookmark for the ECF API (javadocs) web pages. Copy and paste: http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api

 Introduction: ECF Containers
ECF introduces the concept of a communications container. ECF containers represent access to a protocol-specific communications context. For connection-oriented communications, an ECF container loosely corresponds to the traditional notion of a communications session, but the more general container concept is also useful for capturing context even if the communications are not session-oriented.

ECF containers can represent both point-to-point communications (e.g. client/server) or publish-and-subscribe (group) communications. Container instances can provide access to synchronous communications only, asynchronous communications only, or both together. This flexibility allows many communications applications to be constructed out of one or more ECF containers...each of which provides access to some specific communications context and some protocol(s) for communicating within that context.

Instance Creation

Container instance creation is done via ECF-provided factory APIs. For example, here's code to create and IContainer instance:
       IContainer container = getContainerFactory().createContainer(<Container Type>);
       
Note that the getContainerFactory() method should return an IContainerFactory instance and this can be accessed as a singleton OSGi Service (via OSGi ServiceReferece, ServiceTracker or Declarative Services). Once constructed, IContainer instances may be used in the manner appropriate for the given application.

Container Types Available at dev.eclipse.org

PROTOCOL(s)

Container Factory Name

Plugin(s)

Supported APIs

HTTP/HTTPS, file, all other protocols supported JRE URLConnection

ecf.base

org.eclipse.ecf,org.eclipse.ecf.provider.filetransfer

File Transfer

HTTP/HTTPS via Httpclient 3.0.1

ecf.base

org.eclipse.ecf,org.eclipse.ecf.provider.filetransfer.httpclient

File Transfer

None

ecf.container.trivial

org.eclipse.ecf.examples.provider.trivial

Core API Only (Example)

ECF Generic Client

ecf.generic.client

org.eclipse.ecf.provider

Shared Object

Datashare

Remote Services

ECF Generic Server

ecf.generic.server

org.eclipse.ecf.provider

Shared Object

Datashare

Remote Services

ECF Bittorrent Filetransfer

ecf.filetransfer.bittorrent

org.eclipse.ecf.provider.bittorrent

File Transfer

IRC

ecf.irc.irclib

org.eclipse.ecf.provider.irc

Presence

Zeroconf/Bonjour/Rendevous

ecf.discovery.jmdns

org.eclipse.ecf.provider.jmdns

Discovery

Java Service Locator Protocol (RFC 2608)

ecf.discovery.jslp

org.eclipse.ecf.provider.jslp

Discovery

MSN

ecf.msn.msnp

org.eclipse.ecf.provider.msn

Presence

r-OSGi

ecf.r_osgi.peer

org.eclipse.ecf.provider.r-osgi

Remote Services

XMPP

ecf.xmpp.smack

org.eclipse.ecf.provider.xmpp

Shared Object

Datashare

Presence

File Transfer

XMPP SSL

ecf.xmpps.smack

org.eclipse.ecf.provider.xmpp

Shared Object

Datashare

Presence

File Transfer



Container Types Available at ECF Github site

PROTOCOL(s)

Container Factory Name

Plugin(s)

Supported APIs

Yahoo

ecf.yahoo.jymsg

org.eclipse.ecf.provider.yahoo

Presence

JavaGroups Client

ecf.jgroups.client

org.eclipse.ecf.provider.jgroups

Shared Object

Datashare

Remote Services

JavaGroups Manager

ecf.jgroups.manager

org.eclipse.ecf.provider.jgroups

Shared Object

Datashare

Remote Services

ActiveMQ Client

ecf.jms.activemq.tcp.client

org.eclipse.ecf.provider.jms.activemq

Shared Object

Datashare

Remote Services

ActiveMQ Manager

ecf.jms.activemq.tcp.manager

org.eclipse.ecf.provider.jms.activemq

Shared Object

Datashare

Remote Services

Weblogic Client

ecf.jms.activemq.tcp.client

ecf.jms.weblogic.client

Shared Object

Datashare

Remote Services

Weblogic Manager

ecf.jms.weblogic.server

org.eclipse.ecf.provider.jms.weblogic

Shared Object

Datashare

Remote Services

Skype

ecf.call.skype

org.eclipse.ecf.provider.skype

Shared Object

Datashare

Presence

Container Instance Disposal

When no longer required the IContainer.dispose() method should be called to release any resources associated with the container instance upon its construction or used during its lifecycle (e.g. network resources, etc).

Connection/Disconnection

The IContainer interface exposes two key methods: connect(ID targetID, IConnectContext connectContext) and disconnect(). As is obvious, these two methods allow container implementations to initiate communication with remote services, either server-based or group-based communications.

Notice the first parameter to the connect method...targetID. TargetID is of type ID. The targetID parameter identifies the target server or group for the connect operation. It is of type ID so that the to allow the target communications service to be of many kinds...e.g. client-server or peer-to-peer. For example, for http communication the targetID would consist of the URL specifying a particular file at a particular path on a particular server...e.g: http://www.eclipse.org/ecf. For some other communications protocol the ID provided would be different...e.g: sip:someone@example.com;transport=tcp. All such targets for connect may be represented via an instance of the ID interface.

Example Code: Container Creation and Connection

Here's an example code snippet that shows the creation and connection of an ECF container:
       // make container instance
       IContainer cont = getContainerFactory().createContainer("ecf.generic.client");
       // make targetID
       ID targetID = IDFactory.getDefault().createID(cont.getConnectNamespace(),"ecftcp://foo.com:3282/server");
       // then connect to targetID with null authentication data
       cont.connect(targetID,null);
       

Namespaces and ID Construction

The org.eclipse.ecf core plugin defines a namespace extension point, so that ECF provider plugins can provide their own Namespace implementations. For example, here is the namespace extension definition for the org.eclipse.ecf.provider.xmpp plugin:
   <extension point="org.eclipse.ecf.namespace">
      <namespace
            class="org.eclipse.ecf.provider.xmpp.identity.XMPPNamespace"
            description="XMPP Namespace"
            name="ecf.xmpp"/>
   </extension>
       
This assigns the name "ecf.xmpp" to the class org.eclipse.ecf.provider.xmpp.identity.XMPPNamespace. Notice that this class must be a subclass of org.eclipse.ecf.core.identity.Namespace. The XMPPNamespace class provides the XMPP namespace implementation and as described above implements the XMPP namespace restrictions. It is also responsible for constructing new ID instances via the ECF IDFactory. For example, to construct an instance of and XMPP ID, a client could use the following code:
       ID newID = IDFactory.getDefault().createID("ecf.xmpp","slewis@foo.com");
       
Underneath the covers of the IDFactory.createID method the following occurs:
  1. The name "ecf.xmpp" is used to lookup it's associated Namespace class (in this case XMPPNamespace). This lookup is done via the Eclipse extension registry.
  2. The XMPPNamespace.createInstance method is called to manufacture an ID that is in the XMPPNamespace from the string "slewis@foo.com"
  3. The new ID is returned to the caller
Note that there are other IDFactory.createID(...) methods that allow parameters other than Strings to be used for ID construction (e.g. URIs).

Container Extensibility through Adapters

To support run-time extensibility, the IContainer interface inherits from org.eclipse.core.runtime.IAdaptable. This interface exposes a single method: the 'getAdapter(Class intf)' method. In the case of IContainer instances, this allows client applications to query the IContainer instance at runtime about it's exposed capabilities, and get access to those capabilities if they are available. So, for example, perhaps we're interested in creating an instant messaging application and wish to use the capabilities exposed by the IPresenceContainer interface. To do this, we simply query the IContainer instance at runtime to see if it provides access to IPresenceContainer capabilities:
       IPresenceContainer pc = (IPresenceContainer) cont.getAdapter(IPresenceContainer.class);
       if (pc != null) {
           // The container DOES expose IPresenceContainer capabilities, so we can use them!
       } else {
           // The container does not expose IPresenceContainer capabilities...we're out of luck
       }
       
Among other positive characteristics, this adapter mechanism provides a consistent-yet-simple way for a wide variety of container types to be defined and used without the need to update the ECF IContainer abstractions.

See the documentation for the IContainer.getAdapter() method. See also a terrific article on EclipseZone about usage of IAdaptable for runtime extensibility

Identity

In ECF, identity of local or remote entities such as users, remote services, and groups are all represented via the ID interface. This interface provides the basic contract for addressing uniquely identified entities. ID instances belong to a given Namespace Namespaces define the range of allowable values of the ID instances belonging to that Namespace. So, for example, the Namespace of XMPP (Jabber) user identities is defined by XMPP RFC3920 as having the following structure
      jid             = [ node "@" ] domain [ "/" resource ]
      domain          = fqdn / address-literal
      fqdn            = (sub-domain 1*("." sub-domain))
      sub-domain      = (internationalized domain label)
      address-literal = IPv4address / IPv6address
      example         = slewis@foo.com/ecf
       
The ECF XMPP provider implementation restricts jids to this syntax by providing a Namespace subclass responsible for constructing ID instances that follow the rules defined by the protocol specification. Other communications protocols and their associated service identities have their own Namespaces (e.g. ftp, http, sip, irc, etc, etc), each with it's own requirements for addressing and identity. The ID contract is not bound to any specific protocol, and makes it possible to create client applications that are insensitive to the addressing differences between protocols while still guaranteeing basic uniqueness requirements within a given namespace.

Example: Container creation, ID creation, container adapter, and connection

         // Create the new container 
		IContainer client = ContainerFactory
				.getDefault().createContainer(containerType);
		// Create the targetID 
		ID targetID = IDFactory.getDefault().createID(client.getConnectNamespace(), uri);
	    // Check for IPresenceContainer....if it is, setup presence UI, if not setup shared object container
		IPresenceContainer pc = (IPresenceContainer) client
				.getAdapter(IPresenceContainer.class);
		if (pc != null) {
			// Setup presence UI
			presenceContainerUI = new PresenceContainerUI(pc);
			presenceContainerUI.setup(client, targetID, username);
		} else throw new NullPointerException("IPresenceContainer interface not exposed by client with type "+containerType);
		// connect
		client.connect(targetID, getJoinContext(username, connectData));
       
UNDER CONSTRUCTION 6/17/07
back to top