Is JMS is platform dependent? (e.g Java<->.Net) - queue

I want to be able to produce messages to a client using a queue.
Producing the message and putting it on the queue should be both asynchronous and reliable so that if a message isn't flagged as consumed it will be not be cleared from the queue.
I thought using JMS and read about its capabilities.
Is it platform dependent so that i as a Java web application can act as a producer while other 3'rd party as a .NET application can act as a consumer?
Thanks.

It depends which JMS implementation you use. Here's some (not a comprehensive list, just a sampling...)
WebSphereMQ: Has clients for a ton of different languages.
ActiveMQ: Clients for Java, C, C++, C#, Ruby, Perl, Python, PHP
RabbitMQ: Java, Ruby, Python, .NET, PHP, Perl, [lots more]
Apache QPID: Java, Python, C++, Perl, Python, Ruby, .NET, Go
Some JMS implementations support various client types via non-java-specific messaging protocols such as STOMP, AMQP and MQTT.

Related

Difference between Spring Kafka lib and native Kafka Java API

For a Java/Kotlin Spring boot app, if I want to send messages to Kafka or consume messages from Kafka. Would you recommend using Spring Kafka library or just using Kafka Java API.
Not quite sure are there any more benefits Spring provides or just a wrapper? For Spring they provide a lot of annotations which seems more magics when having some runtime error.
Want to hear some opinions.
Full disclosure: I am the project lead for Spring for Apache Kafka.
It's entirely up to you and your colleagues.
It's somewhat comparable to writing assembly code Vs. using a high level language and a compiler.
For an existing Spring shop that is familiar with spring-messaging (JMS, RabbitMQ etc), it's a natural fit, the APIs will be very familiar (POJO listeners, MessageConverters, KafkaTemplate, etc, etc).
When using the simplest APIs, Spring takes care of the low-level stuff like committing offsets, transaction synchronization, error handling, etc, etc.
If you have very basic requirements and/or want to write all that code yourself, then use the native APIs.

What is Cometd ? Why it is used and how to work on that

i'm just a beginner in cometd , and i'm interested and wanted to learn what cometd is and what for it is used i googled it out and found some resource.Under the following link
1.http://docs.cometd.org/reference/installation.html#d0e346.
I tried out with the given demo but i could not able to get the expected output from it. can anybody post some resource url's so that i can learn ?
Disclaimer: I'm the CometD project leader.
CometD is a set of library to write web applications that perform messaging over the web.
Whenever you need to write applications where clients need to react to server-side events, then CometD is a very good choice. Think chat applications, online games, monitoring consoles, collaboration tools, stock trading, etc.
See more at the preface.
CometD ships a JavaScript client library, a Java client library and a Java server library.
This allows you to write applications in the browser with fine-grained logic and control on the server.
The server library, being in Java, leverages the high scalability of the JVM and the powerful asynchronous I/O API that the JVM and the Servlet specification provide.
CometD is transport agnostic: you write your applications using high level APIs, and CometD takes care of delivering the messages over the wire using the best transport available: WebSocket or HTTP, also providing a transparent fallback in case WebSocket does not work.
CometD provides a clustering solution called Oort that allows you to scale horizontally your web applications.
CometD comes with a ton of features and an extended documentation along with tutorials and demos you can use as a starting point for your project.
Join CometD to start hacking on your CometD-based web applications.
The CometD tutorials are currently written for CometD 2.x, but a port to CometD 3.x (the current version of CometD) is currently underway, so that requires a bit of patience.
But you can start right away by following the primer and deploying the demos.
I hope you can get started with CometD with the above references.
Drop an email on the mailing lists for any help you may need.

JMS Vs JAX-WS or JAX-RS

I want to understand the usage of these two JAVA EE API's.
I understand that we can use JMS for messaging between two systems/modules, synchronously or asynchronously. We can do this either by P2P or Publish/Subscribe methods.
And I also understand that JAX-WS is the SOAP Implementation Java API.
But in common both offers sending messages and receiving messages.
So my questions are:
When should we use JMS over JAX-WS?
When should we use JAX-ws over JMS?
Is JMS really interoperable?
Thanks

Can we use JAX-WS to generate web service clients for TIBCO

In my project I am using a wsdl provided by TIBCO to generate web service client classes. These clients are responsible to to consume TIBCO web services over SOAP/JMS.
I see that the designer has made a comment in design doc like this:
TIBCO jms bindings are proprietary, so standard tools liek JAX-WS , JAX-RPC cannot be used to generate clients. Hence Spring Web Services will be used to generate the clients.
What does this mean? The designed is no logner with the team. I have no way of asking him
Standard SOAP binding to JMS defines a set of JMS properties that can be then used by the toolkits like JAX-WS or JAX-RPC to send the SOAP over JMS. E.g. SOAPJMS_requestURI, SOAPJMS_soapAction, SOAPJMS_contentType, etc.
The developer has probably not followed all the requirements stated in the standard and e.g. already existing endpoint that produces the SOAP requests might not set all the required JMS properties when sending a JMS message, or it might require different set of JMS properties to be set for messages that it consumes.
Spring-WS is probably more flexible when it comes to such customizations and not so picky when processing received messages thus it was recommended by the developer.
At the time the TIBCO code was written, there was no standard for SOAP over JMS (A W3 recommendation for SOAP over JMS was released just over a year ago) and all SOAP over JMS bindings were proprietary.
All this really means is that some tools will not understand the bindings and you will need to configure them yourself manually. Other tools will understand the bindings and will automatically configure the bindings in the client. Try it with different frameworks and see how you go.

SOAP over JMS, requirements for WSDL

I'm trying to implement integration using JMS as a transport and SOAP WebServices being interfaces for my applications to be integrated.
Is it required that the WSDL itself defines transport as JMS?
Can I leave it to be HTTP and move the configuration of the JMS queues elsewhere?
I'm considering Apache Camel as an alternative.
The JMS parts in the WSDL are only hints how to invoke the service. There might be somewhat tricky without the hints if you rely on some import tool generating skeleton code, without the hints though.
I have even used WSDLs with both HTTP and JMS transports defined in them, so that is also possible.
How you configure your queues is another matter, because it depends on which framework you use.
I can't see how Apache Camel should be an alternative to SOAP over JMS. Camel is an integration engine (actually able to do SOAP over JMS) but not a transport standard itself. As a small sidenote, I really recommend Camel to do integration tasks.
You might want to carefully think about your requirements for your integration needs. SOAP over JMS can be quite powerful, but also a bit complex to design with, since people tend to think about SOAP as a synchronous service definition and JMS is designed mostly for asynchronous communication, even though there is somewhat support for synchronous calls as well.