Alright, the question might be broad. We've been looking at Jboss and a few other similar app. servers.
From the feature list it would be perfect for replacing our soon to be outdated homegrown reporting application on the server side. But at this point, for 2 developers, just grasping all the setup, configuration, administration, tuning,testing not to mention the APIs and programming itself just seems way too much, too big, too complex.
What path does people take to become familiar and productive with such application servers ?
Start with a simple one, and only use a more complex one if you really need the features.
For example, Do you really need the full JBoss stack? Would Tomcat not be sufficient? It's much less of a handful.
I would approach this the same way I approach anything new.
Start with the documentation - read the introduction and basic setup/configuration documents. Then move on to tutorials and maybe some simple apps that I find interesting. In your case, maybe port a few features over to the new system. As time goes on, you should get better with the tools at hand.
From my experience using one is the best way to learn what you like/dislike about it. Once you have a project set up for one application server it should not be too much work to migrate it to another. I am currently working on an application that we develop & test daily using a simple Tomcat v6 server, but which runs in production on both Websphere Application Server and JBoss.
As a side note for your development, I strongly recommend looking into integrating your Eclipse development environment with your chosen application server through server adapters - it will greatly speed up development tasks and simplify the debugging process.
I'd say that the minimum features for using Java EE are:
Servlets and JSPs, written using JSTL (no scriptlets)
JDBC
JNDI for pooling database connections (optional but recommended)
Basic authentication for security
You can accomplish a great deal knowing just those. If you want to minimize the learning curve, I'd recommend starting with those and staying away from EJBs, JMS, Struts, JSF, etc.
Another benefit is that this subset of features is common to both servlet/JSP engines, like Tomcat, Jetty, Resin, etc. and full-blown Java EE app servers like WebLogic, JBOSS, WebSphere, etc. An app that runs on one should be portable to any of the others, as long as you stay away from app engine-specific extensions.
You should realize that there's a trade-off here. You'll have to develop pieces that might be easier if you leverage the app server more. But hopefully you'll start with some simpler problems and work your way up once you're comfortable with the basics.
There's another approach: Hire an experienced guide to help you with training and mentoring for the first project. A six-month gig with a reputable consulting firm might get you started.
Last of all, I'd recommend Spring. It would also have a learning curve, but it's a good alternative to Java EE EJB development.
Related
I want to develop an server/client software of which the clients will be in different Os's.
(Think Mobile phones, tablets, desktop pc's, I even consider this service to connect with asterisk and work with a phone call center).
I'm really searching amongst all the available server frameworks and cannot decide what is the best for my case or whether I even NEED for my specific problem.
Things to consider:
I need it to be scalable: Initially that server will be accessed through a website but later it will expand and allow people to access it through mobile apps, desktop applications, phone call/sms service, etc..
Low cost hosting and open source
Thousands of users to be using that service in the future. (So it must be able to handle this)
Small dev team (1-3 ppl)
I've done past projects in C/C++, actionscript, a bit java and a bit php.
I don't know much about server programming yet (but I'm ok with learning).
So:
it must have an active community and not have died yet.
Be as easy as possible to learn.
it must already solve the problems of security, packet asynchronism, concatenation
for me etc.
Is there such a thing, should I even bother to mess with a framework? What options do I have considering the tools available? What does the industry use? A list of possible options would be greatly appreciated!
A common technology stack which is open source, scales well and has a very active community is:
Java
Tomcat Servlet Container
Spring Framework (with Spring Security)
Either Spring Web-services or Apache CXF for web service (mobile connections for example)
JPA (Hibernate) ORM on top of MySQL
There are numerous other projects that sit around these technologies that fulfill various requirements. I would certainly recommend this as a starting point to your investigation.
I'm carrying out a feasibility study on writing, let's say it's a lightweight run-in-browser MMORPG. (It's not exactly an MMORPG, but would take longer to explain, and the requirements are similar.) I'm trying to figure out the required technology stack.
Client side, it runs in the browser, so the client is Javascript. That was nice and easy :-)
Server side, I'm looking at Java. The common Lamp stack was designed for RESTful applications, as I gather were typical Java web frameworks, and this application is different - it needs a continual stream of data going back and forth between the server and all the clients. I think what I need in this case is Java of the non-framework, full no-holds-barred Java EE variety, someone please correct me if my understanding is incorrect or incomplete? I would need something that is commonly available on reasonably cheap hosting, Java EE fits this description, right?
(Figuring on using MySQL for the database, as this is what's most commonly available. Also I might actually write the code in Scala, being a Java-compatible but supposedly slightly nicer language. I assume neither of these makes any difference?)
Supposing I were writing a website in Lamp, doing at least the initial development on Windows, then I'd install Xamp, which gives you a running copy of the entire server stack right there on your desktop, so you can just alt-tab back and forth between your editor/IDE and browser for testing.
Now my question is: What's the best equivalent setup for Java, for developing something like this on Windows?
Right, in a sense it is. What I think I'm really saying is that almost all discussion of server-side Java seems to talk about JSP, EJB, Glassfish, Google app server etc which are frameworks in the sense that they put restrictions on what your code can do, whereas Java EE puts no such restrictions, you can use as much or as little of the standard library as you want, but it doesn't stop you running arbitrary persistent Java code. Is that correct?
You've thrown out a bunch of terms there:
Glassfish is an application server that implements (all of) Java EE.
JSP is a specification that is part of Java EE, and implemented by application servers such as Glassfish as well as web servers such as Tomcat and (I think) Jetty.
EJB is another specifications that are part of Java EE. It is typically implemented by application servers.
"Google app server" is really "Google Application Engine" (GAE), and is really a platform for implementing web servers in a cloud computing environment. If that's not what you want / need to do, GAE is probably a blind alley for you.
Glassfish, JBoss, Tomcat, Jetty and so on are all platforms that implement some or all of Java EE. None of them stop you implementing arbitrary persistent Java code.
GAE on the other hand does restrict what you can run, because the platform only allows you to run standard Java classes in a whitelist. If your "arbitrary" code depends on other standard Java classes, you are out of luck. (And hence my warning about blind alleys.)
And of course, there are various other Java-based frameworks that are targeted at web development in one form or another. Some are compatible with Java EE servlets and other EE technology, and some have gone off in a different direction.
My recommendation would be to start with something straight forward using plain servlets on a stock platform. Only look at the high performance stuff if and when performance looks like it will be a real concern (not just a "nice to have"). It is better to have a simple and non-scalable prototype, than a high performance solution that you don't have the time and skills to get working. And you can treat the prototype as a learning exercise.
A little hard to tell from the requirements given, but I would look at the following based on your description:
http://www.playframework.org/
http://www.zkoss.org/
http://code.google.com/webtoolkit/
Play Framework is a nice web-centric framework that provides a complete stack (you can code in Java or Scala). ZKoss (ZK) and GWT both provide user interface frameworks. ZK, GWT, and Play all run nicely in Tomcat/MySQL and should work just fine in typical Java/MySQL hosting environment.
... not sure what your definition of 'cheap' is but, that and 'no holds barred Java EE' don't exactly go together. Also, 'frameworks' by themselves don't put restrictions on running any arbitrary java on the server side. When I say 'frameworks' I mean Spring, Struts, etc. Servers will be a little different story. If you need EJBs you'll need Glasfish or JBoss or another EJB compliant container. Hosting with these will be more expensive compared to getting by with Tomcat. IMHO easiest and quickest way to get started is with NetBeans. Comes with Tomcat and / or Glassfish out of the box, all you need is a db.
I have a few questions to understand better Java's usage in context of web applications:-
Is Java EE web development suitable for small start-up (with less human resource) looking to develop an web application ?
What kind of difficulties may arise in Java EE web development, deployment & maintenance ?
What kind of things should be kept in mind/ considerations to be made when moving from PHP background to Java ?
Why Java web applications are not so popular today? ( or in case I perceived it wrongly, please list any major deployments beside linkedIn and ebay)
and Finally, What are some of the most important things to learn before starting web development in Java EE ?
Thank you
Generally the answer to the question of "what technology to use" is "the one which you have most experience with". However, Java EE is huge and clunky, and definitely not good for rapid prototyping, which you will be doing if you're doing a startup.
Personally I would recommend a more modern and dynamic environment. If you're coming from PHP, you should be able to pick up Ruby on Rails or Django (Python) easily. These two choices are in my opinion orders of magnitude better than Java EE. If you want to stick with Java, at least go with the Play framework then.
Is Java EE web development suitable for small start-up (with less human resource) looking to develop an web application ?
Yes, I worked in a startup where I was the only full time programmer.
What kind of difficulties may arise in Java EE web development, deployment & maintenance ?
The same as in any other web development shop. Of course, the problems have their Java flavor. For instance, one bug we discovered was caused by different minor version of JDK used on the live system than on our test system.
What kind of things should be kept in mind/ considerations to be made when moving from PHP background to Java ? Do not code the PHP way. Java's strength is OOP and its many libraries/ open source frameworks. Use that.
Why Java web applications are not so popular today? ( or in case I perceived it wrongly, please list any major deployments beside linkedIn and ebay)
I don't know why you think that, but Java is used everywhere. It is one of the few languages that Google officially uses. They use PHP as well, but it has a "lower" status.
and Finally, What are some of the most important things to learn before starting web development in Java EE ? Use Java's strong points which I mentioned above.
Updated after comment
I cannot make the choice for you. If you are in doubt and in a big hurry you should not go with Java. This is common sense. However, it is an opportunity for your team to learn and grow. Maybe there is a PHP/other client for Cassandra. I knew a former PHP programmer in a startup, who switched to Java. Not saying anything bad about PHP programmers in general, but he did all kinds of strange things, such as not leveraging the power of Java web frameworks and writing lots of procedural code mixed with HTML and SQL. Obviously there are lots of Java programmers who would do the same thing. The point is that your team will probably learn new ways to do things and benefit from it in the future.
Allow me to answer these from the perspectives of a developer/architect in a small start-up, experiencing a bunch of these issues.
What kind of difficulties may arise in Java EE web development, deployment & maintenance ?
How do you decide on which toolset/framework to use? Do you need an IDE? Which version control system and why? Do you want to develop at some place and deploy somewhere else, or develop directly on the server? Do you buy a linux box for this, or rent some cloud? How much do they cost, in terms of licenses and training?
What kind of things should be kept in mind/ considerations to be made when moving from PHP background to Java ?
How would your servlet send out an e-mail? It's much simpler in PHP. Need secure transfer of encrypted objects? Java is your friend. What about session tracking? Use cookies, or have a dedicated class do it? How do you access the database? Want to use hibernate? What other tools is hibernate dependent on? What are their costs (license+learning)? Can you use JDBC directly? What are the pros and cons? Which db to use to why.
Why Java web applications are not so popular today? ( or in case I perceived it wrongly, please list any major deployments beside linkedIn and ebay)
I am not sure if this is the case, but possible reasons could be the availability of .net and integration with C# based systems and Apple ditching Java from its SDK. But that is my speculation, don't quote me on it. I am developing a large scale system myself with Java 6.
and Finally, What are some of the most important things to learn before starting web development in Java EE ?
(This is my opinion) have a test or trial set up of the entire architecture. Is the GUI web-brower based? Is it an applet? Standalone application talking to a server? JNLP system downloading archives and JRE off the net? You will find some stuff do not work on Windows 7, some do not on Vista, W3C have deprecated the applet tag from HTML but Sun/Oracle asks you to use it, different browsers do not support contents of your style sheet, etc.
Firewall set up is another major challenge - you start using thread pooling using Spring libraries and your capabilities to use DBvisualizer to check on DB tables are gone! Now you need a DBA and a sys-admin to fix these who you do not have!
Personally I found the LAMP architecture (Linux-Apache-MySQL-PHP) the fastest way to go for smaller applications, but if you need heavier guns for your app (security, GUI with swing, multithreading, etc), replace the P in LAMP with a tomcat container. The hardest thing I find is to judge the value of a tool in the context of my application - I do not need a tool that generates Java files with getter/setter methods given a list of variables - to me that is yet another level of indirection, but then JUnit in eclipse is helpful for debugging.
Just shared some of my thoughts - hope this helps, - M.S.
For a startup an interesting choice could be the Lift web framework, which is used for developing "Java Web Applications" (although in Scala).
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.
OK, this is a little unusual, because ANY Java EE container can do the simple things I want to do (XML processing, JPA, Hibernate, SOAP/REST web services, etc). This is for personal use, more to gain skills than to accomplish essential functionality. I have my own Linux server (Ubuntu Jaunty x86_64) with business class internet, so I can install pretty much anything.
I use Tomcat a lot now, however, I ran into a few situations lately job hunting where they were looking for experience in a specific Java EE container (which defeats the whole purpose of having a standard), and of course not the same one each time.
So what I'm looking for is a Java EE server that:
Is in demand in the marketplace right now
Is free (or
Is not too horrendous (disk space, time) to install and to deploy applications on
Runs on Ubuntu x86_64
I've been able to glean some information via Indeed's keyword search, and that tells me to stay away from Jetty/Glassfish, even though they fit "lightweight" and "free". I also see from this SO post that WebSphere is a steaming pantload of bloatware that's hard to deploy/configure, but I don't know if that's accurate or current. I like Tomcat (completely FOSS, smallish, easy to deploy, plenty of docs/users), but it's less in demand than some of the bigger boys.
So what would you recommend I install? Thanks in advance.
My personal recommendation is JBoss. Not only is this a solid server, but there are other JBoss Platforms and Frameworks that easily integrate into JBoss. One example is JBoss ESB.
Far too often, I've seen servers like JBoss and WebSphere (I've worked with them for the last 5 years now) rush to market with broken implementations. Unfortunantely, the part that is broken might be very small, but it will be just what you will be breaking your head on.
Oracle Weblogic just kicked the hell out of me with a broken implementation of MDBs (annotations).
If you want a server that is the most Java EE 5 compliant, will give you the least heartache and pretty much production-worthy, go for Glassfish and yes... use Netbeans as your dev IDE.
+1 on JBoss, that is mainly what I use for personal use and work. I have also used OC4J, and find that it is harder to use, and more finicky with it's class loading mechanism, maybe I'm just used to JBoss. But there is definitely more and easier to find community support for JBoss. So that is reason enough if you are doing this for personal use and are not going to get a support license, there will be many more users willing to help out if/when you encounter issues.
I've only used Tomcat myself, professionally. I've been using it for the better part of my (so far) three year career and I havn't experienced many problems with configuring or deploying applications to it. I use Eclipse WTP for Java EE developers 3.4 (Europa) at work, and mostly develop JSF applications utilizing ICEFaces. We deploy using the Tomcat web manager for most of our smaller projects, and through Hudson for some of our broader applications.
Please bear in mind some caveats, however:
We host about 20 seperate web applications, mostly JSF with a few older JSP apps.
The web applications served by my office have a very, very narrow scale. Our department currently supports about 20 unique users, so most of our applications do not receive a lot of heavy traffic.
Most of our web applications are very processor intensive (i.e. here's a 2GB CSV file...write a program to calculate the total number of people that reside within homes that have 3 or more children...) that only usually perform one-off runs either weekly or daily (or even yearly...). In other words, "Give me all your resources for 2 hours...then I'm going to lunch".
Our primary web server is a Solaris 10 box with a Dual core sparc processor (I believe clocked at 1.8 GHz if memory serves correctly), with 2GB of RAM (don't recall if it is DDR or DDR2).
That being said, I've definitely noticed performance problems over time with regards to our application environment that probably have more to do with our application code as opposed to Tomcat itself. I'm willing to bet that the problems have to do with poor memory management within our processing logic and data allocation than anything. The reason I believe this is because on a fresh restart of Tomcat our applications usually execute in an incredibly responsive fashion, yet over the course of even just one or two days the user experience is degraded.
Take it for what you will. We've probably got some problems to deal with on our end, but Tomcat itself seems to be pretty performant in a localized environment.
I ran into a few situations lately job
hunting where they were looking for
experience in a specific J2EE
container (which defeats the whole
purpose of having a standard), and of
course not the same one each time.
Well, I think you have (half) answered the question yourself! If your primary aim is to help you find a job, you need to look at what Java EE container the recruiters in your geographical area are asking for. Go to your favourite recruiting websites, pull up the Java / Java EE jobs for your area for the last couple of months, and count for each kind of web container. (And also count the jobs that don't specify a particular web container.)
If the results of your research say that you need to learn WebSphere, you have my sympathy :-)
Don't forget that a "mandatory" requirement may not actually be mandatory if you are you are good enough in other areas. It all depends on what other candidates the recruiter can find. Don't be afraid to say "you asked for X, but I have Y and Z which demonstrates that I have broader experience with this technology".
Oracle officially ceased to support Glassfish. All bugs found there (and there are quite a lot of them) will never be fixed.
Payara is now the best option, as this is a clone of Glassfish, but is continued to be developed by the Java community.