Discussions

News: The status of JBoss AS 5

  1. The status of JBoss AS 5 (75 messages)

    So, was all of this just a fancy engineering exercise? No, not at all. This investment will have a drastic impact on the overall JBoss Enterprise Middleware offering, its longevity and its ability to adapt to market changes. If you take a 40,000 foot view of the AS market, you can essentially split it in three layers: • The base runtime • The core middleware services • The programming model/API & language More..

    Threaded Messages (75)

  2. Rock solid[ Go to top ]

    "We have built rock solid, scalable and flexible middleware services" hint: try to search the jboss issue tracker for 'deadlock' before posting such fancy news next time.
  3. ..maybe I'm wrong, but I'm just deeply suspicious of anything that takes three years to develop - that has a smell of multiple things going wrong somewhere along the way, or at least there being a very real risk that the world has gone by whatever was set out to be accomplished. The latter might be very much the case, as I see application servers loosing in relevance every day, with people opting more for picking and choosing the components they wish. But then again the more componentized JBoss AS can deal with this? Could be a case of "JBoss AS is dead, long live JBoss AS"?
  4. Agreed. I still wonder why did they take so long to deliver? Was it due to Redhat? We decided to switch to Glassfish from JBoss due to "lack of activity" on the JBoss side. Now We are very happy with glassfish and JBoss AS5 or not, we see no reason to use JBoss in enterprise any longer and I am sure there are many other companies that have adopted or moved on from JBoss
  5. Last time I checked, Glassfish platform is much much better than JBoss in any aspect. If you don't believe me, try it out and you wont be disappointed if you are in a need to work with EJB. To the best of my knowledge, only thing Glassfish is missing is product of similar quality as Tangosol Coherence (now re-branded to Oracle). Too bad Sun's (open source) marketing department is failing at their job.
  6. To the best of my knowledge, only thing Glassfish is missing is product of similar quality as Tangosol Coherence (now re-branded to Oracle).
    Take a look at JBossCache (http://www.jboss.org/jbosscache), which is used as the underlying replicated cache (for example for HTTP session replication) in the JBoss appserver. Bela
  7. Take a look at JBossCache (http://www.jboss.org/jbosscache), which is used as the underlying replicated cache (for example for HTTP session replication) in the JBoss appserver.

    Bela
    Thanks for the link. I am aware of JBossCache and JGroups offerings, however I doubt it can match Coherence in the quality. While I do not have practical experience and/or scientific recommendations to back up my doubts, considering they were bought by Oracle, and instinct that companies specialized in one certain area always outperform corporations that offer everything at medium quality, I believe it stands correct: Coherence > any OS tool.
  8. Thanks for the link. I am aware of JBossCache and JGroups offerings, however I doubt it can match Coherence in the quality.
    In what respect ?
    Performance-wise, our benchmarks indicate JBossCache is about the same. If you benched the 2 products, and see us behind we'd be happy if you sent us your benchmark so we can run it ourselves.
    Feature wise, they're ahead with data partitioning, but we're working on it (http://wiki.jboss.org/wiki/JBossCachePartitioning).


    While I do not have practical experience and/or scientific recommendations to back up my doubts, considering they were bought by Oracle, and instinct that companies specialized in one certain area always outperform corporations that offer everything at medium quality, I believe it stands correct: Coherence > any OS tool.
    Indeed, my team specializes in clustering: JGroups, JBossCache and PojoCache, as if they were standalone products. Thanks for the kudos :-) Bela (happy JBoss employee)
  9. In what respect?
    Like I said, I haven't done research in this area and my experience is limited to writing totem single ring membership protocol impl at spare time, however my 6th sense is telling me Coherence is better product overall (not cheaper).
  10. In what respect?


    Like I said, I haven't done research in this area and my experience is limited to writing totem single ring membership protocol impl at spare time, however my 6th sense is telling me Coherence is better product overall (not cheaper).
    Thanks for sharing with us your 6th sense. My 6th sense tells me many users won't know what to do with what your 6th sense tells you :)
  11. Thanks for sharing with us your 6th sense.

    My 6th sense tells me many users won't know what to do with what your 6th sense tells you :)
    Well my 6th sense was largely based on the fact that 3rd largest software company in the world purchased Coherence, and that same company delivers best database in the world, so it is highly unlikely they would purchase something which is not among, if not, the best in the world. =)
  12. Thanks for sharing with us your 6th sense.

    My 6th sense tells me many users won't know what to do with what your 6th sense tells you :)


    Well my 6th sense was largely based on the fact that 3rd largest software company in the world purchased Coherence, and that same company delivers best database in the world, so it is highly unlikely they would purchase something which is not among, if not, the best in the world. =)
    Hey, they (Oracle) tried to purchase us (JBoss) first, before InCoherence....So... Great theory, I agree with it wholeheartedly!!! -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com
  13. Hey, they (Oracle) tried to purchase us (JBoss) first, before InCoherence....
    Poor Bill .. ;-) Peace, Cameron Purdy Oracle Coherence: Data Grid for Java, .NET and C++
  14. Thanks for sharing with us your 6th sense.

    My 6th sense tells me many users won't know what to do with what your 6th sense tells you :)


    Well my 6th sense was largely based on the fact that 3rd largest software company in the world purchased Coherence, and that same company delivers best database in the world, so it is highly unlikely they would purchase something which is not among, if not, the best in the world. =)
    I don't get your logic. Because you have the best DB, what does it mean? that you only do wise acquisitions? or that all of your products are great? But then, if all of your products are great, why do you need to do acquisitions in the first place? I don't follow.
  15. Thanks for sharing with us your 6th sense.

    My 6th sense tells me many users won't know what to do with what your 6th sense tells you :)


    Well my 6th sense was largely based on the fact that 3rd largest software company in the world purchased Coherence, and that same company delivers best database in the world, so it is highly unlikely they would purchase something which is not among, if not, the best in the world. =)


    I don't get your logic. Because you have the best DB, what does it mean? that you only do wise acquisitions? or that all of your products are great? But then, if all of your products are great, why do you need to do acquisitions in the first place? I don't follow.
    No! NO!....Sacha...I like his logic, by his logic, we are the best app server in the world...
  16. No! NO!....Sacha...I like his logic, by his logic, we are the best app server in the world... Quite the opposite Bill. If JBoss was better than BEA in terms of cash flow and steady growth, Oracle would have purchased it over BEA. Simply JBoss financial statements were in poor condition compared to BEA's. And even if they have purchased BEA to kill it, it again shows they consider BEA much bigger threat on the market than JBoss. Those are the facts.
  17. No! NO!....Sacha...I like his logic, by his logic, we are the best app server in the world...


    Quite the opposite Bill. If JBoss was better than BEA in terms of cash flow and steady growth, Oracle would have purchased it over BEA.

    Simply JBoss financial statements were in poor condition compared to BEA's.

    And even if they have purchased BEA to kill it, it again shows they consider BEA much bigger threat on the market than JBoss.

    Those are the facts. Had to report, didnt use quote tags correctly.
  18. I doubt it....[ Go to top ]

    No! NO!....Sacha...I like his logic, by his logic, we are the best app server in the world...



    Quite the opposite Bill. If JBoss was better than BEA in terms of cash flow and steady growth, Oracle would have purchased it over BEA.

    Simply JBoss financial statements were in poor condition compared to BEA's.

    And even if they have purchased BEA to kill it, it again shows they consider BEA much bigger threat on the market than JBoss.

    Those are the facts.

    Had to report, didnt use quote tags correctly.
    Oracle bought BEA simply because they saw a lot of high value customers using BEA products. The problem now is that a lot of companies are moving to using a lot of open source in their projects hence the growth of spring etc,etc. Oracle know that for the short term they have the previous BEA customers over a barrel hence the price hike. People may bitch about how long it has taken JBoss 5 to come out and how that *now* [insert appsvr name here] is so much better but remember that these things a cyclic and soon enough others will be bitching about other app servers.
  19. Re: I doubt it....[ Go to top ]

    Oracle bought BEA simply because they saw a lot of high value customers using BEA products.
    Couldn't agree more on this one.


  20. I don't get your logic. Because you have the best DB, what does it mean? that you only do wise acquisitions? or that all of your products are great? But then, if all of your products are great, why do you need to do acquisitions in the first place? I don't follow.
    We all know Oracle has two strategies like any other big corporation: purchase and either embrace (Oracle doesnt have similar in house offerings or has but with lower quality, or simply purchased product has better brand) or kill (Oracle has better or similar quality offerings, just wants to get rid of competition). If Oracle purchased MySql, they would have killed it, since we all know Oracle DB > Mysql. They didn't had Coherence-like offerings in house, and they decided to strengthen their market position in middleware area by purchasing the best solution on the market. That sounds like pretty solid plan to me, and considering Oracle has been on the market for over 30 years, it is very likely they have made very, if not the best move when purchasing Coherence. There you go, you have just been enlightened...
  21. Don't be so selfish[ Go to top ]

    Thanks for sharing with us your 6th sense.

    My 6th sense tells me many users won't know what to do with what your 6th sense tells you :)
    Communities like TSS are not representative of the IT world out there. Posters are usually versed into new buzz, innovations and are very vocal. That's great, but it would be a mistake to think there is a one-to-one mapping between this community and the middleware market at large
    You cannot be so selfish. People from "Communities like TSS" usually recommends technology to decision makers (if they are not decision makers), so it is not too bright from you to ignore them. Meanwhile they will continue to deploy on Glassfish as a real enterprise quality open source JEE5 AS. Oh, I forgot that JEE is not your business anymore,
    It is not *really* about EJB3
    Well, you seem to forget the origin of the JBoss name (EJBOSS rings any bells to you?). But, yes, that was Marc Fleury's crazy ideas... Flury is gone, lets do business with whats left, two years later. Well, maybe JBoss AS 5 is the best platform if you want to deploy anything different to EJB3 and JEE5. Until I need something like that I will continue using JEE as the best EE platform in the world, and of course over JEE commited Application Servers, like Glassfish.
  22. Performance-wise, our benchmarks indicate JBossCache is about the same.
    On anything less than 10G Ethernet, Coherence is wire-limited. On 10G Ethernet (and Infiniband), Coherence is bus-limited, but can still sustain aggregate data throughput of over 10 gigabytes (bytes not bits) per second in a 16-node data grid on commodity x86 hardware. For distributed caching use cases, most accesses should be local, and thus most products should benchmark similarly. For data grid use cases, Coherence has consistently won every benchmark that I've been aware of for the past several years. Nonetheless, our customers point out to me that the important thing is that the solution they pick has to highly available and must never lose data -- those are the "non-negotiable" items, and are much more important than performance .. Peace, Cameron Purdy Oracle Coherence: Data Grid for Java, .NET and C++
  23. Performance-wise, our benchmarks indicate JBossCache is about the same.
    You are comparing apples (coherence) to well, something that's not even a fruit. I've personally used Tangosol Coherence in a project before and it's simply not a "replicated" cache like JBOSS cache. It's a lot more than that, its flexibility is outstanding - just look at the number of combinations available to configure the right cache topology for the job. In regards to benchmarks, you must strictly be talking about it from a replicated cache point of view (if one were to configure Coherence strictly as a replicated cache). Compare it instead to Coherence configured as a near cache (local cache for the front, and a partitioned back cache). Guaranteed it will be much faster for most use cases and will use up alot less memory on the cache servers.
  24. I am aware of JBossCache and JGroups offerings, however I doubt it can match Coherence in the quality.
    Coherence is rock solid. It has to be: It runs many of the largest exchanges, trading systems, travel systems, logistics systems, etc. around the world, 24x7x366 (it's a leap year .. ;-) Peace, Cameron Purdy Oracle Coherence: Data Grid for Java, .NET and C++
  25. I did the same thing, JBOSS 5 beta's couldn't even deploy a properly packaged JEE5 ear. Moved to Glassfish and never looked back.
  26. ... The latter might be very much the case, as I see application servers loosing in relevance every day, with people opting more for picking and choosing the components they wish.
    But then again the more componentized JBoss AS can deal with this?
    Could be a case of "JBoss AS is dead, long live JBoss AS"?
    I don't buy into the "AS are dead" simplification. As I explain in my blog, call them whatever you want (AS, component frameworks, whatever), at the end of the day, you will still rely on the same enterprise services. AFAICT, nothing that happened in the last 3 years says that applications shouldn't be secure anymore, or not use transactions anymore, or not be clustered. The core remains, the APIs come and go. What people are asking for is more granularity in what they can do, they are not asking to get rid of any of the enterprise services. Now, call the resulting set of enterprise aspects the way you want, I personally don't shy away from using the name "application server". That's probably because we never saw JBoss AS as a fat monolithic AS in the first place :) Sacha CTO JBoss, a division of Red Hat
  27. profit[ Go to top ]

    Also, senior executives do not know and understand technology, nor they should. All they see are numbers: profit/growth, call it how you want. Its your duty as techie to chose best option, not only for development phase, but also for the future, 5-10 years, depending how long project will live. If two technologies are comparably equal, and neither one brings dramatic improvements in some areas where big revenue could be generated by simple fact of using one over the other, then standards will always be used, and standards will win. That is why JEE is The Best at the moment. New technologies must make significant improvements in order to replace JEE.
  28. Re: JBoss 5[ Go to top ]

    Nice job, Sacha... This is a welcome statement from an organization with a history of over-educating its audiences, and it was time for JBoss to make a statement to the Java community, thanks... I may not have absorbed everything in the post, but i know i am going to have ongoing problems with this thesis, as stated in the blog entry: "But what is interesting is that about 80% of those customers are not waiting for an EE5-certified application server, but want to leverage specific features of our AS 5.0 architecture (mostly our JBoss Microcontainer)." While this may be true, that a sample of customers were taken and the consensus seems to be that they will not be migrating their apps to EJB 3, etc..., I find it to be a poor job of understanding JBoss' role and competitive advantage in the wider middleware space: if JBoss 5 does not get customers to move to JEE 5, then it will be a Vista-like failure, where upgrades will be simply about extending e.o.l. support contract timeframes, and will not deliver the technical benefits of a revised specification, nor the new business opportunities for JBoss to go after.... in short, Sacha, watch your marketing of JBoss 5 as a fancy, techno, micro-container innovation, especially at the expense of application component development innovations, because there is this little company called SpringSource that is currently eating your lunch... my suggestions is to get back on message with promoting JEE, and establishing JBoss 5 as the pre-eminent deployment platform for all things JEE on Linux, and start making a ton of money; nothing says market opportunity for Seam, like hundreds of new installations of JEE 5 shops that adhere to the full complement of the spec... that is boring, and I understand Muzilla is on the 're-factoring' angle, so i am not going to scold, or question, i just think that there is real competition now, with Oracle, IBM, Glassfish, Spring, and .Net to compete with JBoss: u guys need to execute like hell, and prove to everyone why u won the leadership position in the 1st place...
  29. Re: JBoss 5[ Go to top ]

    Nice job, Sacha...This is a welcome statement from an organization with a history of over-educating its audiences...
    Good points. Seems they have forgotten about the bottom line here. No concrete evidence has been shown that JBoss5 brings anything revolutionary to the table that will enable users to generate profit, hence seems JBoss5 development was nice way to lose time. Is there anything in JBoss5 stack feature list that can not be done by some other OS tool, or combination of there of? Anything revolutionary, any killer app in middleware area? If JBoss5 is not about EJB3, then I dont know what it is about.
  30. Re: JBoss 5[ Go to top ]


    If JBoss5 is not about EJB3, then I dont know what it is about.
    It's *really* not about EJB3 - JBoss AS 4.2 was about EJB3 and that was released over a year ago. What it is about is a well-designed, very flexible, modular enterprise Java run-time that has utility way beyond running EJBs. It's the same run-time we'll be able to use when the next server-side framework, programming model or paradigm comes along. We'll be able to adapt quickly and without disrupting the operational footprint of the run-time. - Rich Apprentice JBossian
  31. Re: JBoss 5[ Go to top ]


    If JBoss5 is not about EJB3, then I dont know what it is about.


    It's *really* not about EJB3 - JBoss AS 4.2 was about EJB3 and that was released over a year ago.

    What it is about is a well-designed, very flexible, modular enterprise Java run-time that has utility way beyond running EJBs. It's the same run-time we'll be able to use when the next server-side framework, programming model or paradigm comes along. We'll be able to adapt quickly and without disrupting the operational footprint of the run-time.

    - Rich
    Apprentice JBossian
    If I got this right, JBoss5 will bring major advantage only in case new Big Paradigm shift and similar happens, and for good ol' Java EE its ok to stick with 4.2? (I know 5 brings another improvements, but I am referring here only to major big advanateges that 5 could bring over 4.2)
  32. Re: JBoss 5[ Go to top ]


    While this may be true, that a sample of customers were taken and the consensus seems to be that they will not be migrating their apps to EJB 3, etc..., I find it to be a poor job of understanding JBoss' role and competitive advantage in the wider middleware space:
    Doug, the point here is that many of the Java EE 5 features and APIs we're already included in AS 4.2 back in 2006 - so few customers have been demanding full EE 5 compliance from JBoss. EJB 3 isn't new to JBoss customers. I'll restate it - Java EE 5 isn't the only release driver for AS 5.0 and JBoss has always been and always will be more than just a standard Java EE container. We're not betting our business on Java EE though we'll continue to support it as long as there is demand. The world doesn't revolve around Application Servers (though they continue to be important). And AS 5.0 isn't *just* a better App Server (though it may well be) - it's our investment in the future. A way for us (and others) to standardize on a very flexible enterprise Java run-time. - Rich Apprentice JBossian
  33. Re: fundamentally disagree[ Go to top ]

    Rich, I am not sure if this has turned in to a pissing match for some reason other than i am publicly saying what many are feeling, but your response is patently false, with respect to JBoss AS 5: it is about JEE, and the balance of the Internet does revolve around application servers, that are the run-time for everything from databases, to BPM, to ESBs, to Portals, i mean name one thing that does not touch app servers, and i'll show u an outdated and irrelevant mode of software development... for the product management team to believe the hype around other modes of middleware is fine, but to come up with a statement like this: "We're not betting our business on Java EE though we'll continue to support it as long as there is demand." is just plain funny to me, i mean u of all people should be inculcating the JBoss org. with the mantra of stop splintering JEE, and deliver a world-class run-time for it, especially to make revenue on Linux deployments... i mean what other ways do you guys expect to make money with JBoss other than on Enterprise Java?
  34. Re: fundamentally disagree[ Go to top ]

    Rich, with the mantra of stop splintering JEE, and deliver a world-class run-time for it, especially to make revenue on Linux deployments...

    i mean what other ways do you guys expect to make money with JBoss other than on Enterprise Java?
    Doug, nothing I have said should imply that JBoss is trying to splinter Java EE - we're not. JBoss has been a strong supporter, we employee lot's of bright people who work on various JSRs to make Java EE better. We support Seam - a framework that makes Java EE a better and more productive environment. The concepts in Hibernate made Java EE better. I'd say that JBoss has done a lot more than most vendors to make Java EE better. But the fact remains, many of our customers do not want or need Java EE; they are mature and experienced enough to choose the technologies and frameworks that they want and they expect us to support them. And we will. We support Java EE but it isn't our job to push it as the one and only technology for all use cases. - Rich Apprentice JBossian
  35. Re: fundamentally disagree[ Go to top ]

    i mean name one thing that does not touch app servers, and i'll show u an outdated and irrelevant mode of software development...
    I think a lot of people consider application servers to be an outdated approach to development. JEE is considered by many to be irrelevant.
  36. Re: misguided[ Go to top ]

    Perhaps i am the biggest curmudgeon on TSS, but after re-reading Sasha's blog entry, i am feeling a little queasy on the direction of JBoss, and wonder whether there is actually customer support for the premise that different development models will actually make JBoss more business-scalable... it is tempting to build a bigger business than the 1 that a company may b in, but i will submit that the temptation to be a run-time for everything including Spring, Grails, and potentially other development models, we have a product-line that is at least a year late to market...Cost-Benefit Analysis is tricky especially preceding a product release, but i am not so sure about this bet that JBoss has made on a new type of application server implementation, especially considering that it appears that SpringSource and Glassfish have already accomplished this modularity... what is going to be the market adoption of something that is so classically in a follower position? that really is the question, and i just don't know what data and information went in to the decision to move beyond JEE, but I haven't seen anything convincing, other than purported job request figures from the Spring guys... have enterprise customers moved away from Java: perhaps some, but to claim this is a trend that justifies what has happened with JBoss 5 seems a bit of a stretch; James Watson's statement of JEE being "irrelevant" is 100% propaganda, as is the premise that app servers don't have a future in generating the development model counter to .Net implementations... basically, i am saying nothing new, but it just seems the more that people bet against JEE, or at least, predict its ultimate demise in reduced demand, that it is lacking in historical precedence or even based in reality...its one thing to have some fellow developers try out different development paradigms, it is quite another to get enterprise customers to standardize on something other than what is legacy... i am so tired of the "JEE is dead" discussions, that i am completely baffled why JBoss seems to be hedging 4 it, perhaps u could argue that it is a risk-mitigator for the future, but right now, i just think it was misguided MRD and PRD analysis that called for an entirely new platform, that is not even close to done, with all the other moving pieces that need to be integrated... my suggestion: get a Red Hat Enterprise Linux certified JBoss 5 out to market, and ditch Solaris, Hp-UX, AIX, and even NT, with a development supported product for XP; everything else is just too risky to pull off... Rich, I hate to continue to be inflammatory, but i can c why they brought u in for Product management: JBoss is in some serious need of people to make decisions that are non-technical, and rely on business metrics; i hope u make the best of it...
  37. Re: misguided[ Go to top ]

    James Watson's statement of JEE being "irrelevant" is 100% propaganda
    I didn't actually write that, of course. But I will point out that you haven't actually made any coherent argument for JEE, you've just stated that anything else is outdated. Honestly, this seems pretty laughable to me and I find JEE so boring that I'll agree with you that talking any more about how it's dead isn't really a good use of time. Hope you find your missing shift key and good luck.
  38. Re: JEE[ Go to top ]

    This is fun, i actually got 1 past the JBoss contingent, even considering the inflammatory nature of my post that things are awry...i hate being such a punk, but i think that is a label that people most refer to when things go against conventional wisdom... James, u r correct, u actually said some people rather than making it your own statement, so apologies for making it a quote, that was not legit...but it gives me reason to advocate to JBoss marketers and all potential nay-sayers of why JEE is alive, active, and relevant: It is simple math - - .Net is predicated on volume, and other development models have come and gone based on the inability to reach critical mass; with a sizable head-start, Enterprise Java established itself as the singular platform 4 developers that needed to create web apps, and even without Netscape's ability to run the table, J2EE was without question the safe choice for Internet enterprise development and deployment... a lot has come about in the 10 years since its cohesive introduction, but still the fact remains that TSS, the JCP, and the app server are the center of the universe for everything that is not Microsoft...Grails, Ruby, Spring, PHP, and the rest of the contenders are complimentary technologies but would never be considered a viable alternative to .Net; JEE is... fashionable statements are exciting, because some common theories hold that innovation trumps all else, and Spring has demonstrated a business model that seriously contends with EJB for business logic on middleware, but there is no way JEE or the delivering mechanism of application servers is going anywhere... the upgrade path as well as the migration path is 2 straight-forward, well-documented, and vital to the interests of the vendors that support it; evidence for this comes from Oracle in its embrace of WebLogic, in IBM's utilization of Geronimo, in Sun's re-commitment via Glassfish, in NetWeaver, and ultimately in the acquisition of JBoss... what is not clear 2 me is that business people are running the show at JBoss, and even though it is a technical platform and there are literally dozens of moving pieces, some one over there needs to be taken to the Red Hat side of business and be indoctrinated with execution practices, and not make a shoot-the-moon strategy pre-eminent over delivery... ultimately, whether anyone wants to admit yet or not, JBoss is not going to be scalable enough nor utilize efficiencies of scale to compete with anything other than Linux, and why would they? all deployments are going there anyway...just focus on business, get the darn product out, and quit trying to 're-factor' everything in the cloud... it is really straight-forward, analysts will be calling for explanations in the next con call, and the answer will have to be a non-technical 1, is anyone willing to make the hard decision to do the right thing, and go all-Linux, all-the-time, we shall c, but i think it is only a matter of time...
  39. Re: misguided[ Go to top ]

    I find JEE so boring that I'll agree with you that talking any more about how it's dead isn't really a good use of time.
    JEE could be boring, but who cares? Any serious business will always prefer standardized solution for mass scale development of business applications, irrelevant whether it is the best option or not. For specialized solutions (such as Coherence) it is not that important whether they have standard API. Any serious manager will always go for standard solutions, such as JEE, simply because it is less risk.
  40. Any serious manager will always go for standard solutions, such as JEE, simply because it is less risk.
    To play the devil's advocate for a second: WHY is it less risk? 4-6 years ago, everyone went crazy for EJB's because it was "a standard and less risk". Now most people who adopted them are in a right mess: can't upgrade their JVM's or app servers, too big a risk, can't improve or extend their codebase, too big a risk since EJB's are almost untestable. On the other hand, anyone who went with writing things in mostly plain Java have been able to continue on their codebase and update JVM's & app servers to their hearts content. Just stating something is "less risk" because it is a standard doesn't make it so. Sometimes you actually have to _think_ about what the actual, real risks are.
  41. Now most people who adopted them are in a right mess: can't upgrade their JVM's or app servers, too big a risk, can't improve or extend their codebase, too big a risk since EJB's are almost untestable.
    I could say the same for all the in-house component/pojo libraries that turn into in-house component/pojo frameworks that eventually turn into in-house component/pojo platforms. It is not just the technology here but the planning, project, process and people as well. In my CORBA days I always said that every custom built "light weight" remoting solution will eventually end up looking like CORBA they only difference is that one was designed with most of the features in mind whereas the other evolved as the (overlying simplified) problem domain was expanded because of harsh realities. The same can be said for much of the component/pojo middleware today. Which approach do you think is better? One big problem with such debates on TSS is that the perspective is very narrow though understandable. It is always focused on the support offered during development and not on manageability of the runtime and the support for processes and teams. You might also take into account the available skill pool. William
  42. In my CORBA days I always said that every custom built "light weight" remoting solution will eventually end up looking like CORBA they only difference is that one was designed with most of the features in mind whereas the other evolved as the (overlying simplified) problem domain was expanded because of harsh realities. The same can be said for much of the component/pojo middleware today. Which approach do you think is better?
    The problem at the heart of the issue is over-engineering: how many people that use ejb's actually _need_ the remoting capabilities? If not, do they actually need ejb's at all? The same goes for custom built "light weight" remoting solutions. J2EE was originally applied with a crowbar into every crevace it could find. If you are effectively shuffling data from a database to and from a web front end, why would you need anything more than a servlet container, a nice web framework, and an ORM framework? By the same token, if you are dealing with a messaging system, why would you need anything but messaging middleware and possibly message driven beans? See what I'm getting at?
  43. The problem at the heart of the issue is over-engineering: how many people that use ejb's actually _need_ the remoting capabilities? If not, do they actually need ejb's at all? The same goes for custom built "light weight" remoting solutions.
    ...
    If you are effectively shuffling data from a database to and from a web front end, why would you need anything more than a servlet container, a nice web framework, and an ORM framework?
    By the same token, if you are dealing with a messaging system, why would you need anything but messaging middleware and possibly message driven beans?
    EJB != Remote Beans. Why not just stick with the servlet spec and JDBC? Why bother with all that heavy weight ORM and web framework stuff? Why should I bog my app down with the Hibernate criteria api, or query by example when I just need to persist objects to and from the database? How are you going to manage state? When your Ajax web framework keeps hammering the server with requests that you have to handle against your model, are you going to keep shuffling the data from the database to the view/business logic until it slows your app to a crawl? How are you going to handle optimistic locking when you keep on using the latest copy from the database? Are you going to throw it into the session? How are you going to handle replication? Dirty checking? Are you sure you pushed the object back into the session every time you modified it? What about opening the same page in two windows or tabs? Will it break because you name the session object the same thing in each page with one page overwriting the values of the other page? Suddenly, just using a nice web framework and an ORM lib has you writing a bunch of additional code to handle all this. Not every web application is just a hello world or a pet store with a session scoped user and shopping cart. I often wonder how people solve these problems in applications they build, but the more I see other people's code, the more I think they either a) Ignore it or b) just aren't aware of it because they certainly don't plan for it. To address another point you made :
    To play the devil's advocate for a second: WHY is it less risk? 4-6 years ago, everyone went crazy for EJB's because it was "a standard and less risk".Now most people who adopted them are in a right mess: can't upgrade their JVM's or app servers, too big a risk, can't improve or extend their codebase, too big a risk since EJB's are almost untestable.
    That like saying years ago, people were using Microsoft DOS and now nobody uses it and they are stuck with all these unsupported DOS applications and data, so we should avoid all OS's from Microsoft which is fine because Mac OS X is way better than Dos. You can't compare what is available today with what is available now, especially when the technology of yesteryear was a building block to todays offerings. There is no Spring without EJB 2.1 frustrating the heck out of people. If you are referring to homegrown POJO solutions, I would say that these probably have less functionality and are more complex to deal with until the developers are familiar with a custom framework. If a 'public' framework like Spring, Wicket etc is less risk (and less complexity) than writing your own framework, it seems logical to follow the assumption that a 'standard' framework (which had obtained reasonable public acceptance) is even less risk.
  44. EJB != Remote Beans.
    ..you are telling that to someone who has spent the bulk of his career working with messaging systems, so I've dealt with my fair share of MDB's, however, it does not take away the fact that a lot of cases of EJB use is supported on the strawman that maybe, just maybe someone somewhere will want to remotely access something over RMI (when in fact it will never happen). As for your barrage of questions: you are just being ridiculous and completely missing the point. People should use the technologies and frameworks that _make sense_ in their particular situation, but throwing in everything and the kitchen sink just because it is "a standard and less risk" is stupid. And don't tell me it doesn't happen: I've seen it too many times when people just bulk up on everything, for no good reason (other than padding their CV's), and end up having 10 "standard" technologies and 5-6 layers when 2-3 technologies and 3 layers would have been enough. KISS is a pretty good attitude and practice: use what you need, and no more.
  45. If you are referring to homegrown POJO solutions, I would say that these probably have less functionality and are more complex to deal with until the developers are familiar with a custom framework.

    If a 'public' framework like Spring, Wicket etc is less risk (and less complexity) than writing your own framework, it seems logical to follow the assumption that a 'standard' framework (which had obtained reasonable public acceptance) is even less risk.
    It depends on what you consider to be a standard framework I guess. I'm (happily) surprised you mention Wicket, because a common argument people have against Wicket is that it isn't a standard framework (these people pick JSF instead). Personally I believe that people always win over frameworks. Frameworks, standard or not, can help you save a lot of work and reduce complexity etc, but they can also get in the way. But good people can do anything, even with mediocre tools/ frameworks.
  46. Any serious manager will always go for standard solutions, such as JEE, simply because it is less risk.


    To play the devil's advocate for a second: WHY is it less risk?
    4-6 years ago, everyone went crazy for EJB's because it was "a standard and less risk". Now most people who adopted them are in a right mess: can't upgrade their JVM's or app servers, too big a risk, can't improve or extend their codebase, too big a risk since EJB's are almost untestable.
    On the other hand, anyone who went with writing things in mostly plain Java have been able to continue on their codebase and update JVM's & app servers to their hearts content.

    Just stating something is "less risk" because it is a standard doesn't make it so. Sometimes you actually have to _think_ about what the actual, real risks are.
    It is less risk in the future, not less risk now. Lets say two years after mission critical business application was developed and deployed in production environment, software problems/bugs occur. Company has no in-house development, and has always outsourced/bought software development. The original supplier does not longer exist (went out of business), so they have to buy contractors from some other company. If that business application was developed in some unknown technology stack, takes much more time to fix bugs because: 1) contractors have to learn technology 2) contractors have to learn business semantics of application. In case it was developed in JEE, considering how big workforce market is, it would be easy and cheap to find workforce which would have to do only: 1) learning and fixing business semantics of application. Since time is money, and application is mission critical, they are losing X$ per day. With JEE they save Y$.
  47. It is less risk in the future, not less risk now. Lets say two years after mission critical business application was developed and deployed in production environment, software problems/bugs occur. Company has no in-house development, and has always outsourced/bought software development.
    My point exactly is that it may _not_ be less risk in the future. How do you migrate an application based on EJB's from one app server coming to End of Life to a recent version in a risk free way? You don't. How do you do it with something built in mostly plain java? You just drop it in. The same thing goes for future development once the original people have buggered of: plain java is plain java, a skill easy to find. Finding someone who knows EJB 1.1 on Websphere 4 and all the ins and outs of deployment is harder, especially years on, not to mention someone actually willing to do the work. Most people I know who would have that skillset don't particularly want to use it if they have a choice, leaving you with subpar developers to try to make sense of your old application. Then try to find new developers/maintenance guys who have the courage to make changes if the testing cycle is change/build/deploy/test that takes 15 minutes.
  48. Most people I know who would have that skillset don't particularly want to use it if they have a choice, leaving you with subpar developers to try to make sense of your old application.

    Then try to find new developers/maintenance guys who have the courage to make changes if the testing cycle is change/build/deploy/test that takes 15 minutes.
    Its not about migration but about size of workforce market, at least IMHO. More people have know-how and offer services around standard APIs, tools. Also you cant code everything in plain java, maybe can in small to mid size applications, but when there is lots of money at stake (any mission critical system), I can guarantee none project leader will allow usage of open source, a.k.a. you wont see usage of Bitronix, JOTM or any other open source transaction manager for big systems. That's why you buy EJB container: you buy contractual guarantees that mission critical aspect of your system (correct transaction management) is working correctly etc.
  49. Its not about migration but about size of workforce market, at least IMHO.

    More people have know-how and offer services around standard APIs, tools.
    But that's exactly what I'm saying! I'm pretty sure there are more people around that now Java and the JDK API's, than people who for instance also know everything about EJB 1.1 on Websphere 4. If people are more familiar with JEE API's than JDK API's, I'd be very wary of letting them come anywhere near my company.
    Also you cant code everything in plain java, maybe can in small to mid size applications, but when there is lots of money at stake (any mission critical system), I can guarantee none project leader will allow usage of open source, a.k.a. you wont see usage of Bitronix, JOTM or any other open source transaction manager for big systems.
    I don't think it really has to do with size of projects, it is about what technologies you need, and what they bring to the table to solve your task.
    That's why you buy EJB container: you buy contractual guarantees that mission critical aspect of your system (correct transaction management) is working correctly etc.
    I've seen lots of instances where people using EJB containers get it all wrong with transaction management for instance (explicit "beginTransaction", "commitTransaction" allover the place, swallowing Exceptions etc), and on the other hand instances with no EJB container where the transaction management has been flawless and completely transparent. A container can only give you _contractual_ guarantees, not absolute guarantees. At the end of the day it comes down to quality of people and practices. Believing a "standard" is automatically less risk and will automagically solve all challenges is just lazy thinking in my opinion.
  50. A container can only give you _contractual_ guarantees, not absolute guarantees. At the end of the day it comes down to quality of people and practices.
    Absolutely agree.
    I'm pretty sure there are more people around that now Java and the JDK API's, than people who for instance also know everything about EJB 1.1 on Websphere 4.
    I agree, but you cant do everything in Java SE, there are services in EE not present in SE, which you could emulate in SE but you would then reinventing the wheel in non-standard way, and with lower quality.
    I've seen lots of instances where people using EJB containers get it all wrong with transaction management for instance (explicit "beginTransaction", "commitTransaction" allover the place, swallowing Exceptions etc), and on the other hand instances with no EJB container where the transaction management has been flawless and completely transparent.
    Well I have seen pretty bad cases as well, however I still feel that given developers with same level of skill, usage of standard APIs will provide less risk in long term.
    Believing a "standard" is automatically less risk and will automagically solve all challenges
    Standard is less risk in high majority of cases, but it of course does not solve challenges: for that we need smart developers.
  51. A container can only give you _contractual_ guarantees, not absolute guarantees. At the end of the day it comes down to quality of people and practices.

    Absolutely agree.

    I'm pretty sure there are more people around that now Java and the JDK API's, than people who for instance also know everything about EJB 1.1 on Websphere 4.


    I agree, but you cant do everything in Java SE, there are services in EE not present in SE, which you could emulate in SE but you would then reinventing the wheel in non-standard way, and with lower quality.

    I've seen lots of instances where people using EJB containers get it all wrong with transaction management for instance (explicit "beginTransaction", "commitTransaction" allover the place, swallowing Exceptions etc), and on the other hand instances with no EJB container where the transaction management has been flawless and completely transparent.


    Well I have seen pretty bad cases as well, however I still feel that given developers with same level of skill, usage of standard APIs will provide less risk in long term.

    Believing a "standard" is automatically less risk and will automagically solve all challenges


    Standard is less risk in high majority of cases, but it of course does not solve challenges: for that we need smart developers.
    I think we are at an agreement. :)
  52. I'm pretty sure there are more people around that now Java and the JDK API's, than people who for instance also know everything about EJB 1.1 on Websphere 4.


    I agree, but you cant do everything in Java SE, there are services in EE not present in SE, which you could emulate in SE but you would then reinventing the wheel in non-standard way, and with lower quality.
    I'll jump back in here since I started this little sub-thread. I agree that IT management tends to go for the standard because it is perceived to be less risky. In theory it should be but the experience of J2EE calls this into question. We have to support multiple app-server vendors because 3rd party products "only run on WebSphere" or "only run on WebLogic". If you don't get interchangeability, then there's no value being confined to the limits of a standard. Actually, the Servlet spec from J2EE is a resounding success in my book and that's J2EE. It's just not what I think of when people talk about J2EE. The other thing I'll say is that even though it seems that people would have to know JSE to know JEE, I interview a lot of people who are familiar with JEE and can't really answer any basic JSE questions. They seem perplexed that someone actually cares about the fundamentals. I agree with Willie that I don't want these people on my team. Lastly, there are things that JEE offers that you shouldn't try to do yourself, assuming you actually need them. I have coworkers that insist that we need a full-blown app server when all they are acutally using is the servlet-container and a connection pool. To me that's just paying for something that's free and making life much more painful than it needs to be. As far as standards go, I see a lot of potential in OSGi and I'm unconvinced that JEE has a value proposition that makes sense.
  53. I see a lot of potential in OSGi and I'm unconvinced that JEE has a value proposition that makes sense.
    I'll try to quote one regular poster on TSS, who shall remain anonymous for the sake of simplicity "OSGi is JAR file with lifecycle" I agree with this strong but IMHO correct statement, OSGi is not some kind of revolutionary technology, and it seems it is more of IT buzz term, since in order for global IT companies to generate steady stream of income, we need from time to time to create buzz in the industry in order to sell easier to executives. Personally, OSGi belongs to same groups as SOA, Web2.0, Agile, REST etc. People have been there and done that. Same old things in little different flavor. Also, English aint my native so I couldnt figure out if you are saying that OSGi will replace EE? If not, please ignore this sentence.
    The other thing I'll say is that even though it seems that people would have to know JSE to know JEE, I interview a lot of people who are familiar with JEE and can't really answer any basic JSE questions. They seem perplexed that someone actually cares about the fundamentals. I agree with Willie that I don't want these people on my team.
    I agree with this but this is out of the scope, we are discussing why we need EJB/EE servers from business/tech perspective, not from HR/project leading view. Bad developers are bad in any platform/language etc.
    I agree that IT management tends to go for the standard because it is perceived to be less risky. .... then there's no value being confined to the limits of a standard.
    I dont think they only perceive, I think they know its less risky, and personally I would do the same. Imagine what would happen if we didn't have standards like JMS, JDBC and so on. With standards you go and see if vendor A is compliant, and if so, you read official spec, and you are 100% sure what the behavior of certain methods from standard API is. With standards we have globally agreed semantics of certain behaviors.
  54. I see a lot of potential in OSGi and I'm unconvinced that JEE has a value proposition that makes sense.

    I'll try to quote one regular poster on TSS, who shall remain anonymous for the sake of simplicity

    "OSGi is JAR file with lifecycle"

    I agree with this strong but IMHO correct statement, OSGi is not some kind of revolutionary technology, and it seems it is more of IT buzz term, since in order for global IT companies to generate steady stream of income, we need from time to time to create buzz in the industry in order to sell easier to executives. Personally, OSGi belongs to same groups as SOA, Web2.0, Agile, REST etc.
    OSGi is more than just a jar with a lifecycle. If that's what you really think it is, you should read up on it because you might be doing things in an outdated fashion without realizing it.
    Also, English aint my native so I couldnt figure out if you are saying that OSGi will replace EE? If not, please ignore this sentence.
    OSGi is one piece of the puzzle. It allows you to pull modular parts together. It means that you don't necessarily need a single vendor to deliver all the parts.
    I think they know its less risky, and personally I would do the same. Imagine what would happen if we didn't have standards like JMS, JDBC and so on. With standards you go and see if vendor A is compliant, and if so, you read official spec, and you are 100% sure what the behavior of certain methods from standard API is. With standards we have globally agreed semantics of certain behaviors.
    Standard can be very good. They can also be very bad. Just because something is a standard doesn't mean it's a good choice. J2EE has become a huge money sink for companies and most apps running on them are not portable without costly development efforts. Standards are like anything else. You must consider them based on their merits.
  55. OSGi is more than just a jar with a lifecycle. If that's what you really think it is, you should read up on it because you might be doing things in an outdated fashion without realizing it.
    I have read and used this stuff, so we shall see what OSGi will turn out to be.
    OSGi is one piece of the puzzle. It allows you to pull modular parts together. It means that you don't necessarily need a single vendor to deliver all the parts.
    You dont have to use one vendors stack in JEE as well. I just have counted jar files on classpath from my last project, and it includes ~80 jar files, excluding implementation of standard APIs provided by app server.
    Standard can be very good. They can also be very bad. Just because something is a standard doesn't mean it's a good choice.
    Well, we shall see about this part as well. If we keep an eye on new Spring's AppServer, we shall see how big players in industry will respond to offerings of non-standard platform, with no global consensus.
  56. Standard can be very good. They can also be very bad. Just because something is a standard doesn't mean it's a good choice.


    Well, we shall see about this part as well. If we keep an eye on new Spring's AppServer, we shall see how big players in industry will respond to offerings of non-standard platform, with no global consensus.
    First of all, where's the global consensus on JEE? J2EE was never derived from global consensus and that's where it went wrong. JEE is what it is now because tools that gained global consensus made it look ridiculous. OSGi, on the other hand is a standard built on consensus. It's not owned by a single company. There's nothing that remains to be seen about that statement. There are many standards that adopters have regretted adopting. J2EE is a perfect example. All I have to do to make my case is show one bad standard. You would have to show that all standards are good. Anyone with a basic understanding of logic knows that. Either logic isn't your thing or you are purposely avoiding the real point that has been made. Either way, it's an annoying response. Whether a non-standard implementation succeeds or not has nothing to with whether all standards are good.
  57. J2EE was never derived from global consensus and that's where it went wrong.
    Come on now, that statement is soooo wrong. Go take a look at list of vendors cooperating on EJB3, over 20 big corporations. Probably every vendor supporting OSGi is also taking participation in some EE standard as well.
    [osgi] It's not owned by a single company.
    Being owned by single corporation is not automatically bad thing. Remember we are talking here about Sun, one of biggest open source contributors in the world, and they cant do as they are pleased since if there was no global consensus on EJB in early days, it probably wouldnt hit the mainstream.
    All I have to do to make my case is show one bad standard. You would have to show that all standards are good.
    Wrong again. One word: evolution of IT. If there were no EJB, there would be no Spring. OSGi aint no silver bullet, and in couple of years we will see new technology that will claim to be new OSGi, and circle of "innovation" will continue. No EE standard is bad, but there are some better alternatives for certain standards.
    Either logic isn't your thing
    Anyways, I aint gonna argue with you any more, believe what you want. I think you are pissed off at Sun/EE for some reason and hate anything related to EE and like everything that is alternative to EE. Similar to RoR/Ruby/Scala guys. Go ahead do your thing, I'm kind of busy now, trying to make some cash and have fun at the same time on the most mature and stable platform in the world: Java EE.
  58. All I have to do to make my case is show one bad standard. You would have to show that all standards are good.

    Wrong again. One word: evolution of IT. If there were no EJB, there would be no Spring.
    You are repeatedly demonstrating an inability to follow a basic logical proposition.
    I think you are pissed off at Sun/EE for some reason and hate anything related to EE and like everything that is alternative to EE.
    Right. I couldn't actually mean what I said. If anyone disagrees with you it means they have an ulterior motive. That's a really mature way to think about the world. I think you are long on rationalizing and short on critical thinking.
    Similar to RoR/Ruby/Scala guys. Go ahead do your thing, I'm kind of busy now, trying to make some cash and have fun at the same time on the most mature and stable platform in the world: Java EE.
    Oh really? I hate fun and money. That must be why I don't have much interest in JEE.
  59. If anyone disagrees with you it means they have an ulterior motive. That's a really mature way to think about the world.
    Hahaha yeah, and if someone is disagreeing with you then "logic ain't his thing". You started first that kind of conversation buddy.
    Glassfish's modularity comes from OSGi. If you are talking about the Spring Application Platform, that too is built on OSGi.
    So what. There is nothing so revolutionary about OSGi you claim it to be. Morover, OSGi is sooo small part of overall IT and project management, yet you bully entire EE, though OSGi is alternative to maybe 0.005% of entire EE stack. Your entire talk seems totally invalidated, go re-read your posts, you compare EE with OSGi and you say "I see a lot of potential in OSGi and I'm unconvinced that JEE has a value proposition that makes sense."
  60. Re: misguided[ Go to top ]

    Any serious manager will always go for standard solutions, such as JEE, simply because it is less risk.
    And the smart ones make up their own mind and pick the best match for their projects. Also, many impressive tech companies (Google, Amazon) built their own software infrastructure, or at least important parts of it.
  61. Re: misguided[ Go to top ]

    Also, many impressive tech companies (Google, Amazon) built their own software infrastructure, or at least important parts of it.
    The talk is about companies whose primary interest is not in IT, a.k.a. companies which use software to support daily operations. They will always prefer to buy than to develop in house because its cheaper and less risky.
  62. Re: misguided[ Go to top ]

    Also, many impressive tech companies (Google, Amazon) built their own software infrastructure, or at least important parts of it.


    The talk is about companies whose primary interest is not in IT, a.k.a. companies which use software to support daily operations. They will always prefer to buy than to develop in house because its cheaper and less risky.
    Also, I agree partially. If the difference between quality of non-standard and standard product is huge (in favor of non-standard solution, with potential to gain competitive advantage at some level), yes they will chose non-standard. If there is no difference, or difference is minor in favor of non-standard solution, they will go for standard solution, though it is more expensive.
  63. Re: misguided[ Go to top ]

    If there is no difference, or difference is minor in favor of non-standard solution, they will go for standard solution, though it is more expensive.
    That sounds sane, but is it actually true? Can you point to research that supports your opinion? I would hope that many decision makers look at a broad spectrum of pros and cons, including whether their project team will be happy to use a certain technology, whether that tech supports the way they want to work (e.g. do they put the emphasis on test first programming, or do they want to build quick prototypes using visual interfaces), etc. There can be advantages to using a 'standard' - though you'll have to make those advantages explicit for your situation -, but I don't think that should ever be the sole deciding factor like you sketch it to be.
  64. Re: misguided[ Go to top ]

    That sounds sane, but is it actually true? Can you point to research that supports your opinion?
    Nope, no research, my opinion is based on various business management sources such as books, blogs, and on my work experience, such as one for 70k employees company, one of the largest in its industry (non-IT sector).
    but I don't think that should ever be the sole deciding factor like you sketch it to be
    I agree, standard should not be sole reason, however given factors from my previous post seems IMHO standards will always win. Simply compare these two numbers: 1) Potential profit to be gained by using non standard solution (for example will give huge boost to daily operations...) 2) Potential loss (risk) by using non standard solution (core developers leave in middle of development so new hires must be found with limited market workforce pool, post development maintenance and critical bug fixes, if application is mission critical what will happen if original supplier of non-standard solution is out of business in 5 years, who will bug-fix if it is written in unknown technology X, and even if there are suppliers for that technology, it will cost more than EJB workforce body leasing, since high demand and low supply increases prices) If 2 is bigger than 1, standard wins.
  65. Re: misguided[ Go to top ]

    That sounds sane, but is it actually true? Can you point to research that supports your opinion?


    Nope, no research, my opinion is based on various business management sources such as books, blogs, and on my work experience, such as one for 70k employees company, one of the largest in its industry (non-IT sector).

    but I don't think that should ever be the sole deciding factor like you sketch it to be

    I agree, standard should not be sole reason, however given factors from my previous post seems IMHO standards will always win.

    Simply compare these two numbers:

    1) Potential profit to be gained by using non standard solution (for example will give huge boost to daily operations...)

    2) Potential loss (risk) by using non standard solution (core developers leave in middle of development so new hires must be found with limited market workforce pool, post development maintenance and critical bug fixes, if application is mission critical what will happen if original supplier of non-standard solution is out of business in 5 years, who will bug-fix if it is written in unknown technology X, and even if there are suppliers for that technology, it will cost more than EJB workforce body leasing, since high demand and low supply increases prices)



    If 2 is bigger than 1, standard wins.
    Its all about numbers and risk in business.
  66. Re: misguided[ Go to top ]

    Perhaps i am the biggest curmudgeon on TSS, but after re-reading Sasha's blog entry, i am feeling a little queasy on the direction of JBoss, and wonder whether there is actually customer support for the premise that different development models will actually make JBoss more business-scalable...

    it is tempting to build a bigger business than the 1 that a company may b in, but i will submit that the temptation to be a run-time for everything including Spring, Grails, and potentially other development models, we have a product-line that is at least a year late to market...Cost-Benefit Analysis is tricky especially preceding a product release, but i am not so sure about this bet that JBoss has made on a new type of application server implementation, especially considering that it appears that SpringSource and Glassfish have already accomplished this modularity...
    This is very wrong. The modularity required to face the challenges of the next 3-5 years is much higher than what you can find out there. Stating that things are fine because your AS relies on OSGi is as useful as stating that it is based on CORBA or CCM or JMX. Evolution's need have stronger requirements.
    what is going to be the market adoption of something that is so classically in a follower position? that really is the question, and i just don't know what data and information went in to the decision to move beyond JEE, but I haven't seen anything convincing, other than purported job request figures from the Spring guys...
    Agreed: EE is very strong, hence our TOTAL SUPPORT FOR IT (since AS 4.2.x btw). But why do you want JBoss to be mono-maniac when it comes to APIs and programming models? Those are like tastes and colors, you won't fit a one-size-fits-all solution, so let's bring flexibility! As a EE user, what does it change for you? Just ignore the APIs you don't want to use :) It is about choice.


    have enterprise customers moved away from Java: perhaps some, but to claim this is a trend that justifies what has happened with JBoss 5 seems a bit of a stretch; James Watson's statement of JEE being "irrelevant" is 100% propaganda, as is the premise that app servers don't have a future in generating the development model counter to .Net implementations...

    basically, i am saying nothing new, but it just seems the more that people bet against JEE, or at least, predict its ultimate demise in reduced demand, that it is lacking in historical precedence or even based in reality...its one thing to have some fellow developers try out different development paradigms, it is quite another to get enterprise customers to standardize on something other than what is legacy...

    i am so tired of the "JEE is dead" discussions, that i am completely baffled why JBoss seems to be hedging 4 it, perhaps u could argue that it is a risk-mitigator for the future, but right now, i just think it was misguided MRD and PRD analysis that called for an entirely new platform, that is not even close to done, with all the other moving pieces that need to be integrated...

    my suggestion: get a Red Hat Enterprise Linux certified JBoss 5 out to market, and ditch Solaris, Hp-UX, AIX, and even NT, with a development supported product for XP; everything else is just too risky to pull off...

    Rich, I hate to continue to be inflammatory, but i can c why they brought u in for Product management: JBoss is in some serious need of people to make decisions that are non-technical, and rely on business metrics; i hope u make the best of it...
    No worries, we are doing more than fine. But we are certainly NOT going to ditch support for other OSes: we have a significant portion of our users going in production on Solaris, Windows, etc. and again, that is a matter of choice - we won't dictate that. Cheers, Sacha CTO JBoss, a division of Red Hat
  67. Re: nice work[ Go to top ]

    Sacha, My congrats to you and to some extent, Rich, for coming on here and getting some much-needed information in to the public domain, i think it is a historical testament to JBoss' success that ur poeople have time and again, come on TSS to further the debate and make statements that give people more than just guess-work perspective... I wrote a blog entry on my thoughts on the application server market that you can reference below, but here are a couple of points that i will make w/r/t the JBoss 5 impending release: a. no one is buying 4.2x as JEE5 It may be that you guys have been in the expert groups, and have even been the shepherds of the process for bringing EJB back to life w/ v.3 and JPA, and I understand u have the latest JAX support in 4.2x, but as u kind of mentioned this does nothing for developers and truly only is relevant to die-hard JBoss customers to 'test' JEE 5 capabilities, albeit that is a large group, but Glassfish is now the go-to JEE 5 server, by any account... b. OSGi and modularity I honestly don't even understand this discussion, as I mentioned before referencing Muzilla's "re-factoring" discussions in the Register, so I can't comment on what it exactly mean to be "modular", but i don't think anyone can truly believe that u r more modular than Glassfish or Spring, that is simply a matter of semantics... c. multi-OS strategy What kind of business do you have on AIX and HP-UX, its got to be in the single digit millions with no real reason for that to go up, based on the growth projections of those OS's? I like the Linux only strategy because it declares u as the go-to implementation for all Red Hat customers, which is a magnitudes larger base than JBoss, and Solaris is kind of dying, anyway...besides, there is an opportunity cost component that i tried to address with the length of the JBoss 5 delay; also, there are so many things that could be done with ISVs if they just were able to certify on JBoss/Red Hat and not do every other platform: imo, the major thing holding back the Red Hat Application Marketplace or whatever that OSS clearinghouse is called is JBoss, and not having something for the ISVs to mark to, and so it is actually hurting Red Hat to have a multi-OS JBoss strategy; that is a significant opportunity cost, in many respects... d. JEE we r just going to have 2 agree to disagree that there is a future for JBoss outside of JEE, i just dont see it, and considering the market opportunity, it kind of feeds the opportunity cost argument, that the more u guys 'diversify', the less ideas, implementations, and execution is given to the fight against Spring (to a small extent) and to .Net (to a much larger extent)...i know, i know, u guys love Spring, i just don't see it, until there is some common ground found with EJBs... truly, all the best, i am apparently out of ideas, but i would encourage u guys to continue to populate this message board with information, i think we are all better-off the more that JBoss fights for its place in the marketplace, rather than assume it with a whiz-bang new release... douglas dooley douglasdooley.blogspot.com
  68. Re: nice work[ Go to top ]

    b. OSGi and modularity

    I honestly don't even understand this discussion, as I mentioned before referencing Muzilla's "re-factoring" discussions in the Register, so I can't comment on what it exactly mean to be "modular", but i don't think anyone can truly believe that u r more modular than Glassfish or Spring, that is simply a matter of semantics...
    Glassfish's modularity comes from OSGi. If you are talking about the Spring Application Platform, that too is built on OSGi.
  69. Re: Frank and James[ Go to top ]

    Apologies, I have been sleeping for the past couple of days on this thread, and i didn't take the time to respond to the responses from u guys... Frank, I took the advice of the nice guy who defended me above, and looked at some of your older posts, where you claimed Java to b "legacy", to which i say: thank u, for making my main point in enterprise software - - that is, to be legacy is to b credible and reliable and legitimate, and therefore make that the best alternative in a sea of options... Java as dying is your go-to argument, mine is Java is alive and very well, i think i am going to win this 1 every last time we discuss... James, I understand that modularity in this context often references an OSGi implementation, and i believe (though still not perfectly clear on it) that Muzilla was referring to modularity with his made-up concept of "re-factoring", and i know that Sacha's blog talks a bit about the JBoss 'modularity' campaign that may or may not be the same as Muzilla's re-factoring, but i am still unclear what the hell that means... I am just a low-key observer, but i got to expect that after 10 years following Enterprise Java, if i don't have any idea what Muzilla is talking about, and if modularity seems to be a nice thing to have, but not a differentiator, that those Red Hat customers in Nebraska and around the world that the JBoss team should be focusing on won't have any idea either... myopia is an interesting and useful word when appropriately utilized, and i throw it around from time-time to be inflammatory (like when MuleSource claims to b 'standard' without JBI), so i'll apologize a bit for thinking out loud here, but it seems that you guys have been somewhat myopic on this thread with the 'Java means nothing' argument, all i can say is: keep trying, its fun beating up on u...
  70. Re: JBoss 5[ Go to top ]

    Hello Douglas, Nice to see how passionate you are about this :) Passion is good.
    ...I may not have absorbed everything in the post, but i know i am going to have ongoing problems with this thesis, as stated in the blog entry:

    "But what is interesting is that about 80% of those customers are not waiting for an EE5-certified application server, but want to leverage specific features of our AS 5.0 architecture (mostly our JBoss Microcontainer)."

    While this may be true, that a sample of customers were taken and the consensus seems to be that they will not be migrating their apps to EJB 3, etc..., I find it to be a poor job of understanding JBoss' role and competitive advantage in the wider middleware space:

    if JBoss 5 does not get customers to move to JEE 5, then it will be a Vista-like failure, where upgrades will be simply about extending e.o.l. support contract timeframes, and will not deliver the technical benefits of a revised specification, nor the new business opportunities for JBoss to go after....
    Douglas, I think you misunderstood what I wrote. I never said that EE5 or EJB3 weren't important. What I wrote is that JBoss 4.2.x *already* provides a BIG chunk of what is interesting in EE5. As part of JBoss AS 4.2.x, we ALREADY provide a complete EJB3 container, an EE5 WS stack, etc. Consequently, customers that are eagerly waiting for our AS5 release, mostly do because: - they want to leverage AS5.0 specific features (like our microcontainer - OEM/ISV) - because their internal policies require that they use a EE5 *certified* AS (and 4.2.x is not EE5 certified) As you probably remember, we have been big proponents of the EJB3 and JPA specs (we have provided the first implementation to market years ago) So we are certainly not shying away from EE5, we have spent a lot of time, energy and innovation into it.
    in short, Sacha, watch your marketing of JBoss 5 as a fancy, techno, micro-container innovation, especially at the expense of application component development innovations, because there is this little company called SpringSource that is currently eating your lunch...
    Again, read my blog: we are perfectly aware that many of our customers are using very different APIs to leverage our AS services. Most of them rely on EE, some of them on Spring, etc. And that's fine. I don't really mind which "wrapper API" they are using: we are here to support them in their preferred scenarios. What matters is how flexible our underlying foundation is so we are able support these multiple scenarios. Having an API-agnostic core is key to longevity of your investment. This doesn't mean we don't care about these API/programming model, but they are really two different concerns.
    my suggestions is to get back on message with promoting JEE, and establishing JBoss 5 as the pre-eminent deployment platform for all things JEE on Linux, and start making a ton of money; nothing says market opportunity for Seam, like hundreds of new installations of JEE 5 shops that adhere to the full complement of the spec...

    that is boring, and I understand Muzilla is on the 're-factoring' angle, so i am not going to scold, or question, i just think that there is real competition now, with Oracle, IBM, Glassfish, Spring, and .Net to compete with JBoss:

    u guys need to execute like hell, and prove to everyone why u won the leadership position in the 1st place...
    (NOTE: we are a multi-OS solution, ew are not a Linux-only solution. We certify all of our platforms at least on Windows, Linux, Solaris, HP-UX, AIX. This doesn't mean we are not working on synergies with the RHEL team, au contraire, but our platforms are OS-agnostic) As for the "boring" note, no need to sell me on this. Communities like TSS are not representative of the IT world out there. Posters are usually versed into new buzz, innovations and are very vocal. That's great, but it would be a mistake to think there is a one-to-one mapping between this community and the middleware market at large. Our job at JBoss is to make sure we provide what the largest number of "real life" users need out there *and* work on innovation for what's needed tomorrow (much like we did with EJB3 and JPA and what we do now with WebBeans). They are complementary tasks, they are not exclusive.
  71. Congratulations to JBoss.[ Go to top ]

    JBoss is a big deal for our industry and a big deal for free software. It is good to see that it is healthy, alive and kicking and still doing the most interesting stuff of any container. Congratulations! As far as deployment goes (at least in the financial industry), Glassfish/Jonas and the other free containers are few and far between and JBoss has stayed strong and continues to grab marketshare away from Weblogic/Websphere. As for EJB3/Spring. I couldn't stand EJB before 3 but EJB3 was a remarkable move forward. Personally, I'm a big Spring fan and use it every day (even with EJBs), but for apps that need the full services of a container (db access/modeling, hot-deploy, message-queing, transaction management, efficient RPC), "rolling my own" in Spring is really a much harder option (believe me I've tried) and there is something to be said for a pre-integrated enterprise stack that you don't have to write reams of XML to weave together from scratch. So thanks, Redhat/Jboss for a major architecture refactoring, a brave push into component architecture for services and please keep the releases rolling.
  72. Re: Congratulations to JBoss.[ Go to top ]

    ...and still doing the most interesting stuff of any container
    Are you sure? Mural MDM, Comet Ajax, native integration with second best IDE in the world (NetBeans) much? Adding support for "JAR files with lifecycle", aka OSGi and similar is hardly innovation.
  73. Re: The status of JBoss AS 5[ Go to top ]

    Congratulations to the JBoss team. We're on an older version of JBoss, but even when JBoss 3 came out it was obvious that there were going to be non-standard pieces of JBoss that existed primarily because certain customers requested certain features. I don't see what's so wrong with that. More kudos will be expected when it's released.
  74. CR to GA[ Go to top ]

    When is the GA? Hope it is not another few years.
  75. Either this guy should be hired by RedHat as a strategic technical blah, or should be fired by his current employer. Seriously dude, what's your major malfunction?
  76. What exactly is wrong with his post? I did see some of yourother post and they are merely useless one-two liners wiht no real technical stuff in them. So what's YOUR major malfunction?