Re: [ecf-dev] which ECF protocol to use?

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

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
>