I'm going to be building an app shortly that requires reliable, reasonably high throughput messaging. Many of the endpoint consumers of our messages are SOAP web sevices however.
RabbitMQ and related technologies look very attractive - decoupling message delivery from the application, and providing a reliable message queuing system that can persist even through a reboot. This sounds very attractive, but from what I've read, RabbitMQ is designed for an architecture in which you maintain both the consumer and the publisher.
Are there any similar messaging systems that can target web services?
You will always need some mapping between the message and the parameters of the web service. Should be very easy to create a small "bridge" app to receive the message and call the web service. You would still gain teh advantages of using RabbitMQ / SOA and the arcitectures this allows
Related
My company long time ago decided to expose a JMS queue to customers in order to exchange data. We're in the process to migrate application server and we have to update all the client libraries. So we thought to expose a more "standard" interface.
We're looking to a simple way to expose a JMS queue through a standard SOAP or REST protocol. It's not SOAP over JMS, it would rather be the opposite "JMS over SOAP".
Seem that ActiveMQ(Artemis) has a REST protocol. It is a viable solution for us since we're migrating to Wildfly 10, but it's a bit complicated (see for instance posting a message requires 2 calls: see Posting Messages), and it is ActiveMQ-specific. We have to implement it again for the old Weblogic servers.
The solution we're searching for should have the same reliability of JMS, in respect of the CAP theorem (providing message deduplication on send, and idempotent reads). Any suggestion?
As per my understanding this is anti pattern where we want to combine both REST/Webservice and JMS or creating hybrid model.
JMS has strong reliability,performance,monitoring,exception handling, async response and guaranteed delivery in compared to REST/Webservice.
The only weaker point of JMS is external firewall access that can be overcomed by creating hybrid model.
Restful JMS.
http://activemq.apache.org/rest.html
http://activemq.apache.org/activesoap.html
Thanks
In developing backend components, I need to decide how these components will interact and communicate with each other. In particular, I need to decide whether it is better to use (RESTful, micro) web services versus a message broker (e.g. RabbitMQ). Are there certain criteria to help decide between using web services for each component versus messaging?
Eranda covered some of this in his answer, but I think three of the key drivers are:
Are you modeling a Request-Response type interaction?
Can your interaction be asynchronous?
How much knowledge does the sender of the information need to have about the recipients?
It is possible to do Request-Response type interactions with an asynchronous messaging infrastructure but it adds significantly to the complexity, so generally Request-Response type interactions (i.e. does the sender need some data returned from the recipient) are more easily modeled as RPC/REST interactions.
If your interaction can be asynchronous then it is possible to implement this using a REST interaction but it may scale better if you use a fire and forget messaging type interaction.
An asynchronous messaging interaction will also be much more appropriate if the provider of the information doesn't care who is consuming the information. An information provider could be publishing information and new consumers of that information could be added to the system later without having to change the provider.
Web server and message broker have their own use cases. Web server used to host web services and the message broker are use to exchange messages between two points. If you need to deploy a web service then you have to use a web server, where you can process that message and send back a response. Now let's think that you need to have publisher/subscriber pattern or/and reliable messaging between any two nodes, between two servers, between client and server, or server and client, that's where the message broker comes into the picture where you can use a message broker in the middle of two nodes to achieve it. Using message broker gives you the reliability but you have to pay it with the performance. So the components you should use depends on your use case though there are multiple options available.
SOA is about integrating heterogeneous applications or composing business processes from lower level services.
Can we realize complete SOA solution in a large enterprise where applications cross departmental and ownership boundaries using only state of the art JMS provider that supports both Java and non-Java JMS clients and using web services and application servers at various integrations points if needed without using more complex ESB product?
Integration architect with good industry experience can best answer this question.
Yes - an ESB is not necessary to implement SOA.
Preferably, use Web Services over JMS for implementing your services.
Some issues that are commonly addressed by ESB, that you should be aware of:
Adapters
When using legacy service provider or client that don't support the relevant technologies (JMS, SOAP,...) the ESB can act a an adapter for them - in your case all you services and clients should support these technologies them self, or you'll need to implement an adapter.
Routing
The ESB acts as a router, hiding the physical address of the service provider.
you should use a strict Queue \ Topic naming convention to ensure consistency and maintainability of your solution.
consider coexistence of multiple environments and versions when planing the naming scheme.
Service Registry
You should have some kind of registry with the specs of all services.
some issues that are not easily supported are
Content Based Routing
Central Logging \ Policy enforcement \ Auditing
In addition to what is in Ophir's answer:
Your question translates as, "can JMS be used for wiring?" Yes, it can be.
SOAP - the crux of many an SOA solutions - is inherently a messaging protocol. This allows an asynchronous solution, and hence JMS fits the bill. SOAP needs to run on another session/application-layer protocol, which JMS can be.
Envisage the solution as following:
Service providers listen on a JMS bus, possibly a specific queue/queue+message selector
Service consumers post messages on the JMS bus, addressing the service they need (particular queue)
The response varies based on the requirement, typically a separate queue for response (possibly specified in the JMS reply-to property,) to which the consumer listens to for responses.
In essence, the service port is a JMS queue.
I venture that most but not all web services today are synchronous. A fundamental design decision existing if to implement asynchronous processing.
Is there value in implementing a processing queue system for asynchronous web services? It is a MOM/infrastructure decision with which I am toying. Instead of going system-to-system implement a middleware which will broker said transactions. The ease of management and tracking/troubleshooting of a spider web of services seems to make the most sense.
How best have you implemented asynchronous web services?
It is interesting I stumble into this question. I have exactly the same concern with the current project I am developing.
Our web services are develop using TIBCO technology, and they are also synchronous by default. We are considering creating a queue mechanism to process these requests asynchronously; the reason being: the back-end storage technology we have to interface with is notoriously slow (it is an imposed technology, and we have to deal with it)
Personally I am considering creating a 2nd WSDL definition for the asynchronous replies (which can occur from a few seconds to a few hours later than the request, depending on the load on the mentioned back-end storage.) Clients calling our Web Services will have to in turn implement a web service using this "2nd WSDL" to which we act as clients.
I'd be interested in knowing the directions you are exploring.
This question already has answers here:
JMS vs Webservices
(9 answers)
Closed 7 years ago.
I need to develop a system which accepts orders and returns confirmation. Orders could come from java or non java clients.
Not sure whether to go for web service implementation or JMS.
Any suggestions ...
JMS is an API which abstracts messaging middleware, like ActiveMQ or IBM MQSeries.
Messaging middleware has a store-and-forward paradigm and asynchronous message passing, while web services tend to promote a synchronous procedure calling paradigm. In distributed systems where a lot can go wrong, dealing with things asynchronously tend to focus the mind better to the things you need to do when part of the system is not available or poorly performing and the code needed to deal with that tends to be a lot less complicated.
Clustering parts become trivial if you have multiple servers listening on the same queue, parallelism and load balancing is for free in this case.
Personally I find JMS much easier to work with and more robust and reliable than web services, but the messaging middleware must support all platforms you want to use. If all the components who need to talk to each other are under your control, I would give a messaging middleware with a JMS interface serious consideration.
If the other party is external then probably Web Services rule, and in that case you could think of a using thin layer to convert the external web service to an internal message passing infrastructure so you still have the most of the advantages.
If it is "just slapping an remote API on a webapp" then of course it does not pay either to setup asynch messaging.
You can use both depending on your interoperability, scale, distribution and integration requirements.
Web service approaches utilising SOAP, XML RPC and REST provide something quite interoperable given the use of HTTP as the protocol. From a service side, you might receive a web service request and then marshal it into a message. Your message could then be delivered to a messaging bus.
JMS is a reasonable API for interfacing with a messaging bus and I've found that Active/MQ very good here. Active/MQ supports JMS across many languages.
With messaging you can utilise the Request/Reply Enterprise Integration Pattern to receive responses and return them via your web service. However think about the merit of providing immediate feedback as to whether the order has been processed vs feeding back the fact that an order has been received; you might not need to implement request/reply to acknowledge that an order has been received.
The benefits of messaging can be found here: http://www.eaipatterns.com/Messaging.html
You may even want to look at Apache Camel to simplify the development of highly scalable and distributed service layers.
check the links
difference between using JMS/Messaging Middleware versus Web services
Messaging, JMS and Web Services
Web Services HTTP vs. JMS
Choosing among JCA, JMS, and Web services
Java Message Service
Web service
So if communicating Applications are Java based use JMS and if may be different then Web services... thats what which I follow.
For interoperability sake, use a web service. JMS is little used outside the Java world.