A number of free, or nearly free, application servers are available from open source groups and vendors. An new article discusses the various products, providing points to help you decide whether an open source server solution is for you.
Read Should You Consider an Open Source Application Server?
At our company, we've been using JBoss as our main development application server, with Weblogic or Websphere for production deployments. It's been a huge cost savings, and the problems with porting our applications to Weblogic have been minor. (Websphere hasn't been quite as cooperative though.)
Any time we've found a problem with the version of JBoss that we're using, it's usually already been fixed in a later release. I'm still not comfortable throwing a huge load at it, but hopefully some of those issues will be solved by the 3.0 release.
Can you specify what issues have come up that make you think that JBoss is still not ready for prime time? I work for a company where I have been actively promoting JBoss for both development and production. Since our production release won't happen until later this year I'm expecting JBoss 3.0 to be released by then. But nothing I've seen so far in 2.4.x indicates that it's not working well enough to deploy.
SUN says JBoss is illegal and anyone using it is in violation of the J2EE license. I hope Sun and JBoss can work things out, since I am in favor Open Source. I am not sure I would JBoss in a major enterpise at this time, I don't think it will scale very good.
doh, one of my messages got deleted... oh well...
anyway, according to JBoss, they're not in violation. Here's an excerpt from Jboss (full note found at http://www.jboss.org/licensesun.jsp
"Several people have suggested that JBoss is infringing Sun's copyrights by incorporating some of Sun's code into JBoss. We have carefully reviewed the JBoss code base and are confident that, with the exception of seven jars, all code distributed with JBoss was independently written by JBoss project contributors. As for those seven jars, that code was licensed from Sun under Sun's Binary Code License Agreement, which provides that JBoss can distribute that software in binary code format only. JBoss is fully complying with the terms of that license.
Other than for the seven jars just mentioned, JBoss does not believe it requires any licenses from Sun to distribute JBoss software, because JBoss is an independent implementation that meets widely available standards. Sun has never accused JBoss of violating any of their licenses, and JBoss is not violating any of Sun's licenses by distributing JBoss.
JBoss long ago informed Sun that we were interested in obtaining the J2EE certification suite so that we could apply Sun's certification mark to the JBoss software. Sun quoted a price for that certification suite that is beyond the current financial resources of the JBoss team. As a result, we have chosen not to "certify" our software. Nevertheless, JBoss fully complies with Sun's published standards. JBoss customers can be confident that they are using a complete, J2EE-compliant server implementation despite the absence of Sun's certification mark.
Also, if you look on Sun's Forte for Java site, they have some JBoss modules. Ah, the irony of it all.
I agree that JBoss seems to have done their homework. The problem here is that it's a matter of law and not up to the JBoss organization. If Sun wants to stop them, they probably could - but I don't believe they would ever want to.
I think it does, however, create uncertainty about building any system with JBoss because of what happen with Enhydra. I would not want to build anything tremendously serious with it because of the possible threat of having the rug pulled out from under me.
Now, in reality, I don't believe Sun will ever do this - JBoss is a great tool for introducing people to J2EE and getting them experienced with the technology.
An earlier poster talked about using it just for development, which I think is an interesting way of off-setting costs, I would just worry about compatibility - I would probably, as an organization, make an investment into a development environment to ensure a smooth development cycle rather than worry about the $30-40k it will cost to get the licenses.
My 2 cents!
I think it does, however, create uncertainty about
> building any system with JBoss because of what happen
> with Enhydra.
From my recollection, Lutris pulled the plug on Enhydra Enterprise voluntarily, not at Sun's request. They tried to justify their decision to not open-source the app server saying that Sun's license prohibited it. All Sun said was that, if they wished to be J2EE-branded, then they needed to take and pass the compliance tests.
Lutris could have chosen not to be J2EE-branded. This is the approach JBoss has taken. They chose otherwise.
<i>I think it does, however, create uncertainty about building any system with JBoss because of what happen with Enhydra. </i>
Enhydra was trying to get a J2EE Certification from Sun. JBoss has no interest in this. The two situations are quite different. Comparing them is naive, at best.
<comment>Enhydra was trying to get a J2EE Certification from Sun. JBoss has no interest in this. The two situations are quite different. Comparing them is naive, at best. </comment>
I agree, the situations are different - I was merely making the point that it is not, despite what the JBoss community says, necessarily a closed issue because Sun controls the license. As I also pointed out in the rest of my post, I don't think this will happen, but it could create doubt in the mind of corporate IT personnel and thus hinder adoption.
As for your personal attack about being naive, well, I'll chaulk that up to a defensive person. It would be so refreshing to see a series of postings on theserverside that don't devolve into personal attacks. Hey, I can dream can't I?
Sun if your listening...
A. My company deploys JBoss(a great middleware product) on a 52,000 Solaris machine.
B. It would probably be M$ middleware on an M$ machine if open source was not an option
Give JBoss your blessing, so we can get back to programming!
I worked back in July last year with the beta version of IBM Websphere 4.0....
While starting, the log would display a message saying that the app server was based on Lutris technology.
Is it where Enhydra disappeared???
Not the app server -- the message is from the startup of the lightweight "in memory" database (InstantDB, licensed) that is bundled with the single-server edition of the product. This DB is used as the persistence layer for some of the sample EJBs that come along with WebSphere.
Views are my own and not necessarily shared by IBM
Michael Ellis said:
" SUN says JBoss is illegal and anyone using it is in violation of the J2EE license."
Do you have a source for that?
"SUN says JBoss is illegal and anyone using it is in violation of the J2EE license."
Michael, as far as I know, despite the fact that JBoss's site claims they are in contact with Sun, proving that Sun is not ignorant of the existence of JBoss, there is no official Sun position statement vis a vis J2EE licensing and JBoss. You guys are welcome to conjecture away and play legal eagle on licensing, trademark, scsl, and the legal quagmire Sun has put in place around J2EE.
I certainly have no ideals about Sun, but in their own self interest, I don't think they're going to go around squashing open source implementations of the J2EE spec when .NET is looming on the horizon.
My pragmatic view of JBoss in production: at best, you get a great app server, with the added advantages of open source and zero cost. At the worst, it will take you a day and a half to port to Weblogic or Websphere and you'll pay the money you would have paid anyway.
We at netprise have based our product suite which bridges the enterprise and internet on open source products like
jboss, apache-tomcat, soap, xml, ebxml, Rosattanet, EDI (ANSI X12)
Pease visit http://www.netprise.com
for more details are contact me @ 408-3739344 or Raj Nukala @ 610 564 8150.
We have based our solution on open source since we are a bunch of designers and developers who wanted to follow the traditional approach to get funding rather than go around finding angel investers to fund our business plan.
We thought it would make perfect sense to come out with a product proto before going to market to fund some investment opportunities in this touch ecnomic situtation.
If Sun says, uisng JBoss is illegal and infringment of law, then we have to dump our efforts of past 6-7 months , since we do not have any more personal resources to develop and sevice something innovative things to customers in this great grand free world called America or US of all A's.
Only the website is hosted by a third party using microasoft technologies since it was free through some of our contacts. Ohterwise, the product suite is built on EJBS, XML technolgies.
Thanks for taking time to look at the website.
... one thing emerging is that open source app servers are very relevant in production environments - no need to shell out expensive license fee!
Want to know if there are a lot of us who follow this and also go for a commercial app server in the actual deployment scenario. ???
I'm using Enhydra XMLC Servlet (not Enterprise), JOnAS EJB server and InterBase to handle about 1000 - 2000 users daily in OpenUSS production site (also Open-Source project). It works fine. Although through a memory leak problem in JOnAS 2.3, I have to restart my system once a while... I compensate this with huge RAM (1 GB RAM)... ;-) This problem should be removed in the newest version of JOnAS.
I think, it is great working with Open-Source products, because you are forced to understand all the stuffs better! Not just click this and click that, like you used to do, if you have a user friendly development environment! You need to understand the base architecture of J2EE better and invest more in all those J2EE components and their relationships. But at the end you can see the whole stuffs clearer. You also tend to develop effectively because you just don't have all those "wizards"...
"but they use ASP!"
Hey, isn't that the spec that JSP was ripped from? ;-)
If Sun says, uisng JBoss is illegal and infringment of law
I would be extremely suprised if Sun ever said that. Note that the original comment was posted here completely without reference/qualification by a discussion group troll.
Your post was one of the few coherent messages on this topic, and dead on. I'm using JBoss and its fantastic. If JBoss tanks, about 90% of my code is directly portable to BEA (notwithstanding the weblogic-ejb-jar.xml writing....)and the remaining 10% of JBoss extensions I"m using exist in one form or another in BEA and would take a few days to fix. Not a bad bet because if JBoss tanks as a result of Sun legalese, I can still go on using it for a few days...
The answer to "Should You Consider an Open Source Application Server?" is a most resounding YES if $50,000 is valuable to you, or to your customers if you sell turnkey solutions. Otherwise ** who cares ***.
Your information is definitely incorrect.
1. Sun has never publicly stated that JBoss is in violation of anything.
2. JBoss has an agreement to distribute the jar files as part of the distribution.
3. There is no requirement to aqcuire J2EE Certification.
4. But Sun does not permit the distribution of the development tools, namely the JDK, without licensing agreements. JBoss does not provide the JDK.
How do you know that JBoss won't scale? Are there examples where it's failed to deliver in an enterprise environment?
How do you know that JBoss won't scale? Are there examples where it's failed to deliver in an enterprise environment?
I can speak to an example where JBoss exceeded our own expectations for scalability and performance. We had a Segue-driven stress test where web pages were generated from Tomcat and supported by Jboss for data/transactions. Jboss 2.2 was running on a quad-processor NT box with 4Gb of RAM, very beefy machine. We were able to see 250 concurrent users flooding the environment with transactions with no loss of service. Our EJB transaction rate was around 50K per hour and SQL transactions at over 200K per hour. For us the JVM memory tuning seemed to help considerably. I think Jboss 3.0's clustering will provide the critical piece of failover when one considers a total solution. I feel it held up admirably for an open-source solution.
Certainly i will chose Open Source Application Server
as ISV,i can make the solusion less cost.
as for tech suport,we can privide non-free tech suport service.
Define "cost", will you?
With the rates we charge our customers for the design and the implementation of a "solution", the application server licenses are invariably negligible ("ears on a camel" is a rough translation of the Turkish observation). A "solution" does not cost less simply because you omit application server licenses, open source software has its own costs (though no licence fees).
Mastering EJB II, page 460, topic "Open Source":
"If you choose an open source code EJB server, be sure you choose one for the right reasons-- you'd like more fine-grained control over the code base, you are running a nonmission critical deployment, or you'd like to foster the open source community.
The wrong reason is usually the price. Realize that the total cost of ownership of your deployment includes far more than just the cost of the application server. The total cost of ownership includes hardware costs, software costs, costs to employ developers, costs to train developers, and opportunity costs if your system is not ideal. Unless you are strapped for cash, we recommend you take price out of the picture."
<Posted by david wu 2002-01-23 03:26:45.0.
<Certainly i will chose Open Source Application Server
<as ISV,i can make the solusion less cost.
<as for tech suport,we can privide non-free tech suport <service.
This is bad business.
1. A "solution" (as opposed to an off-the-shelf application) works for one customer. You're willing to provide support for that one customer for as long as that customer chooses to maintain the solution? Better transfer the technology, turn over the solution and develop a new business.
2. Non-free support for free software. That is not a truly honest (or acceptable) proposal to the customer, is it? You can guarantee neither the software's status nor its continuous development. The cost to the customer does not drop much. The ISV's cost to build the solution does, however. While that may seem good for the ISV,
3. Another problem with non-free support for free software by a party other than the developers is that it is not nice and, in some cases, legal. Open source software is not meant to make you or your company rich. It is for the benefit of all and open source communities need the money from training and support to continue their errands. The open source communities protect their rights to such services. Most of the times, supporting free software for a fee is not an option.
I know this about Open Source and I 100% support any Open Source project, and would give time it I had it. I'm surprised no one has mentioned the Comercial apps server that dont have hideously expensive licensing costs. eg Orion, which I think is free to developers and resonable to deploy. Its only down side is that you dont get the source code.
Hmmm ... we have been through all of the Lutris stuff some time ago. Enhydra and was withdrawn suddenly amidst a series of allegations rgearding exploitation of the open source community ... the source for Enhydra Enterprise was never released and so it was never actually Open Source.
Whilst not open source, HP's Application Server (formerly Bluestone) appears now to be free. Has anyone come across issues in using this in commercial / non-commercial environments?
Very good article.
OSS Web App Server makes sense for development and low end products and OEM situations.
In my organization we are using Tomcat to develop & test our Servlet and JSP stuffs. We port them without problem on commercial App Servers.
For EJB and other j2ee developments we are evaluation and considering jBoss.
For production platforms, most of our customers are more confident with commercial app servers like WebLogic and WebSphere.
I think support is not the real issue. Administration console GUI, performance analysis and debug tools and integrated legacy application connectors are what is missing today in open source App severs.
It's right, that commercial app server vendors are now targeting new markets like portal, BPM and EAI.
One thing that really strikes me as interesting but incorrect about this article is the statement:
>"If you look at how application server companies are
>evolving their products, you'll see that they're extending
>their capabilities around database integration,
>application integration, e-commerce, workflow, transaction
>tools and moving up the stack to portal frameworks,"
This statement makes one to believe that these features are added benefits of commercial applications server. But in my experience and probably for many of you out there these aren’t simple value added additions to their products. There are inherent dangers and costs involved.
All popular commercial venders have packages or frameworks to deal with a particular enterprise problem domain like those mentioned above. But name one that doesn't require additional costs in addition to the paid license of the base product. These added costs are in many cases on a per cpu basis.
Furthermore, the danger lies in with vendors going beyond the defined specifications. Wouldn't applying these add-ons lead to a type of vendor lock-in? True, these packages are comprised of ejbs in many cases but you can't just simple port them with your own application code to another vendor implementation. Plus as they so conveniently did not mention is that the open source community has been acting as a bean provider as well. Many of these added packages have been and are in development with the open source community. This is more in line with the true spirit of j2ee and ejb development of component reuse through its pluggability in different scenarios.
Now back to reading Mastering EJB 2nd edition ;)
Many people here speak about JBoss.
But do you know JOnAS ( Java Open Application Server), it's a good EJB container too.
The approach for the license is to get close to the Mozilla Public License version 1.1 (MPL1.1) not GPL.
"Should You Consider an Open Source Application Server?" Not till I run out of options. We use both JBoss and RI for our development and training but no one could make me deploy on either. Why? Can they not stand up to the job?
They surely can. I am pretty sure the other open source app servers also stand up to the challenge.
What's wrong with them then?
When you get a show-stopper, when you're losing money as a product of ticking seconds, you need to have something that the open source software lacks: support. When I mean support I mean a 7x24 functional phone number and an on-site visit by qualified product support personnel at 3:32am on an hour's notice. If I am not getting any sleep, why on earth should anybody?
Businesses cannot take it light when you say the solution is in identifying and hacking the defect in a software that you didn't develop in the first place. You will be remembered as the nerd who was browsing through FAQs and finally code and chatting to his friends whose suggestions for the problem was almost always a cryptic "RTFM", while the company was losing money at a constant rate of x bucks per minute.
Your complaint about open source (in a nutshell, "no ones butt to kick when something breaks") falls down in the real world IMHO.
Almost all paid commercial tech support I have ever used has been sub-standard. You typically don't get particularly good people working on helpdesks, and I usually end up educating them (whilst paying through the nose for the privilege!).
The open nature of open source projects means that you can usually find the answer to your problem recorded in an open forum via google. Close source companys keep their bugs private, and in closed databases.
If you are still nervous, there is the JBoss Group, which provide commercial support.
All in all, I feel more confident using a established open source product (Linux, apache, php, JBoss, PostgreSQL etc) in a production environment than a closed source one, BECAUSE of the support.
I understand how it can make managers nervous, but I don't think having a butt to kick actually helps get the problem solved most of the time.
By the way, I have been using JBoss for about 6 months, and it performs very well.
Also, I dumped SCO Unix years ago for Linux, and have had MUCH better support (not to mention free).
I think the so-called support offered by big-name vendors is ultimately a rip-off. If there is a show-stopper at 3:33 am on a saturday in a product that you have dumped 40k/cpu in a production environment, all of the paid tech-support in the world isn't going to help you. Mostly this goes to making managers feel cozy. In using open-source app servers, web servers, etc, I have always gotten MUCH better help from their resources than I ever have from somebody in a so-called tech support role. They don't tend to know the ends/outs of the products, and they certainly aren't going to fix it for you at 3:30 am. Managers who feel more cozy with some sort of 24x7 tech support arrangement need to be educated - I heard the same sorts of stories when linux was coming to the fore. Now, of course, with many open source products, you can buy tech support if you want it, and it is often staffed by people who *do* know the product. Linux is everywhere now. I predict the same trend for products like JBoss.
Just my $.02 ... you often will get better support from others doing what you are trying to do ... i.e. the developer community around any product (whether open source or not). Such a community may grow around open source products, but generally you are treated differently if you are a contributor vs. a user. I've seen many times users asking for help with [insert purportedly popular open source J2EE app server name here] and apparently the questions were just a nuisance because this particular app server is more about building it than having anyone use it.
I'm no manager, it's just that I make the fine line between what *I* as a architect/developer would like and what would benefit the client. Let me stress that *I* develop using JBoss and RI. They both perform well. RI is very good for training purposes with its deployment tool.
What the client needs for a production environment is actually an expert that can kick-start a stopped show back to life. I have, as architect, five major succesfully completed projects under my belt; the best advice I give any client is "buy on-site (and not on-line or helpdesk) support". I don't offer that advice to add to IBM's or Oracle's or whatever company's revenue and neither do I offer it to soothe the managers. I offer that advice because I believe that to be the most beneficial way for a client to maintain its system.
Basically, the app server is a strictly *business* choice. It should be; when one pays the money, one has the right to decide one's peer. I will never tell a client to go for some software. Sometimes, they come asking. I just collect their tendencies, gather up data for the products, put down pros and cons and let them decide.
What if a client decides to go for JBoss or another open-source software? I would tell them to "buy on-site support" and if they cannot (no JBoss Group here in Turkey), "go for something else", or if they are hell-bent on it, "set aside a couple of guys to keep track of changes and, better yet, contribute to the software".
The biggest problem I've faced in using an open source application server (specifically EJB/J2EE container) is lack of EJB2.0 support.
Am I missing something, or do none of the open source J2EE servers support EJB2.0?
Jonas Application server has message-driven bean support (from version 2.3).
Full EJB 2.0 support is not currently available.