[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