[news.eclipse.technology.ecf] Re: Server architecture?

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Bryan,

We currently have two provider implementations for ECF:

1) a 'generic' reference implementation (in org.eclipse.ecf.provider 
plugin, incidently)
2) XMPP (in org.eclipse.ecf.provider.xmpp).  This one uses the Jive 
Smack API to communicate with an XMPP server

We will soon be working on one based upon a JMS implementation (and some 
others).  We're not yet sure which JMS implementation we will be using, 
however.

So, as for the server architecture...the server architecture will, of 
course, be specific to the provider implementation.  For the reference 
implementation there is a trivial server implemented in the 
org.eclipse.ecf.provider plugin, with class: 
org.eclipse.ecf.provider.app.ServerApplication.

In this class you will see that the application creates an instance of a 
'TCPServerContainer' and it does all the work.  This is an ECF shared 
object container implementation that serves as a server (based upon just 
raw TCP communication).  This TCPServerContainer implementation does all 
the work of the server...which is, basically, to be a container for 
shared object instances (like all the client container instances), but 
to also do message fan out, group authentication, and provide other 
group management functions.  If you look at the TCPServerContainer type 
hierarchy you will see the following class structure:

SOContainer
      \
   ServerSOContainer
  	\
      TCPServerSOContainer

The SOContainer class is an abstract and 'topology independent' 
container implementation.  Note that the ClientSOContainer is a direct 
subclass of SOContainer also.  We will also likely use the SOContainer 
class as a superclass for container implementations that are based upon 
peer-to-peer protocols as well...e.g. JavaGroups, others, etc.

Of course, you and anyone are completely free to use/reuse/inherit from 
this code to build custom server implementations...or replace all of it 
with your own implementation of ISharedObjectContainer (the core 
required container interface).

Note also that the org.eclipse.ecf.provider plugin makes the 
TCPServerContainer available via the SharedObjectContainerFactory, so 
that the following will create an instance of a TCPServerContainer:

ISharedObjectContainer servercontainer = 
SharedObjectContainerFactory.makeSharedObjectContainer("org.eclipse.ecf.provider.generic.Server");

Applications can therefore create/start/run servers from within Eclipse 
as well.  If you are curious about this, see the declaration within the 
org.eclipse.ecf.provider/plugin.xml that starts like this:

   <extension
         point="org.eclipse.ecf.containerFactory">
      <containerFactory
            class="org.eclipse.ecf.provider.generic.ContainerInstantiator"
            description="Generic Server Container Instantiator"
            name="org.eclipse.ecf.provider.generic.Server">


One more point about the code in org.eclipse.ecf.provider (and 
org.eclipse.ecf):  They don't have any dependency on Eclipse...*their 
only runtime dependency is on Java 1.4+ and OSGI 3.0*.  This makes them 
potentially useful for the development of a more complete server 
implementation without requiring Eclipse itself.  Our intention is to 
keep the ECF core codebase that way...to have the use of the ECF 
interfaces (org.eclipse.ecf plugin) and the generic provider 
implementation (org.eclipse.ecf.provider) *only* depend upon java and 
OSGI 3.0 so as to support provider implementations from a variety of 
sources (commercial and/or open source), without the need for non-OSGI 
Eclipse code on the server...indeed without the need even for java on a 
server, etc.

We are working on further docs...we'll do our best to produce them 
quickly.  Hopefully this will help get things going for you though. 
Please let us know if you wish to implement your own new ECF provider 
with your own server.  We will happily help.

Scott


Bryan Hunt wrote:
> I was looking a bit at ECF and noticed that you are using a server (for 
> at least the chat part).  Do you have any docs on the server 
> architecture?  I was thinking that a server based on maybe the rich 
> client platform or maybe J2EE could be very interesting.
>
> Bryan