Hi Christian, I see that you already mention OSGi RFP 158: 'Distributed Eventing'. This is currently only an RFP, so just a requirements document, but once the OSGi Enterprise R6 work is out of the way I think we will be looking at creating a design for that in the OSGi EEG. This combined with the work done in RFC 206 might give us a nice, protocol/technology-independent way to use distributed asynchronous services.
Cheers, David On 3 March 2014 16:18, Christian Schneider <[email protected]> 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 >>> >> > > > -- > 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 _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
