I am interested in learning how web application are evolving. The idea is that if new technologies or design methodologies should be introduced in java based web application, what would be the top 5-10 technologies worth exploring? Also it would be helpful if someone can point out good books or online resources to conduct this research.
One key aspect is developer productivity. There has been some excellent research and presentations done in this space by Matt Raible (generally, the non-EE space) and Adam Bien for the EE6 space.
The ability of your application to successfully evolve over time has more to do with your software architecture than it has to do with either your technology or methodology. However, your choice of technologies and methodologies will influence how you architect your software.
First off, know what you are up against. In that late 1960s, people started studying what happens to applications over time. Over the last 40 years, those observations have been turned into a set of laws (c.f. Meir Lehman). This stuff might seem obvious, but it is a good starting place:
As a system evolves, its complexity increases unless work is done to maintain or reduce it.
The functionality of a system must be continually increased to maintain user satisfaction over its lifetime. The quality of a system will appear to decline unless it is rigorously maintained and adapted to operational environment changes.
If your in this for the long haul, the biggest questions are probably organizational and not technical. For example, what technologies does the development staff already know and enjoy using? If the developers plan to stick with the company for 5-10 years, ask what it is about the future that excites them. The best places to collect ideas about "hot" Web app technologies is http://www.infoq.com/.
Consider what methodologies are a good fit to both the technical and business culture of your organization. Agile development is great, but it isn't the right fit for every organization or every environment.
Consider vendors. I worked at a site once that was a true-blue IBM shop because IBM made solid software and hardware. However, the client was really locked into the vendor. The client was still using token ring networks and OS/2 in 1997. Give yourself some room to switch tools and technologies when the need arises. A living, breathing application almost never survives a decade of use without switching technology stacks at least once.
To really create a software design that will hold up to changes in the business environment, follow the old adage "build one to throw away". We once built a new system using a new operating system, a new programming paradigm, a switch from green-screen terminal to fat-client GUIs... it was a complete reinvention of the company's information technology. We would have never succeeded if we had not build a prototype and throw it away. We didn't pick all the right technologies and methods the the first time around, when we build the prototype. But we got the chance to correct those mistakes when we built the production system. This only works if you can create a prototype and then throw it away before it is used for real business needs. Once the application goes into production, the window to "throw one away" is gone.
Best of luck!
-Aaron
For all my quick and working web solutions I use Grails. It gives productivity, reasonable performance. It is supported by VMWare, so long term support looks OK.
Related
In a big company I work for, a very (costfull) ESB has been bought, the purpose is to be able to align with business goal quickly by resusing legacy infrastructure wrapping them with webservices, that is to say no more coding needed. Are ESB/BPM now really mature enough for that because it's now more than 10 years old or is it just an other vendor promise ?
Almost certainly just a vendor promise. If this becomes a reality for your company, they'll be the first to be so lucky!
This is the same sales job being done again and again for over a dozen years now (remember 4GLs?).
Most companies find the reality is that 1) it takes far more effort to install, integrate the ESB/BPM tool than they were led to believe, 2) only the most trivial changes can be made with the tool - it still takes coders to perform any meaningful process change / addition, 3) whenever the ESB/BPM tool vendor upgrades their tool, it's a huge effort to upgrade and be eligible for support (look into the history of any of these tools and what pains shops go through to upgrade, particularly Webmethods and BEA/Oracle's products over the years), 4) support services are expensive and rarely provide help (I know of companies that have paid for premium support who have filed dozens of tickets only to have one or two of them resolved by the idiots on the phone before someone in-house finally found the solution / work-around themselves.
You certainly can use an ESB / BPM to wrap legacy infrastructure and facilitate a migration towards a more modern target architecture. In fact that's one of the best reasons to adopt an ESB/SOA strategy in a complex application environment.
However, it's a complete fallacy to say that this implies "no more coding needed". After all, you will need to orchestrate a potentially complex sequence of web services with detailed knowledge of the state and transactional semantics of the legacy systems. Another word for that is.... coding.
p.s. It may be too late for you now but, for the sake of others reading this, I feel obliged to point out that costly prorprietary ESBs are often a waste of money. What you need can be done perfectly well (and sometimes even better!) by the open source solutions. JBoss and Mule spring immediately to mind. Since you are going to need to do most of the hard work in-house anyway, you might as well spend the time learning a great open source toolkit rather than locking yourself in to a vendor's proprietary solution.
I need to choose a language/platform for the new development of a series of services in a SOA. I'm looking into Scala and Clojure but don't think the community and products are mature enough for a real-world enterprise product yet.
Update/Clarifications:
Of course we can use many languages/platforms for SOA but some language/platforms are easier and more suited for an SOA. IMO the best ones for SOA should allow interface programming (to ease definition of contracts), should have options for hosting the services (like Felix for Java or WCF in .NET) and scale well (see Twitter issues with RoR).
Java has always been the favourite in the enterprise market. However, many developers are looking into dynamic languages as well as talking about stagnation of Java after v6. As a result many new post Java languages have arrived: Scala, Clojure and Groovy to name a few that still run on JVM but are not Java.
I hope these clarify the question.
Depends what you mean by "mature enough for a real-world enterprise product", and your relative level of tolerance for living on the cutting edge.
For example, I'm currently building a "real-world enterprise product" in Clojure (I'd have been equally happy with Scala, it was only that Clojure fitted my needs slightly better from the concurrency and meta-programming perspective).
I'm very happy with my decision.
Some quick perspectives if you are considering this "post-Java" path:
The communities are great and supportive, but you'll still have to solve problems yourself, if only because nobody else has run into the same problem yet. None of these are likely to be insurmountable, but it does present a bit of extra risk to delivery schedules.
Both Scala and Clojure can be very productive (in terms of value delivered to customers per hour coding), but you can equally well write bad and unmaintainable code in any langauge. Java pretty much forces you to write things in a standardised, somewhat verbose but syntactically simple and understandable way. With Scala and Clojure you get a whole new arsenal of crazy ways to hit your target or shoot yourself in the foot. Is your team going to be able to make the best use of Scala/Clojure advantages?
It's harder (though by no means impossible) to bring skilled people on board with existing Clojure/Scala skills. On the flipside, the people who do have these skills (or are keen to acquire them) are likely to be among the more talented / motivated developers so the search may still be productive.
Be prepared to make tough decisions regarding whether to target language/library features that are "just round the corner". For example, do you wait for the enhanced primitive support coming in Clojure 1.3? Or make do with the perfectly adequate but slower boxed primitive functions in Clojure 1.2?
A great benefit of being on the JVM is that you can still take full advantage of the Java ecosystem without being tied to Java as a language. Don't underestimate how useful this is: for example, I use a number of extremely well tested, mature Java libraries (e.g. Netty) pretty much transparently in my Clojure application. This significantly reduces your risk and the amount of new development that you need to do.
At the moment (having just completed a services/integration project ) Jersey on top of Spring are right up there on my favourites list for web services.
I can't offer any suggestions for a SOA framework, last time I was involved in that type of thing we user Oracle BPEL Process Manager and I have mixed feelings about it. We weren't using REST then either and I'm not sure how well the Oracle software works with it.
For me python seems the easiest way to do some SOA and have interoperability with Windows computers. I don't have frameworks name but there is a lot of them in SOAP, REST, RPC...
I would like to start up a project from scratch. I am a java developer for years. I did even write my own mvc framework some time ago for fun. Now I am working in a company using in-house framework - which i think is a total loss of time and money. I respect the idea of teaming up with different skilled people for a large scale project. The separation of the project is very important; Graphics guys, front end developers, software architectures, software developers, database experts, etc. I cannot risk to use a scripting language like php.
Lately, I am researching java technologies for a large scale project in every aspects. What I mean by that, for the front layer I come across with very famous technologies.
Spring
MyFaces
Tapestry
Google Web Toolkit
Cocoon
Velocity
Every one of them states that it is the simplest, the fastest, the latest technology and whatsoever. Of course only one them can hold the truth. I need a front end technology for fast implementation for ajax, customer/administrator security, themes, templates, internationalization, caching static pages, clustering and a support of ejb. It should also have IDE support, community support, rich documentation and online tutorials. Still I have no experience of those frameworks which to choose from. Maybe there is even better one? And most importantly, I cannot risk to start up on a technology which has development limitations. Is there any suggestions for this layer?
For the business layer, I am sure of EJB and JPA. I do even considering a web service for facade of this layer for interoperability purposes for future extensions. However, I have no idea about securing that layer (it could be applied on its web service level) which is still a problem for me. For the application server I am considering GlassFish.
And for the last question is what IDE should be picked for development. Regarding all the technologies, which are going to be used, an IDE should help me in every step, either doing the configuration for me or helping me configuring with its ready wizards. I suppose the IDE will have proper plugins for to be used technologies.
I know that I want too much, however I have a hope for a combination of technologies which will help me saving time and money in my future plans.
I ll be really glad to hear your responses, experiences for a bigger picture.
edited: There is no ultimate answer, I know that. I am just taking advice. Any answer is appreciated.
Well, I'm going to go out on a limb and give concrete recommendations, since I think the question can be answered.
I'll simply recommend my stack.
My stack is Stripes for the front end, and Glassfish/Java EE 5 on the back end.
Stripes is a simple Action (or MVC, whatever floats your boat), that has a small, but robust and vocal community. It has tight integration with JPA (through a plug in), a very good, and current, printer book on the topic as well as excellent reference documentation. It's main rendering tech is JSP with JSP Tags and EL.
It is not a component framework like JSF/MyFaces, so it's implementation is simpler, and it's lifecycle is simpler. It works very well with Ajax.
The key factor around Stripes, since it's based on the HTTP request cycle is that it does most of the grunge work for you, yet is very lightweight. It's easy to pick up and understand. Creating a basic Stripes app is a couple lines in the web.xml and two jars (one of which is log4j). If you can think in HTTP, then Stripes is a good fit for you.
On the back end I would simply stick with EJB and GlassFish. Java EE 6 and GFv3 are out have been out for sometime. It offers a lot of new features over Java EE 5, and GlassFish offers most any web service tech you would like to use. Java EE 6 and Spring are pretty much equal on a bullet point by bullet point basis, and since you were looking at GF, you may as well use EJB since it's there and integrated in the box. If you were using Tomcat, then Spring might be a good choice.
And, that's it. That's all you need (I dunno what you wanted Velocity for, you can add that trivially if you like, but I wouldn't use it for pages, personally, modern JSP is much better IMHO).
Glassfish will secure your web services, you can use Java EE security with your web apps, you can share logic between the back end EJBs and your web app and web services. It all works out of the box with 15 minutes of configuration to get Stripes running.
I use NetBeans, but all of the other IDEs work as well. NetBeans is nice because it come integrated with Glassfish. One less thing to configure. Download it, fire it up, and it works.
There's a Stripes plugin for NetBeans, that I don't use. I don't see a need. Once you add your few lines to your web.xml that you cut and paste from the web site, you never see Stripes again. From there, it's all simple annotations.
Unless you have a crushing need for all of the complexity and learning curve of a component framework, it doesn't get any better than Stripes, and GF w/Java EE 6 has everything you need in the box.
So, in summary: Stripes distro from www.stripesframework.org, NetBeans download from netbeans.org, and stripersist from stripes-stuff.sourceforge.net. It's a rock solid foundation that will go wherever you want to take it.
Come on by to the Stripes IRC on freenode at #stripes, and we'll answer any question you have (or hit the mailing list).
Well, first of all, your question is not good. Every technology has it's bright sides and dark sides. To choose some specific technology - you need experience in all of them to estimate which problems can emerge with your project. Given your definition: fast implementation for ajax, customer/administrator security, themes, templates, internationalization, caching static pages, clustering and a support of ejb - 90% of frameworks support all of it either directly or using some plugins.
Moreover, various technologies are better optimized for various needs. You can't have a all-in-one-super-framework that is flawless and does everything the best way possible. Given that the framework is highly scalable and fast (example: Spring and/or Portlets) will make it hard to configure for some small tasks.
So the only thing I can recommend is to google "Java Web Framework Comparison" and hope for the best.
As about IDE, I can see only 2 choices: IntelliJ Idea and Eclipse. Again, there is no clear winner so yet again google is the only source of information you can get.
Added:
Talking about frameworks again, complex projects use several of them at once taking the best parts of each to aid with the specific project needs. But to do that effectively - you need to be a guru in all of the mixed technologies.
There is almost no way that someone can actually answer this question for you. In terms of frontend technology, one of the frameworks will work for you and others won't. It all depends on which one makes sense to you. My suggestion would be to try them all out and pick the ones that you feel the most comfortable with.
With that being said, I do have a few suggestions. First, don't limit yourself to using Java. If it were me, I would use Ruby on Rails running on jRuby as the frontend as it is the fastest framework for developing web applications that I have used. By running it on jRuby, it allows you to hook into Java and let java and its libraries do all the heavy lifting on the back end. I would stay away from web services and implement things using ReST.
In terms of an IDE, definitely go with IntelliJ IDEA. It may take a little bit to get used to, but it is definitely the fastest IDE on the market. However, both Eclipse and Netbeans are also very good for Java and a tad cheaper.
Once again, the answer is, "it depends".
All of the above projects started off with simple ideas. As they gained traction, they have all added neighboring features which are useful to some but not necessarily all. In other words, you will have to do deep analysis to pick the perfect framework.
You are not going to find a perfect match unless you just happen to be of like mind as the dozens of people working on the particular framework, assuming that all those minds were ever in perfect agreement. The only "perfect" fit is the one you write yourself, and even then you find it's not perfect as you are limited in time and effort on developing the framework; after all, you DO have a program to write, and the framework development time competes with the program development time.
As far as IDEs go, there's differences in taste and style. I tend to gravitate between the old standbys of Netbeans and Eclipse, and my next IDE to play with will be IntelliJ Idea. The thing to remember is that most people commit to one IDE and then defame the rest, so you really can't get a good comparison. IDEs take too much time to really learn for a person to give a honest unbiased opinion. A good candidate IDE "X" will be the worst in some eyes and be the best in others.
Given how the other answers look, I would say the biggest remaining factor is the learning curve for you and your team. Given your description of the separation of roles, your primary concern should be picking an overarching framework, such as Spring. From there, your database guys can pick whatever they want for data persistence (hibernate, jdbc, whatever) and your gui guys can pick whatever they want for their front-end (tapestry, jsf, etc.).
The primary concern I would have with such a distinct separation of roles would be the communication on the team. Make sure that their is a high degree of open communication, especially when discussing interface design, as those will be integral in the success or failure of your project (especially if you pick Spring).
As far as IDEs go, it's personal preference. The two mentioned in the other posts (Eclipse and IntelliJ) are the two I hear the most about, with Eclipse being my standard IDE for the last 4 or 5 years. I'm not familiar with IntelliJ, but I know that Eclipse has plug-ins to support Spring, Hibernate, and a host of other frameworks and ORM solutions. It also has plug-ins to support other languages as well, such as Ruby and PHP.
"I did even write my own mvc framework some time ago for fun" - at the end of the day it may happen that you will regret that you did not stay with it. In fact the technology that is better than currently "famous" most probably is the one that will be famous a little bit later, not now. Half of your list is already "famous" as obsolete.
I have to develop an ERP System for a 2,000+ end users organisation.
Could you please suggest me with comparable points that among (Java or .Net)
in which technology I should invest money and time? Although I have done
some average projects in both, but this project is going to be very big in near
future in terms of scalability.
I want to know your experiences and some tips from you people, so that I can develop
and deploy this project efficiently.
I rate .Net > Java for this project only due to less development time available.
We have to use some Rapid App Development technology.
I have to deploy this on Cloud (Azure or Google App engine).
It will be better if I got answers from those people who works in both (.Net and Java).
I will appreciate answers from your experiences.
I would suggest creating a very small proof-of-concept project in both technologies, which do something real - like allow people to log in, see messages, and allow them to type in new messages, and log out again.
Even if the project is laughably small, if you do it well, you will have a finished product on each platform which have shown you by experience how things works and if you like the way you had to do them. You will be able to see if you can debug in the cloud, if you can profile when load testing, if you can do fast work inhouse which then works well when deployed to the cloud.
And you will need to figure out things. Are the online resources good? How responsive is the StackOverflow community for each platform when you ask questions?
Personally, I consider the ".NET is Windows-only" to be important. Except for that I do not believe there is any technical showstopper for either platform.
I think both approaches can be used to deliver this successfully. I would expect you to have the same amount of success/pain with either choice. When it comes to making a decision you should base it on the amount of expertise that you have to hand. That is, your own and that of your existing colleagues and the resources that you can acquire (new recruits, contractors, consultants etc.).
That said a couple of technical notes:
The Java approach tends to have more freedom, i.e. more frameworks and choice of technologies for various solutions (although GAE will bring in some restrictions).
There is less choice in the .NET space, but that is not always a bad thing. E.g. you tend not end up in tireless debates about the logging frameworks.
Java is starting to age as a language and C# is a bit nicer, however there a number of newer languages that run on the Java VM (Scala, Groovy, Ruby, Clojure).
If gathering requirements for a medium-to-large web-based project, at what point should one consider using Java-based back-end, JSP, etc, over a scripting language like PHP, Python, or Ruby?
Hearing "use the right tool...", when is Java the right tool for web-based projects?
What is the "Best" language is often degrades to an emotional debate rather than practical. Champions of each language are extremely good at making arguments for why each language is the best. I ususally look ata couple of factors:
A) What languages are you and your team confortable with?
B) Is there an existing application/system to be extended or integrated? If so, what languages are most effective for such an integration
C) Are there built in or redily available libararies, components, etc that will allow you to more effectively produce results in one language over another
My decisions almost always boil down to what language/platform is my team going to be most effective on both developming and maintaining.
In my opinion, the language decision cannot be made independently of the larger development and runtime platform. This is implied by what James Conigliaro wrote, and also by what jonnii wrote, but neither called it out specifically.
Making such a decision, people often use unwarranted relative weightings for different evaluation criteria. For example, one of the criteria might be "runs on iPhone." But if you are not actually developing on an iPhone, you really don't care.
"Performance" is another criterion that can get an unwarranted weighting. Most Intel-based servers today, costing let's say $2000 without storage, are plenty fast to support a fairly high-volume web site regardless of your choice of language. If your load exceeds that which can be run on a single server (don't assume!), or if you need to share the server among different workloads, then perf may become more important. But generally your app load will fit in a 1-server box.
The development environment, including the IDE but also the source code control, the configuration management, and defect tracking - I guess what you might call application lifecycle stuff - is more important, in my opinion, than the language per se.
Another aspect you may wish to consider is, the "pull" the language itself will have on devs for your team. In the early days of Java, you could attract devs just by saying "we're doing it in Java." Now, that phenomenon has largely faded for Java, but in pockets it may still be true for other langs and platforms. This factor may or may not be important to you.
Pick the language/platform that your team is most comfortable using, the one which matches your deployment target and that you're mostly proficient in.
I have over 20 years of programming experience and I learned one important fact: it doesn't matter which tool you use, as long as you're comfortable using that tool. For larger teams, all team members must be comfortable with the choice you made.
I always tell people that it doesn't matter which tools you used to create an application. All that counts is if it will work as expected.
I'm planning to use Java for a project served using Google App Engine (Java support, of course). This is not The Answer [tm], but only my 2 cents :-)
Whoever has the libraries you need:
If you want to customize something pre-made, use PHP. This will usually be shopping carts, forums, and CMS
Java will have more libraries for random things (like fetching RSS feeds)
Don't know about Python/Ruby on Rails;
Rails is simple to learn, well organized and well documented. It's also agile and RAD (rapid application development). It's not perfect, but you could give it a try. It's another take on the web development. Java web framework are not so easy to understand and start is not so simple IMHO.
If you have to build a large web application, with rails you could separate the monolith app with different apps and then use ActiveResource restfully.
http://guides.rubyonrails.org
Almost always :-)
What I mean is that you can do any web project with Java/JSP adding more or less to the mix ( Spring, iBatis, etc )
But, as already pointed out, there are cases when you decide to use something else because for instance your team has a lot of experience with younameit and no experience with java or things like that.