That means the HTTP endpoints have more the "notion" of an "API
server",
while the _REAL_ work is dispatched to a message broker
-Matthias
On Mon, May 20, 2013 at 2:20 PM, Matthias Wessendorf <matzew(a)apache.org>wrote:
Hi,
for ticket "AEROGEAR-1222" ([1]) I looked a bit at JMS integration hooks.
The JIRA has an updated description, and two SIMPLE "UML diagrams".
Also, I created a branch that uses JMS for (GCM/APNs) based broadcast
(more to follow later this week).
Example:
The HTTP enpoint for the "broadcast sender", publishes a JMS messages and
immediately returns:
https://github.com/matzew/pushee/blob/Messaging/src/main/java/org/aerogea...
Yes, there is no guarantee at all, that the message really arrives the
device (see Apple/GCM doc for details)
Behind the sceneses, a "Consumer" is responsible to deliver the message to
the network:
https://github.com/matzew/pushee/blob/Messaging/src/main/java/org/aerogea...
The code above performs all the "heavy" work ("blocking" JPA lookups
and
PushNEtwork Delivery)..
We now should use the "standalone-full.xml" configuration, since that
supports JMS. I double checked and the SimplePush/Netty Adapter are working
fine here too.... also, for JMS (for now), we need to declare some JMS
topics in the "standalone-full.xml" file
More during the week,
Matthias
[1]
http://jira.jboss.org/browse/AEROGEAR-1222
--
Matthias Wessendorf
blog:
http://matthiaswessendorf.wordpress.com/
sessions:
http://www.slideshare.net/mwessendorf
twitter:
http://twitter.com/mwessendorf