[
https://issues.apache.org/jira/browse/CELIX-389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15769963#comment-15769963
]
ASF GitHub Bot commented on CELIX-389:
--------------------------------------
GitHub user rlenferink opened a pull request:
https://github.com/apache/celix/pull/12
CELIX-389: Added publisher/subscriber implementation
Added the publisher / subscriber implementation which is based on the
concepts of the remote service
admin (i.e. rsa / topology / discovery pattern).
Publishers are senders of data, subscribers can receive data. Publishers
can publish/send data to certain channels (called 'topics' further on),
subscribers can subscribe to these topics. For every topic a publisher service
is created by the pubsub admin. This publisher is announced through etcd. So
etcd is used for discovery of the publishers. Subscribers are also registered
as a service by the pubsub admin and will watch etcd for changes and when a new
publisher is announced, the subscriber will check if the topic matches its
interests. If the subscriber is interested in/subscribed to a certain topic, a
connection between publisher and subscriber will be instantiated by the pubsub
admin.
The dfi library is used for message serialization. The publisher /
subscriber implementation will arrange that every message which will be send
gets an unique id.
For communication between publishers and subscribers UDP and ZeroMQ can be
used. When using ZeroMQ it's also possible to setup a secure connection to
encrypt the traffic being send between publishers and subscribers. This
connection can be secured with ZeroMQ by using a curve25519 key pair per topic.
The publisher/subscriber implementation supports sending of a single
message and sending of multipart messages.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/rlenferink/celix pubsub
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/celix/pull/12.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #12
----
commit 701eae493f0299c73bec9fe4f944734b881654bb
Author: Roy Lenferink <[email protected]>
Date: 2016-12-22T12:34:38Z
CELIX-389: Added publisher/subscriber implementation
----
> Publisher / subscriber implementation
> -------------------------------------
>
> Key: CELIX-389
> URL: https://issues.apache.org/jira/browse/CELIX-389
> Project: Celix
> Issue Type: Improvement
> Reporter: Roy Lenferink
>
> Over the past few months I've been working together with Pepijn Noltes,
> Erjan Altena and Gabriele Ricciardi on a (secure) publisher / subscriber
> implementation, which is based on the concepts of the remote service admin
> (i.e. rsa / topology / discovery pattern).
> Publishers are senders of data, subscribers can receive data. Publishers
> can publish/send data to certain channels (called 'topics' further on),
> subscribers can subscribe to these topics. For every topic a publisher
> service is created by the pubsub admin. This publisher is announced through
> etcd. So etcd is used for discovery of the publishers. Subscribers are also
> registered as a service by the pubsub admin and will watch etcd for changes
> and when a new publisher is announced, the subscriber will check if the topic
> matches its interests. If the subscriber is interested in/subscribed to a
> certain topic, a connection between publisher and subscriber will be
> instantiated by the pubsub admin.
> The dfi library is used for message serialization. The publisher / subscriber
> implementation will arrange that every message which will be send gets an
> unique id.
> For communication between publishers and subscribers UDP and ZeroMQ can be
> used. When using ZeroMQ it's also possible to setup a secure connection to
> encrypt the traffic being send between publishers and subscribers. This
> connection can be secured with ZeroMQ by using a curve25519 key pair per
> topic.
> The publisher/subscriber implementation supports sending of a single
> message and sending of multipart messages.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)