Re: [corona-dev] Communication Alternatives

[Marcin Okraszewski <marcin.okraszewski@xxxxxxxxxxxxx>]

We have discussed it in Gdańsk with Edyta and Paweł. We are rather for solution to use web services. As collaboration events may come quite often and have some impact on performance we could use the ECF only for events transport. All other communication would be done by WS.

Below there are points we find in various solutions. WS + ECF is the case when we use ECF only for passing events, and WS for all other communication.

	WS	ECF	WS + ECF
advantages	well defined standard we are open for integration with external tools by default no redundant work for implementing both WS for external tools and ECF for Eclipse we do not use a "secret API" for our own use, but all clients are equal by default WS use HTTP, so it goes well through firewalls; using other protocols is also possible but rarely available probably simpler for new community members (more people know WS than ECF)	protocol independent - various transport protocols can be used Eclipse solution probably the lowest performance impact provides a group communication mode	compromise between performance and interoperability
disadvantages	impact on performance - a big risk we would need an implementation which can work with a continuously open connection (eg. keep alive), because clients may be unreachable form server	early stage, some things are not implemented, bugs, etc. weak documentation is future of ECF clear? what if nobody use it and it dies? I'm not sure, but it looks like there is no pure HTTP available so there might be a problem with firewalls; however there is XMPP which usually goes over HTTP it seems ECF currently doesn't support request - response model WS for external and ECF for internal use may get out of sync	using two protocols may introduce additional problems on firewalls - what if only one of them can go through?

Such table often helps to make decision.

The question is which of those are the most important for us. For me only the performance issue is really against WS. I'm also a bit afraid of situation in hybrid approach when only WS goes through firewall and ECF events do not. It is similar to SIP there signailling and voice goes in different sessions and sometimes phone rings but voice session do not go through firewall. Although ECF provides a group communication mode, we still need to implement broadcasting in WS because far I understand we want external tools to receive them as well.

Marcin


O'Flynn, Dennis napisał(a):

Corona requires both synchronous and asynchronous communications between the Corona server and clients (Eclipse Workbench, etc...).

 

·        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 Corona server will support web services for its communications.  This will allow both native Eclipse and non-Eclipse applications interact with Corona.

 

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 Corona server?

 

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-----
From: Okraszewski, Marcin
Sent: Wednesday, May 31, 2006 10:03 AM

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 Corona server.

>>

>>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.

>>

The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.

_______________________________________________
corona-dev mailing list
corona-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/corona-dev
  

The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it.