Hands-On: Is JBoss Ready for Your Enterprise?

Discussions

News: Hands-On: Is JBoss Ready for Your Enterprise?

  1. Hands-On: Is JBoss Ready for Your Enterprise? (41 messages)

    Executive Overview
    Among topics covered in this article are:

    A 6-step assessment of JBoss' maturity -- or enterprise-readiness. Areas investigated include: (a) Software, (b) Support, (c) Documentation, (d) Training, (e) Product integration, and (f) Professional Services

    An overview of the Open Source Maturity Model (OSMM), a product-independent methodology that architects/developers can use to assess the suitability of a wide range of Open Source offerings; and

    JBoss total "score" for enterprise-readiness, along with suggestions for weighting values based on your enterprise's risk tolerance and in-house available skills.

    It's been about a month since JBoss, the Open Source J2EE application server, received its full certification from Sun.

    Now, in the first detailed, hands-on review of JBoss offerings -- technologies, service and documentation, Integration Developer News turns to Open Source Java expert Bernard Golden to answer the question, "Is JBoss a good fit for your enterprise?"
    Is JBoss Ready for Your Enterprise?

    Threaded Messages (41)

  2. They missed JBossIDE[ Go to top ]

    Looks like a point in the software area was lost due to a lack of IDE integration, which is incorrect. With this included, the score would be 82.

    I personally find these rating systems only useful for a first pass survey of an area of interest. You have to roll up your sleeves to get into the details, like what JBoss's Unified Class Loader actually means for deploying multiple applications and off the shelf components, how clustering works etc. It all goes back to requirements.


    Sherman
  3. They missed JBossIDE[ Go to top ]

    Looks like a point in the software area was lost due to a lack of IDE integration, which is incorrect. With this included, the score would be 82.I personally find these rating systems only useful for a first pass survey of an area of interest. You have to roll up your sleeves to get into the details, like what JBoss's Unified Class Loader actually means for deploying multiple applications and off the shelf components, how clustering works etc. It all goes back to requirements.Sherman
    I definately know JBuilder supports JBoss. Talked to one of their developers at JavaOne. IDEA has a JBoss plugin I think. Lomboz project supports JBoss (Eclipse). And JBoss.org has JBoss IDE (further eclipse integration).

    Bill
  4. They missed JBossIDE[ Go to top ]

    Looks like a point in the software area was lost due to a lack of IDE integration, which is incorrect. With this included, the score would be 82.I personally find these rating systems only useful for a first pass survey of an area of interest. You have to roll up your sleeves to get into the details, like what JBoss's Unified Class Loader actually means for deploying multiple applications and off the shelf components, how clustering works etc. It all goes back to requirements.Sherman
    I definately know JBuilder supports JBoss. Talked to one of their developers at JavaOne. IDEA has a JBoss plugin I think. Lomboz project supports JBoss (Eclipse). And JBoss.org has JBoss IDE (further eclipse integration).Bill
    And all of you guys missed forgot about the excellent MyEclipseIDE.

    It is a high-quality set of eclipse plugins, including appserver(JBoss 2,3,4 + lots of others) plugins that let's you quickly deploy and debug J2EE application while running your appserver of choice inside of eclipse.
  5. Not in the same league...[ Go to top ]

    Looks like a point in the software area was lost due to a lack of IDE integration, which is incorrect. With this included, the score would be 82.I personally find these rating systems only useful for a first pass survey of an area of interest. You have to roll up your sleeves to get into the details, like what JBoss's Unified Class Loader actually means for deploying multiple applications and off the shelf components, how clustering works etc. It all goes back to requirements.Sherman
    I definately know JBuilder supports JBoss. Talked to one of their developers at JavaOne. IDEA has a JBoss plugin I think. Lomboz project supports JBoss (Eclipse). And JBoss.org has JBoss IDE (further eclipse integration).Bill
    And all of you guys missed forgot about the excellent MyEclipseIDE. It is a high-quality set of eclipse plugins, including appserver(JBoss 2,3,4 + lots of others) plugins that let's you quickly deploy and debug J2EE application while running your appserver of choice inside of eclipse.
    Having played with JBossIDE recently, it does not hold a candle to what you can do with WebSphere in WSAD. And I say this as a JBoss certified engineer :). In any case, according to the guy's methodology, it doesn't really make any difference - it's still deployable in production by early majority organizations.
  6. Not in the same league...[ Go to top ]

    But it is websphere in wsad ;-)
  7. They missed JBossIDE[ Go to top ]

    Yes, JBuilder supports JBoss (we are using this).
    And Jdeveloper (Oracle) do support deployment for JBoss too

    Dmitry
    http://www.servletsuite.com
  8. Recovery log[ Go to top ]

    Does it have a recovery log now? The ability to survive a crash is important.
  9. Recovery log[ Go to top ]

    Does it have a recovery log now? The ability to survive a crash is important.
    Especially if you're going to run it on Win32!!!

    -John-
  10. Recovery log[ Go to top ]

    Does it have a recovery log now? The ability to survive a crash is important.
    ??? I thought recovery logs was a feature of DB engines. I've never seen that in a J2EE application server. Did you mean a JTA transactions recovery service, used to automatically switch the started JTA transactions to another server in the cluster in case of failure ?
  11. Recovery log[ Go to top ]

    Does it have a recovery log now? The ability to survive a crash is important.
    ??? I thought recovery logs was a feature of DB engines. I've never seen that in a J2EE application server. Did you mean a JTA transactions recovery service, used to automatically switch the started JTA transactions to another server in the cluster in case of failure ?
    It is for transactions that contain more than one transactional resource, or "Resource Manager" (RM) in OTS parlance. For example, let's say I have MQ Series and an Oracle database, and one of my transactions processes a message from MQ Series and does updates to Oracle. If I fail to commit, then I don't want my partial changes being made to Oracle, which is what a simple JDBC transaction does for me. Even more importantly, if I fail to commit, then I want someone else to get the message from MQ Series, as if I had never seen it.

    This is called "recoverable two-phase commit with multiple resource managers," and implies that a recoverable transaction manager log the various steps that it goes through when it commits a transaction. In this case, the "transaction" is a virtual construct with two "branches" - one going to an Oracle transaction and one going to MQ Series. Let's consider what can happen:

    1) Something screws up and we roll back the transaction. In this case both branches are rolled back, and everyone is happy. Since we never tried to commit (i.e. we never "prepared" the transactions,) each of the branches would know to automatically roll back if a certain time period passed without notification. This is called "assumed rollback before prepare."

    2) Nothing screws up and we commit the transaction. This commit in turn prepares both branches, and if both succeed, then it does a commit on both branches. Everyone is happy.

    3) The problem areas exist only once the first branch is requested to prepare, until all branches have been either committed or rolled back. For example, if both branches are prepared, but then the server calling "prepare" and "commit" dies before it gets both "commit" commands out. In this case, the transaction is left hanging and has to be either manually "rolled forward" or "rolled back," or the transaction log needs to be recovered.

    This "transaction log" thingie is basically a record of all the potential problem points (prepares, commits, post-prepare rollbacks) that the server managing the "virtual transaction" has encountered. The problem is that when the server restarts and reads its log, it doesn't have the old JDBC connection object that it was using to manage the Oracle transaction, and it doesn't have whatever JMS (etc.) objects that it was using to manage MQ Series. So now it has to somehow contact Oracle and MQ Series and figure out "what's up." The way that it keeps track of the transactions that it no longer has "references" to is to create identifiers for the transactions and each branch of the transaction. These are "transaction IDs", or "XIDs" since "X" is often used to abreviate "transaction." These XIDs are logged in a special kind of file (called a transaction log) that is supposed to be safely flushed to disk at each stage (note that I gloss over the details because entire books are written on this tiny subject) so that when the server comes back up, it is sure to be able to find out everything important that happened before it died.

    Now, getting back to the JBoss question, it used to have a non-recoverable implementation, meaning that if the server died during 2PC processing, those transactions would not be recoverable by JBoss. I haven't looked lately, so it could have been fixed already .. there are several open source projects that they could have glued in to resolve it with minimal effort. (JBoss is 90% "other projects" anyway .. which is one of the benefits of being able to make new open source stuff out of existing open source stuff.)

    As far as whether it is an important feature is largely irrelevant to most "J2EE" applications, since they have exactly one transactional resource -- the database. However, "enterprise" applications often have more than one RM, and in fact that is what qualifies the applications as being "enterprise" -- the fact that they have to glue together lots of ugly crap from previous "enterprise" applications that in turn glued together ugly crap from previous generations and so-on. (For some reason, some people think that "enterprise applications" are just apps that have lots of users. If that were the case, Yahoo! would be an "enterprise application." ;-)

    The funny thing about this particular article is that it's written by a guy who gets paid to sell you open source solutions, so he's writing an article that says it's OK for you to pay him to sell you on JBoss. That doesn't mean that he's right or wrong, it just means that the article is about as objective as a marketing user story .. but at least it was submitted to TSS by the US Chamber of Commerce. ;-)

    To answer the question, is JBoss ready for enterprise deployment .. that's a tough one. I know what Bill Burke would say, and if you had Bill Burke working for you full time, then you would probably be comfortable using JBoss for some enterprise deployments. I think that the best way to ascertain the applicability of JBoss (or any product) to a particular problem is to find users who were braver than you and already tried it to solve a similar problem. Further, it's more than just asking "Does it work?" but also finding out "How does it react when things go wrong?" For example, without a recovery log, JBoss will work fine with 2PC transactions .. until a JBoss server crashes. How does it react when you reboot the server? How do you deal with heuristically mixed transactional outcomes? Is it a manual process? Do you know how to resolve the problem? How much does it cost to get support from JBoss to answer the questions?

    JBoss if fine for 90% of "J2EE" applications. In fact, it's probably overkill for the 75% of those that should just use Caucho Resin. ;-) The question remains, is it fine for "enterprise deployments." I'm not convinced, but it's only a matter of time until it (or Apache Geronimo) gets there.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  12. Recovery log[ Go to top ]

    If you really need 2PC in your application (most apps don't - yes, even so-called "enterprise" apps), you can easily plug in either Arjuna's or Iona's TM, both of whom have a partnership with JBoss. This option is a lot less expensive than buying WebSphere or WebLogic. Lots of JBoss shops are doing this; most simply don't need to.

    By the way, Cameron is wrong to say that you need this whenever your app has two transactional resources. You only need it if you access two transactional resources *simultaneously*, and *transactionally*, and can afford to bear the performance cost of the 2PC protocol. When I have worked on apps like this, recovery was always done, not via 2PC, but via application-level mechanisms. And yes, this was all on WebSphere and MQ Series.

    Cameron is, in his usual style, succeeding in implying all kinds of nasty things about the reliability of JBoss, combined with some kind of weird snide ad hominem at Bill, without actually saying anything that the original poster did not already say: "JBoss does not, at present, have a transaction log". It's best to ignore Cameron, open source scares him to death :-)

    (Jus' jokes, Cameron, don't take it serious!)
  13. references[ Go to top ]

    Cameron wrote: I think that the best way to ascertain the applicability of JBoss (or any product) to a particular problem is to find users who were braver than you and already tried it to solve a similar problem. Further, it's more than just asking "Does it work?" but also finding out "How does it react when things go wrong?
    Feel free to contact our sales department at sales at jboss dot org to get the long list of customers (now these are just JBoss Inc. customers) that are using JBoss in production.

    Looking at the Middleware app server paper you'll see that JBoss is 3rd behind WLS and Websphere for production use. Go back 2 years ago and you'll see these numbers skewed much more towards IBM/BEA. Goes to show how quickly people are adopting jboss as we are the fastest growing in app server market share.

    Bill
  14. Recovery log[ Go to top ]

    By the way, Cameron is wrong to say that you need this whenever your app has two transactional resources. You only need it if you access two transactional resources *simultaneously*, and *transactionally*, and can afford to bear the performance cost of the 2PC protocol. When I have worked on apps like this, recovery was always done, not via 2PC, but via application-level mechanisms. And yes, this was all on WebSphere and MQ Series.
    Actually, I thought that I explained all of that. Some apps still require 2PC corrections to be made manually, not using "recoverable" logs at all. Since you have used MQ Series, you are probably aware of how many difficult challenges there are related to this particular subject.
    Cameron is, in his usual style, succeeding in implying all kinds of nasty things about the reliability of JBoss ..
    Hmm .. that's interesting. I went back and re-read my post and didn't see all kinds of nasty things. Is there anything in particular that you are referring to?
    .. combined with some kind of weird snide ad hominem at Bill ..
    To the contrary, I was pointing out that I'd feel a lot more comfortable having someone technical available on staff who understands the workings of JBoss. It was intended to be a compliment to Bill, not "some kind of weird snide ad hominem." I am starting to think that you are getting paranoid. ;-)
    It's best to ignore Cameron, open source scares him to death :-)
    This conversation was not about open source, Gavin; it was about JBoss. I am, and long have been a supporter of open source. You will find that there are people who can support open source without putting on blinders.

    I appreciate your technical clarifications on what I wrote; I felt that I had objectively provided an explanation to what was asked. If there are areas that are wrong, or need more information, then by all means provide it. I have no problem admitting when I am technically incorrect. Were you bothered by the technical content of my post, or is it that I did not endorse JBoss as a product that is truly ready, without question, for enterprise deployment? And, if the latter, are you suggesting that I should censor any dissenting technical opinions because JBoss is open source?

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  15. paranoia[ Go to top ]

    I am starting to think that you are getting paranoid. ;-)
    Dude, I ain't _starting_ anything, been paranoid longer than you have known me :-)
    Is there anything in particular that you are referring to?
    Your post attempts to raise questions about the reliability of JBoss, without actually risking coming out and taking a position on the subject, or actually offering any evidence either way. It's like if I say: "does Cameron Purdy beat his wife? Well, you'll have to ask someone who knows Cameron's family better than I do...." I plant the suggestion in the reader's mind, but don't actually have to provide any evidence for it.

    It's a kinda cowardly way of saying something, without actually being able to be held reponsible for really saying it.

    I dunno, I mighta got you wrong. Just I notice that you often post things that sorta seem to have a point but then when read closely don't actually make that point after all, and could be maybe interpreted as mere fence-sitting.

    Anyway, don't mean to be too down on you ... you asked ... I most certainly AM paranoid :-)
    It's not And, if the latter, are you suggesting that I should censor any dissenting technical opinions because JBoss is open source?
    eh?? censor? who said censor? I merely suggested that your post is ignorable. A quite different thing....
  16. paranoia[ Go to top ]

    Gavin: "does Cameron Purdy beat his wife? Well, you'll have to ask someone who knows Cameron's family better than I do...."
    Well, if Cameron did indeed beat his wife and she (got forbid) disappeared afterwards, then there would be no way for us to find out what really happened without the transaction log.

    :-)

    Regards,
    --Dmitriy.
  17. Recovery log[ Go to top ]

    Cameron wrote: I felt that I had objectively provided an explanation to what was asked. If there are areas that are wrong, or need more information, then by all means provide it.
    Since JBoss Cache basically competes with Tangesol's key offering, any comment you make about JBoss should be taken with skeptism.
  18. Recovery log[ Go to top ]

    Since JBoss Cache basically competes with Tangesol's key offering, any comment you make about JBoss should be taken with skeptism.
    And vice versa. Even worse, how do we know that Cameron is the author of the comment? Or that the above isn't Joe Murray posing as "Bill Burke"? BTW, is this "Bill" for real or not in the first place?

    These days you can't trust anyone on anything, so it's best to be sceptical of everything and everyone at any time, at least with regard to online forums, and use personal experience to validate anyones claims, both positive and negative.

    My personal experience with regard to this topic is that, for example, the JVM on NetWare has a tendency to die quite abruptly, which may leave transactions hanging in the middle. Having software that either can handle such situations directly or can recover from it is pretty nice to have.

    From the comments on this thread one might guess that JBoss isn't that good at handling recovery for advanced scenarios. But don't take their word for it! Go out there and pull the power plug on those servers and find out! :-) Then you'll know.
  19. Recovery log[ Go to top ]

    Hi Bill,
    Cameron wrote: I felt that I had objectively provided an explanation to what was asked. If there are areas that are wrong, or need more information, then by all means provide it.
    Since JBoss Cache basically competes with Tangesol's key offering, any comment you make about JBoss should be taken with skeptism.
    First, itÂ’s Tangosol.

    Second, following your exact logic, every comment you make that deals with Application Servers, AOP, Clustered Caching, ORM frameworks, Apache Servlet Containers, *Nukes, clustered communication frameworks, IDEs, Java bytecode manipulation and/or Mail Servers should be taken with skepticism. Let's not forget JDO as well. The order of this list should look familiar to you.

    Later,
    Rob Misek
    Tangosol, Inc.
    Coherence: It just works.
  20. Recovery log[ Go to top ]

    Bill Burke :
    Cameron wrote: I felt that I had objectively provided an explanation to what was asked. If there are areas that are wrong, or need more information, then by all means provide it.
    Since JBoss Cache basically competes with Tangesol's key offering, any comment you make about JBoss should be taken with skeptism.
    Are there quantitative results on how they compete with each other? Any performance measurements?

    - geir
  21. Recovery log[ Go to top ]

    If you really need 2PC in your application (most apps don't - yes, even so-called "enterprise" apps), you can easily plug in either Arjuna's or Iona's TM, both of whom have a partnership with JBoss.
    If you write MDBs and you use separate jms and ejb servers, you need two-phase commit.

    And the coordinator needs a recovery log. That's true even for a toy application. So it's not far fetched.

    However, if all your XA Resources are JBoss-implemented (JMS, EJB Container, etc.) then you can use the XA one-phase optimization, meaning there is only one recovery log, which is the database log.

    But if you want to use MQSeries to send messages to MDBs inside JBoss, for example, and those MDBs use, say, DB2, then you probably need to add a recovery log to the JBoss Transaction Manager.

    So that answers the question. What I can't understand is why this is not considered a priority. I don't dare ask about TCP/IP multiplexing ...
  22. 2PC[ Go to top ]

    Like I said , whenever I have encountered the scenario of message server + database in actual *real applications* (as opposed to in books), and it is most certainly a common scenario, the failure cases were handled at the application level, not via use of 2PC. Now, perhaps my experience is atypical, and that there are many people out there using 2PC. But it seems that whenever I talk to people and ask "are you using 2PC in *your* application?", the answer is invariably "no". (And it's a question I ask quite often, by the way...)

    It would be very, very interesting to so some actual surveys to find out exactly how many J2EE applications use XA. The impression I get is < 1%. Could be wrong, it's pure speculation.

    Now, I most certainly agree that JBoss should have the functionality, if only for marketing purposes (it's a big FUD point). I merely disagree that it is really that important in practice.
  23. JMS and XA[ Go to top ]

    My favourite message in JBoss ( yes I am a JBoss user and in production ):
    16:17:27,550 WARN [TxConnectionManager] Prepare called on a local tx. Use of local transactions on a jta transaction with more than one branch may re
    sult in inconsistent data in some cases of failure.

    Fortunatelly we are not using JMS (in our case MDBs) for anything critical because of the above, but yes it would have been nice to have 2PC rather than doing a lot of if else at the application level to see if something wrong has happened.

    Not so sure about the number of people actually doing XA in applications, but another question is how many people realize that they are doing XA(or could have relied on XA) behind the scenes i.e. there's lots of questions in the JBoss forum with regards to what the above message means, and that message used to be even more cryptic in earlier versions of JBoss.

    Regardless, I still think JBoss is a good product (otherwise we will not be using it :).
  24. 2PC[ Go to top ]

    I'am a former employee of Bea, on the profesional services area and i must say that aprox. 80 percent of the projects i work on were related to system integration, of course WL (Tuxedo on its happy days) in the middle of n legacy / RDBMSs / sync.-async. messaging systems, etc. So for me in that time XA was a need.

    By the way, today i'am an open source enthusiast (not trying to put a WL-Jboss discussion ;-))
  25. 2PC[ Go to top ]

    Hum, I might be wrong, I guess it all depends where your background is....

    *shrug*
  26. 2PC[ Go to top ]

    It would be very, very interesting to so some actual surveys to find out exactly how many J2EE applications use XA. The impression I get is < 1%. Could be wrong, it's pure speculation.Now, I most certainly agree that JBoss should have the functionality, if only for marketing purposes (it's a big FUD point). I merely disagree that it is really that important in practice.
    Since that is your impression, I think we can conclude that since you don't have that feature, you are not getting any of that business. I think if you put it in, then you will see a whole other sector of applications. Right now, I can't use JBoss at work for this reason.
  27. 2PC[ Go to top ]

    Oh, I was referring mainly to my work as a WebSphere consultant, before I actually joined JBoss. These days I'm just living in my insular little ORM world ;-)
  28. 2PC is not for FUD[ Go to top ]

    the failure cases were handled at the application level, not via use of 2PC.
    If it was that simple, then why there was a need for xa_recover in XA/DTP spec ?
     

    whenever I talk to people and ask "are you using 2PC in *your* application?", the answer is invariably "no".
    Make sure people you ask understand what is XA or 2PC ;)
    Also you have to be working in those projects where there are multiple "simultaneous" transactional resources. Those apps do exist, I am pretty sure :-)
  29. 2PC[ Go to top ]

    Like I said , whenever I have encountered the scenario of message server + database in actual *real applications* (as opposed to in books), and it is most certainly a common scenario, the failure cases were handled at the application level, not via use of 2PC. Now, perhaps my experience is atypical, and that there are many people out there using 2PC. But it seems that whenever I talk to people and ask "are you using 2PC in *your* application?", the answer is invariably "no". (And it's a question I ask quite often, by the way...)It would be very, very interesting to so some actual surveys to find out exactly how many J2EE applications use XA. The impression I get is < 1%. Could be wrong, it's pure speculation.Now, I most certainly agree that JBoss should have the functionality, if only for marketing purposes (it's a big FUD point). I merely disagree that it is really that important in practice.
    Well, I think you were offbase on Cameron's post (look back, he was answering someone's question on what the transaction log is for), but I can give an example of why you're right here.

    We used to let exceptions roll back our 2PC transactions across a JMS Queue and an XA JDBC connection... Until we had to port to WebSphere. It turns out WebSphere likes to kick you when you're down. It does roll back the transaction, and the read of the Message from the Queue is rolled back... but then it shuts down the Queue and no more messages are delivered. For this reason we have to make the JMS read and the work done against the database be separate transactions, and we ALWAYS read the message and catch all exceptions coming out of the REQUIRES_NEW transaction. If an exception happens in the inner transaction, we re-queue the message and manually keep track of the number of retries.

    As an aside, WebLogic's JMS has these retry features plus Queue failover... It's definitely ready for the enterprise. I haven't used JMS on JBoss, how robust is it?
  30. 2PC[ Go to top ]

    Well, I think you were offbase on Cameron's post
    I may indeed be offbase; as Cameron correctly points out, I am paranoid, especially when posting on TSS at 3 AM Melbourne time. Cameron: I'm sorry man, do you still love me? :-)
    I can give an example of why you're right here
    I was thinking even beyond that - I mean, when you are dealing with other legacy applications, the assumption that all your XA resources and all the receivers at the other end of your message queue exhibit well-behaved fully ACID behavior is ... well ... very "idealistic". ;-)

    At your end, you may be doing some perfect textbook two-phase commit - but if the legacy applications at the other end have a funny habit of, say, mysteriously "losing" one transaction every day or so, then all that work might have been really a bit pointless, and you are going to need to implement application-level mechanisms *anyway*.
  31. 2PC[ Go to top ]

    I may indeed be offbase; as Cameron correctly points out, I am paranoid, especially when posting on TSS at 3 AM Melbourne time. Cameron: I'm sorry man, do you still love me? :-)
    Of course, but if you were my wife, I'd have to beat you ;-)

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  32. haha[ Go to top ]

    LOL!
  33. children[ Go to top ]

    Sometimes I think you guys haven't realised the profile you've built in the java space or you wouldn't be carrying on like such children.

    I'm sure these sorts of antics (and particularly Marc's) hurt the perception of open source in the enterprise _more_ then technical issues.

    Best Regards.
  34. children[ Go to top ]

    Sometimes I think you guys haven't realised the profile you've built in the java space or you wouldn't be carrying on like such children.I'm sure these sorts of antics (and particularly Marc's) hurt the perception of open source in the enterprise _more_ then technical issues.Best Regards.
    Well, your point is well-taken.

    I guess its a sign of how much open source developers tend to *care* about their projects, compared to developers who write software for other people. Also remember that most of us made our projects successful in the first place via very nontraditional ways of getting our message out; we just didn't have teams of salespeople pushing our stuff. It was Just Us.

    In addition, OSS projects are just so much more open in general, with so much of what goes on, going on online - in publicly visible places - that perhaps we forget ourselves. We're not trying to hide stuff, and so we get into the habit of telling people what we think. It's not a massaged, vetted, marketing spin. It's raw and off the cuff. I can understand how that makes people uncomfortable. But, on the bright side, at least you know we aren't lying to you...

    peace
  35. 2PC[ Go to top ]

    <blockquoteif the legacy applications at the other end have a funny habit of, say, mysteriously "losing" one transaction every day or so, then all that work might have been really a bit pointless, and you are going to need to implement application-level mechanisms *anyway*.That's not typical of legacy transaction systems in my experience. These old beasts are often pretty good at making sure transactions don't disappear: one reason why they stay around.

    Compensations are a royal pain to do correctly without compensation based infrastructure, something that has never taken off despite lots of work in this area. What you're proposing is surely necessary sometimes, but probably the least desireable consistency strategy I can think of, especially when dealing with database intensive applications.

    There are whole solution domains that require extensive use of transactions. I'm sure they don't represent a majority of web applications by any stretch of the imagination, but app servers tend to be used to solve a wide range of problems these days. Using global transactions indiscriminately is a poor idea at best, but suggesting they aren't used or useful is not realistic.

    Greg
  36. Recovery log[ Go to top ]

    However, if all your XA Resources are JBoss-implemented (JMS, EJB Container, etc.) then you can use the XA one-phase optimization, meaning there is only one recovery log, which is the database log. But if you want to use MQSeries to send messages to MDBs inside JBoss, for example, and those MDBs use, say, DB2, then you probably need to add a recovery log to the JBoss Transaction Manager.So that answers the question.
    Is this because MQ Series is not JMS/XA compliant ?
    http://eservercomputing.com/iseries/articles/index.asp?sid=10&id=568&pageID=570 :
    "JMS/XA not possible with pub/sub messaging because of remote broker shortfall."
    If so, it is a problem of MQSeries and not of JBoss. I don't know why JBoss should provide a workaround for a shortcoming in an external message broker. But, I can be wrong.
  37. Recovery log[ Go to top ]

    However, if all your XA Resources are JBoss-implemented (JMS, EJB Container, etc.) then you can use the XA one-phase optimization, meaning there is only one recovery log, which is the database log. But if you want to use MQSeries to send messages to MDBs inside JBoss, for example, and those MDBs use, say, DB2, then you probably need to add a recovery log to the JBoss Transaction Manager.So that answers the question.
    Is this because MQ Series is not JMS/XA compliant ?http://eservercomputing.com/iseries/articles/index.asp?sid=10&id=568&pageID=570 :
    "JMS/XA not possible with pub/sub messaging because of remote broker shortfall."
    If so, it is a problem of MQSeries and not of JBoss. I don't know why JBoss should provide a workaround for a shortcoming in an external message broker. But, I can be wrong.
    Thank for pointing this out. However, you are talking about pub/sub, i.e. JMS _Topics_. I was talking about PTP, or JMS _Queues_. IBM is just saying that with pub/sub they don't support xa transactions, which is not so bad. Some message brokers use multicasting to implement pub/sub, to allow for large numbers of receivers. But in that case I think the prevalent practice would be to use non-transactional messaging.

    So I think in this case IBM is just being its usual understated self.
  38. Recovery log[ Go to top ]

    So I think in this case IBM is just being its usual understated self.
    I can be wrong as I haven't used MQSeries for a long time. Can MQSeries 5.2 do pub/sub ? I'm pretty sure MQSeries 5.1 couldn't, but I'm not sure about 5.2. If not, they're rather self overstating.
  39. Recovery log[ Go to top ]

    Not sure of the version but MQ Series can do pub/sub. I could at least 2 years ago.
  40. The rationale behind the numbers in these categories seemed a bit flawed to me.

        A) The assertion that having an integrated IDE has anything to do with whether a product is ready to go into production seems bizarre. Integrated IDEs (whether they are from the same company or not) can be important to developers, however, it seems strange that whether or not a company has an integrated IDE can be the difference between whether the product is O.K. for a pilot project or production (which it seems is possible in this model).

        B) This analysis seems to dart around the real issues around whether this is something you want to put in your data-center, such as: what happens when it crashes, has it been in large deployments (and how has it faired), how is it's performance, how is it's reliability, etc. Even the support questions are more of a check-box issue rather than a real rating of whether it is good enough for production. Saying there are nine patches a month does not mean anything without context. How many patch requests are there a month? How fast is average turn around? How bad to the bugs that are being patched? If you have 9 data-corruption level bugs a month, this means something different than having 9 obscure performance bugs a month.

    I feel like I could apply the same rationale as this article to Microsoft Access and come up with the conclusion that it was good enough to go into my data center.

            --Will (Ex-BEA employee)
  41. Make up your own mind....[ Go to top ]

    For web applications, my experience shows that yes, JBoss is ready...

    www.bolt.com
  42. Methodology for assessing software[ Go to top ]

    One shortcoming of this report is that its entire evaluation of the "software" aspect of JBoss is "It fully conforms to J2EE and passes the test suites." While it's certainly good that JBoss does this, it is not fair to evaluate any J2EE application server merely by noting whether it fully conforms to the J2EE specification, because the specification leaves a lot of aspects of the application server open, and there is a tremendous amount of room for individual application servers to provide facilities, features, robustness, scalability, performance, and so on and so forth. A simple observation about conformace to the spec omits all of these factors. Each of the application servers has strengths and weaknesses in these areas. I had hoped to see a deeper dicussion of JBoss. I found the report disappointingly superficial in this respect.