I have not yet tried chronicle but it looks like a good choice e.g. some
trading floor applications. I would be very interested in creating a
transport for Aries rsa (more below).

About the comparison between CXF DOSGi and ECF.
Traditionally CXF DOSGi was limited to CXF as a transport layer. So it has
quite advanced support for CXF but the stack also brings some complexity.
ECF on the other side has a big number of transports and discovery
solutions available. One disadvantage of ECF is that it is historically
based on the Eclipse Communication Framework APIs which predate Remote
Service Admin and are quite different. So there is a certain overhead when
creating providers for it.

Something that could also be interesting is the new Aries rsa project. It
is a separation of the CXF Remote Service Admin impl from the CXF transport.
So in the future CXF DOSGi will only host the CXF provider as a
DistributionProvder impl for Aries rsa.

You can find more informations at http://aries.apache.org/modules/rsa.html

Aries rsa will concentrate on implementing the spec and will also host
additional providers. It is designed to be extremely light weight and
extensible. Currently there are two extension interfaces defined:
DistributionProvider for implementing transports
ExportPolicy for implementing system wide governance rules.

The first new provider is a very simple tcp transport with java
serialization. Its main purpose is to provide a nice example for how to
implement new providers and it is the transport used in the Aries rsa
itests.

The whole aries rsa framework is just about 160kb. I just created a small
example that uses bndtools to package the echo tcp example for docker.
Bndtools packages this as a runnable jar and it is just 2.5mb including the
OSGi framework, Aries rsa, zookeeper, the example and all dependencies.
See https://github.com/cschneider/echotcp-docker

I plan to do the first release in the next two weeks and would be happy
about any feedback.
Btw. another nice stat about Aries rsa is that the whole build including
OSGi tests just takes 10s. I think this also shows how light weight it is.

Christian



2016-03-23 22:34 GMT+01:00 Scott Lewis <[email protected]>:

> On 3/23/2016 1:28 PM, Nick Baker wrote:
>
> Thanks a lot Scott,
>
> We'll definitely keep you guys in mind as we get to our distributed
> feature later this year.
>
> I've been particularly curious as to if anyone has tried integrating Java
> Chronicle ‎https://github.com/OpenHFT/Chronicle-Queue as the transport
> layer. Obviously not a solution for machine clusters but could make a
> micro-services architecture more appealing in HPC applications.
>
>
> Yes, indeed.  I've not yet used Chronicle, but it does look very
> interesting as a remote services transport.   After a quick look at the
> docs, it appears it would be straightforward to create an ECF RSA
> distribution provider.   If interested or want to collaborate on this,
> please see the new tutorial/example on creating custom distribution
> providers [6] or contact me directly.
>
> [6]
> https://wiki.eclipse.org/Tutorial:_Creating_Custom_Distribution_Providers
>
>
>
>
> Sent from my BlackBerry 10 smartphone.
> *From: *Scott Lewis
> *Sent: *Wednesday, March 23, 2016 3:55 PM
> *To: *[email protected]
> *Reply To: *[email protected]
> *Subject: *Re: ECF 3.13 released
>
> On 3/23/2016 12:13 PM, Nick Baker wrote:
>
> Hey Scott,
>
> Thanks for the update. We're actually looking to deploy Remote Services in
> our next release. Can you speak to the relative merits of ECF vs the Apache
> CXF Distributed OSGi subproject?
>
>
> I don't want to explicitly or implicitly criticize CXF, so I'll just list
> some of the things that I think ECF has that are advantages.   Some of
> these may be shared with CXF...I don't know enough about CXF to say which.
> Also I should say that I've been working with Christian and others to
> create a general distribution provider API for Aries that will work with
> OSGi RSA.
>
> 1) We implement the latest OSGi R6 specs...both Remote Service (chap 100
> in enterprise spec) and Remote Service Admin (chap 122 in enterprise spec)
> 2) We test our implementation against the OSGi compatibility test suite as
> part of our continuous integration
> 3) ECF has an open modular architecture, which allows new distribution
> (and discovery) providers to be easily used (see [2] and [3] below)
> 4) ECF's RS/RSA implementation is small/lightweight
> 5) We've recently created and documented a number of new distribution
> providers...see [3]
> 6) One of these providers uses CXF (Jax-RS), allowing backward
> compatibility with CXF-based remote services
> 7) We are also gradually introducing tooling for developing, debugging,
> deploying RS/RSA apps [2].  This will continue.
> 8) We have few dependencies (4), and so we run on any OSGi R5+ compatible
> framework
> 9) We have started building remote services for monitoring/management of
> remote (and/or local) frameworks [5]
>
> Scott
>
> [5] https://github.com/ECF/OSGIRemoteManagement
>
>
> Thanks,
> Nick Baker
>
> From: Scott Lewis <[email protected]>
> Reply-To: " <[email protected]>[email protected]" <
> [email protected]>
> Date: Wednesday, March 23, 2016 at 12:39 PM
> To: " <[email protected]>[email protected]" <[email protected]
> >
> Subject: Re: ECF 3.13 released
>
> iv)  ECF 3.13 also supports using maven to install Karaf features [4].
>
> On 3/17/2016 9:37 AM, Scott Lewis wrote:
>
> ECF 3.13 has just been released [1].
>
> ECF provides a modular and CT-tested implementation of OSGi R6 Remote
> Services and Remote Service Admin (1.1) specifications.
>
> The important additions in 3.13 [2]
>
> i) New API (and tutorial) to simplify the creation of custom remote
> services distribution providers.   The distribution provider API makes it
> easy to introduce alternative/new/private protocols, serialization formats,
> or communication patterns (e.g. client/server or pub-sub groups)
> **without** modifying the service API or implementation
> ii) Distribution provider implementations based upon MQTT, CXF, Jersey,
> Hazelcast and associated technical documentation [3]
> iii) Eclipse tooling to aid in the development, debugging, testing, and
> deployment of remote services [2]
>
> Scott
>
> [1] https://www.eclipse.org/ecf/downloads.php
> [2] https://www.eclipse.org/ecf/NewAndNoteworthy.html
> [3] https://wiki.eclipse.org/Distribution_Providers
>
> [4] https://wiki.eclipse.org/EIG:Install_into_Apache_Karaf
>
>
>
>


-- 
-- 
Christian Schneider
http://www.liquid-reality.de
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>

Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>

Reply via email to