[
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:
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
