Skip to main content

[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




Back to the top