I have made a Java Swing application. Now I would like to make it a Client-Server application. All clients should be notified when data on the server is changed, so I'm not looking for a Web Service. The Client-Server application will be run on a single LAN, it's a business application. The Server will contain a database, JavaDB.
What technology and library is easiest to start with? Should I implement it from scratch using Sockets, or should I use Java RMI, or maybe JMS? Or are there other alternatives that are easier to start with?
And is there any server library that I should use? Is Jetty an alternative?
Given that you have the application already, perhaps the simplest thing to do is to identify the interface that you require between the client and server, and first of all to refactor your application to use that interface to talk between the back-end/front-end within the same process.
Then you can start to split this apart. A simple solution would be to split this apart using RMI (since you're talking Java objects and have Java method calls). Spring contains useful tools to simplify/automate the RMI exposure of interfaces.
For the notification requirement, a simple UDP multicast (or broadcast) would suffice.
Note that as soon as you split your application up, you have issues re. maintaining consistent views of data, managing timely updates, handling cases when the server is down, possible loading issues when you get lots of clients etc. In a sense, splitting the application up into a client and server is just the start of a new architecture process.
Mina is a good choice as a network application framework for building a simple server for this purpose - it's a much better option than using raw sockets.
http://mina.apache.org/
If you really need an application server then you could take look at JBoss. It also provides a remoting component (as an alternative to something like Mina):
http://www.jboss.org/jbossremoting
You probably won't have much need for Enterprise Java Beans though. In most cases a simple POJO based framework is more than sufficient - you could tie this altogether with a dependency injection framework such as Guice:
http://code.google.com/p/google-guice/
or Spring. Keep it simple, don't use a J2EE server unless you really need to. Hope that helps.
This is much of what J2EE does, but it's a whole new learning curve because they have pre-solved many of the problems you will run into and many you may not and therefore add on a lot of new technologies.
But at it's most basic, J2EE answers just that question.
I worked in a project like this. We implemented Client-Side Swing and Server side with J2EE. We used EJB,Stateless beans and Message Driven Beans.Also I have been in a device tracking, management project. Our clients were trucks+Swing users and We have used Servets+TCP/UDP,Apache Mina framework to handle and keep connections.
I have been working in Java Swing Client/Server applications for almost 3 years. I would suggest you to go for RMI/EJBs. The initial application that we developed was doing this using RMI/EJB for client-server communication with WebLogic being the server.
But we later found out that there are lot of "browser-like" features to be included to the application such as session-timeout etc., So, we used the BrightSide Framework which wraps the RMI calls through HTTP. One more enhancment we made is that we replaced Weblogic with the open source JBoss server.
The wrapping of calls with HTTP will become very handy and you can make your swing applications really rich. Later, when the situation demands for you to use a website strictly, you can deploy your swing using jnlp.
Hope this helped.
Related
I have an existing java project that I wish to create a mobile 'remote control' application that is capable of calling a few public methods from the existing project.
I have no previous experience of any sort of networking development so would appreciate some guidance on where I should start. I've found a few libraries out there but I'm not entirely sure what I'm looking for (or if I'm overcomplicating things!).
Thanks,
Adam
Java RMI technology may be what you need, here's where to start http://docs.oracle.com/javase/6/docs/technotes/guides/rmi/hello/hello-world.html. It can be used when both client and server are in Java.
If you want to use webservices you could take a look at this Exposing existing API as a Web service
You could check this out Java client/server application with sockets? in order to learn from previous discutions on the client/server subject.
Perhaps lean towards JAX-RS unless you want to deal with low level or have any constraints on protocol to use. http://docs.oracle.com/javaee/6/tutorial/doc/giepu.html.
I'm gonna be creating a fairly straightforward Java app for my company that will process a csv file nightly. It's going to be running on our existing Small Business Server 2011 box so it definitely needs to run as a service (cause it has to run whether someone is logged into the server or not). Eventually I'd like to add a web component to it so I can view the log files from this app via a browser instead of having to pull them off the server manually.
I'm looking for feedback on what would be the best approach for this project. Should I use Jave SE and use a service wrapper around the created app to turn it into a service. Or should I use Jave EE (which I assume already runs as a service)? I've never used or developed for Java EE, so I'm not sure if this would be the best approach or if it would be overkill. If Jave EE is the best approach any and all information you can share on how to get started with it would be much appreciated.
Thanks,
Harry
For the short term, are you looking for a web interface through which someone uploads (web interface) or some process pushes (web service) a csv file that you then process? If yes, then consider Java EE: servlets, RESTful web services, and such, as others have mentioned.
Otherwise, are you just going to process an existing csv file that's "out on the file system somewhere" on a scheduled basis? If yes then consider timer based Java EE service.
Your production environment's management team might have some insight on what they'd prefer. If they are oriented around a windows management scheme they might be more comfortable with the "native windows" approach to deployment, start, stop, restart, scheduling, etc (i.e. the service-wrapped java program). Another layer of "service management" for just one process may be unnecessary complexity.
Document your setup/configuration/expectations whatever you do.
Longer term, as pointed out by others, your desire for a java-based web monitoring interface will require an app server. Consider your short/longer priorities, schedules to be met, etc. What do you need, when?
Java EE is a set of APIs, including JMS, servlet, JNDI, JDBC, EJBs etc. Consequently by using any one of these APIs you can pretty much claim that you're using Java EE, for what it's worth.
As to your particular problem, I would perhaps develop your program as a simple servlet based app and run it under a small container such as Jetty. That way you have a lightweight container (Jetty) and a fairly trivial program to write that can have a simple front-end for admin/monitoring. Note that the Servlet API forms part of the Java EE spec, so you're Java EE compliant, albeit in a minor fashion.
An alternative to this is (depending on how important that web interface is) is to write the program as a standalone program, and run it as a service using the Java Service Wrapper. At a later date you can then embed Jetty into your program and write your simple servlet-based API to run under the embedded web server. I used this approach on a number of projects and it works very well.
Anything that requires enterprise-level functionality should be done using Java EE:
The Java EE platform is built on top of the Java SE platform. The Java EE platform provides an API and runtime environment for developing and running large-scale, multi-tiered, scalable, reliable, and secure network applications.
http://docs.oracle.com/javaee/6/firstcup/doc/gkhoy.html
Others have explained you what is JavaEE.
Since you say "simple", I guess JSP and Servlets can do the work. You will need a web container like tomcat and that's all(it is easier than having a ejb container + web!). Actually servlets and JSP can do stuff which are not simple too.
If you are willing to use something like sessions, which have great design than Servlet sessions, then you might want to deal with EJB and all.
Unless you're ready to implement a web server yourself from Java SE, you don't have much choice: you'll need some web application framework. It can ba a Java EE web container, or another implementation like Play, for example. But Java SE won't be sufficient.
You may use webservices for instance axis2
I am having a Java application and a .NET application both residing in two different machines and need to design a communication layer between these two applications. Any inputs or ideas would be really helpful. Below mentioned is the nature of interaction between these two applications.
Java applications sends large amounts of data to the .NET application
Data latency should be kept to a minimum
.NET application should also be able to request for some data (synchronously/asynchronously)
The easyest way .Net and Java can talk is using Web-Services - we have done in my company with much success (using apache's cxf and standard code on the .Net side).
But if latency and size are the main requirements, you should use Sockets - both platforms offer a pretty extensive socketing frameworks and it would give you the best performance possible.
I think this can be done by setting up an xml webservices layer on the java side. You can use RestEasy for restful web services. Just my .2 cents.
Another alternative is some form of MOM (Message Oriented Middleware). There are a lot of implementations, but one to look at first might be ActiveMQ as it has both Java and C# bindings (among others).
I'm not saying this is better than using a web-service, it entirely depends on what your requirements are.
We have had good experiences with providing web services with JAX-WS (part of standard runtime in Java 6). They explicitly list .NET compatibility as a goal and is well supported in IDE's.
The Endpoint.publish() mechanism allow for small, simple deployments.
You can use Web Services. Jax-WS is the API in java that allow you to use it. As the implementation of this API I recommend metro (http://metro.java.net/), this already came with the SDK, and has a great integration with netbeans.
As already someone referred yet, you can use a socket, and create a communication channel on that, but this have some problems, starting with security. Don´t use this in real life applications.
If you need help with this subject you can start reading this:
Getting started with JAX-WS
It really depends on your requirements. The simple way is generally Web services. However, if you want higher performance, or more fine-grained access to the API on the other platform, you might want to consider JNBridgePro (www.jnbridge.com).
Disclosure: I work for JNBridge.
Our application often connects to a different kind of back-ends over web services, MQ, JDBC, proprietary (direct over socket) and other kinds of transport. We already have a number of implementations that let us connect from our application to these back-ends and while all of these implementations implement the common java interface, they do not share anything else.
We have realized that there are signification portions of code that are common for all of these particular connector implementations and we have decided to streamline the development of future connectors through one universal connector. This connector will be capable of formatting messages to a format expected by back-end and sending them using the available transport mechanism. For example, fixed-length message format over MQ or over a socket.
One of the dilemmas we are facing is the most appropriate technology for this kind of connector. So far, our connectors were basic java classes that implement the common java interface. Since we generally host our applications in some Java EE application server, it seems that Java Connector Architecture would be the most appropriate technology for this piece of software. However, implementing JCA compliant connector seems to be relatively complex. What are the palpable benefits of going with the standard – JCA and do benefits justify the additional effort?
Indeed JCA seems the most appropriate technology for you. Already excellent arguments have been made, namely the portability, standardised interface, the connection pooling and transaction support. And don't forget security.
With WebSphere Process server the adapters could be exposed as a SCA service which can have a lot of benefits if that's important for you.
Also some development tools have extensive support for developing and testing JCA connectors.
Another benefit is (experienced) Java EE Administrators and Java EE developers (should) know the standard so administration and development should be easy to streamline.
But in the end you should have to find reasons to implement JCA based on the scope of your project, the future plans you have for your project or maybe within the policy of your company.
Short answer: I see no benefit on selecting JCA over other technologies, I see it as a drawback since you need Java EE container.
Long answer:
I've been skeptic about these Java EE standards for some time now. I don't see a compelling technical reason to use a full featured Java EE server anymore, since there are better open source implementations for every feature offered. I've been bitten several times by implementation incompatibilities when moving to/from "enterprisey solutions".
The idea for JCA is surfacing here right now and I am pushing to try apache camel or spring integration instead. I am all for open source implementations that you can use everywhere. And there is a lot going on. Check this list of components. Granted, maybe is smaller than whats already developed with JCA, but every bit is open sourced and it's all on one location. Also, I believe the documentation is simpler and more complete. The urge for integration calls for a powerful SPI with plenty of open source, real live examples, developed in the same fashion, and that can be found on the same place.
I am hating the negativity, but I don't like full featured application servers. For instance, I would go for tomcat and terracota any day over other "enterprisey" products, just as I would go with camel before JCA, until the need for JCA gets proven. I don't like the idea of the Java Committee to tell how I should develop my own applications because I don't trust them. I believe it is in my best interest when the piece of software can work just as easily on Java SE/RCP as in a Java EE environments or in a pure Servlet container.
I've just developed an inbound resource adapter for a gps device communicating over an proprietary protocol. It wasn't that much hassle, though I've got the impression that developing an outbound one might require more work. The worst thing with the JCA is the lack of documentation. All books and articles seems to have the same dumb example.
The thing I'm most pleased with is the portability. Once you've written the adapter you can plug the rar (resource adapter archive) into any application server to provide deployed applications the ability to communicate with eis supported by your ra. Or you can bundle the rar into the war/ear.
The benefits are primarily for vendors who wish to sell connectors to proprietary back end systems for use with any app server, for customers who want to be able to drop in a connector without worrying about whether it only works on WebLogic not Websphere, etc. Indeed this is the goal of Java EE in general.
Note that JBoss has decided to put several things into JCA, for example JDBC connections go via JCA.
Your future client code will have a standardised interface, some pooling and transaction support etc. but it's important to keep sight of the bigger picture; namely that the benefits are not targeted at you and your one project specifically, but at a software eco-system consisting of many app servers, many back end systems, many connectors and so on.
Sounds like a good use for a JBI container with binding components. Discussion of JCA vs JBI.
I have an application written in java, and I want to add a flash front end to it. The flash front end will run on the same computer as the java app in the stand alone flash player. I need two way communication between the two parts, and have no idea how to even start going about this. I suppose I could open a socket between the two programs, but I feel that there must be an easier way. Is there a nice part of the api in actionscript 3.0 that will allow me to access java methods directly, or will I have to resort to sockets? I am relatively new to flash, by the way, so any good guides would be much appreciated!
Thanks
AMF is a messaging protocol commonly used to talk between flash and a backend system. There're several Java implementations, but I haven't used any of them so can't tell you which is best.
Blaze DS
Red5
Granite DS
Flash can also talk plain old XML, SOAP or REST to the backend, so depending on your codebase that might be easier.
There is also OpenAMF. It is very mature, stable, simple and lightweight relative to Blaze, Red5 and Granite.
BUT, it is also dated (AMF0 protocol only) and the project is no longer active. Lots of people are still using it out in the wild. And the documentation is borderline non-existent.
Granite DS is a good solution, it will allow you to set up services to communicate not only to POJO's but to EJB3 session beans also. It comes with a GAS code generator for converting your java beans into as3 equivalents and also data push to the client using the gravity side project.
MERAPI is a bridge framework for communication between Java and Flash.
I agree on Granite DS. It was easy to setup and get going.
I have used it to talk directly with a EJB3 bean communicating with thrift generated objects.