[
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:
Thanks Scott for your detailled answer,
So, I'd like to be sure. I understand that if i want to write a :
- classical client / server application (which coud be based upon RMI);
- with no synchronous messaging need;
- with no VOIP need;
- no private protocol, i'd like to use an XMPP server (eventually
connect ECF compatible python clients if it's possible one day).
Normaly, I should find all the bricks in ECF ?
I think so. The main bricks from ECF:
1) ECF core (identity and core bundles)
2) ECF remote services API (org.eclipse.ecf.remoteservices)
3) ECF XMPP provider (org.eclipse.ecf.provider.xmpp)
4) optionally...presence API, others/UI bundles?
The ECF remote services API provides you with the ability to do
'classical' client/server (where the 'server' for a given service can be
any peer/participant). Note that if you want the server itself to
provide access to arbitrary remote services then it will be necessary to
implement an XMPP server in/on OSGi...which although we would like to
have one we do not have one that is part of ECF...yet. There have been
several folks that have expressed interest here and on the newsgroup
however...so it might be possible to put together a sub-project to
create an OSGi/Equinox-based XMPP server using ECF.
Another technical question, is there really some cases where
synchronous messages is the only solution to design an application ?
In my opinion, no. In some cases it is easier to create a distributed
application purely based upon synchronous messaging (actually
call-return semantics/RPC...where methods/procedures 'look' the same
whether invoked locally or remotely), but I would say that it's likely
to be possible in nearly all cases to build the application using either
asynchronous approaches and/or both.
There are things that make asynchronous messaging harder to use in some
contexts (e.g. error handling and not having a blocking call/call stack
around when asynchronous events are received). And there are things
that make synchronous messaging undesirable (e.g. having methods block
or fail unpredictably because they require a network operation).
I'm of the opinion that optimally the programmer should/has to choose
from a tool box of both synchronous/RCP and asynchronous messaging
approaches, based upon application-level (or even middleware-level)
requirements...e.g. reliability, user interface responsiveness, required
flexibility, required scalability, etc.
ECF's remote services API presents an RPC approach that allows remote
methods to be invoked via blocking/synchronous call/return, asynchronous
invocation with callback, the use of a notion called a
'future/IAsyncResult', and a pure asynchronous 'fire and go' approach.
Of course, we also allow people to do 'transparent RPC' (i.e. accessing
an OSGi service just like it was a local/in process service).
The ECF IRemoteService interface documents these approaches:
http://www.eclipse.org/ecf/org.eclipse.ecf.docs/api/org/eclipse/ecf/remoteservice/IRemoteService.html
Here is some test code that shows the usage of the various
IRemoteService methods:
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.ecf/tests/org.eclipse.ecf.tests.remoteservice/src/org/eclipse/ecf/tests/remoteservice/?root=Technology_Project
(see the public methods test* in the AbstractRemoteServiceTest class.
Also see public test* methods in the AbstractServiceTrackerTest
class...which shows the use of 'transparent RPC' via the OSGi
ServiceTracker).
I know, this question is out of context but your opinion is important
for ECF adoption.
Yeah, it is a larger question about the construction of reliable
distributed systems/applications. Like I said above, I'm of the opinion
that even though it creates more complexity for the programmer (i.e.
more than one-way to construct a distributed application), it's better
to provide several models for interprocess communication (synch, asynch,
etc)...and allow/support middleware and/or application-level concerns to
dictate the 'correct' approach, rather than to have the
infrastructure/network abstractions only allow one approach.
Does Asynchronous equal to less responsive client than synchronous (in
the context of ECF) ?
No. Actually, in many cases, it's likely to be the opposite. Take, for
example, making a synchronous RPC call in the user interface thread...by
mistake or by design. Because of network latency, jitter (variability),
and relatively frequent network partition, such a remote call may fail
with a runtime exception, or simply block forever. This can/could
result in the user interface 'freezing', because of some issue with the
network or with a remote machine. Obviously, to the user this would not
look more responsive :).
Thanks a lot,
OK, hopefully this helps.
Scott
