I'm interested in building a JBoss service. Because I'm reusing some existing code, the service must be able to talk SSL/TLS and Protocol Buffers.
The documentation I see on the JBoss wiki makes it look like services have their transport and data interpretation handled by JBoss itself. Is it really the case?
How could I implement this requirement?
Regards,
M-A
Related
I'm building a spring-websocket application that currently uses RabbitMQ as a message broker via the STOMP protocol. The rest of our organization mostly uses IBM Websphere MQ as a message broker, so we'd like to convert it away from RabbitMQ. However Websphere MQ doesn't support the STOMP protocol, which is spring-websocket's default. MQTT seems like the easiest supported protocol to use instead. Ideally our front-end web clients will continue to use STOMP, but I'm also OK with migrating them to MQTT if needed.
What classes do I need to overwrite to make spring-websocket interface with the broker via MQTT instead of STOMP? This article provides some general guidance that I should extend AbstractMessageBrokerConfiguration, but I'm unclear where to begin.
Currently I'm using the standard configuration methods: registry.enableStompBrokerRelay and registerStompEndpoints in AbstractWebSocketMessageBrokerConfigurer
Ryan has some good pointers.
The main work is going to be creating a replacement for StompBrokerRelayMessageHandler with an MqttBrokerMessageHandler that not only talks to an MQTT broker but also adapts client STOMP frames to MQTT and vice versa. The protocols are similar enough that it may be possible to find common ground but you won't know until you try.
Note that we did have plans for for MQTT support https://jira.spring.io/browse/SPR-12581 but the key issue was that SockJS which is required over the Web for fallback support does not support binary messages.
Here's my stab at this after reviewing the spring-websocket source code:
Change WebSocketConfig:
Remove #EnableWebSocketMessageBroker
Add new annotation: #EnableMqttWebSocketMessageBroker
Create MqttBrokerMessageHandler that extends AbstractBrokerMessageHandler -- suggest we copy and edit StompBrokerRelayMessageHandler
Create a new class that EnableMqttWebSocketMessageBroker imports: DelegatingMqttWebSocketMessageBrokerConfiguration
DelegatingMqttWebSocketMessageBrokerConfiguration extends AbstractMessageBrokerConfiguration directly and routes to MqttBrokerMessageHandler
Add this to server.xml on WebSphere Liberty:
<feature>websocket-1.1</feature>
My next project is a RESTful application, so Restlet seems to be an excellent choice for implementation. However, I couldn't find any support for AMQP. What is the best way to add AMQP support, in particular QPID, to my project? I'm thinking of extending org.restlet.Client but not sure how to start. Any pointer is appreciated.
Thanks,
Khoa
QPID is a implementation of AMQP protocol - an ESB if u want or a server that you connect to. Usually you get connections to it through JNDI, or AMQPConnectionFactory (if I am not mistaken the name). Restlet has to do with Servlets. I can't see the connection between one and another to be honest. For example with Restlet you can map a HTTP GET to a certain path, but what you do after the GET (for example connecting to QPID) is totally your business.
I have explored the web on MULE and got to understand that for Apps to communicate among themselves - even if they are deployed in the same Mule instance - they will have to use either TCP, HTTP or JMS transports.
VM isn't supported.
However I find this a bit contradictory to ESB principles. We should ideally be able to define EndPoints in and ESB and connect to that using any Transport? I may be wrong.
Also since all the apps are sharing the same JVM one would expect to be able to communicate via the in-memory VM queue rather than relying on a transactionless HTTP protocol, or TCP where number of connections one can make is dependent on server resources. Even for JMS we need to define and manage another queue and for heavy usage that may have impact on performances. Though I agree if we have distributed and clustered systems may be HTTP or JMS will be only options.
Is there any plan to incorporate VM as a inter-app communication protocol or is there any other way one Flow can communicate with another Flow Endpoint but in different app?
EDIT : - Answer from Mulesoft
http://forum.mulesoft.org/mulesoft/topics/concept_of_endpoint_and_inter_app_communication
Yes, we are thinking about inter-app communication for a future release.
Still is not clear when we are going to do it but we have a couple of ideas on how we want this feature to behave. We may create a server level configuration in which you can define resources to use in all your apps. There you would be able to define a VM connector and use it to send messages between apps in the same server.
As I said, this is just an idea.
Regarding the usage of VM as inter-app communication, only MuleSoft can answer if VM will have a future feature or not.
I don't think it's contradictory to the ESB principle. The "container" feature is pretty well defined in David A Chappell's "Enterprise Service Bus book" chapter 6. The container should try it's best to keep the applications isolated.
This will provide some benefits like "independently deployable integration services" (same chapter), easier clusterization, and other goodies.
You should approach same VM inter-app communications as if they where between apps placed in different servers.
Seems that Mule added in 3.5 version, a feature to enable communication between apps deployed in the same server. But sharing a VM connector is only available in the Enterprise edition.
Info:
http://www.mulesoft.org/documentation/display/current/Shared+Resources#SharedResources-DefiningDomains
Example:
http://blogs.mulesoft.org/optimize-resource-utilization-mule-shared-resources/
I am using OSGI with Glassfish 3.0.1.We use Jersey REST as the resource layer. We have lots of osgi services. we are planning to decouple them & deploy it in a cloud. One way we do this is by doing a http REST call. But we would like to do service to service call at the api level. One way to do this is by using DOSGI. But Glassfish 3.0.1 doesn't seem to support DOSGI. Any other suggestions?
I believe that Glassfish contains Apache Felix, which is a fully compliant OSGi Framework. Therefore you do not need explicit support from Glassfish in order to use a set of bundles that provide Remote Services (the name "DOSGI" is now deprecated). Indeed, this is kind of the point of OSGi!
Anyway the next obvious question is which Remote Services implementation to choose. I would advise you NOT to use CXF since it is too buggy and unmaintained. That leaves Eclipse ECF or Paremus RSA.
(Disclaimer: the Paremus implementation is commercial and I work for Paremus).
I'm developing a STOMP binding for Ada, which is working fine utilizing TCP/IP as the transport between the client and an ActiveMQ server configured as a STOMP broker. I thought to support UDP as well (i.e. STOMP over UDP), however, the lack of pertinent information in the ActiveMQ documentation or in web searches suggests to me that this isn't possible, and perhaps it doesn't even make any sense :-)
Confirmation one way or the other (and an ActiveMQ configuration excerpt if this is possible) would be appreciated.
this is not implemented in ActiveMQ at the moment as Stomp transport uses TCP only. It is possible to implement, so if you have a time to do it, give it a try.