A layered spec sounds good, or specs building upon other specs.
To add to your layers I'd really like to see a layer where the
service can have a "clean" API free from messaging distribution
artifacts:
0. Classic class/methods API
1. Messaging-oriented API
...
and it seems the new Async API could fit here, with some added
help from a Messaging<->Classic API bridge configuration.
Best regards
Mike
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+C
amel+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
