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."
Tomcat is only a basic application server (if it can be considered one at all) and does not support J2EE.
A Java application server is a platform written primarily in Java that serves web content through Servlets. For example, IBM has WebSphere Application Server (WAS) that is the core to most of their web products. It is a servlet manager with a DB API all combined with a modified version of Apache. You can develop with this directly, or you can purchase the next step up of IBM Websphere Commerce Suite which has tools and a DB schema for web (especially e-commerce) development.
An app server is not a physical computer, merely a server package akin to a web server or ftp server. The clustering capabilities refer to the capability to share the load across several machines and having been programmed with parallel computing in mind.
--Dave
He doesn't compete with Tomcat, it actually even uses it.
Tomcat is not a J2EE application server, it's basically a jsp/servlet engine.
An appserver has many more features, like JNDI, transaction, connection pooling, EJB, etc...
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.
IBM has WebSphere Application Server (WAS) that is the core to most of their web products. It is a servlet manager with a DB API all combined with a modified version of Apache
Just a small correction: even though WAS provides its own version of apache, it also provides a plug-in to be used with the original apache
Most of the servlet engines out there (like Tomcat, JRun and WebSphere) offer the option to integrate with an external web server, mainly because they don't perform as well as the "regular" web servers on static pages.
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
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.
Quick answer to your question -- JBoss runs within an APP server. So you run JBoss within Resin or Tomcat. You don't need anything to connect JBoss with your Webserver.
JBoss has a version which include a version of Tomcat, which runs inside the same JVM as the app server, which improves the performance greatly in many cases. That means no network connection, even locally, for RMI calls. Tomcat itself (Jakarta really), Apache's JSP/Servlet container, even as a seperate product integrates very well into Apache since they are made to work together.
Don't know if that answers your question or not.
-Pete
Soccer Goal Plans
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
Bingo. IBM's offerings aren't just about the app server - that's actually a very small part of the Websphere family of products. It's the development tools, the extra features, the integration with other IBM back-end systems that make Websphere so attractive, not just the ability to run EJBs. If that's what appeals to you for a particular project, then JBoss can't come close to matching it right now.
That said, if you just want the basic J2EE functionality, you could do a lot worse than JBoss, for a lot more money.
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
Yes, JBoss integrates with both Jetty and Tomcat.
:)
:)
Jetty is full-fledged http server, and Tomcat has an Apache module.
You can download JBoss/[Tomcat|Jetty] bundles, and lo and behold, they run "out of the box" on both Linux and Windows.
JBoss is extremely convenient for development since it doesn't require any special compilers, converters or whatever BEA call their ejbc-tools; just jar it up, drop it in the 'jboss/deploy' directory and watch the log file.
With the new versions of Ant supporting ear and war in addition to ordinary jars, the build.xml (ie. the Makefile) for for a JBoss project is dead easy to write.
Several IDEs are now supporting JBoss as well, providing support for those "corporate developers" stuck in "tool hell"
(I use Emacs and Ant and would only swap those for a very fat paycheck
JBoss is definitely not just an EJB server. It provides a JMX managed component framework with components that wrap around the various services that comprise a J2EE app. It provides JNDI, JMS, EJB 2.0, JMX, etc. I uses third party implementations of the Servlet/JSP subsystem which is appropriate, there's really no need to have anything more tightly integrated than that. JBoss also has a JCA implementation, obviously a JTA/JTS implementation, JAAS implementation, and is SOAP capable. So I think it is pretty complete. :)
difference between JDk and SDK: Prior to Java 1.1 (inclusive) the developer kits were called "Java Developer Kit" (or JDK). From Java 1.2 on, it's been called the "Software Development Kit."
The SDK contains what you need to compile and run programs. The JRE (Java RunTime Environment) is just the run part of the SDK. The JRE comes with the JDK.
The concept of having source files match the class name within is required for classes that are 'public.' It's also good development practice to do it that way.
As for the download problem - check your browser settings. You might need javascript/cookies or something.
Dont worry too much about the over-acronyming and over-buzzwording of all the Java stuff out there. It's nearly impossible to keep it all straight. (for example, I dont bother with about 95% of the java stuff out there) But to learn what you need just takes the usual: practice and experience.
The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
If you aren't using J2EE, but just Servlets & JSP's, then I suggest Tomcat 4. They've really improved tomcat mucho (especially if you have to work on a Win32 machine). But only for development.
Another reason is that Tomcat & JBoss aren't resource hogs, when you need to be debugging and coding with it running).
Ah, I think, since you are unsure of the facts surrounding the reliability of different appservers (as am I), that you are really more concerned with "who to scream at" should your appserver go down.
One of the great fallacies of application hosting is that if there is somebody to scream at, you are somehow less responsible to your clients for the production screw-up than you would be if there was nobody but open-source developers to be frustrated with. [Yelling at open-source developers seldom helps your cause, no matter what it is.] Let's face it, your clients aren't going to care if you are blaming a commercial entity for the screw-up; it makes you look bad.
What you should be concerned with are:
1) Reliability - JBoss is more reliable than all other AppServers in use right now, and introduces cost savings because it is easier to use, and less buggy!
2) Support (NOT "blame") - I have used purchased appservers (well, admittedly "appserver"), and JBoss, and let me tell you; the JBoss group helped me quickly and easily with any problems I have had, wherewas the commercial product I was using was IMPOSSIBLE to get support for, even though my employers had paid big $$$ for it. [The same actually goes for all open source projects I have used.]
Daryl.
Actually, Tomcat 4.0 has its own JNDI provider, so it does support looking up resources (JDBC datasources, etc.) in a standard way. It is also possible to extend its JNDI provider to support your custom resources, they have an example where you can register an arbitrary Java Bean in your web app, and then look it up from a servlet.
"The deluded are always filled with absolutes. The rest of us have to live with ambiguity." - Aristoi, Walter Jon Willia
JBoss 3.0 supports entity and session clustering...
I think if you have a mission critical application then it is not right time to move to JBoss straight away, You should wait for 3.5 or 4 to be released. What Jboss really needs is backing from Big gaint like IBM etc.. this is what Marc, JBoss Founder/President, is trying to do create awareness, gain popularity. Once that is done application server market will be like HTTP server market... Who pays for Http server nowadays???
Why would a client pick you to deliver an application because of your sysadm skills for application server Random vX.Y? If you make your application correctly (possibly with a few work arounds), your application should deploy equally well on all three.
Weblogic and Websphere have one thing that JBoss will never get directly - a corporation that backs the product and promptly deals with support. And that is what you pay for.
Unable to read configuration file '/bigassraid/htdig//conf/14229.conf'
Geocrawler error message.
There are some better post at http://theserverside.com ... a few interesting comments from Rickard Oberg
http://www.theserverside.com/home/thread.jsp?threa d_id=10469
I work at one of the largest vendors of software for banks, and diversity of server platforms is a fact of life for our clients. Many banks are quite happy to continue using applications that were written 20 years ago, in RPG, for the IBM AS/400 platform. And it makes sense; those applications work quite well, and they represent millions of lines of code, which can't be thrown away just because RPG isn't a modern language.
Many of those same banks also have applications running on all sorts of Unix systems. And of course, Windows is widely used for front-office applications. Oh, and they all use different RDBMSs, too.
If you think it's easy to write, say, C++ applications that are portable across all those environments, I suspect that you've never really tried.
We've written our in-house middleware in Java; we develop on Windows desktop machines (alas!), and the code works out of the box on AS/400, Solaris and Linux, as well as with every RDBMS we've come across. It's an easy sell to our customers, many of whom have strict requirements about which operating systems they're willing to use for which projects. And we haven't spent any time porting our software.
More importantly for this point-of-view is these (like many other programming techniques) allowed the group to implement solutions with widely varying performance: from slow but explicit code to hand-tooled solutions that utilize aspects of the problem domain. While it is a common conception that systems with as rich a feature set as JBoss are performance hogs, it should be noted that most enterprise scale systems don't have very attractive small-scale performance (some Oracle DBs can have a +1GB footprint before any user data or DBs are added which ain't exactly embedded.) JBoss is both small and fast enough to run from student/school-lab quality development systems (real budget machines IHMO) but has sufficient performance to match wits with a full-blown ecommerce application. I helped implement a complete on-line store (liquor store, that is) that held under our test loads (page view/transactions per sec) without relying on clustering.
The onjava.com article does bring up a valid point: like many complex software packages (tcsh, ant, Java) does have a complex environment to setup and maintain. A large part of this however (much like with tcshrc config files) it is a matter of how much you want to custom tailor YOUR system. Much like makefiles and easy builds, a little bit o' work goes a long way (I've seen a factor of ten improvement with some cases.) I think though you will find the best improvement in performance not from hoping between J2EE systems but from good ol' fashion Data Structures and Algorithm Analysis appropriate to you application.
Happy coding.
"You cannot have a General Will unless you have shared experiences. You cannot be fair to people you don't know."
Session-state peristence.
2 Scenarios:
1. w/o clustered persistence:
You have two appservers. One dies. You fail over, the app server has no idea who you are. Log in again. What state was your transaction in again? Did you buy that widget or not?
2. w/ clustered persistence:
You have two app servers, replicating session between the two. App1 fails. App2 knows about your session, picks up where the other left off.