Im trying to implement an Observer/Observable pattern on an EC2 instance. I have been able to create the application using RMI relatively simply. However trying to get RMI and the Amazon cloud to work has been neer impossible for client callbacks.
RMI also limits the client applications to being Java based. Hence i've been messing around with JAX-WS in order to use SOAP messages. However i havent been able to come up with a solid way to make callbacks on the client with it.
Does anyone know of a way that i would be able to program in a similar way that RMI works with client callback methods to update Observers when something on my server has been changed, using hopefully a language independent distributed method?
I would be willing to make it so that all my clients must be written in java, but i need to be able to get it working on the EC2 instance which RMI seems incapable of doing callbacks even if i open all TCP ports and use a security manager.
Thanks,
Ben
You could try a messaging solution, something like RabbitMQ.
In this way Observable pushes a message to subscribers (Observers). Completely decoupling your clients from the implementation language/specifics of the EC2 instance.
Related
I must create a desktop java client that comunicate to a servlet in order to receive some notificationes.
The servlet is an async servlet but my doubt is with the client.
How is the best way to "listen" a response from the server. I looked to the httpcomponents-asyncclient from apache, but I´m not trully convinced about that library. Maybe an infinite loop?
You might want to check out netty, it's what we use for our IntelliJ IDEA real time collaboration plugin to communicate with our remote server. It's very simple to get started with and abstracts all the hard parts, including creating secure connections. This is the netty user guide, it should get you started.
HttpComponents from Apache is very common
(be careful not to use the old one). Check a simple example.
Do you need to be constantly waiting for responses? If so, this is not the correct direction! The client should not have to call any method to get notifications... it should just be listening to some socket that the server writes to... Or just processing some queue. Perhaps you need to consider learning a bit of real time technologies and methods.
I have a JRuby/Rails app that needs to get data from a system written in Java. I have already worked out how to call Java code from Ruby.
However, lets say that the Client object I need to create, starts threads, communicates with the internal system etc, and that the data is delivered asynchronously in callbacks.
Do I have to write a separate web service (that creates this Client) with a permanent connection to the Java system? In such a way that my Ruby/Rails code can call it synchronously. Or is it possible to write this asynch handler directly in Rails?
When multiple HTTP clients issue their GET's, I would of course have to connect to the Java system when the first client arrives. For the following clients, the data would already be there.
I realize what the proper solution would be, but I'm curious whether I can do it all in Rails.
I can (for now) live without the realtime updating of the webpage, as long as the data in the Java callbacks are stored "somewhere" so that the next HTTP refresh/GET can return it. Nest step would be SSE, Javascript etc.
I think I know how to create the Java web service, however I would rather keep the solution a bit simpler with fewer services.
Thanks
Since you also have access to the java code, I have two approaches to extend the java backend, in order to provide the data you want to use in your ruby frontend application.
Use REST or a HTTP Service
Your ruby webservice could interact with the backend utilizing REST (or any other HTTP approach). This would result in cleaner and more reusable code. Since you're able to access the backend data with any client that is capable of HTML.
Use TCP together with a little protocol
In this approach the clients have to connect to a TCP socket on the backend to send data back and forth. You have to write a little byte or string based protocol which you also have to parse. It's more complex than the first approach, but also more performat and you don't have to rely on external libraries (e.g. jersey, for REST). It also has all the advantages of the former approach, you can serve any client capable of network communication and socket handling.
I'm writing a server-client architecture based game in Java.
For design reasons, I would like to use asynchronous calls for passing client actions to the server, and also asynchronous callbacks for passing the result(s) of said actions back to the client. Asynchronous calls allow buffering of client actions. Queued buffering allows simple, basically one threaded processing of client actions.
At the moment, my server and client code is pretty symmetric. They create a registry, then export and bind themselves.
Asynchronicity is achieved by buffering the incoming actions or results in a ConcurrentLinkedQueue. Actual processing is done by a thread running at regular intervals.
However, this current architecture does not work when clients are firewalled or behind a NAT. In this case the server simply can not reach clients to push results to them.
Furthermore, in this current architecture the server does not know which client sent a given action, unless a redundant layer of authentication or session handling is introduced. This allows forged actions and cheating.
I've been thinking about possible solutions but haven't found a proper one:
Client pull instead of server push. There could be a method on the server that the clients call periodically to fetch their results. However, this approach seems very ugly, it introduces additional delays, bandwidth and timing issues. Does not solve action forgery either. Direct notifications are also very much preferred.
TCP connections by themselves allow bidirectional communication, and can definitely identify clients, so RMI or JRemoting might be hacked to support it, but I'm don't know how, and I'm not aware of any existing solution.
Message passing. I'm not sure whether message passing frameworks support authentication / sessions or client identification. I'd definitely lose remote methods though.
I believe the correct solution would be to find a remote method invocation framework that supports all of the above.
So in a nutshell, I'm searching for a way to:
call the server asynchronously or pass a message to it
call the client asynchronously or pass a message to it, even behind firewall or NAT
identify the client sending the action
preferably be able to call methods, not just pass messages
keep the ability to easily test it with JUnit and Mockito (multiple clients per machine)
Are there any remote method invocation frameworks with support for these? Which is the best?
I don't know why you would insist on using a RMI or anything similar, as it is by definition unidirectional. But I had to learn a similar lesson...for one of my client-server systems, I implemented something similar to what you have now, using RMI and long-polls. That turned out to be a horrible mess, that just getting worse and worse.
Then I found out about the wonderful world of publish-subscribe frameworks. These are a natural way to build a client-server application without the need to implement a lot of your own plumbing. Moreover, these frameworks support things like auto keepalives, time syncing, session authentication and permissions, and tons of other stuff that you wouldn't want to implement yourself.
For my project, I ripped out all of my own work and replaced it with CometD, which supports both Java and browser (Javascript) clients, and couldn't be happier. It would certainly support all your needs - asynchronous communication initiated from either side, client identification (and many other features), and clients behind NAT would not be a problem once a connection is established. Easy to write tests too, and the whole framework has been scaled up to be able to handle 100k clients, which would be impossible for RMI.
I would strongly suggest that you consider dropping the requirement to be able to call methods remotely. Methods are inherently one-sided, but they still require a call and return. It's much better to design your system with event-driven programming.
Update: I've since moved to the world of web apps, specifically using Meteor.
I'm experimenting with grails in order to interface with an online trading platform.
specifically Interactive Brokers (IB) http://interactivebrokers.com/en/p.php?f=programInterface&ib_entity=llc
The way the API works is you need to have their client program, Trader Workstation (TWS http://interactivebrokers.com/en/p.php?f=tws&ib_entity=llc) running and then we consume the API to do stuff. Consuming the API basically involves creating a "broker" object, calling a connect() member function (this makes a local port connection to the TWS software) and calling something like getData()
The value of grails in this scenario are the GORM features and the web framework provided. I want to be able to define objects abstracted from db implementation, easily do persistance operations and easily provide users with a UI to do CRUD and custom actions.
My challenge is the IB API uses asynchronous communication for requests and replies. i.e. when i call getData(), the API knows to use the callback function dataResults() when it is ready to send them. In order for dataResults() to be callable, the broker object I created still needs to be around to receive the reply.
Inside a controller function, if i create a broker object and call getData(), when the request finishes, the broker object obviously also disappears. So I'll never be able to receive the reply.
I think there might be some way to do this by kicking off background threads but i'm not sure this is the path i want to go down.
Does anyone have any recommendations on what the best approach is?
I'm not married to grails, the reasons i'm using it are above. If there is a desktop app framework that I can also easily make a web interface on top of later, I'm definitely open to that.
thanks in advance.
Create your object in Service and make the Service singleton (which is by default):
static scope = "singleton"
In terms of web UI Grails is definitely a good choice.
Then, the asynchronous operations could be handled by Ajax calls as you shouldn't block the controller waiting for results.
The following [presentation][1] has some good examples
1: http://skillsmatter.com/podcast/java-jee/high-volume-scalable-ajax-with-grails
I'm in the process of writing a client/server application which should work message based. I would like re-use as much as possible instead of writing another implementation and curious what others are using.
Features the library should offer:
client and server side functionality
should work message based
support multi-threading
should work behind load balancer / firewalls
I did several tests with HTTPCore, but the bottom line is that one has to implement both client and server, only the transport layer would be covered. RMI is not an option either due to the network related requirements.
Any ideas are highly appreciated.
Details
My idea is to implement a client/server wrapper which handles the client communication (including user/password validation) and writes incoming requests to a JMS queue:
#1 User --> Wrapper (Check for user/password) --> JMS --> "Server"
#2 User polls Wrapper which polls JMS
Separate processes will handle the requests and can reply via wrapper to the clients. I'd like to use JMS because:
it handles persistence quite well
load balancing - it's easy to handle peaks by adding additional servers as consumer
JMSTimeToLive comes in handy too
Unfortunately I don't see a way to use JMS on it's own, because clients should only have access to their messages and the setup of different users on JMS side doesn't sound feasible either.
Well, HTTP is probably the best supported in terms of client and server code implementing it - but it may well be completely inappropriate based on your requirements. We'll need to actually see some requirements (or at least a vague idea of what the application is like) before we can really advise you properly.
RMI works nicely for us. There are limitations, such as not being able to call back to the client unless you can connect directly to that computer (does not work if client is behind a firewall). You can also easily wrap your communication in SSL or tunnel it over HTTP which can be wrapped in SSL.
If you do end up using this remember to always set the serial version of a class that is distributed to the client. You can set it to 1L when you create it, or if the client already has the class use serialver.exe to discover the existing class's serial. Otherwise as soon as you change or add a public method or variable compatibility with existing clients will break.
static final long serialVersionUID = 1L
EDIT: Each RMI request that comes into the server gets its own thread. You don't have to handle this yourself.
EDIT: I think some details were added later in the question. You can tunnel RMI over HTTP, then you could use a load balancer with it.
I've recently started playing with Hessian and it shows a lot of promise. It natively uses HTTP which makes it simpler than RMI over HTTP and it's a binary protocol which means it's faster than all the XML-based protocols. It's very easy to get Hessian going. I recently did this by embedding Jetty in our app, configuring the Hessian Servlet and making it implement our API interface. The great thing about Hessian is it's simplicity... nothing like JMS or RMI over HTTP. There are also libraries for Hessian in other languages.
I'd say the best-supported, if not best-implemented, client/server communications package for Java is Sun's RMI (Remote Method Invocation). It's included with the standard Java class library, and gets the job done, even if it's not the fastest option out there. And, of course, it's supported by Sun. I implemented a turn-based gaming framework with it several years ago, and it was quite stable.
It is difficult to make a suggestion based on the information given but possibly the use of TemporaryQueues e.g. dynamically created PTP destinations on a per client basis might fit the problem?
Here is a reasonable overview.
Did you tried RMI or CORBA? With both of them you can distribute your logic and create Sessions
Use Spring....Then pick and choose the protocol.
We're standardizing on Adobe's AMF as we're using Adobe Flex/AIR in the client-tier and Java6/Tomcat6/BlazeDS/Spring-Framework2.5/iBATIS2.3.4/ActiveMQ-JMS5.2 in our middle-tier stack (Oracle 10g back-end).
Because we're standardizing on Flex client-side development, AMF and BlazeDS (now better coupled to Spring thanks to Adobe and SpringSource cooperating on the integration), are the most efficient and convenient means we can employ to interact with the server-side.
We also heavily build on JMS messaging in the data center - BlazeDS enables us to bridge our Flex clients as JMS topic subscribers. That is extremely powerful and effective.
Our Flex .swf and Java .class code is bundled into the same .jar file for deployment. That way the correct version of the client code will be deployed to interact with the corresponding middle-tier java code that will process client service calls (or messaging operations). That has always been a bane of client-server computing - making sure the correct versions of the respective tiers are hooked up to each other. We've effectively solved that age-old problem with our particular approach to packaging and deployment.
All of our client-server interactions work over HTTP/HTTPS ports 80 and 443. Even the server-side messaging push we do with BlazeDS bridged to our ActiveMQ JMS message broker.