What exactly is Solace JCSMP?
Is it just a more suited JMS API for Solace? What kind of other benefits does it have?
For example, I would need to create a Java application using SolaceMQ that needs to send/receive messages over to/from AMQP protocol so that all different microservices written in different languages would be able to consume them. Is JCSMP right for that? or is it just another JMS API that it only works between Java applications?
What exactly is Solace JCSMP?
JCSMP is the Classic Java API for Solace's SMF (Solace Message Format) protocol. Note that Solace recently introduced a more modern messaging API for java devs using their event brokers that is just referred to as the "PubSub+ Messaging API for Java". If you are new to Solace and using Java it may make sense to use that instead of JCSMP.
Is it just a more suited JMS API for Solace? What kind of other benefits does it have?
JCSMP allows developers to take advantage of the full feature set offered by the Solace Broker whereas the Solace JMS implementation only covers the features defined in the JMS specification itself. For example, use of Solace features such as Replay or having Queues subscribe to Topics are not programmatically possible via the JMS API and would have to be done administratively if using JMS.
For example, I would need to create a Java application using SolaceMQ that needs to send/receive messages over to/from AMQP protocol so that all different microservices written in different languages would be able to consume them. Is JCSMP right for that? or is it just another JMS API that it only works between Java applications?
Solace PubSub+ Event Brokers provide protocol translation between any of the protocols supported by the broker. It doesn't matter whether you are using SMF (which both Solace JMS and JCSMP use), MQTT, AMQP 1.0, etc. or what programming language you are using. For example when you send a message using JCSMP you can receive it using a Java app using JMS, a Python app using AMQP and a Go app using MQTT. The Solace Event Broker even has support for calling a RESTful webhook using it (Check out Solace "Rest Delivery Endpoints"). Just a heads up that if you're using headers you'll want to checkout the Solace docs to see how they're mapped during protocol translation.
Related
I'd like to use regular AMQP or JMS clients to connect to a Solace message broker but don't know enough about these protocols to know if they are compatible. From what I can tell Solace implements AMQP and JMS bu possibly with incompatible extensions (e.g. "message vpn").
Does Solace have incompatible extensions, particularly for JMS, or is there a straightforward way to get a JMS client to speak to a Solace broker with "message vpn" enabled?
The choice is yours as Solace provides both a JMS client implementation and it also supports AMQP 1.0.
Keep in mind that JMS is an API and AMQP is a protocol. The JMS API can be implemented over any suitable wire protocol, and AMQP can be exposed via any suitable API. JMS is Java-based and there are many JMS implementations using different protocols under the covers. There are also many AMQP clients written in different languages on different platforms all with different APIs. There are even projects which combine both JMS and AMQP like Qpid JMS.
Solace's PubSub+ event broker works on binary payloads which means that you can indeed publish and consume messages on cross protocols and APIs.
The Solace APIs have detailed documentation on how to process the payload in a type agnostic fashion.
As you can see in this diagram, we support a wide range of APIs and protocol integrations.
There are also sample codes present over at this Github account listing examples on using Solace broker with JMS and AMQP : https://github.com/SolaceSamples?
(Answering my own question).
I basically wanted to know if it was possible to connect to a Solace/JMS broker using more popular messaging libraries. As far as I can tell the answer is no in general.
For example,
one feature of JMS is JNDI lookup of the InitialContextFactory. I don't think that is possible to do outside of a JMS library.
Newbee to Spring world. I have some knowledge on ActiveMQ. Recently used in one of my projects. While reading about Spring Events raised a doubt.
Spring Events: Publisher -> Listener. We do publish events and we would have created some listeners for that.
ActiveMQ: Publisher -> Listener. We do publish events and we would have created some listeners for that.
So anyone helps me to understand the use cases or difference between these two APIs.
As far as I can tell, Spring Events are an application level events mechanism, so that different parts inside our application can communicate/coordinate. The scope and functionality appear to be quite narrow and small respectively. You can publish events and deal with those events either synchronously (default behaviour) or asynchronously (using #EnableAsync and #Async). There is no broker. This functionality may be a perfect fit for your application if this is all it needs.
On the other hand, ActiveMQ is a full-featured message broker. Generally speaking, it runs as an independent server process (although it can be embedded in your application). It supports industry-standard protocols like AMQP, MQTT, & STOMP which have client implementations on numerous platforms and in various languages. For example, you could send STOMP messages via Websockets from a Javascript client and process those messages with an AMQP client written in .NET on Windows. It provides both a JMS & JNDI client implementation. It supports both publish-subscribe and point-to-point semantics. You can use it as an integration platform and scale it up to multi-node clusters with high-availability for the message data and thousands of remote clients using various protocols or you can embed it into your application and just use it for local events.
NEWBIE Question here, maybe I am way off...
When I send a JMS text message to an ActiveMQ topic using the activemq-all jar, is a JMS message actually sent over the wire, or does ActiveMQ actually map/transform the message to pure AMQP?
Thanks.
JMS is an API specification and not a wire level protocol specification. It defines a set of APIs a Messaging provider must implement to call the messaging provider a JMS provider. How the JMS APIs are implemented is internal to the implementer. ActiveMQ might(or does) use AMQP protocol under the hood to implement JMS APIs. Others, for example, IBM MQ uses it's own proprietary protocol.
For me JMS and ESB seem to be very related things and I'm trying to understand how exactly they are related.
I've seen a sentence that JMS can be used as a transport for ESB - then what else except the transport should be present in such an ESB? Is JMS a simple ESB or if not, then what it lacks from the real ESB?
JMS offers a set of APIs for messaging: put a message on a queue, someone else, sometime later, perhaps geographically far away takes the message off the queue and processes it. We have decoupled in time and location of the message provider and consumer. Even if the message consumer happens to be down for a time we can keep producing messages.
JMS also offers a publish/subscribe capability where the producer puts the message to a "topic" and any interested parties can subscribe to that topic, receiving messages as and when they are produced, but for the moment focus just on the queue capabilty.
We have decoupled some aspects of the relationship between provider and consumer. However some coupling remains. First, as things stand every message is processed in the same way. Suppose we want to introduce different kinds of processing for different kinds of messages:
if ( message.customer.type == Platinum )
do something special
Obviously we can write code like that, but an alternative would be to have a messaging system that can send different messages to different places we set up three queues:
Request Queue, the producer(s) puts their requests here
Platinum Queue, platinum consumer processing reads from here
Standard Queue, a standard consumer reads messages from here
And then all we need is a little bit of cleverness in the queue system itself to transfer then messsage from the Request Queue to the Platinum Queue or Standard Queue.
So this is a Content-Based Routing capability, and is something that an ESB provides. Note that the ESB uses the fundamental Queueing capabilities offered by JMS.
A second kind of couppling is that the consumer and producer must agree about the message format. In simple cases that's fine. But when you start to have many producers all putting message to the same queue you start to hit versioning problems. New message formats are introduced but you don't want to change all the existing providers.
Request Version 1 Queue Existing providers write here
Request Version 2 Queue New provider write here, New Consumer Reads here
And the ESB picks up the Version 1 Queue messages and transforms them into Version 2 messages and puts them onto the Version 2 queue.
Message transformation is another possible ESB capability.
Have a look at ESB products, see what they can do. As I work for IBM, I'm most familiar with WebSphere ESB
I would say ESB is like a facade into a number of protocals....JMS being one of them.
An addition to the above list is the latest Open Source ESB - UltraESB
JMS is not well suited for the integration of REST services, File systems, S/FTP, Email, Hessian, SOAP etc. which are better handled with an ESB that supports these types natively. For example, if you have a process that dumps a CSV file of 500MB at midnight, and you want another system to pickup the file, parse CSV and import into a database, this can easily be accomplished by an ESB - whereas a solution with just JMS will be bad. Similarly, integration of REST services, with load balancing/failover to multiple backend instances can be done better with an ESB supporting HTTP/S natively.
This Transformation does not happen automatically. You need to configure the mapping or write transformation service
Look at https://access.redhat.com/knowledge/docs/en-US/JBoss_Enterprise_SOA_Platform/4.2/html/SOA_ESB_Message_Transformation_Guide/ch02s03.html
Regards,
Raja Nagendra Kumar,
C.T.O
www.tejasoft.com
ESB offers integration with a lot of different protocols in addition to JMS.
Most use JMS behind the scenes to transfer, stor and move messages. One such solution OpenESB, uses XML format messages.
There are open source ESB which you could checkout -
OpenESB
Apache Camel
MuleESB
WSO2 ESB
JMS implementation like ActiveMQ come with Camel inbuilt into them.
JMS is a protocol for communicating with an underlying messaging layer. ESB operates at a higher level, offering integration with multiple technologies and protocols, one of which would be JMS, in a uniform way that makes management of complex flows much simpler.
There are JMS message brokers , that you can easily configure with ESB. https://docs.wso2.com/display/ESB470/JMS+Transport
JMS and ESB both provide a way of communication between different applications. But the context for JMS and ESB are different. JMS is for simple need. JMS is implemented by JMS Provider. It is Java specific.
Examples of JMS Providers are: Apache Active MQ, IBM MQ, HornetQ etc.
ESB is for complex need. ESB is a component in EAI providing communication facility to various applications. It is generic & not specific to Java. JMS is one of the supported protocols.
Examples of ESB provider are: MuleESB, Apache Camel, OpenESB
Use Case: It may be an overhead to use ESB, if all our communicating applications are in Java and are using the same message format. Here JMS may be sufficient.
How does RabbitMQ compare to Mule, I am going to build an application using message oriented architecture and AMQP (RabbitMQ) provides everything i want, but i am perplexed with so many related technology choice and similar concepts like ESB. I am having a doubt if i am making a choice without considering other alternatives.
I am mostly clear that RabbitMQ is a message broker and it helps me in mediating message between producer and consumer (all forms or publish subscribe and i could understand how its used from real examples like twitter , or Facebook updates, etc)
What is Mule, if i could achieve what i do in RabbitMQ using mule, should i consider mule similar to RabbitMQ?
Does mule has a different objective than that of a message broker?
Does mule assumes that underlying it there is a message broker that delivers message to the appropriate mule listeners (i could easily write a listener in RabbitMQ)
Is mule a complete Java bases system ( The current experiment i did with RabbitMQ took me less than 30 Min to write a simple RPC Client Server with client as C# and Server as Java , will such things be done in Mule easily).
Mule is an ESB (Enterprise Service Bus). RabbitMQ is a message broker.
An ESB provides added layers atop of a message broker such as routing, transformations and business process management. It is a mediator between applications, integrating Web Services, REST endpoints, database connections, email and ftp servers - you name it. It is a high-level integration backbone which orchestrates interoperability within a network of applications that speak different protocols.
A message broker is a lower level component which enables you as a developer to relay raw messages between publishers and subscribers, typically between components of the same system but not always. It is used to enable asynchronous processing to keep response times low. Some tasks take longer to process and you don't want them to hold things up if they're not time-sensitive. Instead, post a message to a queue (as a publisher) and have a subscriber pick it up and process it "later".
Mule is a "higher level" service implemented with message broker. From the docs
The messaging backbone of the ESB is
usually implemented using JMS, but any
other message server implementation
could be used
You can build an ESB with rabbit; however, you're going to be limited to sending byte[] packages, and you'll have to build your system out of messaging primitives like topics and queues. It might be a bit faster (based on absolutely no benchmarking, testing or data) because there are fewer layers of translation. Mule provides an abstraction on top of this, speaks a variety of transports, and can handle some routing logic.
Mule is a Enterprise service bus providing end to end integration solution where as Rabbit is message broker for queueing messages between subscriber and receiver.
RabbitMQ, a open source message broker software is written in Erlang programming language and is built on Open Telecom Platform for clustering and failover. It is easy to use, supports a huge number of developer platforms and runs on all major operating systems. It works on a concept called Exchange.
Mule connects RabbitMQ with AMQP connector.