| [corona-dev] Communication Alternatives |
|
·
A synchronous call performs its
action completely by the time the call returns. Synchronous communications
are needed for request/response operations. ·
An asynchronous call returns
immediately but its action does not immediately complete. When the action
completes, the success or failure status returns through a callback on a
responder object. Asynchronous communications are needed for
collaboration events. The The Eclipse Workbench (client) will have the Eclipse Communication
Framework (ECF) installed. This will provide collaboration tools such as
chat and shared editors. The issue that must be resolved is: how should the Eclipse Workbench
(corona-client) communicate with the The following are the identified alternatives: 1) ECF
for both synch/asynch 2) Web
services for both synch/asynch 3) Web
services for synch / ECF for asynch There have been several debates on these. I would like to conduct
additional discussion in this email forum. Please post your replies to corona-dev@xxxxxxxxxxx. -----Original Message----- Hi, We have investigated the subject and it doesn't look good. In fact the only hook about synchronous communication we could find is org.eclipse.ecf.core.comm.ISynchAsynchConnection. The implementation of
the interface is org.eclipse.ecf.provider.comm.tcp.Client, and it is used by TCPClientSOContainer. The ISynchAsynchConnect.sendSynch() implemented in org.eclipse.ecf.provider.comm.tcp.Client sends a
message, flushes it and closes the link (in fact it only marks the connection to
be closed but it is not closed in fact). It do not read response from the other side and always returns null. Maybe it is just unfinished implementation, but this is how it looks now. The code was checked out today. We have made an experiment with it and it worked as described above - the server received a message, but client received null. Every
following request to the server ended with connection closed exception. We used ECF 0.8.3. In order to make synchronous request - response exchange, we would have
to make an extra layer that would match requests with responses. No matter then if it is a synchronous or asynchronous message transfer. An
additional impression is that ECF is extremely badly documented. There are rarely javadoc comments and only a few documents at the web page.
It makes it even more difficult to handle. After this we think that it would be be better to use web services instead of ECF. It would provide not only a more stable and mature environment, but also it would provide simpler integration of any non-Eclipse tools. In addition we wouldn't have to maintain two
separate protocols (ECF vs. WS) as it will be in current approach - sooner or later they will get out of sync. -----Original Message----- From: Wright, Jim > > In the ECF code
org.eclipse.ecf.provider.generic.TCPClientSOContainer, there is a method called
'createConnection'. This method creates an object called
'ISynchAsynchConnection'. This interface seems to provide a synchronizied
call. The TCPClientSOContainer's parent 'ClientSOContainer' also creates
the 'ISynchAsynchConnect'. > > This seems like a good place to start looking for synchronized
messages/calls. > > JimW > > > -----Original Message----- > From: O'Flynn, Dennis >> >>During today's conference call, you heard us debate ECF vs web
services. The issue is due to the need for both synch and asynch
communications between an Eclipse Workbench client and >> >>ECF is very good w/ asynch. However, early releases of
ECF had little support for synchronous communications. >> >>A research task is needed to figure out how to best support
invoking request/response synchronous calls using ECF. >> |