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

[David Donohue <dd@xxxxxxxxxxxxxxxx>]

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?
(2) I assume that my application can support multiple ECF protocols at once?
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
>>
>
>