I think both have a part to play. We need
to support ECF by providing context, and there will be cases where a side
effect of a Web Service interaction may be a series of ECF events, but I don’t
think we need to use ECF as a communication backbone. I believe Web Services is
more appropriate. Does that make sense?
-----Original
Message-----
From:
corona-dev-bounces@xxxxxxxxxxx [mailto:corona-dev-bounces@xxxxxxxxxxx] On Behalf Of Marcin Okraszewski
Sent: Thursday, June 01, 2006 8:58
AM
To: Corona development
Subject: Re: [corona-dev]
Communication Alternatives
I wouldn't say
synchronicity is the main factor for me. It was rather a releaser of the
discussion and has a minor importance for me. It seems you are rather for WS +
ECF, am I right? As I look at it, this way seems to be tempting but I'm afraid
that we will create a "spaghetti" solution.
Marcin
Hawkins, Joel napisał(a):
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.
_______________________________________________
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.