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
Related
I have a Soap web service deployed in one Application Server. We want to integrate that Soap Webservice with Apache Camel in another application server (JBoss Fuse) server. Are there some guidelines available?
What is the application server that hosts the webservice? What language/technology is the webservice coded in? What (broadly) will the Camel route do.
Camel provides a heap of different data input endpoints -- direct memory, HTTP, FTP, files, SOAP, etc., etc. Connecting your webservice to Camel comes down to choosing one of these that endpoints that your webservice can use. Camel offers a huge amount of flexibility in how it accepts and responds to data, and the choice of an approach really depends on the needs of your application, and how it is developed.
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.
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.
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.
What are the disadvantages of using SOAP services?
Quotes from this wikipedia article: SOAP
Because of the verbose XML format, SOAP can be considerably slower than competing middleware technologies such as CORBA. This may not be an issue when only small messages are sent.[7] To improve performance for the special case of XML with embedded binary objects, the Message Transmission Optimization Mechanism was introduced.
When relying on HTTP as a transport protocol and not using WS-Addressing or an ESB, the roles of the interacting parties are fixed. Only one party (the client) can use the services of the other. Developers must use polling instead of notification in these common cases.