Slashdot Mirror
JBoss Founder Interview
peterdaly writes "The JBoss website has an interview with Marc Fleury, the JBoss founder regarding his vision. In case you have been living under a rock, JBoss is an Open Source Java Application Server (J2EE) which has been picking up tons of steam recently, especially with the recent introduction of features like clustering. Competing products from companies like IBM (WebSphere) and BEA (WebLogic) go for tens of thousands of dollars, which is interesting since JBoss is starting to have features the big boys don't. JBoss had 72,000 downloads in October. This is a project to watch."
This is not just a project to watch... When 3.0 is release, all other Java Middleware will be worthless. It is more than a project to watch, but one to support, use, and contribute to.
...JBoss article.... must... plug... Jakarta Project.
Jakarta contains whole bunches of open source tools that work great for Java Projects (I'm using struts and ant on my current project).
They all work extremely well (and simple to install) with JBoss.
I don't know the level of people using JBoss, though. The top two app servers are WebSphere and Weblogic. They take 50% of the market. The next is iPlanet (netscape), then I think its JBoss. So, even though its the cheapest (free), doesn't mean its got the market.
It'll be tough to crack WebSphere & WebLogic.
What JBoss needs is a certification (with levels) for developers to obtain.
If I go to a client and say "I have a level 3 WebLogic certification, a level 2 WebSphere certification, and know JBoss", what are they gonna pick?
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
Let's face it - JBoss appeals to us Slashdotters because
(a) It's open source
(b) It has a whole heap of fantastic development features.
What I didn't see an emphasis on is running on a daily basis in production. Sure, I think that JBoss is fantastic for development, and most of the leading edge features are great for developers, but what about running a mission critical production system? What benefits does it provide in that arena, given that if I have Weblogic or WebSphere, and it breaks on my 24x7 website, I can scream at the respective vendors?
Develop with JBoss, deploy with WebSphere/Weblogic. Anyone enlighten me to benefits of JBOSS in production over a commercial offering?
Gollo.
Not strictly right, AIUI.
The Websphere application family is built up on several layers (described by IBM as the e-business application framework). The Foundation layer contains those tools that provide the fundamental low-level functionality of the system, and this basically comprises WAS and MQ Series.
On top of this you've got the Foundation Extension layer: tools for optimising the performance of the Foundation tools, and for development and deployment. Here you've got tools like VisualAge for Java, the personalization suite for Websphere, and Edge Server (used to be called the performance pack, IIRC, but clearly that didn't sound cool enough...)
Finally, over the top of this you have the Application Accelerator layer, consisting of tools for building particular types of application. That's where Commerce Suite lives, along with tools like the Websphere B2B Integrator.
JBoss itself corresponds to just part of the Websphere Application Server - it's really just an EJB server rather than a full J2EE server. However, combined with Tomcat (and you can download the two as a nicely integrated bundle from the JBoss site) you end up with something comparable in many ways with Websphere Application Server (advanced edition). In some ways it's better, in others it's worse. It's certainly more up-to-date - Websphere is (as with most IBM Java systems) a couple of versions behind the bleeding edge. That gives it the benefit of stability and reliability, but it gives JBoss the advantage in enhanced functionality (such as support for CMP2.0).
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
A more accurate description is a platform that handles "back-end" functions for distributed or networked applications. This might include accessing databases or performing calculations or functions in a centralized location. It is not limited to web-based applications, though this is a primary use for application servers. The generic model is for various clients (browsers, standalone applications, or some type of service) calling functions that are executed by the application server. Often, information is then passed back to the client. The domain associated with application servers is the execution of "business logic". Servlets are often part of an application server platforms but application servers are not limited to serving up dynamic web content.
At my office we use JBoss as part of an entirely Open Source and free platform stack:
OS: Linux
Web Server: Apache
Servlet engine: Tomcat
EJB Container: JBoss
DB: PostgresQL
And a great set of middle level libraries such as Struts for form processing, a slew of other jakarta classes, tinySQL fro xBase integration, JUnit, and HttpUnit.
I came from a company that did oracle/ATG integrations. I can honsetly say as a developer, I have everything I need that I used on thos platforms.Plust I like that fact that it is a little closer to the J2EE standard than ATG.
Open Source Identity Management: FreeIPA.org
A java apllication server is a software package that runs the logic of many high end java applications. An application server is where most of the hard work of an application is done. On top of application servers, you may see things like Java Applets, Java Applications, or JSP/Servet containers (ala Tomcat) which act as the interface between the application and the user.
Usually on a Java Application Server, programs are design as small server side components, which perform independently of each other. By typing the components together, useful applications are born. For instance in e-commerce, a JSP interface may recieve a credit card purchase. It will run your credit card through a credit card component on the JAS, ask a warehouse component to mark the order for picking, notify the shipping component a package will be coming and where to ship the order number to, notify marketing a sale has been made, and tell the purchasing module to order parts which will be needed to replace the unit in inventory.
All of these are seperate components which can be used in many different applications. By creating a system like this, business login never has to exist in more than one place, which reduces programming time, stabibility, and makes the system as a whole more flexible.
Hope that made sense.
-Pete
Soccer Goal Plans
I've been using JBoss for a little over a year, and my experience has been very good. It's fast, reliable, and seems to keep quite up-to-date with developing standards.
This kind of project is exactly what the free software world needs - usable, cutting-edge, and easily comparable with competing proprietary products.
This project has cemented my opinion on Java on Linux as a server platform, and when combined with PostgreSQL, it forms a complete and surprisingly robust setup.
I wish the JBoss team the best of luck and fully intend to keep using and recommending their software.
Now that J2EE has been briefly explained, and I've stated my position (useful services, with some warts and all, designed to the lowest common denominator, and unfortunately sometimes too easy to build systems that really perform like slugs) I will give JBoss some props for really driving forward the implementations of the standard in several ways. Adoption of JMX is great, JMX is very useful for building custom manageable components that don't fit into the standard J2EE framework (i.e. they need to be stateful and not session coupled so they can't be implemented as reasonably performing, compliant EJBs). Also JBoss provided the first reasonably performing EJB implementation I have seen. Far faster than most of the commercial implementations when it came out for the common case scenarios (the commercial implementations may have improved since, I don't really know). My company moved to JBoss from Weblogic as we discovered we couldn't afford enough Weblogic licenses for every developer to have his own test box. And that the nature of our system makes it really hard to test otherwise (note: this is partially the fault of our system's architectural stupidities, but let's put that aside for the moment). We have generally had great luck with JBoss, and found the JBoss community to be very, very helpful with problems when they sprung up (compared to Weblogic 5.1 where I got some very frustrated engineers on my team stuck with the job of calling Weblogic support bitching at them about weird problems with spontaneous breaking of the EJB standard - anyone who used it knows that SP6, SP7 and SP8 were all released in short succession around the time I'm speaking of).
The moral of all this is that the JBoss team has done a fabulous job at providing a great, useful product that has saved my company thousands of dollars and many hundreds of man-hours of developer time. While the J2EE spec is, err, deficient in certain ways, for a lot of enterprise software projects it's good enough for the task at hand. And JBoss, with full clustering support coming up now, should be good enough for most if not all of these jobs. If you need a real distributed application with high volume transaction processing, you might need to look at other kinds of systems that give you more access to lower level capabilities (think: Weblogic Enterprise, Tuxedo, etc.). Or roll your own.
Another server that is used in the Java arena is the Orion Server. It's very nice and I enjoy working with it on a daily basis, but it's not Open Source which a lot of people consider to be a downside. It's free for development platform and non-profits, but for production it's $1500 USD per host. Cheaper than BEA, but But a lot more expensive than Jboss or TomCat (the Apache JAS).
Hilary Rosen's speech was about her love of money and her desire to roll around naked in a pile of money.
Honestly, most of the J2EE apps I've seen, Servlet performance is a MINISCULE problem compared to much, much larger application architecture issues. You can always add more servlet engines on separate boxes, of course, then the RMI invocations are going to be slow. You did pay attention to using _coarse_ grained components, didn't you? Anyway, this is just my opinion.
In any case, you can't blame the JBoss team for this - you can pretty much embed any servlet engine you want into JBoss - Tomcat and Jetty are pre-done for you, and if some enterprising hackers want to find a better solution and embed that, it isn't that hard to do.
from their web page:
JBOSS SUCCESS STORY OF THE MONTH! NEW
"Just through you'd like to know that the United States Department of Labor's Office of the Chief Financial Officer uses JBoss to process about $3.0M worth of financial transactions yearly in one application alone. There are several other legacy applications scheduled for migration. By using JBoss, we've saved the taxpayers about $100,000 in BEA Weblogic licensing fee and about $10,000 in annual support fees".
Michael R. Maraya, OCFO/OFD/DFAD
Soccer Goal Plans
Mixed platforms on the server side are the norm rather than the exception, in the market where JBoss is trying to position itself.
Consider that JBoss is (will be, in some respects) a J2EE-compliant system, in everything except name. The purpose of J2EE is to deploy in large-scale environments... where you potentially have PC/W2K, Solaris, IBM S390, and God knows what else already providing a business solution.
You will not get a contract to replace the business systems from top to bottom, so take the view that you'll integrate into them instead. Now you're talking multi-tier Facades and Interfaces in order to get these things talking to each other.
You'll want to design things so that there is as little interdependence on co-operating subsystems as possible. Read 'Design Patterns'. Have a serious *think* about XML. Look at the Java libraries and the J2EE designs. Understand.
Have you ever noticed that it "just seems easier" to do things in Java than C/C++/VB(spit!) when there's any degree of complexity ? (I'm not talking about a couple of days' hacking, I'm talking about a designed system). There's a good reason why Java works so well - it's been designed well from the bottom up.
J2EE (and hence JBoss) take that elegance to a higher level of abstraction, but what they're doing is to continue the excellent design principles of the class libraries.
A happy JBoss user.
Simon.
Physicists get Hadrons!
I hope somebody can answer this. I am wondering how the application-level clustering (i.e. what JBoss, Weblogic, et al have) compares to the IP-level clustering (i.e. something like the Linux virtual server, or the embedded hardware equivalent from Cisco et al). There would be less overhead at the IP level, so, it seems the load balancing would be more efficient. Also, by doing load balancing at this level you can cluster just about any application -- be it a web/ftp/file or, as in this case, application server. What's the advantage of having clustering built in to the app server? How about Apache mod_backhand?
___
If you think big enough, you'll never have to do it.