Hi Marcin,
et al.
I agree with
your analysis – the only
thing I’d add is that we shouldn’t necessarily consign a
communication event to a particular technology just based its
synchronicity
requirements. I’d favor more of a scenario-driven assignment method.
For
example, in our current use case (the project-join case), we should
probably do
the whole thing with Web Services, using WS-Notification for
advertising the
addition of a new project member. For
more collaborative scenarios (where only Eclipse IDEs
may be involved), then we should consider ECF. I think as we move
forward the
decision criteria for which communication mechanism to use will become
more
apparent.
Cheers,
Joel
-----Original
Message-----
From:
corona-dev-bounces@xxxxxxxxxxx [mailto:corona-dev-bounces@xxxxxxxxxxx] On Behalf Of Marcin Okraszewski
Sent: Thursday, June
01, 2006 7:20
AM
To: Corona development
Subject: Re:
[corona-dev]
Communication Alternatives
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:
ECF for
both synch/asynch
Web
services for both synch/asynch
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.
=00The 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.
