|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 22
Messages: 22
Messages: 22
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Rick Sharples: Why pay for a Java EE application server?
Rick Sharples, a Sun engineer, responded to a Javalobby post with "Why pay for a Java EE application server?," saying that "free" wasn't the end of the story: features, performance, support factor in as well.
The original Javalobby post had this text: JBoss is a J2EE app server with a good reputation and it's free. The same holds true for Resin. So why Fortune 500 companies pay for super expensive app server's licenses and purchase WebLogic or Websphere? Are they just plain stupid or there is something else that it's not obvious for a regular J2EE developer? Disregarding the obvious slant and emotion of the original post, Mr. Sharples' reply had some good points, but was itself merely a starting point for discussion itself, because he finishes with a huge product plug for Sun's application server without quite acknowledging that the free application servers also have specific features, performance, and support networks.
What do you think? What is the justification for using the application server (if any) that you use? Is that justification enough to make you decide the same thing in the future? What criteria should an application server have?
|
|
|
Message #185376
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
6 words ...
"You get what you pay for."
I think that about sums it up. Open source is great (I use it all the time), but some open-source hippies seem to be in denial about the quality of open source in general (just my opinion). I'm speaking very generally here. Honestly, how many open source web site have you been too that produce comprehensive documenation, samples, and support ... in a timely manner?!? I take part in many open source projects and my experience has been that you're more or less on your own unless some other user takes pity on you and throws you some nugget of support. Commericial apps are here to stay. Just my 2 cents.
|
|
|
Message #185380
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
6 words ...
Well, the irony here is that "you get what you pay for" works both for and against Rick here, as Sun's app server is "free" as in "cost" - just like JBoss is, with Sun and JBoss both offering support services.
|
|
|
Message #185384
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
is it really free?
To me, JBoss isn`t free. Last time I worked with it there was no useable documentation, even if you pay for it. Whole subsections of the (purchased) documentation would contain only a single incomplete sentence. JBoss consulting isn't cheap and if they have an similarity to the personality of Fluery, I`d probably beat the crap out of the consultant before I got my money`s worth.
|
|
|
Message #185393
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The real costs of application servers
Take a junior JEE developer that is new to application servers and have them install Weblogic and JBoss. Have them configure it with DataSources and JMS. Next create a simple EAR containing Session EJBs, Message EJBs and a basic web service. The time it takes from start to finish + licensing costs is the real cost of software.
For someone like me that has been working in JEE since it's enception, JBoss is the least costly. But for the beginners, JBoss is unwieldy and complicated. Will this change in the future? Yes. JBoss will become increasingly easier to use. Just like Hibernate, Struts, and JSF is easier to program with Eclipse plug-ins from Exedel and MyEclipse.
John Murray
Sobetech
|
|
|
Message #185399
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The real costs of application servers
the previous was a test since i posted several times without result. Lost my original text, don't want to type it again sorry, it was a rant anyway.
|
|
|
Message #185401
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The real costs of application servers
Since my appserver is hanging again i have time to rant about it. That thing makes my daily life a nightmare. The bigger companies are like sheep, they follow eachother. For some reason the first one bought the story and now we are all doomed. Why pay for a server?
- because of support, never had it.
- extra features, another phrase for "lock in".
- quality, my ***.
|
|
|
Message #185402
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
6 words ...
For the most part I agree with that sentiment but the truth is a little more dodgey when it comes to app servers. I have used WebLogic extensively and the companies that were paying for it payed dearly for those licenses. However, I found their product to be buggy, well documented in some areas and very poorly in others, and the support dismal (getting anything actually resolved always requires going through escalation procedures). Their EJB caching in the 7.x product was completely broken. I've heard, even after they rewrote it for 8.x, that it's still broken (have fun using it in a cluster). Granted, I'm talking about one vendor here. I haven't used WebSphere or any of the other ones. But my point is that just because you pay a bunch of money doesn't mean that you're getting what you pay for.
I think it's really a testament to the state of app servers that you see this situation.
And before anyone thinks I'm some kind of open source junkie...I spend far more of my own money on tools than anybody else I know.
|
|
|
Message #185418
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The real costs of application servers
John,
I wouldn't agree with you. I'm just a student and not a junior JEE developer. We had to do a small EJB project in our university and therefore we had to use WebSphere for this kind of project. After we tried WebSphere several times without success we decided to use JBoss. It was very easy to set up and to use. The documentation for us as beginners was very good what was actually surprising for us.
Thomas
|
|
|
Message #185431
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Rick Sharples: Why pay for a Java EE application server?
Seems more and more the question is why use a JEE application server at all.
Or rather, how often do you really need something bigger than a Servlet container?
|
|
|
Message #185433
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
What do you get for the $$$$
The problem with paying big bucks to a big company for support is: They don't really care about the small/medium guy's problems. You can point out a bug and they either acknowledge it and fix it a year later in a new release you have to pay more $$ for or they start pointing fingers at everyone else.....
|
|
|
Message #185436
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Rick Sharples: Why pay for a Java EE application server?
Seems more and more the question is why use a JEE application server at all. Or rather, how often do you really need something bigger than a Servlet container?
+1!
|
|
|
Message #185446
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Rick Sharples: Why pay for a Java EE application server?
As soon as you need horizontal scalability, or true asynchronous operations, or distributed transactions and processes... not that you can't get those with just a servlet engine, but it's a lot more work than using JEE at that point.
|
|
|
Message #185471
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
why pay?
Why pay for licenses?
- Operational robustness. The main "non lock-in" feature of the newer commercial application servers is about making sure the system does not go down, for planned or unplanned reasons. Sure, it may not be applicable to an average website, but this is the level of reliability that's being demanded by Fortune 500 customers that already use the OLDER infrastructure servers, whether CICS or Tuxedo or IMS or whatnot. Including things like fine-grained resource managers, side-by-side deployment / zero-downtime upgrades of applications, transaction dyeing, very high-speed + scalable messaging, support for the latest WS-* standards, etc. are not trivial (otherwise everyone would have it).
- Extra features. Sometimes they're worth it, sometimes they're not. The database vendors have made a good business out of this. Frankly, I think way too many are obsessed with avoiding lock in. It happens. Yes, it should be managed. But it's a tradeoff, not a holy grail. Even if you use an open source project, you're effectively locked in -- you can either fork the code base, or you're stuck with the direction of that project. It's a business decision whether you want to run the risk of having to maintain the code, just like it's a risk that a proprietary vendor may go belly up. Which is more palatable? Depends on the context, I suppose. I think relying on a financially stable vendor is much more risk averse than betting you have developers that can successfully maintain an OSS codebase alongside their "real work".
- Maintenance/support discounts. License deals often have drastic offsets to annual support renewals.
- Bundles. Large integrated hardware/software companies can give major discounts on hardware if you purchase software license. (though this works too for OSS if you purchase large consulting contracts)
- Indemnity. Large software deals usually imply an ability to tailor your own terms and conditions. Government agencies, for example, are notorious for negotiating 10+ year warranties, withholding revenue recognition until delivery, unlimited liability, and getting massive discounts on license and/or support. Do you really think a small support-driven OSS company can meet these terms? One successful lawsuit, and the tent is swept away.
- License offsets consulting. Something has to fund development -- support fees can only go so far, and consulting is where a lot of that maintenance happens. In a way, I think open source advocates are treading down a path of "software as a service" without realizing what that implies. It does NOT necessarily imply a wonderful array of libertarian independent free agents using only open source software (though that model is working in some areas and will grow). It more likely implies that software infrastructure companies will have a subsidiary large system integrator that can dump busloads of green consultants charging $200/hour to fund product improvements. And it probably means that product quality will suffer so that there is incentive to purchase consulting.
Large companies, as much as people like to think they're stupid, are not necessarily that stupid, they just have different priorities than most developers.
|
|
|
Message #185758
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Rick Sharples: Why pay for a Java EE application server?
As soon as you need horizontal scalability
Do you mean clustering here?
or true asynchronous operations
JMS isn't enough?
or distributed transactions and processes
An XA JDBC driver and JTA isn't enough?
not that you can't get those with just a servlet engine, but it's a lot more work than using JEE at that point.
I think you can get enough of it with Spring and a servlet engine to get by in a lot of cases.
%
|
|
|
Message #185826
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Spring and servlet container sometime just isn't enough
not that you can't get those with just a servlet engine, but it's a lot more work than using JEE at that point. I think you can get enough of it with Spring and a servlet engine to get by in a lot of cases.%
Since when Spring provides JTA Transaction Manager implementation for 2PC transactions support? Or may be any servlet container has it? Not the last time I checked. What you going to do if you need one? How about try JOTM without transaction recovery code implemented, or JBoss without persistent transaction log? Have a productive day.
|
|
|
Message #185827
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Rick Sharples: Why pay for a Java EE application server?
or true asynchronous operations JMS isn't enough?
JMS is enough, but it's not part of the Servlet spec, and plain Servlet containers don't provide JMS.or distributed transactions and processes An XA JDBC driver and JTA isn't enough?
No, you also need a transaction manager. Again, Servlet containers don't usually come with a JTS XA transaction manager. not that you can't get those with just a servlet engine, but it's a lot more work than using JEE at that point. I think you can get enough of it with Spring and a servlet engine to get by in a lot of cases.%
Spring USES these services (JMS and JTA) but doesn't PROVIDE them. You'll need to integrate other libraries / servers into your deployment environment to let Spring make use of them, and then you're pulling together the pieces of an app server yourself (which may be ok, if you know what you're doing).
So who's doing this? I'm evaluating these options right now myself, and trying to determine the enterprise-readiness of opensource infrastructure (i.e. no transaction logging in JBoss is a big no-no).
|
|
|
Message #185911
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
a sad history
I've been using BES for the past two years, and is not really good, we started with version 5.1 and it was a hard time, its a really heavy process , the cluster option hard to make it work, some critical bugs, the some time passed and we got the version 5.2.1 and it was better, but it is still heavy and often crash with an out of memory error, and when you try to deploy a file with the BES console it crash (i had to write my own deployer application in order to put my application in the server).
The the version 6.0 arrived and my company bought it, it was a big mistake a lot of bugs ( many application working with 5.2.1 weren't working properly in 6.0 ) and problems with Jbuilder .We though that the problem were us , but when a few months later Borland release the version 6.5 with the fixes of many of problems the problems that we had, we realized that the problem was the server. We go back to 5.2.1 version after that.
After that i felt like we were paying for a unuseful software that makes our work a hard thing. And if you ask me about support we had like a 15% of useful support it's not a great deal, i think so.
So i am starting to check Jboss, and Tomcat alone they can do the most of things i need to, you can get the newest version for free and if this version is not working with you you go back to a prior version without any felling of guilty. And for support we have google, it is a big helper it has solved the 80% of our problems.
|
|
|
Message #185934
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Why pay for a Java EE application server?
I've written up a few blog entries on this topic.
The benchmarks results are the most quantified way of looking at the problem, but that only covers hardware and software consumption. They key take away is that WebSphere and others may cost less/CPU than WebLogic, but they need more licenses and hardware to carry the same load.
SPECjAppServer2004 Results Analysis
The second way to look at this problem is to look at the relative cost of the app server vs. the total project cost. My crude analysis shows that the total licenses and support over three years come out to only about 2% of the total project cost yet the choice of the app server can have significant impact on the likelihood of success of the project.
The Relative Cost of Application Servers
Eric- BEA Systems
|
|
|
Message #185982
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Why pay for a Java EE application server?
The second way to look at this problem is to look at the relative cost of the app server vs. the total project cost. My crude analysis shows that the total licenses and support over three years come out to only about 2% of the total project cost yet the choice of the app server can have significant impact on the likelihood of success of the project.The Relative Cost of Application ServersEric- BEA Systems
That depends on your deployment environment. If you're deploying on one machine or a small cluster, then sure. But what if you're developing a software-as-a-service offering that's going to be deployed on a 30 node cluster? Adding more customers means adding more nodes which eats into your margin. As you scale the licensing fees become a higher and higher percentage of your total cost, and people's time becomes less and less of a percentage. At some point it becomes financially beneficial to hire away whatever Geronimo developers IBM hasn't snagged to fix what you need fixed.
Free / node scales a lot better financially than $10-$20K/node.
|
|
|
Message #185995
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Why pay for a Java EE application server?
The second way to look at this problem is to look at the relative cost of the app server vs. the total project cost. My crude analysis shows that the total licenses and support over three years come out to only about 2% of the total project cost yet the choice of the app server can have significant impact on the likelihood of success of the project.The Relative Cost of Application ServersEric- BEA Systems That depends on your deployment environment. If you're deploying on one machine or a small cluster, then sure. But what if you're developing a software-as-a-service offering that's going to be deployed on a 30 node cluster? Adding more customers means adding more nodes which eats into your margin. As you scale the licensing fees become a higher and higher percentage of your total cost, and people's time becomes less and less of a percentage. At some point it becomes financially beneficial to hire away whatever Geronimo developers IBM hasn't snagged to fix what you need fixed. Free / node scales a lot better financially than $10-$20K/node.
You are right that any analysis needs to factor in the use case. I had to make certain assumptions to come up with my crude model.
I agree that the use case you outline would reduce the % of cost attributed to development over time, but it is still the majority of the costs so it could take many years to make up for any lost developer productivity.
I would also stand by the claim that a free app server that consumes more hardware can easily offset the costs saved by the license fee. If you need more hardware and OS licenses and the support, power and space that goes along with them, you can easily spend more by using a free app server.
All of that said, it really depends on the use case and requirements that come from them. Sometimes free is the way to go. Sometimes it isn't. You can't paint broad strokes that say one is always the right choice. This is why BEA announced future support for open source frameworks and containers at JavaOne this year.
Eric- BEA Systems
|
|
|
Message #186000
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Rick Sharples: Why pay for a Java EE application server?
Spring USES these services (JMS and JTA) but doesn't PROVIDE them. You'll need to integrate other libraries / servers into your deployment environment to let Spring make use of them, and then you're pulling together the pieces of an app server yourself (which may be ok, if you know what you're doing).
With the parts standardized, it's not that hard or hack'ish to put them together.
And I still see two major advantages in this DIY "app server" over any of the heavyweights:
1. it's less prone to vendor lock-in.
2. it manages to dodge the EJB container, which frankly I'm not sure most of the applications today really need except for 1) the "we are mission-critical" ego, 2) the "we've got to be clusterable at *every* tier" geeky architect, and/or 3) the "everybody else's using EJB" mentality.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman continues to explore the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(January 21, Article)
Ted Neward is an independent consultant specializing in high-scale enterprise systems, and an authority in Java and .NET technologies. He is the author and co-author of several books, including Effective Enterprise Java. At TheServerSide Java Symposium in March, he will be presenting sessions on pragmatic architecture, ECMAScript and Scala.
(January 15, Article)
Now that Oracle is absorbing Sun Microsystems, there mixed views on what should come of the Java Community Process (JCP). While some say Oracle should become the new steward of Java and keep the JCP much as it was, others argue that it may be time to open-source this widespread language.
(November 24, Article)
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
