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.
Related
I am doing some research on SOAP, for a personal project, and I came across a website with a list of pros and cons for using SOAP, and I understood what most of them meant, except for this one under disadvantages:
SOAP is typically limited to pooling, and not event notifications, when leveraging HTTP for transport. What's more, only one client can use the services of one server in typical situations.
From my understanding of pooling, there should be no issue pooling a SOAP Object for re usability. Pooling is simply a way to use the same resources over and over again, like a connection to a database. Also not entirely certain on the context of Event Notifications.
So my two questions here are, what does the above block quoted text actually mean, and is this information correct?
Website: http://searchsoa.techtarget.com/definition/SOAP
SOAP is RPC, and in RPC some local client invokes a method on some remote target and receives a result. That's how it works, so SOAP works that way too. A client invokes a service asking for something and the service just responds.
If you want "events" in this type of communication the most simple approach is to invoke the service more often (i.e. polling). This has the advantage that nothing changes for the server or the client. It's the same RPC call but done more frequently.
These days everyone is connected to the web and everyone is subscribed to all sorts of services. They want to get notified as soon as something happens to the world around them. Pooling becomes inefficient in this sea of users and services because you are wasting resources. You might poll a service a hundred times just to get back one notification. For this reason technology is evolving so that resource use is minimized. And the direction this is moving to is push services.
Now almost everything happens in the browser. Every browser manufacturer rushes to implement the latest technology changes and HTML5 spec. This means actual pages that push notifications to users instead of faking it with Ajax, comet, etc.
SOAP has been around since 1998 and it's not moving as fast as the rest of the web, mainly because SOAP is mostly an enterprise player and because it's a protocol. Because it's a protocol you have to make new technology available to it without breaking that protocol. Things move slower so people have abandoned SOAP in favor of other ways of doing server-client communication.
SOAP is typically limited to pooling, and not event notifications...
That is correct. But be aware that "typically" does not mean "always".
You can have events, but it's harder. It involves using WS-* specifications like WS-Eventing and WS-Addressing. This is a change in the way SOAP clients operate because a client now becomes some sort of a service too because it needs to receive calls too, not just initiate them. If your technology stack implements these specifications then good for you, but if it doesn't, then you have to build it yourself and it's a real pain.
So for these reasons, if you don't have blocking performance or resource usage issues, you "typically" chose doing polling with SOAP and not event notifications.
I'd like to give external access to a web application. Several applications on many clients will use this service extensively (hopefully), which will always lead to CRUD functions on a database.
Is a webservice always the first choice? Is there any rule of thumb when to choose webservices, sockets, etc?
It really depends on who your clients are, what kind of performance are you looking at, how well your clients know the technologies.
Sockets etc might give you a good performance speed but development time might increase for both, you and your clients.
SOAP web services established a standard quite some time back but now people are using REST web services more because of its simplicity and less overhead.
I am heavily impressed by the RESTful webservices offered by twilio
I am sure that Twilio is receiving hundreds of thousands of calls a day and they are performing just well.
Have a look at the following articles for more understanding about them
http://www.ibm.com/developerworks/webservices/library/ws-restful/
http://grails.org/doc/1.0.x/guide/13.%20Web%20Services.html
The big benefit of web services is the ease of use and the predefined interface, but they are "slower" compared to low level socket communication, because for example the XML Requests/Respnses of a SOAP-Service needs to be created/interpreded.
So I would say if you open the service to "outsider" use web services unless speed is really the biggest concern.
Also because web services are mostly accessable through port 80 you have much less problems with proxy/firewalls than with a socket on a random other port.
If you are having a high work load cahcing is also very important because it can speed up the system dramaticaly.
I would choose a web services (SOAP or REST) whenever I can. It's easier to scale a web service than a home brew socket implementation and it takes less time to build a webservice.
Sockets is usually the preferred choice if you need two-way communication (I know that WCF has callbacks).
Webservice makes it a generic way for different type of clients and applications to exchange data also it is dependent on your architecure and infrastructure.
Socket programming is bit complex and some time may create problem in data exchange. It entirely depends on your fuctionaly requirements and architecure which should you use.
if your clients will consume this data from browsers of application then webservice is better choice.
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
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.
I'm building a java/spring application, and i may need to incorporate a stateful web service call.
Any opinions if i should totally run away from a stateful services call, or it can be done and is enterprise ready?
Statefulness runs counter to the basic architecture of HTTP (ask Roy Fielding), and reduces scalability.
Stateful web services are a pain to maintain. The mechanism I have seen for them is to have the first call return an id (basically a transaction id) that is used in subsequent calls. A problem with that is that the web service isn't really stateful so it has to load all the information that it needs from some other data store for each call.