Alternative to Spring Boot websocket/stomp support in OSGI

[markryder <ma...@sri.com>]

Spring boot offers the capability to develop interactive web apps using 
websockets communication with a browser based client (JavaScript UI). 
The stomp protocol is used on websockets and then mapped to activemq 
queues or topics, allowing server side components to interact with a web 
client through the queues or topics and not through websockets. See 
spring boot page: https://spring.io/guides/gs/messaging-stomp-websocket/ 
for details. Normal JMS queues/topics on the server side are mapped to 
‘N’ number of user specific websocket endpoints (see 
http://docs.spring.io/spring/docs/current/spring-framework-reference/html/websocket.html#websocket-stomp-message-flow
).

Camel seems to have all the necessary components to achieve the same thing:
•    AHC-WS – Camel websocket client
•    Atmosphere-websocket - websocket server
•    Websocket - websocket client/server
•    Stomp -  talks stomp to activemq broker
but has nothing prebuilt and that handles the mappings between user 
stomp/websocket sessions and individual server side topics and queues.
We are running in an OSGI container and need to duplicate the spring 
boot websocket (i.e. org.springframework.web.socket.messaging.*) 
capability but without spring due to the difficulties of supporting 
Spring Boot in OSGI. Can anyone suggest an existing example project or 
strategy to achieve this goal? This is a migration of an existing 
project and we must continue to support stomp on the websocket side.

Re: Alternative to Spring Boot websocket/stomp support in OSGI

[Brad Johnson <br...@mediadriver.com>]

I'm not sure exactly what you're looking for here but will give it a shot.
If you use a <recipeintList> it should do what you are after.

<recipientList>
<simple>amq:queue::${header.destinationVariable}</simple>
</recipientList>

I don't know if that destinationVariable is what is in the header or if you
send another name.  But effectively that EIP is used to route without
having to use big choice statements. It may or may not be obvious but what
ever that destinationVariable is has to be the same name as the queue. The
queue can be in only or in out. The latter being request/response. On a
request/response there are two queues set up by Camel/Activemq under the
covers. To you it looks like a single queue that you send a request into
and get a request back.  In fact the queue is unidirectional so a second
queue is set up to route the message back to the caller.

I'm not sure if that's what you're after or not but it's a start.

On Fri, Oct 28, 2016 at 2:10 PM, markryder <ma...@sri.com> wrote:

> Spring boot offers the capability to develop interactive web apps using
> websockets communication with a browser based client (JavaScript UI). The
> stomp protocol is used on websockets and then mapped to activemq queues or
> topics, allowing server side components to interact with a web client
> through the queues or topics and not through websockets. See spring boot
> page: https://spring.io/guides/gs/messaging-stomp-websocket/ for details.
> Normal JMS queues/topics on the server side are mapped to ‘N’ number of
> user specific websocket endpoints (see http://docs.spring.io/spring/d
> ocs/current/spring-framework-reference/html/websocket.html#w
> ebsocket-stomp-message-flow
> ).
>
> Camel seems to have all the necessary components to achieve the same thing:
> •    AHC-WS – Camel websocket client
> •    Atmosphere-websocket - websocket server
> •    Websocket - websocket client/server
> •    Stomp -  talks stomp to activemq broker
> but has nothing prebuilt and that handles the mappings between user
> stomp/websocket sessions and individual server side topics and queues.
> We are running in an OSGI container and need to duplicate the spring boot
> websocket (i.e. org.springframework.web.socket.messaging.*) capability
> but without spring due to the difficulties of supporting Spring Boot in
> OSGI. Can anyone suggest an existing example project or strategy to achieve
> this goal? This is a migration of an existing project and we must continue
> to support stomp on the websocket side.
>
>
>