To put it simple, I've written a JSE Swing app that needs to talk to a GWT server I've written earlier.
I absolutely love the way GWT does remoting between it's javascript and server sides and wish I could utilize this mechanism.
Has anyone managed to use GWT-RPC this way? Should I just go Restlet instead?
If you are doing Java-to-Java communication, RMI would be simpler and more expedient. Serializing data to/from some XML or URL-based format doesn't add a lot of value.
With EJB3, it is dead simple to deploy remote objects and to call them. You can then turn those EJBs into web services if you need to later, but for Java-to-Java, I can't think of a good reason to not use some sort of RMI-based communication.
Related
I have to deploy some Java servers in a bunch of different networks. For each server, I need to monitor its status and send it tasks to be executed in that specific server. Something like distributed workers.
This servers would be used from different platforms and languages so I need to find a way to communicate with them and obtain the needed information. Which is the best way to do this? I've been reading about use JSONs to communicate with my servers but I'm trying to figure out if there is a better approach.
Another solution could be to have a web dashboard and control all through web petitions but I prefer the servers to be standalone. Any ideas on what I can do?
At the moment I would suggest REST interfaces for your Java server. Since REST with Json is easy to implement in other languages too and you can even use HTML and JavaScript to write a Monitor client. So from my point of view this is the most flexible solution.
An other solution would be to use XMPP to "talk" with the server and "ask" them about there state. I remeber this as a solution for machine to machine communication, but this was before the Json and REST boom so I would not suggest to go with this.
When your other platforms consists of Java and C# mostly SOAP could also be a solution, since there are good code generator for both languages which can create the WSDL from code and vice versa. But its kinda difficult to use SOAP in JavaScript (as far as I experienced) and maybe other languages have the same problem with SOAP.
If multiple platforms are involved, web services are probably your best bet. You can have you java servers expose web services (for status and task execution) and you can call them from anywhere/any system.
I'm debating whether I should use java RMI or standard Java networking for an application i'm working on.
The app will be a networked system that has heartbeat sensors and failsafe-features. So it's a 3-tiered system, with at least a DB and java application.
So if my Database fails on one machine, I'd like the 2nd machine to "sense" this.
I'm a bit confused about Java RMI, whether it's worth it to learn it.
Or if I use standard Java networking , I can do the same as RMI? I mean, if I really know the Java networking well.
Thanks!
These days it is pretty easy to set up web services using SOAP or REST. With REST you can use XML or JSON messages without really having to know all about it. All these types of services can be accessed from .NET code or PHP or Javascript. (Well ... SOAP is sort of a pain except in .NET and Java. //personal opinion )
Spring can help you set up a service and a client interface to it is pretty easy. Fairly close to standard Annotations on bean classes and business methods define the interfaces and Spring does the heavy lifting. (I'm talking about Spring Web Services and not the Spring Remoting, though that would work as well. Spring Remoting isn't much better than RMI IMHO.)
You can also use Jersey (JAX-WS) or Jackson (Parse JSON) to do the remoting. Standard Annotations on bean classes and what-not build the interfaces. CXF will do JAX-WS and JAX-RS as well. Those are Java standards for building services and clients that communicate via remote messages.
Alternatively there are eclipse tools for generating both sides of the remote interface. All are tied to some framework (Axis-2 or CXS are some). Its sort of a code generation thing.
You might want to look into these a bit and see which one resonates with the way you look at things.
I know that I prefer all of these over using RMI. But I haven't used RMI directly in a long time.
RMI is higher level protocol compared to the bare TCP/IP support in Java via Socket class that you seem to refer to as "Java networking". If the only thing your system does is sending heartbeats and there are just few nodes you should choose RMI for simplicity reasons. As all of the participants are JVMs there is no need for any interop and extra libraries to support that and as the number of participants is limited there is no need to consider anything fancy.
Most Java web application frameworks use server-side session objects to store session state. Because this complicates scaling, I'm looking at frameworks that implement a shared-nothing architecture, e.g. the Play! Framework and Apache Click. What other frameworks should I add to this list?
GWT framework - you write full AJAX application, so you can store everything you need on client side and to server send only authorization tokens (which could be stored in memory singleton or in database for verification).
Any javascript solution for client side, where you can do the same. On client side you can use Spring MVC just for implementing business methods and allowing them via REST channels (JSON as data transfer protocol is the preferred option).
Take any of MVC frameworks, just don't use sessions. It's dead simple: most of them do not use session by themselves, it is you who decide whether to put anything into a session.
Play framework should provide everything you need as it was designed with stateless principles. As mentioned other framework could do the trick but play is a full stack and geared for rapid development (probably the equivalent of ruby on rails for java).
You can easily and quickly develop fully fledged web application with user authentication and authorisation. I would strongly advice to go through the tutorial. Java development has never been so productive and fun!
Restlet (2.1) has a CookieAuthenticator that handles authentication without reliance on server-side sessions, so that's another framework that can be added to the list.
We have a Swing application. Now I need to set up a Java EE server that provides some services to these Swing clients on a LAN.
What is the best practice to implement this, considering that client and server communicate in both ways?
If the clients are in the LAN and you are programming both sides I would take RMI. Because it is much more performant than Webservices. I think it is the native way for communication with a Java EE Server.
Perhaps you should create Facade classes on the server-side which are providing the services.
Using JAX-RS with implementations like Jersey or Apache CXF with XML or JSON data format is a decent option.
If you need flexibility, go with Spring remoting, as it abstracts the remoting layer, so an eventual change of implementation keeps your hands clean.
I use HTTP Invoker, beacuse it's lightweight and uses java serialization, so it's a good choice for Java client -> Java server communication.
The downside of HTTP Invoker, in contrast to RMI, is that you always get new instances of objects from the server, so if an object sent from the client is changed on the server, the change won't be reflected in the client instance.
Good info is here: Considerations when choosing a technology
I would advice using Webservices.
RMI - This is pretty fine for Java applications, but it's general interoperatibility is imho low. If i imagine that you would like to switch from Swing to other technology or add another client not written in Java, RMI would be nightmare then.
Web services - It does not cover both directions communication. It's fine for Swing - Java EE, but you would have to do also some WS (or any other exposing mechanism) on Swing side which would take care of Java EE - Swing communication. E.g. like REST on Java EE and XML-RPC on Swing.
You can also think of using ESB.
I would suggest Spring RPC or maybe EJB 3 if you have a Java EE server and prefer to stick to standards of Java EE specification
Web Services are not binary and therefor will suffer from performance issues.
I have a java server with a BlazeDS interface to handle Adobe AIR clients. I also have a bunch of legacy stand alone java apps that I'll need to integrate with the server. The java apps need all the same methods and remote calls that the AIR clients needs. So it would save tons of work if I could call the remote object methods from the java apps.
Anyone know if this can be done?
You can use the BlazeDS Java AMF libraries directly over HTTP. But interacting with the BlazeDS MessageBrokerServlet will require some extra work. Probably an easier path is to just expose the same Java services through another protocol that the Java code can more easily use.
Take a look on this library, it allows you to connect Java with a server running BlazeDS. On the other hand if you are interested in pure performance you can investigate another protocols..there are plenty of them.