Catcha.
FYI, in Cellar, we are able to "broardcast" a local event to the other node.
We use a kind of Hazelcast topic.
It's very similar: we provide a simple API that a user can use to
implement consumer/handler on event.
It's not as flexible as you describe.
Regards
JB
On 03/03/2014 04:18 PM, Christian Schneider wrote:
Probably we would need three levels of a spec.
1. API for the user
2. Eventing inside the container
3. Eventing between the containers
For 1. I am looking for something similar to what eclipse E4 has.
Like this to reveive an event:
void anymethod(@Event("topicname") MyEvent event) {
}
And something like this as an attribute to send:
@Event("topicname")
EventSender<MyEvent> sender;
sender.send(myEvent);
The spec could define this API and some frameworks like CDI or blueprint
could implement it.
For 2. eventadmin might already be all we need. The spec just needs to
specify how to send arbitrary objects over eventAdmin.
For 3. We probably need some spec to define a bridge between the event
systems of the containers. Not sure how this would look like.
Probably interoperability would be the most difficult there.
Christian
On 03.03.2014 16:09, Jean-Baptiste Onofré wrote:
Hi Christian,
For asynchronous, I think JMS is already there for async messaging.
You mean a spec like MDB EJB in JEE ?
Regards
JB
On 03/03/2014 04:07 PM, Christian Schneider wrote:
I am also looking forward to a spec about asynchronous messaging in
OSGi.
I think the largely snychronous model behind DOSGi and many remoting
technologies like RMI and Webservices is not really that useful for
remote communication.
What I am looking for is a way to send events using pojos over remotely
with behaviours like jms topics and queues. Serialization should allow
java serialization, jaxb and json.
I think the model of communicating over events is much more suitable to
remote communication than services. Some reasons:
1. Most comminications are in fact asynchronous in nature. For example
almost all UIs do not allow to block the UI thread. So any sync
communication has to be done in a separate thread
2. Services with more than on method are difficult to version when
changes happen in the contract
3. The method is rather an implementation detail. The communication
should rather be defined by the data exchanged
4. Publish subscribe models allow nice extension points where new
listeners can be hooked in
5. Messaging servers (like JMS server) often provide nice failover and
load balancing schemes based on queues
There is a rfp called distributed eventing which seems to look into
this:
http://blog.osgi.org/2013/06/distributed-eventing-rfp-158-now.html
Eclipse E4 has an interesting API for using events too
http://www.vogella.com/tutorials/Eclipse4EventSystem/article.html.
If there are already some nice implementations like this out there I
would be interested about any pointers.
Btw. I have written a blog entry some time ago about using camel to do
pojo messaging. See:
http://www.liquid-reality.de/display/liquid/2011/10/19/Using+Camel+to+do+light+weight+messaging+over+any+protocol
This already has some of the abilities I am looking for but I would like
to see a solution the ideally only makes you depend on an OSGi spec. So
you can stay largely independent of the framework you use.
Christian
On 03.03.2014 15:39, Mike Wilson wrote:
Attempting to look wider than my previous question about remote
services, I'm looking at any way to make an asynchronous call from a
bundle in one OSGi container to a service in another OSGi container.
There's an interesting discussion about asynchronous service calls on:
http://blog.osgi.org/2010/04/calling-your-cake-and-sending-it-too.html
Have there been any new developments towards standardization of any
asynchronous pattern, or is using ECF or making your own still the
main alternatives?
Or, is the preferred option to use some third-party API directly, such
as a messaging API like ActiveMQ?
Thanks
Mike
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
