Home » Archived » Eclipse Communications Framework (ECF) » server-side logic
| server-side logic [message #601185] |
Wed, 15 March 2006 13:42  |
|
Hi,
I'm currently evaluating ECF as a replacement for
some parts of my Net4j/CDO framework (part of EMFT),
but I'm struggling in understanding and separating
the vast numbers of ECF concepts.
CDO is a technology to support distributed shared
and relational persistent EMF models (resources).
Net4j is a (client-server based) framework for
distributed communications, in some sense similar
to what ECF is. It consists of Eclipse plugins
client and server side. Net4j has concepts for
extensible transport layer protocols and extensible
application layer protocols. At transport layer
there are protocol implementations for NIO and
embedded connections.
CDO is an implementation of a Net4j application
layer protocol. It consists of Eclipse plugins
client and server side. At client side a protocol
peer interacts with EMF Resource(Set) instances
and at server side a protocol peer is connected
with an O/R mapper instance.
Now I'd like to replace all the transport related
stuff of Net4j by ECF things and use an MDA-like
approach to generate all the application protocol
related stuff. Something like asymmetric protocol
state machines out of a communications model.
As I said front up I'm not sure which of your
concepts do best relate to mine (and there's not
enough documentation for ECF yet, which is true
for my projects, too ;-) ).
One concrete question is obvious, though:
For my CDO mapper (and in general) I need the
possibility to deploy Eclipse plugins at server
side. In fact my server is a headless Eclipse
instance. Does that work with the ECF generic server?
Cheers
/Eike
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: server-side logic [message #601200 is a reply to message #601185] |
Wed, 15 March 2006 16:06  |
 Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Eike,
Eike Stepper wrote:
> Hi,
>
<stuff deleted>
>
> As I said front up I'm not sure which of your
> concepts do best relate to mine (and there's not
> enough documentation for ECF yet, which is true
> for my projects, too ;-) ).
The central concept in ECF is that of a IContainer...a protocol
independent communications container. This is an abstraction that aims
to be:
1) Protocol independent...and able to be implemented using whatever
protocol is available/preferable/appropriate (including the ones you listed)
2) Simple...there's not very much too it, but it does supply the basics
of IContainer lifecycle management, connect/disconnect, and asynch event
notification through listeners
2) Extensible...so that protocol-specific semantics can be accessed at
runtime by clients of the IContainer instance. This extensibility is
achieved by using what we refer to as 'protocol adapters'. This is the
use of the Eclipse IAdaptable interface (which IContainer extends) to
get access to more specific/less abstract protocol semantics via the
IContainer...e.g.:
IPresenceContainer pc = (IPresenceContainer)
container.getAdapter(IPresenceContainer.class);
So given your desires, Eike, I *think* what you are looking for is to
create what we call an ECF provider...that is, an implementation of
IContainer using one or several of the protocols you list above as
implementations. This is perfectly reasonable...and in fact encouraged
strongly! We want as many implementations of various protocols as
possible...so that interoperability between them at the client
application level can be delivered (i.e. clients and UIs that use
multiple protocols can be easily created).
Chris Anisczck just published a short tutorial on creating a Yahoo IM
ECF provider implementation of IContainer that you might want to take a
look at. It's here:
http://www-128.ibm.com/developerworks/opensource/library/os- ecl-commfwk/
It steps through the creation of an Yahoo IM IContainer instance that
implements IContainer and the IPresenceContainer protocol adapter. But
the idea could be the same for your protocols, and the implementation of
IChannelContainer (datashare) if that's the communication semantics that
you wish to expose to clients.
>
> One concrete question is obvious, though:
> For my CDO mapper (and in general) I need the
> possibility to deploy Eclipse plugins at server
> side. In fact my server is a headless Eclipse
> instance. Does that work with the ECF generic server?
Well, we're working on that actively right now. As of just a couple
weeks ago, the ECF generic server is now being run in a servlet
container running the OSGI runtime. This ECF server is using the
Equinox servlet incubator work:
http://www.eclipse.org/equinox/incubator/server/
to run the ECF plugins all within a servlet-based OSGI runtime. Among
other things, what this allows is the easy installation and
configuration of ECF servers...i.e. by creating server bundles/plugins
and then simply installing them into a running server. All the
bundle/plugin dependencies (classpath etc) are automagically managed via
the Equinox runtime mechanisms (such as buddy classloading, etc).
So although this work is just getting started...we do think it will be
extremely important for ECF server creation and extension, as it will
allow folks like you to build ECF server plugins, build and test them
within Eclipse itself using the PDE, and then deploy them to a server
environment that is similarly equipped (i.e. not just a java application
with a cmd-line specified classpath, etc).
ECF is soon (after EclipseCon) starting a semi-formal 'modular ECF
servers' sub-project to work with the Equinox team in these directions.
Eike if you can participate in that sub-project it would be most
welcome.
And Eike...are you going to be at EclipseCon? Any chance you will be
attending my and Chris A's ECF tutorial?
http://www.eclipsecon.org/2006/Sub.do?id=46
Thanks,
Scott
|
|
|
| Re: server-side logic [message #601220 is a reply to message #601200] |
Wed, 15 March 2006 19:35 |
|
Scott Lewis schrieb:
> Hi Eike,
>
> Eike Stepper wrote:
>> Hi,
>>
> <stuff deleted>
>>
>> As I said front up I'm not sure which of your
>> concepts do best relate to mine (and there's not
>> enough documentation for ECF yet, which is true
>> for my projects, too ;-) ).
>
> The central concept in ECF is that of a IContainer...a protocol
> independent communications container.
By protocol do you mean transport protocol or application protocol or both?
> This is an abstraction that aims to be:
>
> 1) Protocol independent...and able to be implemented using whatever
> protocol is available/preferable/appropriate (including the ones you
> listed)
> 2) Simple...there's not very much too it, but it does supply the basics
> of IContainer lifecycle management, connect/disconnect, and asynch event
> notification through listeners
> 2) Extensible...so that protocol-specific semantics can be accessed at
> runtime by clients of the IContainer instance. This extensibility is
> achieved by using what we refer to as 'protocol adapters'. This is the
> use of the Eclipse IAdaptable interface (which IContainer extends) to
> get access to more specific/less abstract protocol semantics via the
> IContainer...e.g.:
>
> IPresenceContainer pc = (IPresenceContainer)
> container.getAdapter(IPresenceContainer.class);
>
> So given your desires, Eike, I *think* what you are looking for is to
> create what we call an ECF provider...that is, an implementation of
> IContainer using one or several of the protocols you list above as
> implementations. This is perfectly reasonable...and in fact encouraged
> strongly! We want as many implementations of various protocols as
> possible...so that interoperability between them at the client
> application level can be delivered (i.e. clients and UIs that use
> multiple protocols can be easily created).
Thanks for these hints. I will have to further work out the relations
between the various implementations of these concepts. But your explanations
have been very helpful.
> Chris Anisczck just published a short tutorial on creating a Yahoo IM
> ECF provider implementation of IContainer that you might want to take a
> look at. It's here:
> http://www-128.ibm.com/developerworks/opensource/library/os- ecl-commfwk/
>
> It steps through the creation of an Yahoo IM IContainer instance that
> implements IContainer and the IPresenceContainer protocol adapter. But
> the idea could be the same for your protocols, and the implementation of
> IChannelContainer (datashare) if that's the communication semantics that
> you wish to expose to clients.
Yeah, this is very welcome ;-)
I'll go through it.
>> One concrete question is obvious, though:
>> For my CDO mapper (and in general) I need the
>> possibility to deploy Eclipse plugins at server
>> side. In fact my server is a headless Eclipse
>> instance. Does that work with the ECF generic server?
>
> Well, we're working on that actively right now. As of just a couple
> weeks ago, the ECF generic server is now being run in a servlet
> container running the OSGI runtime. This ECF server is using the
> Equinox servlet incubator work:
> http://www.eclipse.org/equinox/incubator/server/
>
> to run the ECF plugins all within a servlet-based OSGI runtime. Among
> other things, what this allows is the easy installation and
> configuration of ECF servers...i.e. by creating server bundles/plugins
> and then simply installing them into a running server. All the
> bundle/plugin dependencies (classpath etc) are automagically managed via
> the Equinox runtime mechanisms (such as buddy classloading, etc).
Is there also effort planned to make an ECF server work in a pure headless
Eclipse instance?
> So although this work is just getting started...we do think it will be
> extremely important for ECF server creation and extension, as it will
> allow folks like you to build ECF server plugins, build and test them
> within Eclipse itself using the PDE, and then deploy them to a server
> environment that is similarly equipped (i.e. not just a java application
> with a cmd-line specified classpath, etc).
>
> ECF is soon (after EclipseCon) starting a semi-formal 'modular ECF
> servers' sub-project to work with the Equinox team in these directions.
> Eike if you can participate in that sub-project it would be most welcome.
Thanks for your trust!
It could indeed be interesting, so please keep me uptodate with your plans...
> And Eike...are you going to be at EclipseCon? Any chance you will be
> attending my and Chris A's ECF tutorial?
I didn't plan it this year, but I just signed a good contract and
fundings are secured ;-) So I will look if I can get one of the last
committer passports. I'll study the tutorials plan and keep you
informed, too.
Cheers
/Eike
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: server-side logic [message #601235 is a reply to message #601220] |
Wed, 15 March 2006 20:19 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Eike,
Eike Stepper wrote:
>
>
<stuff deleted>
>
> By protocol do you mean transport protocol or application protocol or both?
ECF API plugins (like datashare) are meant to be a software API for a
'class' of application-level protocols (e.g. file sharing, unstructured
data sharing, presence, VOIP call setup/control). ECF providers are
intended to provide the mapping between the desired application-level
semantics (e.g. data sharing), and the underlying protocol
implementation to present that behavior to the application...including
the wire/transport protocol.
So, for example, I can write a single application that uses datashare to
send/receive byte arrays and then substitute say, JMS, for ECF generic
providers, and get exactly the same app-level behavior with multiple
wire protocols.
<stuff deleted>
>
>
> Thanks for these hints. I will have to further work out the relations
> between the various implementations of these concepts. But your
> explanations
> have been very helpful.
Good. It's not as if I am trying to keep these concepts to myself or
anything...it's just very difficult to satisfy all the current demands
on ECF (more docs, more framework code, applications, etc) with the
current level of resources. But I'm working to change that (the current
level of resources and the number/discursiveness of the demands).
>
>
>> Chris Anisczck just published a short tutorial on creating a Yahoo IM
>> ECF provider implementation of IContainer that you might want to take
>> a look at. It's here:
>> http://www-128.ibm.com/developerworks/opensource/library/os- ecl-commfwk/
>>
>> It steps through the creation of an Yahoo IM IContainer instance that
>> implements IContainer and the IPresenceContainer protocol adapter.
>> But the idea could be the same for your protocols, and the
>> implementation of IChannelContainer (datashare) if that's the
>> communication semantics that you wish to expose to clients.
>
>
> Yeah, this is very welcome ;-)
> I'll go through it.
Yes, very welcome indeed.
<stuff deleted>
>
>
> Is there also effort planned to make an ECF server work in a pure headless
> Eclipse instance?
Yes...actually, there *was* an effort to run the ECF generic server in
an Eclipse instance running in a servlet container (tomcat) in this
case. The server that hosts the ecf group:
ecftcp://ecf.eclipse.org:3282/server is running in this mode.
You can check out the trivial server 'admin login' here:
http://ecf.eclipse.org:8080/bridge/servlet/console
For those that are interested in seeing more than the login interface
please just drop be a line to slewis@composent.com and I'll let you
access the admin UI (with username and password).
>
>> So although this work is just getting started...we do think it will be
>> extremely important for ECF server creation and extension, as it will
>> allow folks like you to build ECF server plugins, build and test them
>> within Eclipse itself using the PDE, and then deploy them to a server
>> environment that is similarly equipped (i.e. not just a java
>> application with a cmd-line specified classpath, etc).
>>
>> ECF is soon (after EclipseCon) starting a semi-formal 'modular ECF
>> servers' sub-project to work with the Equinox team in these
>> directions. Eike if you can participate in that sub-project it would
>> be most welcome.
>
>
> Thanks for your trust!
> It could indeed be interesting, so please keep me uptodate with your
> plans...
>
>
>> And Eike...are you going to be at EclipseCon? Any chance you will be
>> attending my and Chris A's ECF tutorial?
>
>
> I didn't plan it this year, but I just signed a good contract and
> fundings are secured ;-) So I will look if I can get one of the last
> committer passports. I'll study the tutorials plan and keep you
> informed, too.
If you or others are interested, all the materials for the tutorial are
checked in at CVS module
/home/technology/org.eclipse.ecf/tutorials/EclipseCon 2006/*.pdf
Any comments/thoughts/criticisms welcome.
Scott
>
> Cheers
> /Eike
>
>
>
|
|
|
| |
  |
Goto Forum:
Current Time: Fri Apr 26 05:02:20 GMT 2024
Powered by FUDForum. Page generated in 0.03241 seconds |
] 
Search
Help
Register
Login
Home
