Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] which ECF protocol to use?

Hi David,

David Donohue wrote:
This was most helpful, Scott!  I do have control over both the client
and the server.
2 Quick follow-up questions:
(1) Can ECF be embedded in a non-OSGi application?

For most of ECF/most providers the answer to this is 'yes'. But there are some things that will be unavailable. And...we have not been testing in any non-OSGi applications for some time, so these things may be more that meets my eye.

(2) I assume that my application can support multiple ECF protocols at once?

Yes, certainly this is correct.

Scott


Thanks again,
David Donohue

On Fri, Oct 9, 2009 at 10:26 AM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
Hi David,

David Donohue wrote:
Hello!
I would like help with my strategy toward using ECF, if you would be
so kind.  I plan to have a central UI client, which might be an OSGi
bundle and it might not.  This client would communicate with many OSGi
servers, which provide data lookup functions for the client.  I would
like these servers to be maximally secure, so I was planning to avoid
use of a protocol that could be contacted using HTTP.  I would like
the communication to be as fast as possible.  I would like to possibly
share Java objects, and definitely share Strings of data in XML or
other.

Can you tell me any advice on these?
 * which ECF protocol to select, that can be used as easily as
possible by non-OSGi clients, for maximal speed and security?
 * does your experience favor any syntax of communicating data, for
maximal speed?  XML?  oth

Given your desire for maximum performance, as well as security, I would
suggest trying the JMS/ActiveMQ provider.  The Java Message Service standard
(JMS) is asynchronous, and been implemented commercially many times (i.e.
there are several very good JMS impls).  My guess is that ActiveMQ would
likely be performant enough for you...but if not then you could easily move
to commercial JMS providers (since the ECF ActiveMQ provider is structured
as a JMS bundle with the bulk of the code and a small ActiveMQ-specific
implementation).

JMS also is asynchronous, which...depending upon your protocol...might
afford some performance gains through the use of one-way messaging and/or
future results (represented in ECF remote services via
IRemoteService.callAsync).

WRT serialization format (e.g. XML vs others)...I'm not sure what the state
of the art is here.  I saw some results several years ago that showed that
Java Object Serialization/deserialization was more performant in many use
cases than the existing xml serialization at the time, but perhaps this has
changed with more recent xml parsers/generators.
One point I should make WRT ECF though...if the ECF APIs are used (e.g. ECF
remote services), then it's possible to change from one provider to another
without application level changes.  So, for example, if you were to find
that your existing/selected provider had insufficient performance or
security (for whatever reason), then it would be possible to change to some
other provider (or replace with new one of your own), without
reimplementing/changing your app-level code.  IMHO, this flexibility is a
big part of the value of the ECF abstractions...because in my own experience
the case of requirements *changing* over time (wrt security and performance
anyway) is fairly common.

Also...ECF has a layered API structure and so with some providers (including
the JMS/ActiveMQ provider) the layering looks like this:

remote services API
           |
          V
shared object API
           |
          V
activeMQ provider impl/wire protocol

The reason this is useful is that *if* one wishes to use the lower-level
shared object API (which provides a number of things...like pluggable
serialization, direct object sharing, remote failure detection, and object
replication with asynchronous messaging) then one can do so without
implementing it directly in provider protocol (i.e. activeMQ in this case).
 If, however, one wishes to stay at the remote services API level, this is
perfectly fine too...and not all ECF providers implement both the rs API and
the so API).
The layering gives choices...which may not seem helpful initially, because
it does introduce some complexity, but having the choice to move among
providers without changing app code is frequently helpful in my experience.

A requirement for interoperation with non OSGi (and non-ECF) environments
also presents complexities.  First, do you have control of these other
environments or is it interaction with some existing/legacy system (via some
protocol) that is outside your control?
JMS/ActiveMQ is widely used and open standard so this would/is certainly
possible as an answer to this.  Also, you might want to look at the recent
work by Holger on the REST API for ECF...although you stated that you didn't
want to use http (for security and perhaps performance reasons).

I hope this helps.  There is unfortunately not a single, clear answer to
these questions, because there are tradeoffs among requirements wrt various
transport-level mechnisms (e.g. synchronous/asynchronous patterns,
marshalling/serialization, etc).

Thanks,

Scott

Many thanks,
David Donohue
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev

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



Back to the top