I'm interested in creating a client/server app in java, but not certain which framework to use. Here are simple scenarios to check disk space:
Scenario 1
1. A user would click on a button on a web page console "Get current disk space usage".
2. The servlet would get all machines from a db and ask each one to return their used disk space.
3. Each machine would reply with the used disk space.
Scenario 2
4. Each machine would update a service every 24 hours with its used disk space.
From what I can tell, I need to have a tomcat instance to host a servlet as the console.
From here is where it gets murky for me - and hence this question.
Would I also need
a) a SOAP service for #4?
b) a SOAP "client" running on each machine for #2?
I'm just not sure when to use SOAP services vs. RESTful services, etc.
Any opinions would be appreciated.
Fairly new to java, so apologies for any mis-spoken jargon.
You don't need a SOAP service nor a client. It would be nice, of course, but (if in a hurry) you can use your own format. CSV's, pipes, whatever fits you.
I've found SOAP services are easier to read but they are not the best choice when you expect a lot of data, mostly 'cos of the tags that you have to open and close. JSON is my choice in these situations.
Now, what you're talking about are not frameworks. They are protocols or convention. A framework is more language-dependent, like Struts, Spring, Tapestry, iBatis, etc.
Hope this helps.
SOAP is only relevant in context of an open ended system where service discovery, etc. would be useful. Otherwise, it is a PITA and entirely overkill.
RESTful services -- recommendation: use json -- would more than suffice for your purpose.
Tomcat is not your only option. Jetty is quite excellent as well.
I would suggest lightweight approach, as your use case is fairly limited, I would suggest going with embedded Jetty, Spring MVC and possibly JSON or XML response.
This will simplify deployment as you can wrap Jetty in wrapper application and make it runnable as process or service in either Windows or Linux, plus the footprint on the whole system will be fairly small.
This could change if you plan to extend this application with more feature and more integration point with other services/applications/protocols.
Related
This is a very beginner question. I have tried to search for advice but am overwhelmed by the amount of information and would like some help with ideas on approaches to server design or what to search for!
What I would like to set up is a backend server that provides search capabilities and business logic and validation across some fairly basic data. It wont get too large.
I would then like to be able to plug in a website as a front end or a mobile app or a facebook app or even a desktop app..
My question is what is the best way for front ends to hook into the backend? I would like to have various user accounts with permission levels so authorisation would be important.
I generally only code as a hobby so whilst technically I have built a spring based website before the exact semantics of the client server relationship weren't clear to me. Now I want to separate the backend so that is is agnostic of how the data is displayed or entered completely and can run on a separate machine.
Thanks,
Rob
There is a ton on options. I had good expirience with apache CXF rest services (logic encapsulated in java beans, spring configuration) and pico web remoting ( more exotic,
but also rest service and plain java objects providing business logic)
if you ar already using spring, I would recommend to stick with CXF - it integtrates seamlesly ( and is spring configured itself )
I'm a long-time client-side (Swing) developer and I operated pretty much by myself in the same job for a long time. Working from home in a vacuum, I was pretty much completely isolated from the community. I recently took a position as a server-side Java guy for a startup, and I'm learning a ton of stuff but I'm the only Java person and am pretty much on my own again. Having never done server-side Java before, so much of this stuff is completely new and I feel like I have no idea what the normal best-practices are, or I don't have an intuitive feel for what tools to use for what jobs. I keep reading and reading various Internet sources (SO is awesome!) trying to bulk up my knowledge, but some things seem hard to search for because they don't have any obvious keywords. Hopefully some of you gurus here can point me in the right direction.
I'm in charge of implementing our backend REST service, which for now supports our website and an iPhone app. We're doing a social media site, eventually with many different clients. Currently the only clients of the service are our own website and our own iPhone app. I'm using Jersey, Spring, Tomcat, and RDS (Amazon's MySQL) on Amazon's EC2 platform. Our media storage is via S3. I've picked up all of these things pretty quickly and so far so good -- things are working fine with the website and the iPhone app. Cool.
Our next step is adding some long-running server-side processing. This processing is basically CPU-intensive stuff that doesn't involve any communication until it's done. I'm trying to figure out what the best way to handle this is. I'm thinking of using Amazon's SQS to queue up jobs in response to the REST events that should trigger them, but I can't figure out how I should handle the dequeuing and processing. I know I need some threads somewhere that take jobs off the SQS queue and process them, and then tell the REST service that the job is done. But where do these threads live?
In a plain "java -jar jobconsumer.jar" process on another EC2 instance that starts a small thread pool. Maybe use Spring to wire up this piece and start it running?
In a webapp deployed in a container like Tomcat on another EC2 instance? I don't really know what benefits I would get from this, but somehow running in a container like this seems more stable? Does this sort of container even really support long-running processing loops, or is it just good at responding to HTTP events?
Now that I write it out like that, I don't really see why I would want to use a container. It just seems like an over-complication. However, the Java community seems so centered on these types of containerized, "managed" environments that to not use a container seems somehow wrong. I feel like maybe I'm not understanding what some of the major benefits of these containers are? I mean, beyond the obvious benefits of the web-facing Servlet and JSP specs. Would any of the functionality of those specs help me out with something like this?
For a regular Java web app, you almost certainly want to be using one of the Servlet containers such as Tomcat - it takes care of accepting connections, parsing and serialising HTTP messages, JSPs, SSL, authentication, etc for you.
For a non-web app, the argument for using Tomcat (or similar) is weaker, but there are a few reasons to still consider it:
straightforward to add JSPs for querying and managing the app or add a web API in future
easy distribution of releases (one .war vs. an unholy mess of jars and config files)
hot deployment (although I've yet to see anyone using this for anything serious)
In terms of long-running processing loops, Servlet containers don't help you out beyond notifying your ServletContextListener when the app starts, so you can kick off any long-running tasks.
It's worth noting that if you're already using Spring, it's relatively easy to switch from a stand-alone app to a container using ContextLoaderListener, so it shouldn't be a problem if you decide later that you need the web stuff.
We recently faced a similar question, as we are hosting a large distributed service on EC2.
In short, we are very happy with Jetty 7 as a container. We use it for our user-facing-www, public-api, and internal-backend-api services. In some cases we use it for non-api services such as a workqueue, simply to expose a bit of status & health info for our monitoring.
The great thing about Jetty (any version) is that it can be configured in ~5 lines of code, with zero external config files etc. It's not a container specifically, but an http server that you can embed.
We use Guice for dependency injection, which also favors config-file-less implementations.
Long lived Java processes are nothing to worry about - you basically bring up your servers / threads / threadpools in your main method and don't call System.exit until you want to shutdown explicitly.
We currently have a 2-tier Java Swing application sitting on top of MS SQL Server 2005. All the business logic is in the database. The client is quite old (and not very friendly), and for reasons of performance and scalability, we've already started porting some services to a middle tier in Java.
However, we still have a number of short and long term goals:
Pick a technology stack for a new front-end
This isn't easy - I can see everything from a web app at one end of the continuum to a traditional desktop app at the other being viable choices. The current front-end isn't really complex (mostly form-based), so I can see web/AJAX fitting, but it's an area where we don't know what we don't know.
Stacks on my list are:
Eclipse RCP, Netbeans RCP
Flex/Flash, Silverlight, JavaFX
Pure Javascript frontends (Sprout Core, Javascript MVC, ...)
Java-based Web frameworks (Wicket, JSF, ...)
Find a way of making the current application perform acceptably in a remote situation
We have some clients who resale our app to smaller clients and need to be able to remotely deploy it. Due to the 2-tier nature of the current architecture this leads to terrible performance (for example, calling a stored procedure that returns 18 result sets). We've used a Citrix solution in the past, but no-one likes that approach. Tunneling JDBC through port 80 also sounds like a bad idea. I was starting to wonder if there's anything that could use a X-Windows like approach to remote just the GUI part.
To simplify development and leverage your experience in Swing consider using Vaadin for your frontend. It is a Java framework for building modern web applications that look great, and perform well. All the code is written in Java and looks very similar to Swing.
As far as overall application architecture I would advise multi-tier, service oriented architecture. The best way to do it is by using Spring framework with Hibernate for database access.
If you want to easily redeploy your application, for an update, security reasons, etc. and if you want your application to be it to be accessed remotely, you should really consider a web based front end.
Plus, this way, only one app, your web app, will handle connection to the database, so no JDBC tunneling or whatever.
Concerning the best framework, it depends on your team knowledge, the way your application will be used (more or less javascript), etc.
We've just gone through a very similar evaluation process as we're migrating a legacy application.
For us the biggest deciding factor in what front-end framework to use was the prior knowledge of the development team. We wanted something that everybody would be comfortable with immediately. We had a couple of the senior developers that have worked with X or Y, but the framework that everybody knew was Swing.
In the end we decided on the NetBeans platform using RESTful webservice to communicate with an EE server.
As a bonus you can get your NetBeans platform application to deploy as a Java WebStart application, which means you get the benefit of not having to worry about individual installations.
If the frontend is mostly form-based, I would stay away from Flex. Flex is great for some applications (I'm using it for a canvas based application), but the form components of Flex has some usability issues. They just don't work like you expect from todays web. (like missing support for mousewheel, typing in dropdownlist only take first character into account etc.)
Assuming that you are going to force all your clients to install a new middle tier, I can't think of an argument against making it a Java web app. As already mentioned you have the benefit of controlling all access into your platform over HTTP, which allows easy resale, just with firewall configuration. There's no reason you can't make use of Javascript within a web front end, you may be interested in DWR, which allows you to interact directly with Java objects via Javascript. I've used this before to add some simple Ajax interaction to a Spring MVC webapp.
The reasons I like this approach, you're already migrating code into Java middle tier, so
Already imposing Java server hardware cost on clients, hosting app server / web server is comparable
Already have Java expertise, can be leveraged with DWR
Can use as much/little Javascript as appropriate (I've used DWR with IE6, Firefox 3, Chrome)
I think you're right to be wary of pushing too much functionality to the client, I'd go for as thin a client as possible. The only reason I'd look at the first two stack choices would be if you have some developer expertise in a particular area, and not Java webapp/Javascript.
I'd suggest to create a short list of candidate frameworks and create a small test application with all of them. This way you will get a sense of good and bad aspects from all of them and also get a picture what the community activity and documentation is like for each project (there is a lot of variance on those).If you end up doing this I hope you'll include Vaadin in your short list, I think it would fit you very well. If you have any questions just come over to our forums and we'll help you to get started.
I want to implement a Java HTTP server locally, I mean the server computer would be in my control. I'm expecting not more than 20 clients to send requests to it.
I was wondering how to go about it:
Should I use a J2EE servlet container, like Apache Tomcat?
Could I use J2SE classes and just build it using them?
Are there any existing alternatives?
What does your experience suggest?
There's a simple HTTP server embedded in the Sun 1.6 JRE. It's not JavaEE or servlet-compliant, it's very lightweight, but it might be good enough for your requirements. No need to download any 3rd party stuff if this is all you need.
The javadocs, rather bizarrely, are out on their own, here.
Embed Jetty in your application. Aside from performing quite well, it is delightfully easy to use and configure
You've got many options, not the least of which are Jetty, Grizzly, and TTiny.
I would strongly urge against writing your own web server, unless you've got time to kill and want to spend it writing things that are already available to you for free.
Seriously, reuse an existing solution. Why the hell are you even thinking rolling your own?
Now, 1. I don't understand your question as being about embedding a container. 2. You mentioned long polling several time. So I'd suggest to use GlassFish v3 / Grizzly (because there are many samples, e.g. have a look at the Dead Simple Comet Example on Glassfish v3 / Grizzly).
If you don't want to rely on the way a container implemented Comet support, use atmosphere and any of the container mentioned on the web site:
Atmosphere is a POJO based framework using Inversion of Control (IoC) to bring push/Comet to the masses! Finally a framework which can run on any Java based Web Server, including Google App Engine, Tomcat, Jetty, GlassFish, Weblogic, Grizzly, JBossWeb and JBoss, Resin, etc. without having to wait for Servlet 3.0 Async support or without the needs to learn how Comet support has been differently implemented by all those Containers.
If this is not a concern, just stick with the suggested option (GlassFish v3 / Grizzly).
For a concrete and recent comparison between Comet server implementation, checkout this awesome Comet Maturity comparison grid view (source: Comet Gazing: Maturity). It might help you to make your final choice... or not :)
I guess the biggest question is: why do you want to build this?
If it is for the purpose of personal development, I'd stick to whatever standard libraries come with your JDK and build it on top of that.
If on the other hand you have a particular application that needs a dedicated HTTP server I would try to take one of the open source servlet containers, like Jetty or Tomcat and build on those.
Perhaps look at the list of 26 open source web servers at http://java-source.net/open-source/web-servers.
http://java.sun.com/developer/technicalArticles/Networking/Webserver/WebServercode.html is actual code in a single file implementing a multi threaded webserver. For your requirements, such as they are, this should suffice.
http://java.sun.com/developer/technicalArticles/Networking/Webserver/ is an analysis of the code.
If you will write your own HttpServer you will have to implement all the methods of the HTTP protocol. Tomcat can be easily used locally.
Is it for practice, fun, to implement special requirements or why don't you just embed an existing solution?
Do you really want to build a HTTP server that deals with the protocol directly, or do you just want to write web apps? If all you care about is writing the web apps, then just use Tomcat, or Jetty, or Glassfish, or another server -- it will save you a ton of work.
If you really are interested in writing your own server from scratch, then the best way would be to just use Java SE, and not use any existing server technology.
Ad your 3) option: Try JBoss Netty.
http://fisheye.jboss.org/browse/Netty/trunk/src/main/java/org/jboss/netty/example/http/websocket
If you have a Java based web application (J2EE webapp - never mind which other underlying frameworks are being used), and you wanted to introduce a Flash based front-end, would you use Laszlo or would you rather expose a ReST-like XML interface and build and deploy a Flash application that uses that?
On one hand, Laszlo is quite amazing - doing for Flash what JSP does for HTML. It is easy to work with. It fits in very well with the rest of the web application (which is JSP based).
On the other hand it might be better to develop a complete Flash app decoupled from the server and use an XML-over-HTTP mechanism to bind the two. This would have the added advantage of being able to use the same XML interface for an AJAX front end if needed.
What would you do, and why?
I would create the contract-first services, deploy them separately, and then write the RIA client to access them.
Coming up with the schema first has the added benefit of completely decoupling the two during development. The RIA developer can create some synthetic XML streams to use for data while waiting for the services to come on-line.
I might have considered Laszlo in the past, but today, I'd stay within the Java stack and use JavaFX.
Laszlo is the product that never made it, there isn't a big enough ecosystem of developers around it.
I'd use Adobe Flex for the front end. The same benefits of using a markup language for doing flash, but it has a much larger developer base and open source projects to draw upon. For the data communication, use either REST or if you want to get clever, use BlazeDS.
OpenLaszlo is a complete RIA framework, so I'm pretty sure that you can 'compile' it to a completely standalone app that communicates with the server over HTTP. It's really very similar to Flex. The advantage Flex has is a much bigger community, a full-blown IDE, and more resources (Adobe), while OpenLaszlo is a little more innovative in that you can deploy to Flash or AJAX from one codebase.
I've actually spent some time working on a implementation similar to what you're suggesting. I had a complied Open Laszlo front end embedded in a web page with a Django (a python MVC library) REST interface on the backend and no Open Laszlo server. It works reasonably well, but there are a couple of things to watch out for. Open Laszlo only supports calls to GET and POST, so you won't be able to easily use the DELETE and PUT methods in your REST API. The other is the lack of community around Laszlo (as mentioned elsewhere). I can sometimes be frustratingly difficult to answer some basic questions when using Laszlo, particularly around the XML HTTP API and XML replication features in the framework. I personally never really looked at the Laszlo back end server seriously as I wanted an open API that could be consumed easily by other clients.
All this being said, the implementation does work and can be effective if you're willing to work around the limitations mentioned above. Plus Open Laszlo is free, which can be a really big plus if your working on a budget.