JBoss Application Server 4 gets J2EE-certified

Discussions

News: JBoss Application Server 4 gets J2EE-certified

  1. It was big news when JBoss announced that they were going to certify their application server. It takes a lot of work (and not necessarily fun work at that!) to pass the Compatibility Test Suite for J2EE, but it looks like JBoss has done it. We are told that they will announce the certification on Monday 19th 2004.

    JBoss claims they are the first open source application server to go through the certification process, with ObjectWeb in the process with JOnAS. Apache Geronimo is also being written in a way to cover certification not only with J2EE, but to pass the many JSR TCKs. Both hope to be certified by the end of the year.

    Bob Bickel also talked about how JBoss is looking to expand into integration and business process automation software, potentially through acquisitions.

    Read more in JBoss Application Server gets J2EE-certified

    Updated News

    JBoss App Server Passes J2EE Muster

    J2EE 1.4 OKs Open Source App Server

    Press Release: JBoss Becomes First Open Source Application Server to Achieve J2EE 1.4 Compatibility Certification

    JBoss airs expansion plans

    What do you think: Is the certification worth it? How will it help the cause of JBoss?

    Threaded Messages (59)

  2. Congratulations[ Go to top ]

    Congratulations to JBoss from the Apache Geronimo project for completing certification!

    The Geronimo Team
  3. Congratulations[ Go to top ]

    Congratulations to JBoss from the Apache Geronimo project for completing certification! The Geronimo Team
    Great that the JBoss people finally seem to have done it!

    Furthermore, there is a saying in Germany that competition stimulates business, which thus has been proved to be true again, as I think without Geronimo's competition JBoss would not have made the effort.

    Three cheers for JBoss,
    Lars
  4. Congratulations[ Go to top ]

    as I think without Geronimo's competition JBoss would not have made the effort. Three cheers for JBoss,Lars
    I think JOnAS is a much more "dangerous" competitor for the moment than Geronimo
  5. Congratulations[ Go to top ]

    I think JOnAS is a much more "dangerous" competitor for the moment than Geronimo
    Even though that might be technically correct, for many years JOnAS' competition did not exert enough pressure to induce JBoss to get certified.

    Is JOnAS certified, by the way?

    Cheers,
    Lars
  6. Congratulations[ Go to top ]

    Even though that might be technically correct, for many years JOnAS' competition did not exert enough pressure to induce JBoss to get certified.
    Right.. but they are just a good competitor who lacks of visibility.. they are just behind
    Is JOnAS certified, by the way?
    The certification is under work.. they plan to be certified before the end of the year.
  7. Congratulations[ Go to top ]

    Congratulations to JBoss,

    Great we can make more dev. with a certified J2EE Application Server;

    cooooool
  8. It helps Sun to strengthen the J2EE brand.

    It helps JBoss to extend their reach to markets that's sensitive to certification.

    It helps J2EE application developers to have an certified open source J2EE implementation.

    It could feul the growth of the J2EE market, which should be good news for all existing J2EE certified vendors. Sure they will feel a price pressure, but that's what they are in the market for, right?

    It would create opportunities for ISVs in delivering J2EE based products in the market at a price that's reasonable for smaller sized customers.

    "J2EE is too expensive" won't be an excuse to not use J2EE any more.

    "J2EE is too complicated" won't be an excuse to not use J2EE any more because of the modular nature of JBoss's class app servers. Don't like Entity Beans? Simply delete the whole module from the app server!
  9. Just some thoughts:
    ...It helps J2EE application developers to have an certified open source J2EE implementation.
    It is correct that JBoss is open source from a licensing point of view. In the spirit, I don't think that JBoss is a real open source effort like ObjectWeb JOnAS or Apache Geronimo. The fact that JBoss had to pay for the certification has certainly something to do with it.
    "J2EE is too expensive" won't be an excuse to not use J2EE any more.
    If you consider TCO (Total Cost of Ownership), do you really think that the application server license really makes a difference?

    I completely agree with your statement that
    It helps JBoss to extend their reach to markets that's sensitive to certification.
    . I am just wondering how big is that market and how many people do really care about certification (especially among smaller sized customers)?

    All comments are welcome.
    Emmanuel
  10. If you consider TCO (Total Cost of Ownership), do you really think that the application server license really makes a difference?
    .

    Depends. Large scale deployments (1000+ machines) will surely benefit from
    cheaper AS. A customer of mine targets a 8500 (max !) deployment of a
    (quite-small) J2EE application.
    I am just wondering how big is that market and how many people do really care about certification (especially among smaller sized customers)?
    .

    Lot of customers blindly choose Tomcat because 1)This is a de facto standard
    and 2) they are not keen/ready using advanced features like EJB or JMS. With
    the advent of architectures highly leveraging AS like ESB & SOA, the certification is bound to open new doors by easing management decisions.

     
    All comments are welcome.Emmanuel
    As well !

    Bruno.
  11. 1000+ machines[ Go to top ]

    ...Large scale deployments (1000+ machines) will surely benefit fromcheaper AS. A customer of mine targets a 8500 (max !) deployment of a (quite-small) J2EE application.
    1000+ machines, 8500 server deployment? Are you serious? Has anyone else ever seen a deployment to so many servers?
  12. 1000+ machines[ Go to top ]

    1000+ machines, 8500 server deployment? Are you serious? Has anyone else ever seen a deployment to so many servers?
    Do you mean in a single farm / cluster? There are a small number of apps I've seen in that configuration, but they weren't web apps.

    However, the original poster might have been talking about deploying an app to many independent servers, such as to a number of departmental servers within an organization, or selling OEM software and including an app server that it runs on. In either case, not paying for an app server (e.g. using Tomcat / Jetty / JBoss / Jonas / Geronimo) could save a lot of money, as long as the free app server meets the requirements. OTOH, all the app server vendors cut pretty sweet deals for OEM usage, as long as you tell them you're going to use JBoss otherwise ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  13. 1000+ machines[ Go to top ]

    1000+ machines, 8500 server deployment? Are you serious? Has anyone else ever seen a deployment to so many servers?
    Do you mean in a single farm / cluster? There are a small number of apps I've seen in that configuration, but they weren't web apps.However, the original poster might have been talking about deploying an app to many independent servers, such as to a number of departmental servers within an organization, or selling OEM software and including an app server that it runs on.
    That's the point indeed. This is a webapp that may be deployed in every department of a huge, public area.

    These deployments are not so scare : I know a couple of other web applications where deployment could either be on a local workstation (for instance laptops, running in standalone mode) or in a centralized location. Same application, same L&F, and in these cases number of licences matters.
  14. 1000+ machines[ Go to top ]

    Yep,
    There are websphere customers running apps on 1000s of machines, same app. Interesting from a scaling point of view...

    Billy
  15. ebay ...[ Go to top ]

    case in the point ..eBay!!!
  16. I don't think that JBoss is a real open source effort like ObjectWeb JOnAS or Apache Geronimo. The fact that JBoss had to pay for the certification has certainly something to do with it.
    I disagree. I believe JBoss to be very much a true Open Source development effort. The fact that JBoss Group is a for-profit company doesn't take away from that. JBoss (the project) is a community-based development effort.

    Cheers
    Ray
  17. JBoss (the project) is a community-based development effort.
    I didn't check recently the contributor list of JBoss. How many contributors does JBoss have and among them, how many are not hired by JBoss Inc?

    Any pointer to public info about this is welcome.
    Emmanuel
  18. I didn't check recently the contributor list of JBoss. How many contributors does JBoss have and among them, how many are not hired by JBoss Inc?
    I don't know - but I do know that it is possible for me to become a contributer and I know I don't work for JBoss Group.
  19. Is JBoss truly open source?[ Go to top ]

    Emannuel wrote:
    JBoss (the project) is a community-based development effort.
    I didn't check recently the contributor list of JBoss. How many contributors does JBoss have and among them, how many are not hired by JBoss Inc?Any pointer to public info about this is welcome.Emmanuel
    Recently Emannuel tried to paint JBoss as truly not an open source project and asked about the number of JBoss contributors. Here's the list:

    http://sourceforge.net/project/memberlist.php?group_id=22866

    Not all CVS committers on project are Jboss employees(see above). All developers at JBoss Inc. were once JBoss contributors before we hired them. We have probably added 5-10 new contributors over the past 6 months who do not work (yet) at JBoss. As we continue to grow, we will obviously recruit first from our CVS committer list.

    There are multiple ways of getting involved with the JBoss app server project, or any of JBoss.org's other projects (Hibernate, JGroups, Mail, AOP, Javassist, Nukes, Tomcat). Find JBoss's roadmap on our website, fix bugs, speak up on our development forums, add a new feature, contact us, if you're code is good, we give you CVS access. You retain your copyright on your code, but you must license your code under LGPL.

    Bill
  20. I use open source EJBs with custom code, and JBoss, and have had a hard time selling, since JBoss isn't really J2EE, and for a software system that runs only in the hundreds of dollars for a license (maybe a few thousands for full deployment and service package), being able to package a certified J2EE server for very little extra cost will be a great boon.
  21. Don't muck with an operating system[ Go to top ]

    Don't like Entity Beans? Simply delete the whole module from the app server!
    If you don't want to use entity beans in a given app, then don't use them in this app. To delete them from your server, you're saying "They are never a valid design choice", which is, I think, false.

    Containers are complex, and some features depend on other features. Perhaps it is safe to disable entity beans in a particular server. Perhaps not. I don't know. Unless you have the CTS and can run it against the modified server, neither do you.

    I blogged some more on this.
  22. Don't like Entity Beans? Simply delete the whole module from the app server!
    If you don't want to use entity beans in a given app, then don't use them in this app. To delete them from your server, you're saying "They are never a valid design choice", which is, I think, false.Containers are complex, and some features depend on other features. Perhaps it is safe to disable entity beans in a particular server. Perhaps not. I don't know. Unless you have the CTS and can run it against the modified server, neither do you.I blogged some more on this.
    Read the blog but I think you are maybe missing the advantage of pluggable modules. To be fair, I haven't had much experience with JBoss yet - I'm a consultant and usually the decision on app server has been made and paid for before I show up. Although I would suggest looking into it as a cost-effective solution.

    I like the idea of an app-server as not one monolithic piece of software, but a backbone that allows you to snap-in the components you want and leave out those you don't need. Why?

    Ease of maintenance: the less knobs to turn and gears to watch, the easier it is to tune and maintain the app.
    Ease of deployment: Less things to bump into and contradict each other.
    Smaller footprint: Why load stuff into memory that will never get used for a given app.
    Security: Along with maintenance, the smaller number of gizmos running means less possible places for security holes.
    Upgrades: I don't know if Jboss does this, but it seems that each module could be developed and maintained separately. Maybe even variants of the same type of module would exist so that a developer could have a choice.

    I think the point of JBoss would be that if a new app came along at a given site that needed, for example, say JMS. You'd plug in the JMS module at that point.
  23. I like the idea of an app-server as not one monolithic piece of software, but a backbone that allows you to snap-in the components you want and leave out those you don't need. Why? Ease of maintenance: the less knobs to turn and gears to watch, the easier it is to tune and maintain the app. Ease of deployment: Less things to bump into and contradict each other. Smaller footprint: Why load stuff into memory that will never get used for a given app.Security: Along with maintenance, the smaller number of gizmos running means less possible places for security holes. Upgrades: I don't know if Jboss does this, but it seems that each module could be developed and maintained separately. Maybe even variants of the same type of module would exist so that a developer could have a choice. I think the point of JBoss would be that if a new app came along at a given site that needed, for example, say JMS. You'd plug in the JMS module at that point.
    Sure, a modular container is goodness to allow modules to be developed independently etc. Absolutely agree. This is a great development process. But I think swapping them in and out, as a process that can lead to change sin behaviour, needs to be supported by testing / validation / etc. One of the benefits of working on top of an existing product is that one doesn't have to reinvent (which includes testing and validation!) that part of the problem.

    Having developed (and benefited from developing) the system in modules, does the user need to turn them on and off? Or start inserting different versions? How will the apps cope with changing sematics across different versions of a module? Without a bunch of new development and testing and soaking etc?

    Less to watch, ok, I get that too. Along with less to load. But this is a statement about bad UI design. Whether EJB is 'loaded' or not, if you don't have any beans in your app then you shouldn't be presented with status / config / whatever for beans. Similarly for other features. To say nothing of why a container would load a module before the app depended on it,

    Less things to bump into / contradict each other, I think I disagree. Systems evolve. So you delete the FooBar module today because you don't immediately need it. You write a bunch of code (some of which may conflict in some way with that now unloaded module), do a bunch of testing, deploy your app. 3 or 5 or 15 years from now someone else adds FooBar behaviour and re-enables that component, and all bets are off as to whether old stuff, or stuff developed in the meantime, continues to behave the way you have come to know and love (or at least expect) over the past however many years.

    It is like the story told of the Space Shuttle onboard systems, with some 300,000 known bugs that they're not going to fix because they *know* them. Start making changes, you might have fewer bugs, but they'll be unknown. (the story might not be true, but it is a great illustration).

    Software systems are discrete (and unstable in the mathematical sense) functions - seemingly small changes in input can lead to large changes in output. Don't give up validation and experience with a given code base / build to accomplish some (to me) minor short-term development goals or a desire to tweak. Software is a lifecycle asset, it isn't just about development.

    I wrote a bit more this morning on this.
  24. If the container isn't modular it is wrong architectured. If I can not swap my modules in and out it is wrong architectured.

    So if what you say is true Sun must redesign the EBJ container specification, that is much more important than any new EJB 3.0. What will happen in that case? Shall all the Java application vendors apply for new certification again? Shall they have to pay again?

    The whole sad story with EJB is not "too little too late" but "too much too early". Nothing should ever be put as a standard that has not proved its worth in real life against competition.

    Regards
    Rolf Tollerud
  25. A two-year old memo from HP executive Gary Campbell to other HP execs has been wending its way around the backrooms of the Internet this past weekend. One of the places it showed up was in the NewsForge submission bin. We held off publishing the memo until we verified its authenticity and gave HP a chance to respond.


    memo -- its full text is provided later in the story, along with HP's response -- briefly explains a patent cross-licensing deal between HP and Microsoft. By itself, that's not a big deal, especially since it was sent two years ago. But the memo asserts that "Microsoft will soon be launching a patent-based legal offensive against Linux and other free software projects." Leaders in the open source community have been warning of such attacks for some time. The memo reveals there may be very good reason for the worry.

    Read more:

    http://www.newsforge.com/article.pl?sid=04/07/19/2315200
  26. perhaps you can tell me?[ Go to top ]

    Ha ha. You are mistaken my friend. It is Sun that can not make products and therefore sue all the time to get money, not Microsoft.

    How many times has Microsoft initiated a patent infringement lawsuit?
    Were any of these those lawsuits instrumental in eliminating a competitor?

    So? Zero? Ok

    You can divide Java people in two camps. The EJB traditionalists with its quasy-scientific High-Priests and followers full of hyperbole and vehemence, and those new people around Spring and similar frameworks that port their systems to C#.

    Your remark shows clearly which category you belong to.

    Regards
    Rolf Tollerud
  27. perhaps you can tell me?[ Go to top ]

    ... and those new people around Spring and similar frameworks that port their systems to C#.Your remark shows clearly which category you belong to.RegardsRolf Tollerud
    Rolf ... you know what ? Shut the hell up. Nobody who ever used Spring will ever want to port their system to C#. You're talking nonsense. Spring is a reason to enjoy java(and even more. read aop and stuff) I can see a single reason for that (port to C#): Their client wants nothing else but a C# implementation.

    BTW, what the hell pissed you off so much in Jboss cert ? That Jboss will go even more mainstream ? That they are no more 'pirates' ?
  28. innovate instead[ Go to top ]

    Since you told me to shut up and that I am talking nonsense maybe I can be allowed to say that you appear confused?

    That Spring and Hibernate is ported to C# does not mean that the authors in anyway give up on their Java commitment. It is just a try to win more adherents for a good idea and make the customers happy- standard capitalism.

    To destroy Microsoft is more important for the monolithic Elephant-Server EJB lovers than their customers. If I am "pissed you" as you express it then it is because I hate to see the young be used to prolong the life of the old. Like termagants (if you read Jack Vance). The Elephant-Servers is going the way of the Dodo anyway- see Weblogic stock- so why not try to innovate instead.

    Regards
    Rolf Tollerud
  29. correction[ Go to top ]

    should be hormagaunt, my mistake.
  30. innovate instead[ Go to top ]

    The Elephant-Servers is going the way of the Dodo anyway- see Weblogic stock- so why not try to innovate instead.RegardsRolf Tollerud
    Weblogic's stock is not going the way of the Dodo simply because it's an EJB appserver. It is more to do with the fact that they have far more competition in that stack space. It's pretty hard to compete with free. Similiar how to Netscape fell by the wayside not because their browser was inferior to IE, but because it's not easy to compete with equivalent/better free products.

    Products like JBoss steal even more of their marketshare especially now that they are certified.
  31. they will never give up[ Go to top ]

    It is a theory. We see what happens when JBoss shall compete with Spring, Tapestry and Webwork. Now when JBoss is "only" a normal Sun J2EE monolith I am not in doubt of the outcome. An Elephant is still an Elephant, even if it’s free. The license is only one small part of the cost to set up shop with an EJB server, if it survives the 70% project failure rate according to Gartner, it will be down medium 6-7 hour a week and the performance will be less than on a vanilla Tomcat installation. Not what I call customer friendly.

    They are persistent though. The EJB advocates will never give up and admit they are wrong because for them it is a way of life, what makes them tick. Take away the Big J2EE server and they will have nothing to live for.

    So prepare to listen to EJB 3,4,5,6 etc talk forever. :)

    Regards
    Rolf Tollerud
  32. Spring, Tapestry, Webwork[ Go to top ]

    Rolf wrote:
    It is a theory. We see what happens when JBoss shall compete with Spring, Tapestry and Webwork.
    Rolf, you are just showing how ignorant you are. JBoss does not compete with Spring, Tapestry, or Webwork. These techonologies compliment the JBoss stack rather than compete with it. JBoss, the app server, doesn't even ship with an MVC framework. Until Spring writes a persistence engine (Hibernate or CMP), a messaging system (JMS), a transaction manager, GUI management, a security API(JAAS), clustering services (JGroups, HTTP Session replication), clustered caching (JBoss Cache), and a servlet container/JSP/HTTP server(Tomcat, yes we fund a lot of Tomcat development), they will not be a competitor.

    Let's get this straight, Spring is an IoC container. They market themselves as almost a kernel. Notice how when people compare Spring to EJB they say, "Spring, Hibernate, and Tomcat". They don't say spring alone. Spring desires to be a kernel much in the same way JBoss's JMX microkernel already is.
    Now when JBoss is "only" a normal Sun J2EE monolith I am not in doubt of the outcome. An Elephant is still an Elephant, even if it’s free.
    This perception that J2EE is a monolith is wrong. J2EE is a set of services. In JBoss we've done our best so that you can mix and match these services and only use the stack you need. JBoss Inc. doesn't make more money if you use our EJB container. Doesn't make more money if you use our full clustering stack.
    The license is only one small part of the cost to set up shop with an EJB server
    EJB != J2EE. I think the EJB3 committee has recognized the failures in EJB and are working to address it. JBoss (and others) hope to have multiple, functional, working iterations of the next coming months.

    Bill
  33. Bill:
    Notice how when people compare Spring to EJB they say, "Spring, Hibernate, and Tomcat". They don't say spring alone.
    So?. All the other 380.000 members of TSS know that when Spring is mentioned, Tomcat or other equivalent web-container are implicit assumed. Now I also know. Thank you!

    Bill:
    Spring desires to be a kernel much in the same way JBoss's JMX microkernel already is.
    But Bill, JBoss does not work either without Tomcat (or Jetty). WhatÂ’s the difference?

    Dustin: "The JBoss appserver can be as lightweight as you want it."

    Ok, let me have 10 different JBoss sites and I put Alertsite on them! :)
    Pardon me if I quote myself, "Mendacious accounts of the Elephant EJB servers performance and scalability have flourished for years".

    We all know that the developers at JBoss wanted to go their own way "where no man has gone before". But Sun brought you back to heel! You should have stood your own.

    Today other winds blow.

    Regards
    Rolf Tollerud
  34. I am not sure about current certified version, but it was possible to run JBoss without webserver or to write pluggin for your favorite webserver/servlet container. Probably not all of JBoss services are better than alternatyves, EJB is not the best application framework, but JBoss server is well designed and it is very good. You can use your favorite services or application frameworks if you do not like some of stuff bundled with JBoss for some reason.
  35. Bill:
    Notice how when people compare Spring to EJB they say, "Spring, Hibernate, and Tomcat". They don't say spring alone.
    So?. All the other 380.000 members of TSS know that when Spring is mentioned, Tomcat or other equivalent web-container are implicit assumed. Now I also know. Thank you!
    I think you missed my point Rolf...Spring needs Tomcat, Hibernate, etc... to be a complete, usable, solution for web applications. I don't think the Spring zealots speak of themselves as THE solution itself, but rather as a component of the solution. It is a potential compliment to the services provided by JBoss , Weblogic, Websphere, rather than a replacement.
    Bill:
    Spring desires to be a kernel much in the same way JBoss's JMX microkernel already is.
    But Bill, JBoss does not work either without Tomcat (or Jetty).
    ???. Of course JBoss works without Tomcat. If you're not doing Web stuff, you don't need a servlet container. J2EE is much more than servlets, and JBoss.org has a bunch of OSS projects that provide services way beyond J2EE. And besides...JBoss Inc. partially funds Tomcat code development and provides professional services around Tomcat itself.

    Bill
  36. Bill:
    I think you missed my point Rolf...Spring needs Tomcat, Hibernate, etc... to be a complete, usable, solution for web applications.
    No, Spring does not need Hibernate. Hibernate works apparently exceptionally well with Spring but they have an JDBC abstraction level. Everyone has not fallen for O/R yet.

    Bill:
    "???. Of course JBoss works without Tomcat. If you're not doing Web stuff.."
    Again, so does Spring, all modules in Spring can be used without a webserver if you're not doing web stuff. In addition, most modules can be used even outside Spring! So you loose that one too.

    Bill, you can not trick the TSS members. They may be a vicious lot, but at least they have style, urbanity and discernment! :)

    Bill: J2EE is much more than servlets

    Yes, that is the reason for the title on the book: "J2EE Development without EJB".

    Regards
    Rolf Tollerud
  37. innovate instead[ Go to top ]

    The Elephant-Servers is going the way of the Dodo anyway- see Weblogic stock- so why not try to innovate instead.RegardsRolf Tollerud
    Weblogic's stock is not going the way of the Dodo simply because it's an EJB appserver. It is more to do with the fact that they have far more competition in that stack space. It's pretty hard to compete with free. Similiar how to Netscape fell by the wayside not because their browser was inferior to IE, but because it's not easy to compete with equivalent/better free products.Products like JBoss steal even more of their marketshare especially now that they are certified.
    Correct me if I'm wrong, but isn't Websphere causing the most damage to Weblogic's sales, followed by MS finally offering a viable alternative in .NET? I agree that JBoss has probably made some small inroads on WLS, especially in the case where licensing becomes cost prohibitive (like in Retail settings, where an app server is installed in each store in case connectivity is lost). But even then, like Cameron mentioned earlier, BEA and IBM reps will work with you on the cost. I would think from the conversations I've had on sales calls that Websphere is generating much more interest with the buyers.

    As far as the elephant app server discussion, while I 110% agree that if I had it my way I'd rarely touch a full blown J2EE server again, I don't agree that IT buyers share the same enthusiam for Spring/Hibernate that IT developers do. My experience has been that IT buyers take a CYA style on strategic decisions. Nobody ever got fired for buying IBM (or BEA or Gartner or Forrester). A CIO who decides to go with a full blown lightweight OS option is exposing themselves to quite a bit of risk. My guess is until we see Forrester or Gartner reports hailing the TCO benefits of lightweight approaches, you won't have a mass exodus from heavyweight containers as a strategic decision. (I'm not claiming that no IT buyer wants Tomcat, just that many established companies that are slow to respond to changing currents will stick with WLS, WS, and JBoss) I've personally used Spring/Hibernate on several projects, but it has always been inside of a heavyweight container, rather than Tomcat.
  38. innovate instead[ Go to top ]

    Correct me if I'm wrong, but isn't Websphere causing the most damage to Weblogic's sales, followed by MS finally offering a viable alternative in .NET? I agree that JBoss has probably made some small inroads on WLS, especially in the case where licensing becomes cost prohibitive (like in Retail settings, where an app server is installed in each store in case connectivity is lost).
    I don't think you are wrong about that at all. My intent was not to imply that JBoss is soley responsible for the demise of Weblogic. This is why I used the phrase "Products like JBoss". Notice the plural.

    Free is not just about saving money either. Having a free server also allows for a company to be very agile in terms of it's deployment strategies both internally and externally.

    Free also allows you to have an unlimited amount of time to test a vendor's implementation without having to hassle with their aggressive sales staff in order to get a demo period extended. Don't need to strike deals. Don't even have to communicate to a single person or give out your life history in order to try a product.

    In terms of the elephant app server. Cannot one draw the same conclusions about the .NET platform especially when coupled with a Windows server and all the baggage that intales? And if .NET is at this point in time is considered a lightweight container, what makes you think it will remain that way given Microsoft's history of feature bloat? What control do you or anyone else have on keeping it lightweight?

    Isn't it also fair to say that if something is called lightweight, that many times that really means it lacks features? So you then go out and find those lacking features you require to add your lightweight container. Rinse and repeat. Now all of sudden, your lightweight container isn't so light anymore and not so standard anymore.
  39. innovate instead[ Go to top ]

    Point taken on JBoss; I read your comparison of the app server state of affairs to the browser wars of old to imply that "free" alternatives to BEA were the primary threat.

    I didn't mean to imply that .NET is lightweight. And let me clarify what I mean by lightweight. I don't mean that spring or hibernate have less features than their EJB/J2EE counterparts. On the contrary, I would claim that they offer much richer functionality in most areas (HQL is much more extensible and useful than EJB QL IMO, Spring's AOP gives all of the power of CMT in EJB plus the ability to control behavior based on exception type, Spring's exception handling framework dwarfs anything I've seen from the EJB world, Spring's DI functionality is much more comprehensive than even EJB 3.0 looks to be, Spring's AOP is amazingly simple and flexible, etc.)

    I think hands down spring and hibernate are "heavyweight" in terms of functionality offered. By lightweight I tend to mean the requirements placed on you as the developer when you commit to using a given framework. So EJB is not lightweight, because I have to write 4 classes/interfaces and a complex deployment descriptor. Rather than focusing on business logic, my code focuses primarily on supporting the framework. I feel the same way (though not nearly as strongly) about Struts, so I would hesitate to call Struts a lightweight framework. With Spring or Hibernate, I can write my classes without regard for what framework/container they're being deployed into unless I want to take advantage of support classes that simplify the code. Ditto for exception handling. In EJB, I force RemoteException's into my interface, tying myself to my EJB implementation. I consider that sort of imposition on my code to be heavyweight. I don't agree with your claim that these two frameworks will necessarily become heavyweight in the sense that I have described, although I've never seen software that has avoided the entropy so common to popular languages/frameworks/applications, and in that sense, I suppose it may be inevitable that bloat will make its way into even Spring and Hibernate.

    It seems that both communities (Hibernate and Spring) focus fanatically on the transparency of the framework, which explains their rapid success. Can I say the same for .NET? Probably not, although I would say that .NET was a quantum leap forward in terms of simplifying the underlying framework (rather than hiding complexity behind an IDE) over the COM/DCOM/COM+ models. I hope MS continues down this path, and I must point out that whether MS does this or not, the world of dependency injection and "lightweight containers" has already been introduced to .NET through various open source projects. Unfortunately the J2EE app server vendors seem to favor the path of creating IDE's that mask the complexity of J2EE, and getting back to my original post, this approach seems to be heavily favored by IT buyers right now. So regardless of how much I myself (and anyone that I can convince to try these lightweight alternatives) prefer to leverage what I feel to be a superior alternative, I have to live with the reality that many of my customers are still brainwashed into thinking there is no alternative to EJB for doing transactions, remoting, clustering, persistence, multi-threading, or security.
  40. innovate instead[ Go to top ]

    Point taken on JBoss; I read your comparison of the app server state of affairs to the browser wars of old to imply that "free" alternatives to BEA were the primary threat.
    My point was more directed at Rolf's comment that seemed to suggest that the only reason Weblogic is failing is because they are an "elephant-server". That may be part of the case, but it certainly isn't all of it.
    So EJB is not lightweight, because I have to write 4 classes/interfaces and a complex deployment descriptor. Rather than focusing on business logic, my code focuses primarily on supporting the framework.
    Tools like XDoclet very effectively shield you from having to hand code these classes/interfaces and deployment descriptors.
    In EJB, I force RemoteException's into my interface, tying myself to my EJB implementation. I consider that sort of imposition on my code to be heavyweight.
    I don't really see the big deal with a dependency to RemoteException in the client. You end up tying your client to some Exception implementation, why not a industry standard one? You are also depending on the DI behaviour of Spring. Sure, your code doesn't depend on it explicity, but it certainly does implicitly in the fact that you are injecting new behaviour and depending on that behaviour for your business logic.
    Unfortunately the J2EE app server vendors seem to favor the path of creating IDE's that mask the complexity of J2EE, and getting back to my original post, this approach seems to be heavily favored by IT buyers right now.
    IDE's certainly are the trend these days, and for good reason. However, I see the industry working on the complexity issue from both the IDE side AND the specification side. EJB3.0, though not perfect (and will it ever be to everyone?), is certainly a step in the right direction in terms of masking that complexity.

    You do make very valid points about lightness of containers like Spring and I certainly wouldn't lose any sleep if J2EE were to fall off the planet tomorrow and was suddenly replaced by Spring. I know that may come as a shock to people like Rolf who think J2EE developers are all zealots who will just take their toys and go home if J2EE doesn't prevail.

    I think it has more to do with standards then anything else. Standards are important to not only those of us who author enterprise systems, but also to the management/companies we develop systems for. It is also less of a risk for companies to leverage products, especially open source ones, if they adhere to an industry wide standard.

    If the J2EE standard compliance wasn't important to the companies that JBoss (and whomever else) are targeting their product and services to, then I dare say JBoss, and whoever else ponies up the substantial amount of money and development time to become certified, wouldn't have done it.
  41. "Heavyweight" does not mean whatever it's user wants it to mean at the time (or at some point after) he said it. It has a specific meaning, in eglish, and in IT frameworks, specifically pertaining to performance, and in particular, memory consumption. A framework that forces users to tie their business objects with the framework's APIs or implementation is "tightly coupled" or "intrusive." But JBoss is, or was at one point, a "lightweight" appserver. Struts is not heavyweight, although it definitely does use more memory than is justified for it's meager functionality. A servlet container is almost always more lightweight than a full J2EE appserver, and JDBC is definitely more lightweight than Hibernate. Entity beans (taken alone) can sometimes be more lightweight than an O/R mapper like Hibernate, but a full J2EE server is probably going to be more heavyweight than Tomcat+Spring+Hibernate. If you have complex transaction logic or messaging, or need IPC, a full J2EE server may end up a more lightweight than your combination of several "lightweight" solutions.
  42. Aaron: "But JBoss is, or was at one point, a "lightweight" appserver"

    How sad. (the word "was")

    It is always useful to put yourself into the minds of people that are different from you. To understand we need to see things with their eyes, from their direction. I give it a try.

    "The Beautiful Dream"
    Pretend for a moment that it is was true that EJB servers are fast and reliable and scale better. And that this result was brought about by for the first time in history, using first-class theoreticians to solve the problem, schooled in OO computer-science, and with funding from real companies like Sun and IBM. That it is a difficult profession hard to learn, but once you master it you are more productive than in any other environment, with adherents that are serious and single minded, "impatient" with beginners and "vb programmers" because of their ignorance in OO and because they don't understand the proper scientific computer-talk, "the lingo", lovingly called.
    You see the dream? Beautiful isn't it? But not a single claim is true, unfortunately, for instance put "wellmeaning and impractical" instead of "first-class".

    "If I found evidence that Atlantis never existed I would destroy it, because it is such a wonderful saga". (Mary Shelley)

    But unlike the Atlantis myth which is harmless, the EJB saga is harmful to Java and to thousands of customers and companies.

    So why do I write this? Only so everybody can understand why this people not so easely will give up their haunting dream. And I am not happy about it either (aka Atlantis).
    But it has to be done.

    Regards
    Rolf Tollerud
  43. P.S.[ Go to top ]

    That the Microsoft Windows Server 2003 Enterprise Edition 64-bit with Itanium that in a couple of years everyone will have a equivalent copy of at the desktop with Longhorn for a mere 1000 dollars or something is the next incarnation of an OS once called DOS (Quick and Dirty), that is the real saga.
  44. Aaron: "But JBoss is, or was at one point, a "lightweight" appserver"
    How sad. (the word "was")
    The JBoss appserver can be as lightweight as you want it. It's modular design allows you to strip it down to the microkernel if you so desire. If you want JMS, EJBs, Servlets, etc, etc, you simply deploy those services. If you don't want/need those sub-systems, you simply remove them.
  45. "Heavyweight" does not mean whatever it's user wants it to mean at the time (or at some point after) he said it. It has a specific meaning, in eglish, and in IT frameworks, specifically pertaining to performance, and in particular, memory consumption. A framework that forces users to tie their business objects with the framework's APIs or implementation is "tightly coupled" or "intrusive." But JBoss is, or was at one point, a "lightweight" appserver. Struts is not heavyweight, although it definitely does use more memory than is justified for it's meager functionality. A servlet container is almost always more lightweight than a full J2EE appserver, and JDBC is definitely more lightweight than Hibernate. Entity beans (taken alone) can sometimes be more lightweight than an O/R mapper like Hibernate, but a full J2EE server is probably going to be more heavyweight than Tomcat+Spring+Hibernate. If you have complex transaction logic or messaging, or need IPC, a full J2EE server may end up a more lightweight than your combination of several "lightweight" solutions.
    So memory footprint is the only "specific meaning" for lightweight? How then do people refer to a methodology such as XP as being more lightweight than XP? I think there is more than one connotative meaning to lightweight. So when people talk about lightweight containers, intrusivesness of the programming model becomes a concept that is bundled in with buzzwords like lightweight container. Attaching connotation to words isn't really a mangling of the english language. Lightweight had a meaning before there was ever even a concept of random access memory, and that meaning will continue to evolve over time.

    And you're flat out wrong when you say that entity beans could EVER have a smaller footprint than hibernate. I don't even think this is a point worth arguing. And your use of the word "probably" when comparing Spring/Tomcat/Hibernate to EJB is just flat out disingenuous. There is no probably, unless you haven't programmed with both of them and seen the differences in performance and number of lines of code (which I believe to be another measure of heavyweight vs. lightweight in terms of the framework being used).

    I don't think JDBC is lightweight from a programming perspective (the load of work on the developer is actually quite heavy in terms of exception handling, iteration, and connection management), although you're certainly right that from a pure memory perspective it is more "lightweight". I just think the discussion of memory consumption as the best reason to choose one framework over another should be reserved for 1989. If memory is your chief concern, stick to C and assembler.

    I do have complex transactional logic, and that is why I choose Spring over EJB 10 times out of 10, even in the case where I have EJB CMT at my disposal. Spring is easier to use and offers MORE flexibility than EJB. It is a simple abstraction over JTA that allows me to selectively veto runtime exception types as rolling back transactions and to allow certain checked exceptions to cause a rollback.
  46. I do have complex transactional logic, and that is why I choose Spring over EJB 10 times out of 10, even in the case where I have EJB CMT at my disposal. Spring is easier to use and offers MORE flexibility than EJB. It is a simple abstraction over JTA that allows me to selectively veto runtime exception types as rolling back transactions and to allow certain checked exceptions to cause a rollback.
    If you have complex transactional logic then this logic must be wrong, there is nothing more simple than transactions from user point of view (demarcation).
    I do not need framework to demarcate my transactions. JTA implementation manages distributed transactions, it can be usefull in some cases, but framework for transaction demarcation is useless. I do not think you need framework to demarcate transactions, drop both and it will be more "lightweight".
  47. perhaps you can tell me?[ Go to top ]

    How many times has Microsoft initiated a patent infringement lawsuit? <
    That reminds me of that old joke ...

    "I've never had a car accident in my whole life ... but for some odd reason, I've seen thousands."

    MS has never initiated a patent infringement lawsuit? Is that because that MS doesn't really have many patents worth infringing? Most of the stuff they have would fail under prior art anyway, so they wouldn't really stand a chance in court.

    Let's look at one of their recent patents;

    "a button that can perform different operations depending on how long you hold it down"

    Mmmm ... like mobile phones have been doing for the past decade?

    No-one has infringed on their patents for 'animated helpers'? Is that because Microsoft don't bother enforcing it, or because every other company realises that folk really don't like being shown how to spell, by a badly drawn cartoon dog?

    Meanwhile, Ms has just thrown in the towel and ($20m), having spent two years in court, trying to destroy a Linux distributor. Dunno about you, but that doesn't give me a warm, fuzzy feeling about MS' attitude towards competition.

    >> Were any of these those lawsuits instrumental in eliminating a competitor? <
    It would be nice if they did use patents though; because at least that would be LEGAL; rather than the sharp practices they have been found guilty of in the past.

    On the other side of the fence, MS has ended up having to pay millions for their own patent trangressions.

    >> You can divide Java people in two camps. The EJB traditionalists with its quasy-scientific High-Priests and followers full of hyperbole and vehemence, and those new people around Spring and similar frameworks that port their systems to C#. <
    .... s'funny, that the only person foaming at the mouth round here, is you. You're getting desperate, and its *realy* beginning to show.
  48. perhaps you can tell me?[ Go to top ]

    You can divide Java people in two camps. The EJB traditionalists with its quasy-scientific High-Priests and followers full of hyperbole and vehemence, and those new people around Spring and similar frameworks that port their systems to C#.Your remark shows clearly which category you belong to.RegardsRolf Tollerud
    And that's an idea. Port J2EE to .NET and make all .Netters followers of the hyperbole. Better yet, marginalize the importance of Microsoft libraries by using ported OS Java frameworks, and steal the control of .NET from Microsoft. We can all use Mono and remove Microsoft forever!

    I also think there is a third group of Java people. I think you belong to it: Closet-Java-Lovers.
  49. Then by your definition M$ should never release any product at all
  50. I hear what you are saying and agree with a lot of it but I would rather have the option of being able to trim down the "OS" to what I need for a particular deployment. Maybe it is because I don't see the app server as an "OS" but as an extension of the application(s) running on it.

    But to use the OS analogy: I wouldn't have a ftp server idling in the background, or an IIS installation on my production server if I didn't need it. So why should I have a JMS module or EJB module if my application doesn't use it?

    I'm not sure I buy the, if you need it later then you'll have to regression test everything to make sure the new module doesn't break anything, argument. My reasoning being is that we have to do this kind of testing for a simple o/s or application server upgrade. Or for a reasonably sized roll out of a new version of the application. So my counter-argument would be that if a new version of the application needs JMS then testing of that module, the cluster, and the other parts of the application would be needed anyway.

    I'm finding a lot of clients who've moved toward having an app-server cluster created for each major application vs installing all applications on one cluster. With enterprise apps it gets hard to tune one cluster to handle each application's particular needs without interfering with other applications.

    Anyway, interesting thought-points all around.
  51. I hear what you are saying and agree with a lot of it but I would rather have the option of being able to trim down the "OS" to what I need for a particular deployment. Maybe it is because I don't see the app server as an "OS" but as an extension of the application(s) running on it. But to use the OS analogy: I wouldn't have a ftp server idling in the background, or an IIS installation on my production server if I didn't need it. So why should I have a JMS module or EJB module if my application doesn't use it? I'm not sure I buy the, if you need it later then you'll have to regression test everything to make sure the new module doesn't break anything, argument. My reasoning being is that we have to do this kind of testing for a simple o/s or application server upgrade.
    If application regression test suites were thorough, and if defects could be corrected without creating new ones, I think I would be saying the same as you. The problem I see is that regression suites are, by and large, really bad. And our ability to correct defects in an historic system without creating new defects is also uninspiring. Put it together, and upgrading significant portions of a container or operating system can have unintended and unmeasurable consequences that will turn up only in later production use, and be hard to fix without causing further impacts.

    In point of fact, I do have an ftp server idling along in the background on even my laptop ... I occasionally use it, the rest of the time it costs practically nothing because it is off in virtual and my threads and process entries aren't fully consumed.
    Anyway, interesting thought-points all around.
    And thank you for the thoughtful and reasoned response.
  52. Congratulations[ Go to top ]

    It is a very good news !
  53. welcome to the fold[ Go to top ]

    Bye, bye. There goes the chance to make something new and innovative. Say hello to old outdated technology; slow, unreliable and overcomplicated.

    Regards
    Rolf Tollerud
  54. welcome to the fold[ Go to top ]

    Say hello to old outdated technology; slow, unreliable and overcomplicated. Regards Rolf Tollerud
    Yes, we all know you're always talking about Microsoft, but this is a J2EE site.
  55. congrats![ Go to top ]

    this is great for java enterprise mindshare. jboss stands in a unique position to both open source and commercial models. i see more companies following the "jboss business model" of lgpl code, outstanding community, cheap documentation, and a quality, professional service team that adds the value to the customer and profit to the bottom line.

    this ecosystem niche benefits customers immensly due to the following factors: (1)ejb was standardized, (2)commercial success paving the way, (3)lousy reference platform, (4) over-prices closed solutions that did not out-innovate open solutions, (5) pressure from .net, (6) customers with real needs

    this is a short-term win for sun because it steers people away from .net. i'm not sure what the longer-term impact will be on commercial ejb vendors.
  56. Well with this certification everybody wins again. ( http://www.jboss.com/services/press/j2eecertfinal.pdf )

    Sun - Got another key player in J2EE Server market supporting 100% of J2EE standard.

    JBoss - Can now very well compete with other Certified J2EE Servers and can possibly get customers who care for certification and standards.

    Users/Customers - Can use, try and recommend this server as it is J2EE Certified. Now they have one great option of an already good but now certified J2EE server.

    Now, who is the looser? Competition? Though it may depend what JBoss provides as compared to competiion and how it performs in production arena.

    But as I know, this is a good news for me. Good job JBoss. All the best.
  57. Code?[ Go to top ]

    Anyone find the certified binary anywhere?

    Or know what tag of CVS was certified?

    -geir
  58. Code?[ Go to top ]

    I don't think that was his point. The point is that you don't work for them and you don't (currently) contribute. I agree with him, I'm not sure there are many people not employed by JBoss Inc. that is contributing, thus the valid questions about the "community effort" claim.

    Jeff
  59. Code?[ Go to top ]

    I don't think that was his point. The point is that you don't work for them and you don't (currently) contribute. I agree with him, I'm not sure there are many people not employed by JBoss Inc. that is contributing, thus the valid questions about the "community effort" claim.Jeff
    I think it would certainly be valid if they were not allowing people outside of JBoss Group to contribute. That's not the case that I am aware of.

    Cheers
    Ray
  60. Code?[ Go to top ]

    I don't contribute to JBoss, but you can download my fork of the code if you want. I'll even change some text strings so it doesn't say "Jboss" in the logs anymore if you're willing to pay for it. Of course, the modified code will be made available.