[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] What can / must not be done with ECF ?
|
Hi Cyril,
cyril giraudon wrote:
Hello,
I'd like to learn eclipse RCP technology in the context of a
distributed (not web) application (client / server).
My first glance was for RMI and then read same papers about ECF.
The use of RMI would be for some calls of remote sevices, object
transfers, sending messages over a secured layer, strong authentication.
Since comments about ECF could make think ECF can be a replacement for
RMI in a some tasks, I'd like to know, if it's possible to answer,
what can / must not be done with ECF.
Hmmm, interesting questions.
RMI is based upon the notion of using remote procedure call (RPC) for
building distributed systems. ECF is closer to a category of
distributed systems frameworks called 'message oriented
middleware'...because the basic model for ECF uses asynchronous
messaging. Message-oriented middleware also includes 'group' messaging
(aka 'publish and subscribe' messaging...i.e. not just single sender and
single receiver as in traditional client-server).
ECF also supports remote procedure call as well (e.g. the ECF remote
services API), as RPC can be (and is) implemented above an asynchronous
messaging layer. Of course, you can go the other way...i.e. implement
asynchronous and group messaging on RPC-based abstractions like RMI.
I think ECFs main strength lies in the notion of creating open
transport-independent messaging APIs. The main ECF APIs: discovery,
datashare, filetransfer, remote services, shared object, presence,
telephony, new ones, etc all share at least two very useful
properties...which I believe are at least closely related to 'openness':
a) the APIs are wire protocol independent...i.e. these apis can (and
have been) implemented on multiple transports and their openness allows
others to create their own transports, own clients/peers, own servers if
they desire
b) they are extensible...using consistent and open extensibility
mechanisms (i.e. OSGi, IAdaptable)
'a' supports greater freedom for integration as well as greater
reuse...i.e. multiple clients and/or servers can be written for a given
protocol.
'b' allows the framework to more flexibly respond to the changing needs
of application developers over time.
As for your questions...i.e. what can/ must not be done with ECF?
What can be done with it: lots. As a framework, we've tried to put as
few limitations in as possible...that is, I believe it's possible to
build very scalable, very performant, very appealing applications with
ECF/pieces of ECF...for a relatively low cost (in code size, memory
space, programmer learning time). It's designed to support both
human-human kinds of communication (e.g. IM, VOIP, filetransfer) as well
as inter-process communication (datashare, remote services, discovery,
filetransfer).
But, I would say that there are parts that are much more mature than
others...for example, we haven't yet done a tremendous amount with the
ECF telephony APIs for doing VOIP. We have done some, but not nearly as
much as with (for example), the datashare APIs. Also, our documentation
is not nearly as complete as it should be. So although lots can be done
with ECF, it still has some way to go in certain areas...but we are
trying to move in those directions as much as possible to address these
areas.
What must not be done with ECF...well, I would say that if your
application has no need for interprocess communication then the overhead
of adding asynchronous messaging would not be worth it. Also, if you
have a legacy app that has a private protocol, and there is no benefit
to you, developers, or users to having others be able to build
applications that interoperate with yours, then ECF's communications
abstractions would not be of enough benefit.
I hope this helps. If others have comments about what ECF provides that
is useful or not useful please speak up.
Thanks,
Scott
Thanks a lot,
Cyril.
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
