Open Source Winning Java Server Market 37
Seldo writes "C|net is reporting that free open-source J2EE servers are gaining market share. From the article: "Analysts say it's difficult to measure the extent to which open-source Java application servers, such as Tomcat and JBoss, have eaten into the revenue of commercial providers of Java application servers. But the growing popularity of the open-source application servers is undeniable." The article also points out that the emergence of J2EE as a standard led to a commoditization of Java-based application servers, giving the low-cost OSS alternatives an advantage."
Re:DUH (Score:2, Interesting)
Re:DUH (Score:1)
Re:DUH (Score:4, Insightful)
Second of all, let's try this again. What about the spec is crap? Can you give some examples? Your argument of "J2EE is crap" really isn't convincing me or anybody who reads this Slashdot that J2EE is an inferior technology. Mmmmkay?
Re:DUH (Score:2)
How about this? Just give us one, just one, example of what "J2EE is crap".
Re:DUH (Score:3, Informative)
Avalon Project: [apache.org] (a well thought out framework for server development)
Phoenix Server Microkernel: [apache.org] (a very good implementation of the avalon framework)
Enterprise Object Broker: [enterprise...broker.org] (allows publication of any java class as a "bean" without having to conform to Enterprise Bean Spec, with hairthin differentiation between local and remote object invocation)
I myself have always believed that server software development has always been unnecessarily complex. If you like actually being able to simply, freely, quickly create a server app, then these products are for you.
Re:DUH (Score:2)
Re:DUH (Score:3, Interesting)
Sure. But not with this stuff you're offering. Let's see... Phoenix requires you to restart the server each time I deploy a new 'block' to the server? Uh-huh, so where are the HA features? How do I service my customers while that server is being kicked down? Where is the clustering for HA? How about fail-over?
One obvious and glaring omission in all of the overviews is the lack of basic notion of transaction handling in these frameworks. So I have my blocks deployed and I need to make sure that my block A and block B are working nicely together, committing their changes in an atomic fashion. So how do I enlist these different blocks within the same transaction? Surely you don't suggest I manage my transactions myself in the code and write my own logic for things like transaction context passing? How is transaction demarcation handled within these 'blocks'?
Why do you think people use J2EE?
If you like actually being able to simply, freely, quickly create a server app
It looks neither simple or quick to me. Looks like some very basic features have been omitted that are available on all J2EE applications servers. Writing log components, deployers or rmi code doesn't really require all that much. And the hard parts they just decided to ignore as 'unnecessary'.
Re:DUH (Score:2)
Sure. But not with this stuff you're offering. Let's see... Phoenix requires you to restart the server each time I deploy a new 'block' to the server? Uh-huh, so where are the HA features? How do I service my customers while that server is being kicked down? Where is the clustering for HA? How about fail-over?
It is in the works. Even jBoss started somewhere, but at least this project does not offer a facade of a free sofware project. Hiding their documentation from potential users who don't wish to spend money on the project. Soon, it will support hot deployment, as well as being cluster capable (depending on configuration, all this really requires are a few changes to the AltRMI library). Until then, well if you really require 24/7 uptime, don't use it. Its not ready for that, yet. It is still a relatively young product.
One obvious and glaring omission in all of the overviews is the lack of basic notion of transaction handling in these frameworks. So I have my blocks deployed and I need to make sure that my block A and block B are working nicely together, committing their changes in an atomic fashion. So how do I enlist these different blocks within the same transaction? Surely you don't suggest I manage my transactions myself in the code and write my own logic for things like transaction context passing? How is transaction demarcation handled within these 'blocks'
I found transaction management to be a moot point. You can handle transactions using any kind of transaction manager you wish. As long as you are consistent across your system, then you should have no problems getting a suitable system in place, with as much transparency as EJB Entity beans provide, and possibly more.
My biggest gripe with J2EE is the fact that they have you implement often times unneeded code. Their system is very rigid. Their code looks unruly and is often times redundant. This framework uses logical interfaces which takes seperation of concerns to the next level, and it doesn't force you to implement anything. It gives you complete freedom in how you implement your systems, and it doesn't have the audacity to claim to know a kill all for data storage and retreival interfaces (aka EJB-QL and CMP). The framework doesn't look perfect, but at least you are not shunned for not using their provided interfaces. J2EE is a model where you are reuired to accept the entire "all encompassing" system. I don't believe Sun has all the answers. Avalon assumes a common server framework. I can build on that.
Re:DUH (Score:3, Interesting)
However, if you're looking for a problem with the J2EE spec, look no further than entity EJBs. These things are seriously screwed up, and scream of an implementation based upon a poorly designed predecessor (CORBA) that was rushed out the door. By comparison, JDO really does things right.
As for Java's popularity, I think it really comes down to competition. When J2EE was first released, it really didn't have any competition. Even today, no Microsoft solution really matches up to J2EE in terms of availability (many J2EE implementations already exist), features, and scalability. That said, don't discount
Re:DUH (Score:3, Informative)
J2EE has it's disadvantages and here is an explation why (i.e. your post) is not a troll.
I agree with you totally. Anyone with any experience with J2EE (i.e. not the original poster), has struggled tremendously with entity beans. I have been following JDO closely and like what I see as well. Unfortunately, I haven't had much time to play some of the implementaions out there. The fact is that most projects don't require the overhead and complexity of EJBs and JDO would provide a much better solution for persistance. This ist actually is a very nice feature of the J2EE spec as it doesn't tightly couple EJBs with your web tier.
Re:DUH (Score:1)
On the other hand, many xml-related technologies (XML Schema, XQuery, XLink, XPointer . . with XSLT and XPath as notable exceptions IMO) are bloated junk designed by huge committees trying to be everything to everyone.
Re:DUH (Score:2, Informative)
Re:JBoss is okay, but Tomcat.... (Score:2, Informative)
Take a look at the org.apache.catalina.session.JDBCStore class sometime. There is a lot more to Tomcat than what is on the surface.
Why are commercial software vendors threatened? (Score:2, Insightful)
I don't get this. Why are commercial software vendors being threatened? MS doesn't care because they don't care about Java. IBM? Maybe, maybe not. WebSphere is really about the whole package not each component. Tomcat is a component. JBoss is a component, so probably IBM doesn't care, either. Sun? They are thrilled to hear news like this. I don't know if Tomcat/JBoss would lead to Sun sales increase, but as far as Sun is concerned, this is exactly what Sun wants to happen. Tomcat/JBoss, Java is getting as widely adapted as ever and... eventually, they'll go to Sun, the creator and the master of Java, right? They may not be selling iPlanet, but they don't care.
Strategy behind Java is very different from that of
Re:Why are commercial software vendors threatened? (Score:3, Interesting)
Re:Why are commercial software vendors threatened? (Score:5, Interesting)
Actually, I think IBM is being threatened. WebSphere is horribly overpriced, buggy, and very late to support new J2EE specifications. While IBM will still get hardware and integration revenue from their customers, I think they will miss the WebSphere revenue. IBM probably worries about this the least, though, as more and more of their business comes from the integration side.
Sun has been relegated to 4th place among commercial J2EE servers these days. I would bet they're far worse than 4th place when considering open source implementations. Even if they aren't upset about losing the revenues from iPlanet, I'm sure they can't be happy about losing control over what is becoming the de facto reference implementation for J2EE.
BEA can't be happy--much of their revenue comes from their overpriced J2EE server.
Microsoft is worried because the open-source J2EE servers are, much like Linux, making robust Unix-based server applications cheaper to deploy than equivalent Microsoft-based solutions.
I'm not sure how the strategy behind Java is really that different than
Re:Why are commercial software vendors threatened? (Score:3, Interesting)
They care. Lots. Take BEA or IBM's product. They have a stripped down version of both products that competes with Tomcat - a mere JSP/Servlet container. The 'express' version is largely a marketing tool to fold in the rest of the enterprise software. Not sure about IBM, but BEA's express version is really the full Monty - app server, etc - requiring only a license key to turn on the rest of the product. It is hard to get your foot in the door, and Tomcat tends to get in first because you don't have to worry about accounting or compliance as you start up.
It gets worse with Jboss. The EJB container is the bread and butter for the J2EE market. You may not be able to run the stock market with an open source version, but it is very hard on initial sales. Jboss works very well for limited deployments. At the point where clustering and other things come into play, it starts costing a lot of money. Don't forget most of these folks make cash on the developer licenses as well.
That is not to say the BEA and IBM products are junk. There are a lot of features, debuggers, books, and other things that make it worth having. The XML parsers alone are worth the cost of the 'express' version in a production environment.. It is like a car. Sure a Geo Metro would get you there, but I really like my heated steering wheel and leather seats. That make Tomcat a sport's bike?... Anyhow...
Sun is an odd duck. They use Tomcat as their reference JSP/Servlet engine now. (I think) They were yanking Jboss's chain back when they were trying to become certified - only to release their own EJB container.
Linux/Java story continues (Score:5, Insightful)
The J2EE market has until recently been a bit like the Unix market 20-30 years ago. Relatively portable and aimed at businesses.. with big money to be made.....and then there was Jboss
There are a few more open-source J2EE app servers than just Jboss and Tomcat - and its good that these are targeting different markets (just like the various Linux Distributions target different types of user/server markets )
Yeah! Companies are really starting to understand the value of open-source (free speech) software. This GetThere guy is really saying you can take you proprietary code and shove it where the SUNW don't shine.
Will the companies that sell J2EE app servers today be in some sort of trouble if J2EE becomes a commodity? No, they're not in trouble at all because they make money from their unique products and services around J2EE. Oracle make money from their databases, for IBM and Sun its hardware + services. Macromedia sell J2EE as a backend to a Flash/swt gui builder kit(yuck! but hey different strokes to move the world i guess) . BEA well... er.. yeah they are in a world of shit probably! (but BEA can adapt and focus on their performance centric niche market).
J2EE was always intended to be a commodity thats why the big guns adopted it because they understood the importance of customer demand for inter-operation and portability. The fact that there are various OS implementations simply proves commodity status has been achieved. I reckon Jboss & tomcat will do for Java adoption in business what Linux did for the Unix market. The big vendors will adapt, costs will fall, and one-hell-of-a-lot more people will finally know what 'Container Managed Persistence' is.
Re:Linux/Java story continues (Score:5, Interesting)
Absoultely. You're certianly not going to run .NET on Linux (well at least not yet, until Mono is released). J2EE gives you the option of picking an OS. It also works the other way around. If you already have Windows boxes as servers, you don't have to switch to Linux just to take advantage of J2EE.
There are a few more open-source J2EE app servers than just Jboss and Tomcat - and its good that these are targeting different markets (just like the various Linux Distributions target different types of user/server markets )
Yes, different application have different needs. One is allowed to chose which application server the feel will benefit their application to most. Resin [caucho.com] is a good example of this, providing a very nice way to do XSLT.
Will the companies that sell J2EE app servers today be in some sort of trouble if J2EE becomes a commodity? No, they're not in trouble at all because they make money from their unique products and services around J2EE.
Exactly. No longer can these companies "shit in a box and mark it garunteed." (Tommy Boy was on cable yesterday). They actually have to work hard to make their product give a signifigant advantage over the OSS versions and be worth the money, unlike some other giant software company we know ...
Re:Linux/Java story continues (Score:1)
I think that Tomcat can't be compared with JBoss ... Tomcat isn't an app server but a servlet engine now very stable ... fully compliant with Java servlet spec ... there is not great difference between Tomcat and commercial servlet engines (JRun, Bea , ... ) Tomcat has not jsp pre-compilation on startup and Bea has; JRun, perhaps, has better performances than Tomcat ... but such differences seem destined to vanish ...
but, at the moment, Bea and JBoss seem stay on two different planets ....
Eaten into the revenue of commercial providers??? (Score:2, Insightful)
And the alternative? That these providers would have eaten into the pockets of all the companies that chose free open source solutions? Anybody remember how freakishly expensive first application servers were?
I don't think they get the point. Software is not there to make software companies rich. It's there to make all the other companies productive and rich.