Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Java Programming

JBoss Founder Interview 223

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 discussion has been archived. No new comments can be posted.

JBoss Founder Interview

Comments Filter:
  • I'm not really following JAVA as I'm more interested in "traditional" programming languages - but this sounds interesting? What's a Java application server? And it has clustering? So it's some kind of physical server computer running Java apps?
    • 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
      • by iapetus ( 24050 ) on Thursday November 29, 2001 @03:58PM (#2632744) Homepage
        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).
        • 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. :)
          • True - I was oversimplifying horribly there. :) Just trying to separate the functionality in JBoss proper (EJB, but also, as you point out, JNDI, JMS, and other related services) from the Servlet/JSP functionality provided by external apps (Jetty/Tomcat) which are required for a full J2EE solution.
      • by igbrown ( 79452 ) <spam@hcc p . o rg> on Thursday November 29, 2001 @03:59PM (#2632749) Homepage Journal
        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.
        • I believe it's actually the same plugin for the IBM HTTP Server and Apache - the differences between them don't affect the interaction with WAS. There are also plug-ins for a range of other servers, including IIS, Netscape Enterprise Server, Domino, and Domino Go Webserver.
  • by Count ( 107594 )
    "..picking up steam"

    ..Yeah It is also a real boost for the Open Source movemnet. This project has been brewing and is sure to mug the competition.

    heheh
  • Tomcat (Score:3, Interesting)

    by RazzleFrog ( 537054 ) on Thursday November 29, 2001 @03:40PM (#2632614)
    How does this compare with Apache's Tomcat (Jakarta) project?
    • Re:Tomcat (Score:3, Informative)

      by Zach Garner ( 74342 )
      Tomcat is only a basic application server (if it can be considered one at all) and does not support J2EE.
      • Re:Tomcat (Score:2, Insightful)

        by snoopdave ( 21953 )
        Actually, Tomcat is a J2EE compliant "Web Container" so it must support Servlets and JSP, but it does not have to support EJB, JNDI, JMS, etc. etc.
        • Re:Tomcat (Score:2, Informative)

          by GrayArea ( 69302 )
          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.
    • Tomcat is for Servlets, not a J2EE app server.
    • Re:Tomcat (Score:2, Informative)

      by felipeal ( 177452 )
      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...
    • Actually JBOSS includes Tomcat within it's framework for serving up Java Servlets, JSP's, etc. Tomcat is purely a server for Web Applications where as JBOSS does EJB's, and a whole slew of other things.
    • Thanks for the great posts. I've just started working with JSP/Servlets so Tomcat is what I've been using.
      • Cool. So once you've built your first web application and discovered the headaches of implementing your own persistence, transactions, messaging etc. you'll be able to understand the value JBoss brings to the table :).
  • To Watch? (Score:4, Interesting)

    by md17 ( 68506 ) <james@@@jamesward...org> on Thursday November 29, 2001 @03:42PM (#2632631) Homepage
    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.
  • I think this is a great project. We use Websphere where I work, and that product is cool to work with. The bigest problem is the price. I just hope they can get the program to be as good/BETTER then the expensive ones.

    "Things like Dynamic proxies with compilation-less deployment have made us the darling of serious development shops"

    Already showing it does stuff Websphere can not. How SWEET!!
  • by imrdkl ( 302224 ) on Thursday November 29, 2001 @03:53PM (#2632702) Homepage Journal
    This sounds pretty nice. We've already sold our souls to BEA, but having used Resin and Tomcat for production deployment before BEA, we are not afraid to try something new. BEA is still not doing for us what we expected, especially in it's loadbalancing and proxying capabilities. The Apache integration for BEA requires a new vhost for every single cluster, and the "load balancing" is simple round-robin. It sounds like this JBoss has that beat already.

    An apache integration is important for us, however, since apache is our frontline proxy. Anyone know if JBoss has an apache module yet?

    • 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
    • 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 :)
  • Performance? (Score:3, Interesting)

    by betis70 ( 525817 ) on Thursday November 29, 2001 @03:54PM (#2632713) Homepage
    I have heard a number of negative things about JBoss's performance [jboss.org] under heavy loads [onjava.com]. Anyone with experience using it care to comment? It seems like the clustering would really help such situations, and I am excited to see it advancing as well as it is. ..
    • Re:Performance? (Score:4, Informative)

      by Fnkmaster ( 89084 ) on Thursday November 29, 2001 @04:15PM (#2632864)
      I believe what you are referring to is Servlet performance. If you are using an embedded servlet engine in production for a high volume site and servlet processing seems to be partially responsible for the performance problems, then I would recommend using embedded Jetty rather than Tomcat (I see in Rickard's post that he can't, but that's his problem, and not a usual one).


      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.

    • Re:Performance? (Score:3, Informative)

      by waveclaw ( 43274 )
      During a two semester introductory course in software engineering I participated in a group that refractored a J2EE application (improved underlying code yet left it bug-for-bug compatible) and then completely reimplementation another J2EE application concept. Throughout both experiences, the rich support of architectures and patterns, on which JBoss (and Tomcat) are designed, made the projects simpler and more effective at achieving the goals of writing maintainable code.

      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 [tcsh.org], ant [apache.org], Java [sun.com]) does have a complex environment to setup and maintain. A large part of this however (much like with tcshrc [sourceforge.net] 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.

  • by FortKnox ( 169099 ) on Thursday November 29, 2001 @03:55PM (#2632718) Homepage Journal
    ...JBoss article.... must... plug... Jakarta Project [apache.org].
    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?
    • Do notice though, that many of the "analysts" measure the market by direct license revenue

      Independent research by Gartner Dataquest shows that BEA holds 41% of the new direct license revenue in the application server software market in 2000, a figure that is 10 share points higher than its closest competitor.

      The Gartner market analysis revealed the following market share results: BEA - 41% IBM - 31% iPlanet - 13% Oracle - 4% HP Bluestone - 4%

      JBoss does not show up here because the server code itself does not generate any revenues.

    • 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.
      • Weblogic and Websphere have one thing that JBoss will never get directly - a corporation that backs the product and promptly deals with support. And what is what you pay for.

        um, i've had the "pleasure" to deal with IBM WebSphere support in Europe. The guy on the phone said: you'll get the answer within 4 working days, we have to contact the guys in the US for this particular problem. i solved it 2 hours later by myself ... and it wasn't a problem with the support contract, I called with our customers support number and he has about 60 AS/400 boxen and various AIX machines sprinkled in between.


    • "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?"

      Hmm... makes one think, eh? As a developer, I've seen a lot of "certification wars" in the corporate contracting world. Here's my take.

      The problem with "level-ified" certifications kinda resembles the "megahertz myth [to quote Apple]" issue. If you're assuming the client is a techno-yokel, you run into this problem with such cert programs.

      Imagine, for example, two imaginary Linux certification programs. The first program (call it "EZLinux") sets out their certification map as follows:

      • Level 1: Ability to use rm, ls, cp, and mv commands.
      • Level 2: Understanding how to use RPM and DEB packages to update and modify a system.
      • Level 3: Ability to use fdisk to create and manipulate partitions.
      • Level 4: Actually got Mandrake running with help from the friendly neighbor kidz.
      Okay, so that's an example of a *terribly* useless "certification" program that wouldn't be worth the paper the cert was printed on. Let's look at the other ficticious program, called "UR-Uber-H4x0r Linux":

      • Level 1: Ability to quote verbatim the man pages for all Mandrake 8 standard linux commands (doesn't necessarily require deep understanding, just inhuman memory).
      • Level 2: In-depth knowledge of kernel configuration and compilation, demonstrated by ability to correctly by hand [no Xconfig for you, for added flavor] compile a 2.4.x kernel for every known supported platform in existence.
      • Level 3: Linux Torvalds willingly calls you Daddy, and calls you up for kernel hacking advice. Alan Cox routinely shows up at your pad asking for tree contributions.
      Now, if you were Joe Hiring Manager, you might not actually know the difference between the two programs. Joe might look at them both, and say "wow, that first one has an extra level, so it's gotta be better!" ...

      Companies will always try to use these tactics to make their products/programs/certs seem better than the others out there. Now, here's the real kicker: if Joe Hiring Manager actually understands why a certain cert is better than the others, he also (in all probability) understands why the product the cert is for is better. Hence, the better product wins. The key is education.

      Just my take, that's all :).

      Web hosting by geeks, for geeks. Starting at $4 USD per month. [trilucid.com]
      If you're gonna email, use the public key!
  • Project Info Page (Score:1, Redundant)

    by Foresto ( 127767 )
    Jboss web site [jboss.org]
  • by Gollo ( 415077 ) on Thursday November 29, 2001 @03:58PM (#2632741)
    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.
    • by Anonymous Coward
      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).
    • by DarylBeattie ( 540029 ) on Thursday November 29, 2001 @04:38PM (#2633048) Homepage
      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.
    • 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???
      • I seriously doubt that, unless IBM is astoundingly stupid, that they will advocate JBoss unless and until WebSphere (you know, that thing their banner ads on slashdot are always talking about, their $$$$$$$$$ java thingie) is not being sold anymore. IBM doesn't make any bucks off of AIX really (compared to the bucks they make on the hw anyway; c.f. solaris and sun), so they have no problems "replacing" it with Linux. Now, I can very much see Sun doing this, as they already support Tomcat as the official reference implementation of Servlet API foo and JSP API bar, and further they don't sell a java app server product that I'm aware of (if they do have one they're not exactly trumpeting it). [If sun started pushing JBoss with Tomcat, I imagine it wouldn't be much of a leap to advocate PostgreSQL as part of that solution. Yes, I am a hopelessly rabid Pg fan. ;-)]

        IBM is a hardware and consulting company with occasional delusions of being a sw company, so sometimes they will have incentives to push open source and sometimes they will not (e.g. notice that they don't support any open source database projects, hmmm, db2?). Sun OTOH is much more of a pure-play hw company (which is why their stock is pretty hammered right now IMHO), so they have a greater incentive to push open source software.
  • by tswinzig ( 210999 ) on Thursday November 29, 2001 @03:59PM (#2632752) Journal
    was working at SUN on Java since the early days, mostly as an evangelist in the beginning.

    After reading his responses, you can really tell he had a job as an evangelist. For you Quake/id fans out there, it's like Paul Steed started coding in Java!
  • hmmmm (Score:2, Funny)

    by Anonymous Coward
    Damn.

    I guess I must live under a rock. I thought JBoss was some "urban" clothing conglomerate, formed when J. Crew and Hugo Boss merged to oust Tommy in the Phat Ghetto Style Stankfinga razmadaza hootchie combo platta market.

    Y'knowumsay'n? Yomesain?
  • by adamy ( 78406 ) on Thursday November 29, 2001 @04:03PM (#2632776) Homepage Journal
    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.
    • You missed a layer (Score:3, Insightful)

      by sab39 ( 10510 )
      You missed the most important layer, and I'm betting that that's because that layer actually isn't open source.

      Are you running this on Kaffe? gcj? ORP? Kissme?

      Didn't think so. (If you actually are, I'm dead impressed - please let me know how you managed it)

      You're using Sun's J2SDK. Which isn't open source.

      I'll be very happy when it really is possible to put together an open source J2EE stack. But that day isn't today, because the VM/classlib layer has no open source alternative that's up to running these enterprise-level apps.
    • Wow. Where do I apply :). In fairnass though it's nice to see that OSS stuff is already reaching the point where you can put together a very decent enterprise app purely out of OSS components. I betcha the performance is ten times better than if you went with a hog like WebSphere.

      Good Stuff.

    • Try JBoss+Jetty in place of JBoss+Tomcat running through Apache. Unless your application is a very simple one, you'll get a 2-4x increase in performance under load.

      Tomcat is nice, in theory, but its dog slow.
  • by peterdaly ( 123554 ) <{petedaly} {at} {ix.netcom.com}> on Thursday November 29, 2001 @04:04PM (#2632782)
    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
  • My JBoss experiences (Score:4, Interesting)

    by pHalec ( 31694 ) on Thursday November 29, 2001 @04:04PM (#2632784) Homepage
    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.
  • Not whoring but... (Score:5, Informative)

    by Fnkmaster ( 89084 ) on Thursday November 29, 2001 @04:04PM (#2632787)
    First, it seems like a lot of posters don't know what an "Application Server" in Java parlance is. JBoss and the other mentioned products in the post are really implementations of the J2EE or Java 2 Enterprise Edition API set, as specified by Sun. This is not in any way opposed to J2SE (Standard Edition), which is the baseline Java SDK (VM + API library), but is an addition to that - it includes the EJB (Enterprise Java Bean) API for writing transactionally aware business logic components and connecting them to persistent data sources (usually RDBMSen of various sorts). I'm mixed on EJB, having built several large systems with it - it's just too damned easy to make applications that suck with EJB if you don't know how to use it. The CORBA CCM spec seems a bit better, with some kinds of components that I consider very useful that EJB doesn't support. Oh well. J2EE also envelops JNDI, a very useful and underutilized naming and directory API that solves lots of VERY common problems in building enterprise apps (the old chicken-and-egg resource location/distributed configuration problem can be solved very easily with JNDI though few people correctly use it). JMS is a decent enterprise messaging API, essentially an API for reliable asynchronous communication between distributed components either within or between enterprises that abstracts the details of writing socket level communications, then worrying about bridging firewalls etc. from the application developer. But it has some serious flaws in the way it forces you to do things. Nevertheless people have addressed these in not-fully-compliant add-ons to the spec to make it more like successful, established products such as TIB Rendezvous. (there are other parts of the J2EE spec, like JMX and the Servlet API, and probably a few others I'm forgetting right now).


    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. :)

    • by RelliK ( 4466 ) on Thursday November 29, 2001 @06:45PM (#2633612)
      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?
      • 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.
        • OK, so is app-server load balancing a substitute for IP-level load balancing or is it supposed to be used in conjunction? (i.e. something like balancing the web servers with a IP-level load balancer and replicating the application state with app server load balancing?)
  • Another server (Score:5, Informative)

    by Xunker ( 6905 ) on Thursday November 29, 2001 @04:05PM (#2632799) Homepage Journal
    Another server that is used in the Java arena is the Orion Server [orionserver.com]. 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).
    • Orion is a fabulous product - its weakness used to be terrible documentation (the last time I did a thorough J2EE server overview). I mean, really weak. I couldn't figure out how to do even relatively basic stuff - a lot of their documentation appeared to be written by non-native english speakers. Some of this applies to JBoss too, but JBoss has enough documentation to get you "close enough" for most things you need to do, and when that isn't enough it's got a great community, user forums, old mailing list archives, etc. which have proven very useful to me for cases where the obvious stuff didn't work and the documentation was poor or out of date.
    • The Orion server is so nice that Oracle bought it and now sells it as their J2EE server.
    • It should be noted that the Orion Server has been licensed by Oracle as the main J2EE component of their 9i Application Server, and does a great job in both performance and fault-tolerance.
  • The number of downloads means little here. I bet that many of those downloads were people looking to evaluate the various J2EE app servers. I know from experience that the vendors like BEA and Oracle do make free trial licenses available for people in the process of picking their app server.

    The interview points to a survey among the sales of various J2EE app servers, and correctly points out that JBoss has no sales to contribute, making the survey be the data among commercial app servers.

    clearly the best way to find the JBoss market share is to survey those who use J2EE, not just the companies that make them.
    • The number of downloads means little here.

      Dude, you are out of your element here. 70,000 downloads per month means little? Or you mean, this is happening because there is one single dialup user who keeps retrying the download because his 56k modem has a baud fart? Yeah... right.

  • Real Use (Score:4, Informative)

    by peterdaly ( 123554 ) <{petedaly} {at} {ix.netcom.com}> on Thursday November 29, 2001 @04:19PM (#2632889)
    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
  • Christ's sake... (Score:1, Flamebait)

    by Tom7 ( 102298 )
    Can anybody actually read more than a paragraph of that shit without their eyes glazing over?

    I can read scholarly papers about programming languages in all their greek letter glory, but this is just too much. It's all enterprise-this and acronym-that and just terrible to understand. Maybe I should have gone to business school? ;)
    • I agree. It seems like being a Java developer requires not only knowledge of the language but knowing about 10,000 extra acronymns also.
      • by jilles ( 20976 )
        That applies to most languages. Just understanding the syntax is about an hour or so of work for most programmers (shorter if they are experienced, longer if they haven't seen a real language yet).

        However, whether you are dealing with the STL, MFC or the Java API, it takes time to get productive with that. The Java API is simply huge and covers an enormous amount of functionality that you don't have to invent yourself. Luckily, there is JavaDoc that helps to browse through APIs. In addition, most APIs are well designed and have been through extensive review processess (unlike the crap Microsoft pours out over you) so if you know your design patterns, you won't have trouble understanding how everything fits together.

        If other languages appear to be simpler, maybe that is because they don't include so much functionality and require you to do more work reinventing the wheel.
  • by JamesOfTheDesert ( 188356 ) on Thursday November 29, 2001 @04:41PM (#2633062) Journal
    I'm all for people feeling good about their work, but Mr. Fleury is a bit bombastic abut his product. Makes it kind of hard to really believe what he's saying (and oddly similar to MSFT sales pitches).

    If he really is planning on something called JBoss.net, I think he'll find that 1) people expect it to run MSFT .net code, and 2) MSFT will expres an unpleasant interest.

    And just what are "socialist marginal characters"? Are they for or against "WebOS" monopolies?

    And why is SUN in all caps? Is that to remind people that it was started from publicly-funded research (Stanford University Network )?

  • I suspect that most people writing web services in Java can get by very nicely just using Apache Tomcat to provice servlet and JSP support.

    That said, the EJB component model is cool, and getting the Tomcat/JBoss bundle is a great way to get started with servlets/JSPs/EJBs.

    To add 'icing on the cake', add the Apache SOAP servlet (or the newer Apache Axis servlet) and also get SOAP support for interop with other systems.

    - Mark

    PS. I live in the mountains in Northern Arizona, and it is snowing. Cool :-)

  • by under_score ( 65824 ) <mishkin@be[ ]ig.com ['rte' in gap]> on Thursday November 29, 2001 @05:24PM (#2633136) Homepage
    This isn't a big deal, but I've been very wary of J2EE app servers. I've been working with server-side Java for about 4 years now, and previously with EOF (Nextstep/Webobjects). EJB is incredibly broken compared to EOF/WebObjects. But my online educational system Oomind [oomind.com] is running on Tomcat right now, and needs a more complete platform. So we are moving. And after some careful analysis and real world experience, we're choosing JBoss. Frankly, it being open-source is a very significant factor. Kudos to JBoss and its developers!
  • One of the huge drawbacks of the current JBoss package is the lack of the ability to distribute your beans across multiple phisical hosts. That makes JBoss applicable to only small production environments. I wonder if this is something that 3.0 is planning to address... If not then JBoss will not be able to compete in the same space as WebSphere and WebLogic.
  • Odds are the product with the greatest market penetration will always have the greatest stability.

    (From the last paragraph of question 3.)

    Microsoft would be the exception that proves the rule?

    I tried to resist saying that, really I did...

  • by jeet_means_win ( 530980 ) on Thursday November 29, 2001 @08:11PM (#2633998)
    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
  • Overly optomistic? (Score:2, Insightful)

    by gss ( 86275 )
    While I am a big fan of JBoss (ever since EJBoss), it does have a long way to go to gain market share in the industry. People who make the decisions would rather put their neck on the line for big companies like BEA or IBM, be it right or wrong. Does this guy really think that BEA and IBM aren't working on their next versions as well? It's a tough market, I just hope JBoss doesn't get too confident.
  • Some questions from a guy who has played around with Jakarta a lot, but never quite used it at work:

    Are there people who are using Jakarta/Tomcat for high-volume sites? I use Tomcat for development all the time (primarily because I can use it on some really low end hardware). But in production use, it's always been a different story.

    I mean, I can point to /. when people say MySQL cannot handle loads -- would any of you know a similar highly-trafficked, prominent site that runs Jakarta software?

    For that matter, how 'bout the same question applied to JBoss? or are they used quietly in departmental intranets, anonymous because they didn't require a big-ticket purchase order to acquire?

    I want to know if you consider Jakarta/JBoss ready from 'prime-time' in the same way (say) Websphere is.

"Protozoa are small, and bacteria are small, but viruses are smaller than the both put together."

Working...