Currently I'm doing the integration work of one project. In this project, we need to expose a restful api with java framework Wink. Since we have several other components to integrate, we put a message queue(activemq) between the api layer and other service parts.But this time the api layer will communicate to the lower level in an asynchronous way. In my understanding, the restful api should run in a synchronous way. For example, in the api layer, if one thread received a request, the response will get returned in the same thread. So there is a internal mismatch between these 2 communication styles. My question is how can we integrate these 2 parts to make the api layer work without sacrificing the features in message queue like reliability and performance?
Any suggestions will be apprciated here.
Thanks
Asynchronous callback is possible in REST communication, see this JERSEY framework example:
https://jersey.java.net/documentation/latest/async.html
But yes the latency should be controlled as your client would be waiting for server to respond, and would be good if client calls it in AJAX way.
Simplest way would be to fork a new process through "executor service", which sends a message in a channel to lower level api and listens back for response in another channel(MQ communication). And on process completion return a response, which then the higher API will push back to client.
Related
I'm exposing functionality to access user details via a rest call.
From reading this post: Is Spring Boot MVC controller multithreaded? spring boot rest services are multithreaded. Does this mean using Akka to multi-thread web services does not serve any use?
Using Java Akka will not offer any multi-threaded advantages but will offer:
If a rest call fails with error (e.g 404) Akka can be used to restart the rest call or kill the thread, so stopping the service.
If the a certain rest call is taking much of time to complete Akka can be used to kill the call after a duration of time.
Akka can be used to throttle requests to rest client, useful if service allows max requests in period of time.
Are my assertions correct? If I'm not concerned with these points above, should I still use Akka or use the functionality to access the user details and not wrap the it with Akka? Could Java futures be also used for these points?
Hi there we are planning on integrating a websocket server implementation as frontend to our RabbitMQ systems. Currently we are running some Java/Groovy/Grails based apps which use the RabbitMQ server.
We would like to have a simple websocket server implementation that handles connections etc and that passes the request to our RabbitMQ layer.
Clients (hardware devices) would connect to a websocket layer that handles the request to RabbitMQ. Some other process takes on the job of handling the request and places back data in the queue if needed so that RabbitMQ is able to pass the data via websockets back to the client.
I am a bit lost in the land of websockets so i am wondering what other people would advise to use.
You can use rabbitmq itself with the webstomp plugin and sock.js for web frontends. You can expose this directly or via something like haproxy.
http://www.rabbitmq.com/blog/2012/05/14/introducing-rabbitmq-web-stomp/
In version 3.x it is now included by default, just enable the plugin.
For Java there are a couple of choices:
Atmosphere
Vert.x
Play 2.0
Netty directly
There are so many ways to skin the cat. Atmosphere will probably get you the furthers if you already using Grails. You will have to write a custom Broadcaster IIRC there is not one for RabbitMQ but you can just copy one of the existing ones.
Also with RabbitMQ or any queue your going to have to decide whether your going to make queues for each for each user (browser using websocket) or your going to aggregate based on some hash and then dispatch internally (ie make a giant map of mailboxes). Akka would be a good choice for mapping to mailboxes.
Before we develop our custom solution, I'm looking for some kind of library, which provides:
Non-blocking queue of HTTP requests
with these attributes:
Persisting requests to avoid it's loss in case of:
network connectivity interruption
application quit, forced GC on background app
etc..
Possibility of putting out all these fields:
Address
Headers
POST data
So please, is there anything usable right know, what could save us whole day on developing this?
Right now we don't need any callbacks on completed request and neither saving result data, as there won't be such.
In my humble opinion, a good and straightforward solution would be to develop your own layer (which shouldn't be so complicated) using a sophisticated framework for connection handling, such as Netty https://netty.io/ , together with a sophisticated framework for asynchronous processing, such as Akka http://akka.io/
Let's first look inside Netty support for http at http://static.netty.io/3.5/guide/#architecture.8 :
4.3. HTTP Implementation
HTTP is definitely the most popular protocol in the Internet. There are already a number of HTTP implementations such as a Servlet container. Then why does Netty have HTTP on top of its core?
Netty's HTTP support is very different from the existing HTTP libraries. It gives you complete control over how HTTP messages are exchanged at a low level. Because it is basically the combination of an HTTP codec and HTTP message classes, there is no restriction such as an enforced thread model. That is, you can write your own HTTP client or server that works exactly the way you want. You have full control over everything that's in the HTTP specification, including the thread model, connection life cycle, and chunked encoding.
And now let's dig inside Akka. Akka is a framework which provides an excellent abstraction on the top of Java concurrent API, and it comes with API in Java or Scala.
It provides you a clear way to structure your application as a hierarchy of actors:
Actors communicate through message passing, using immutable message so that you have not to care about thread-safety
Actors messages are stored in message boxes, which can be durable
Actors are responsible for supervising their children
Actors can be run on one or more JVM and can communicate using a wide numbers of protocols
It provides a lightweight abstraction for asynchronous processing , Future, which is easier to use then Java Futures.
It provides other fancy stuff such as Event Bus, ZeroMQ adapter, Remoting support, Dataflow concurrency, Scheduler
Once you become familiar with the two frameworks, it turns out that what you need can easily be coded through them.
In fact, what you need is an http proxy coded in Netty, that upon a request receival sends immediately a message to an Akka Actor of type FSM (http://doc.akka.io/docs/akka/2.0.2/java/fsm.html) which using a durable mailbox (http://doc.akka.io/docs/akka/2.0.2/modules/durable-mailbox.html )
Here is a link to open-source library that was a Master Thesis of a student at Czech Technical University in Prague. It is very large and powerful library and mainly focuses on location. The good thing about it, though, is that it omitted the headers and other -ish that REST has.
It is the latest fork and hopefully it will give you at least inspiration for "own" solution.
how about those concurrent collections:
http://mcg.cs.tau.ac.il/projects/concurrent-data-structures
i hope that the license is ok .
You'll want to have a look to these to posts. (added at the end of the document)
Very basically an approach that works in a proficient way for me is to separate requests from the queue and the executor.
Requests are executed as Runnables or Callables. Inherit from them to create different kind of requests to your API or service. Set them up there adding headers and or body prior to to executing them.
Enqueue those requests in a queue (choose which fits better for you - I'd say LinkedBlockingQueue will make the job) linked to an executor from within a bound service and calling them from your activity or any other scope. If you don't need to get responses and callbacks you can avoid using Guava for listening to futures or create your own callbacks.
I'll stay tuned. If you need more depth I can post some specific pieces of code. There's the source of a basic example in the first link though.
http://ugiagonzalez.com/2012/08/03/using-runnables-queues-and-executors-to-perform-tasks-in-background-threads-in-android/
http://ugiagonzalez.com/2012/07/02/theres-life-after-asynctasks-in-android/
Update:
You can create another queue for those requests that were impossible to execute.
One approach that comes to my mind would be to add all your failed requests to the retry queue. The retry queue would be trying to re-run these tasks while the phone still thinks that there's any kind of internet connection available. In the request object you can set a max number of retrials and compare it to a currentRetry number increasing it in every retrial.
Mmm this might be interesting. I'll definitely think about including that in my library.
What kind of arguments one should use when choosing between integration using web service vs JMS? I'm familiar with basics of both approaches however in some cases it is unclear as to which one would be the best for a given situation. I guess I'm looking for a high overview comparison with use cases.
thanks
JMS is a messaging service. It is asynchronous and 2 directional, i.e. you can write application that both sends and receives messages. But this must be application implemented typically in java. I mean it cannot be thin client. And standard protocol of JMS is TCP based, so it may be blocked by firewall.
Web service is designed as a transport over HTTP, so it typically passes firewalls. But it is one directional: client calls server; server cannot call client. It just can response client's calls. Client of web service (especially RestFull web service) is very simple, so it can be easily implemented as a thin client (e.g. AJAX client).
Good question.
I will use Web Service when:
1. Dealing with cross domains, typically services environment when I am not sure about the client technology.
2. Need Synchronous response.
And pickup Messaging when (Hope you mean Messaging not just Java version):
1. Need Asynchronous request/response.
2. High Availability.
3. Confirmed Delivery.
What is the best way to provide an asynchronous service interface to multi-platform (primarily java and .net) clients? The backend service is implemented in java.
We are looking at asynchronous web service and message queues, but apparently cross platform asynchronous web service* is not supported yet in java (as far as I know) and for message queues, I was not sure which codec/protocol would be best.
*:Cross platform asynchronous web services can be described in WSDL 2.0, but not in WSDL 1.1 (As far as I understand). Now, JAX-WS 2.x does support asynchronous web service, but not WSDL 2.x. So I'm assuming that JAX-WS asynchronous web service's clients have to be JAX-WS clients, and that we can not use.
Thanks in advance!
EDIT: The difficulty here is that the service is asynchronous, and we prefer a callback based interface for efficiency (so we don't want to use 2 calls on a synchronous WS interface, etc.)
If its messaging, than use a Messagequeue system. like ZeroMQ. they are all cross platform.
otherwise we do it with .net WCF, and use JaxWS from java to test, that the interface is compatible.
Don't know, what's best, but SOAP is a good choice for a Java backend. The messages are xml based (e.g. not restricted to Java platforms) and it is widely used so you get a lot of support, tools and libraries on the net.
Another idea that might fit your needs: XMPP.
It is definitly asynchronous, client sending a service request (wrapped in a xmpp message) is the callback and doesn't wait for an immediate answer. I've used in a scenario where I send 'service request' from a xmpp client to a server and received the answers, immediately or a bit later, depending on the complexity of the calculation. This was a human-machine interaction but machine-machine should be even easier.