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.
Related
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.
I am relatively new to the Java ecosystem and I am trying to determine what frameworks are available that can do some or all of the following:
Expose POJO's over the network using a variety of technologies
Be able to switch the transport layer (HTTP, TCP, UDP)
Supports different message formats (SOAP, JSON, Binary)
Supports Web Services, REST, and RPC
I want to be able to support using multiple of these communication mechanisms using the same code base (for example using RPC in behind the firewall for efficiency, but exposing the same objects via REST for public consumption). For those familiar with the .NET framework, I'm looking for something of a unified communication framework like the Windows Communication Foundation.
So far I have found tools like Jersey (JAX-RS) that works for REST and Axis2 which is more Web Services oriented but also has some REST support. But I haven't found something as flexible and configurable as WCF. Does that even exist in the Java world? What would be the closest thing to it?
Thanks.
You may want to take a look at Apache Camel which will allow you switch and transform easily as well as supporting a variety of transports natively and having out of the box integration for some popular frameworks.
Additionally if you're looking for a platform to build concurrent and highly fault tolerant applications around, akka is worth a look.
For webservices related stuff I would look at Apache CXF which integrates nicely with Apache Camel, Activiti, Mule and more.
In general though you will find that the Java ecosystem has a lot more options and ways to do certain things (for better or worse). Also keep in mind that you can work with non-Java but JVM based libraries as well.
I'm writing my first client/server android app, and need an advice regarding server architecture.
My app is not a browser based app, but a stand alone client.
On server side i use hibernate/JPA and would like to transfer objects to client side.
What should I use:
Implement MVC- meaning writing servlets that will handle http requests (via Apache for example).
Write my own stand alone primitive server, meaning using simple sockets connection(in java for example), and handle each client in a different thread.
if you can think on a better way, you're more than welcome to share..
HTTP is definitly your choice since many carrier will block other protocols, since application servers/containers will take care of handling the multiple connexions and since it will also be a base if you decide to have a browser-based version some day ...
REST + JSON based webservices are well suited for android, given its simplicity, lightness and readability, but SOAP is also available via kSOAP2.
In my opinion. writing your own socket server is only warranted if you are required to implement your own wire protocol.
Most likely it's not a case for you.
So stick with http since it's widely adopted and has excellent client support in Android.
As for specific server side technology, you need to enumerate your requirements and do some research.
Don't start with Apache if plan to use Java, though. Pick Tomcat or Jetty. For framework, my personal choice would be Spring MVC.
Well, I have some experience in this very sphere and we used apache + php "covered" with nginx. I believe it's better to use standard approach, such Apache + PHP or Tomcat + servlets, cause it's easy to scale if needed and support... Of course it interesting to write your own application, but you might have some troubles with when traffic grows or server is down etc.
Imagine a Java client/server ERP application serving up to 100 concurrent users, both web and swing clients. For persistence we can use Persistence API and Hibernate.
But when it comes to client/server communication, do we really have an alternative to using an AS with EJBs to keep down the programming costs of remote communication?
It seems a very heavyweight solution to throw in EJBs and an application server, just for remoting stuff. There is also the standard way using RMI, but who wants nowadays to code everything on his own...
I know that you'll get a lot of features for free with an AS in addition to the remoting part. And, maybe it's the way to go. But, are there really any other (low programming cost) alternatives to an AS for doing client/server communication for an enterprise application?
Personally I consider Seam to be the ultimate solution to the problem I don't have but that aside, there are lots of options and Spring is used for most of them:
RMI;
Hessian (binary HTTP based protocol);
HTTP Invokers (Java serialization over HTTP);
Web Services; or
Even JMS.
The advantage of the HTTP based remoting methods is that they easily plug into Spring's security models. Plus then you get access to things like interceptors.
You can use light weight remoting frameworks. Spring is having a number of options in this section.
If you ask me one word for both, I will suggest two. Seam or Spring. I myself like Seam, but for lightweight remoting Spring has more viable solutions and support. Again if your AS is JBoss, give a thought to Seam.
An application server is a pretty heavyweight solution. Depending on your requirements, I would try to make sure that you can run on a simple servlet container (like Tomcat). I find remoting much easier with Spring-remoting instead of full EJB. Spring-remoting provides an abstraction on the actual remoting technique used. Hessian has a good reputation as a lightweigth protocol.
Having some sort of a server framework (AS or servlet container) is a good thing as you wont need to think as much about all the low level problems (connection establishment, threading, ...).
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.