Discussions

News: BEA adds support to Weblogic for Spring

  1. BEA adds support to Weblogic for Spring (150 messages)

    BEA rearchitected their sample application to use Spring and included this with their "Spring on WebLogic Server kit". In "Spring Integration with WebLogic Server", BEA took a traditional J2EE application using Stateless Session Beans and Struts and rewrote it with Spring using POJOs sans the EJBs. The application employs Spring support for JMS (JMSTemplate), Spring remoting (using JAX-RPC Invoker, Web Services), Spring JDBC support and more.

    If you are using Spring with WebLogic, the example is very valuable as it shows correct configuration of Spring's MBean support, WebLogicJtaTransactionManager (with Springs AOP based transaction support), and configuring Spring's remoting support for WebServices (via JaxRpcPortProxyFactoryBean).

    The document walks through an introduction of both Spring and WebLogic, and then dives into the architecture of the MedRec application. Oddly, the original architecture is referred to as the "J2EE" version and the Spring-enabled version is referred to as the "Spring" version, even though both run inside a J2EE container. Further, the architecture diagram used for the Spring version of MedRec shows direct use of JDBC for persistence, a trend most J2EE developers seem to avoid in favor of an ORM solution.

    BEA announced a formal business relationship with Interface21 at JavaOne 2005, saying that BEA would provide support for Spring in WebLogic. Likewise, Rod Johnson outlined a number of possibilities for Spring's future in relation to the application server.

    Do you think Spring is "committed" to WebLogic with this arrangement? Do you see similar capabilities being provided for other application servers? Should this feature set be part of Java, Enterprise Edition as a whole rather than a specific add-on framework?

    Threaded Messages (150)

  2. Re: BEA adds Spring support to Weblogic
    I think this is a really big if you are using WebLogic and Spring together. I have several clients that use these together (usually with Hibernate as well).


    IBM buys GlueCode (Geronimo support).

    Spring included in BEA with BEA support for Spring.

    BEA buys NitroX's M7.

    JBoss teams with MS.

    Do you see a pattern here?

    It seems like there is a lot of consolidation. What is driving all of this?

    --Rick Hightower
    CTO ArcMind, Inc.
    ArcMind
    blog
  3. what's driving it?[ Go to top ]

    Microsoft & JBoss? Win/Win... Microsoft marginalizes license revenue stream from traditional enterprise plays, JBoss gets interop credibility that in the past was really only assured between Sun, Microsoft, IBM, BEA, and Oracle (being the main WS-I members). The operations manager integration is an interesting one, wait & see. As for Hibernate/EJB3 on SQL Server, sounds fine but I doubt this means much beyond dedicating resources to ensure quality.

    IBM seems to be aquisition-happy, as usual. Buying Gluecode is a wait and see for me. Some analysts think people will en-masse evaluate Gluecode's next version, I haven't seen that pent up demand yet in my travels.

    BEA is playing a pragmatic game... listen to developers and embrace what they love -- like Eclipse, Spring & Hibernate -- but still grow license revenue on broader-picture problems (app server robustness, SOA, ESB, BPM, Portal, data integration, security, etc.). (Standard disclaimer that I work for BEA consulting, and the prior is just my opinion.)
  4. BEA adds support to Weblogic for Spring[ Go to top ]

    Do you see a pattern here? It seems like there is a lot of consolidation. What is driving all of this? --Rick Hightower CTO ArcMind, Inc. ArcMindblog

    Yes I see a pattern, but it is not a pattern of consolidation. Properietary vendors are scared shitless of open source so they are scurrying for a strategy. Well, not Microsoft, but definately BEA and IBM...As for Microsoft? I think Martin Lamonica had the best analysis of the Microsoft deal.
  5. BEA adds support to Weblogic for Spring[ Go to top ]

    Properietary vendors are scared shitless of open source so they are scurrying for a strategy. Well, not Microsoft

    Would that be a case of "oops, got to remember not to rubbish our new partner"? ;)
  6. Doesn't JBoss have a PR person?[ Go to top ]

    Properietary vendors are scared shitless of open source so they are scurrying for a strategy. Well, not Microsoft
    Would that be a case of "oops, got to remember not to rubbish our new partner"? ;)

    Doesn't JBoss have a PR person? ;)
  7. Doesn't JBoss have a PR person?[ Go to top ]

    Properietary vendors are scared shitless of open source so they are scurrying for a strategy. Well, not Microsoft
    Would that be a case of "oops, got to remember not to rubbish our new partner"? ;)
    Doesn't JBoss have a PR person? ;)

    PR be damned. I like the fact that Bill speaks his mind. I hope JBoss never becomes so corporate that its leaders stop cussing in public forums. :o)

    BTW Bill I went to your talk on AOP at the last TSS symposium. Eventhough I have never used the JBoss AOP API, I think your talk was one of the best I've seen on AOP.

    I saw your AOP talk at the first TSS symposium. You have really grown as a speaker (like 1000%). It is like you are a different person. Good work.
  8. BEA adds support to Weblogic for Spring[ Go to top ]

    Properietary vendors are scared shitless of open source so they are scurrying for a strategy. Well, not Microsoft
    Would that be a case of "oops, got to remember not to rubbish our new partner"? ;)

    Please don't take this personally, but...Use your brain, before you make such silly comments.

    Again, do a search for Martin Lamonica and jboss microsoft deal (forget which publication Martin writes for.) I think he analyzed our Microsoft partnership effectively. I'll spell it out for you: IBM/BEA/Sun's actions are in response to open source competition, while Microsoft saw the partnership as a way to put yet another nail into the coffin of IBM's middleware business.

    Bill
  9. BEA adds support to Weblogic for Spring[ Go to top ]

    Please don't take this personally, but...Use your brain, before you make such silly comments. Again, do a search for Martin Lamonica and jboss microsoft deal (forget which publication Martin writes for.) I think he analyzed our Microsoft partnership effectively. I'll spell it out for you: IBM/BEA/Sun's actions are in response to open source competition, while Microsoft saw the partnership as a way to put yet another nail into the coffin of IBM's middleware business.Bill

    Nail in the coffin? C'mon. No matter what you think of WebSphere (and believe me, I'm no fan), it's hard to deny that their market share has grown dramatically over the past 5 years and continues to grow (although at a somewhat slower pace). You guys would all be damn rich if you had IBM's datacenter penetration (i.e. please don't quote me your download numbers).
  10. Please don't take this personally, but...Use your brain, before you make such silly comments. Again, do a search for Martin Lamonica and jboss microsoft deal (forget which publication Martin writes for.) I think he analyzed our Microsoft partnership effectively. I'll spell it out for you: IBM/BEA/Sun's actions are in response to open source competition, while Microsoft saw the partnership as a way to put yet another nail into the coffin of IBM's middleware business.Bill
    Nail in the coffin? C'mon. No matter what you think of WebSphere (and believe me, I'm no fan), it's hard to deny that their market share has grown dramatically over the past 5 years and continues to grow (although at a somewhat slower pace). You guys would all be damn rich if you had IBM's datacenter penetration (i.e. please don't quote me your download numbers).

    +1

    While buying GlueCode was a response to JBoss, I hardley feel that IBM WebSphere is in a coffin. I am using Websphere Portal Server (It is the corporate standard with my current client).
  11. BEA adds support to Weblogic for Spring[ Go to top ]

    We know Fleury's history with Sun. 'Nuff said there.

    We know Fleury claimed some AOP partnership with IBM, with IBM saying "Excusing me? What in the world are you talking about?!?!".

    We know Fleury bashes BEA with every possible opportunity.

    So - who else is left for JBoss to partner with?

    BTW Bill - I'm sure you and your company's negative comments about IBM and Sun and open source go over real well in JSR meetings :-)
  12. We know Fleury's history with Sun. 'Nuff said there.We know Fleury claimed some AOP partnership with IBM, with IBM saying "Excusing me? What in the world are you talking about?!?!".We know Fleury bashes BEA with every possible opportunity.So - who else is left for JBoss to partner with?BTW Bill - I'm sure you and your company's negative comments about IBM and Sun and open source go over real well in JSR meetings :-)

    And Yet EJB3 looks more like JBoss + Hibernate (architecturally) than any other app server. Hmmmm.....
  13. Wanna some more Fleury ?[ Go to top ]

    For those not sick enough with the Bill Berk hyperbole, here's some Fleury-speak for ya. Can you spot the number of delusional statements in the article ?
  14. And for the reality check...[ Go to top ]

    There's this one
  15. BEA adds support to Weblogic for Spring[ Go to top ]

    Properietary vendors are scared shitless of open source so they are scurrying for a strategy. Well, not Microsoft
    Would that be a case of "oops, got to remember not to rubbish our new partner"? ;)
    Please don't take this personally, but...Use your brain, before you make such silly comments.

    Have you had your sense of humour completely removed in an operation or something?
    I thought the smily-face would kind of hint at the fact that it was meant as a joke...
    Lighten up for godness sakes.
  16. BEA adds support to Weblogic for Spring[ Go to top ]

    I'll spell it out for you: IBM/BEA/Sun's actions are in response to open source competition
    And your deal with Microsoft is in response to IBM and BEA's actions. Business as usual.

    Congratulations on your deal, but it's no different from the WS interop deal that Sun concluded with Microsoft last year, and no different from thousands of other deals that happen in our industry every year.

    --
    Cedric
  17. BEA adds support to Weblogic for Spring[ Go to top ]

    Do you see a pattern here? It seems like there is a lot of consolidation. What is driving all of this? --Rick Hightower CTO ArcMind, Inc. ArcMindblog
    Yes I see a pattern, but it is not a pattern of consolidation. Properietary vendors are scared shitless of open source so they are scurrying for a strategy. Well, not Microsoft, but definately BEA and IBM...As for Microsoft? I think Martin Lamonica had the best analysis of the Microsoft deal.

    Okay, let's say you are right. What is Spring's motivation?

    Also why do you think Hibernate was left out of the example app?

    Most of my clients that use WebLogic do so with both Hibernate and Spring.

    SpringJDBC is fine. I think Spring + Hibernate is more prevalent than Spring + SpringJDBC.

    Why not have both examples? There are some tricks to get WebLogic/Hibernate/Spring working together properly (with certain configurations, like JTA and/or CMT). I have one client that wants to work with Hibernate, EJB 2 SSB, CMT and Spring.
  18. Rick
    Also why do you think Hibernate was left out of the example app?
    I believe that the app was ported from an existing JDBC-based version. I also believe that BEA have further plans for it (such as simplifying some of the JMX code with further use of Spring), so perhaps they will consider introducing O/R mapping at that point. The timelines were pretty tight, so there was a limit to the changes that could be made in phase 1.

    Rgds
    Rod
  19. BEA adds support to Weblogic for Spring[ Go to top ]

    Rod is correct. Timing was the reason for the current samples and nothing more as we extended the existing WLS sample application on a tight timeframe.

    Other items we would like to consider in upcoming versions of the samples include using Apache Beehive and the use of O/R mapping.

    Cheers,
    Shane
  20. Rick
    Also why do you think Hibernate was left out of the example app?
    I believe that the app was ported from an existing JDBC-based version. I also believe that BEA have further plans for it (such as simplifying some of the JMX code with further use of Spring), so perhaps they will consider introducing O/R mapping at that point. The timelines were pretty tight, so there was a limit to the changes that could be made in phase 1.RgdsRod

    Good to hear. Thanks.
  21. What is Spring's motivation?

    That should be pretty obvious.
    1. A boat load of consulting work for Interface21,
    2. BEA providing official support for Spring in WLS means that many large enterprises/corporations doing app development will really start adopting Spring more (i.e. the "standards" groups in these companies will lose their "you can't use that in production it's not a supported product!" veto).
    Do you see a pattern here? It seems like there is a lot of consolidation. What is driving all of this? --Rick Hightower CTO ArcMind, Inc. ArcMindblog
    Yes I see a pattern, but it is not a pattern of consolidation. Properietary vendors are scared shitless of open source so they are scurrying for a strategy. Well, not Microsoft, but definately BEA and IBM...As for Microsoft? I think Martin Lamonica had the best analysis of the Microsoft deal.
    Okay, let's say you are right. What is Spring's motivation?Also why do you think Hibernate was left out of the example app?Most of my clients that use WebLogic do so with both Hibernate and Spring.SpringJDBC is fine. I think Spring + Hibernate is more prevalent than Spring + SpringJDBC.Why not have both examples? There are some tricks to get WebLogic/Hibernate/Spring working together properly (with certain configurations, like JTA and/or CMT). I have one client that wants to work with Hibernate, EJB 2 SSB, CMT and Spring.
  22. What is Spring's motivation?
    That should be pretty obvious. 1. A boat load of consulting work for Interface21,2. BEA providing official support for Spring in WLS means that many large enterprises/corporations doing app development will really start adopting Spring more (i.e. the "standards" groups in these companies will lose their "you can't use that in production it's not a supported product!" veto).
    Do you see a pattern here? It seems like there is a lot of consolidation. What is driving all of this? --Rick Hightower CTO ArcMind, Inc. ArcMindblog
    Yes I see a pattern, but it is not a pattern of consolidation. Properietary vendors are scared shitless of open source so they are scurrying for a strategy. Well, not Microsoft, but definately BEA and IBM...As for Microsoft? I think Martin Lamonica had the best analysis of the Microsoft deal.
    Okay, let's say you are right. What is Spring's motivation?Also why do you think Hibernate was left out of the example app?Most of my clients that use WebLogic do so with both Hibernate and Spring.SpringJDBC is fine. I think Spring + Hibernate is more prevalent than Spring + SpringJDBC.Why not have both examples? There are some tricks to get WebLogic/Hibernate/Spring working together properly (with certain configurations, like JTA and/or CMT). I have one client that wants to work with Hibernate, EJB 2 SSB, CMT and Spring.

    That seems like a respectable motivation! I forwarded the message to all my clients that are using WebLogic. I think it is a good deal.
  23. James
    What is Spring's motivation?
    That should be pretty obvious. 1. A boat load of consulting work for Interface21,2. BEA providing official support for Spring in WLS means that many large enterprises/corporations doing app development will really start adopting Spring more (i.e. the "standards" groups in these companies will lose their "you can't use that in production it's not a supported product!" veto).
    A huge number of large enterprises are already heavily using Spring in production with excellent results. Spring is already part of the mandated standard architectures in many huge enterprise. For example, in the last month I have spent significant time with three clients who are standardizing on Spring: 1. a top 10 global investment and retail bank; 2. a huge government institution that is a household name worldwise; 3. a European institution that handles millions of mission-critical financial operations per day. Interestingly, those are all WebLogic or WebSphere accounts; all have evaluated open source application servers and found that (at least as yet) they don't meet their needs. (Yet, interestingly, two of them make some use of Tomcat.)

    But certainly, the validation of BEA will help to break down those barriers to adoption that remain in a minority of large enterprises. From the feedback I've received, not just those using WebLogic, either, although of course it is more significant if a client already has a relationship with BEA. Remember that BEA are used to supporting mission-critical systems. For them to "certify" Spring is far more than marketing; it reflects a lot of testing work and shows that they are confident that enterprise-class customers can safely use Spring. You can't make money supporting flaky software.

    But it's important to note that what BEA is doing is more recognizing the reality on the ground (large enterprise customers using or wanting to use Spring) than promoting Spring for its own sake. Which is a good thing; companies should listen to their customers.

    Rgds
    Rod
  24. BEA adds support to Weblogic for Spring[ Go to top ]

    A huge number of large enterprises are already heavily using Spring in production with excellent results. Spring is already part of the mandated standard architectures in many huge enterprise. For example, in the last month I have spent significant time with three clients who are standardizing on Spring: 1. a top 10 global investment and retail bank; 2. a huge government institution that is a household name worldwise; 3. a European institution that handles millions of mission-critical financial operations per day. Interestingly, those are all WebLogic or WebSphere accounts; all have evaluated open source application servers and found that (at least as yet) they don't meet their needs. (Yet, interestingly, two of them make some use of Tomcat.)But certainly, the validation of BEA will help to break down those barriers to adoption that remain in a minority of large enterprises. From the feedback I've received, not just those using WebLogic, either, although of course it is more significant if a client already has a relationship with BEA. Remember that BEA are used to supporting mission-critical systems. For them to "certify" Spring is far more than marketing; it reflects a lot of testing work and shows that they are confident that enterprise-class customers can safely use Spring. You can't make money supporting flaky software.But it's important to note that what BEA is doing is more recognizing the reality on the ground (large enterprise customers using or wanting to use Spring) than promoting Spring for its own sake. Which is a good thing; companies should listen to their customers.RgdsRod

    Anecdotal evidence is interesting but the reality is that unless this is blessed by some standard group like a jcp, you won't find a lot of shops that'll commit to it. Spring has 1 implementation coming out of 1 "vendor", and this in the eyes of the average CIO won't cut it.

    And partnering with BEA doesn't mean BEA will push it onto its customers, no one wants to depend on a third-party, especially on the little guys.

    The only route left is the one hibernate took, standardize the core and sell support on add-ons and extra features without breaking compat.
  25. BEA adds support to Weblogic for Spring[ Go to top ]

    And partnering with BEA doesn't mean BEA will push it onto its customers, no one wants to depend on a third-party, especially on the little guys.
    Do you imagine that Alfred Chuang (BEA CEO) and Mark Carges (CTO) would spend valuable time in keynotes talking about something that they didn't want to promote to their customers? I can assure you that BEA are serious about this, and are putting a lot of effort into preparing the support offering (in partnership with Interface21). Trying to second-guess what BEA are doing when they are very clearly telling you exactly what they're doing (and spending money doing it and promoting it) seems rather strange. After all, BEA World is an important means of BEA communicating with their customers.
    Anecdotal evidence is interesting but the reality is that unless this is blessed by some standard group like a jcp, you won't find a lot of shops that'll commit to it.
    The reality is that a lot of shops are committing to Spring, or did so a while ago, and benefiting greatly from doing so. Solid evidence of savings and other benefits is a powerful argument for senior managers, and very often it is they who are driving Spring adoption. I could cite many more large enterprises and government organizations besides those three. So I can understand the rationale for your speculation, but it is just speculation. The reality on the ground is quite different.

    Look at the history of Struts. It was never standardized, but become a de facto standard far more widespread than EJB or many JCP standards. JSF, OTOH, has still to reach anything like the same level of acceptance. So JCP standardization is just one factor in technology adoption, not a single decisive issue.

    Rgds
    Rod
  26. And partnering with BEA doesn't mean BEA will push it onto its customers, no one wants to depend on a third-party, especially on the little guys.
    Do you imagine that Alfred Chuang (BEA CEO) and Mark Carges (CTO) would spend valuable time in keynotes talking about something that they didn't want to promote to their customers? I can assure you that BEA are serious about this, and are putting a lot of effort into preparing the support offering (in partnership with Interface21). Trying to second-guess what BEA are doing when they are very clearly telling you exactly what they're doing (and spending money doing it and promoting it) seems rather strange. After all, BEA World is an important means of BEA communicating with their customers.
    Anecdotal evidence is interesting but the reality is that unless this is blessed by some standard group like a jcp, you won't find a lot of shops that'll commit to it.
    The reality is that a lot of shops are committing to Spring, or did so a while ago, and benefiting greatly from doing so. Solid evidence of savings and other benefits is a powerful argument for senior managers, and very often it is they who are driving Spring adoption. I could cite many more large enterprises and government organizations besides those three. So I can understand the rationale for your speculation, but it is just speculation. The reality on the ground is quite different.Look at the history of Struts. It was never standardized, but become a de facto standard far more widespread than EJB or many JCP standards. JSF, OTOH, has still to reach anything like the same level of acceptance. So JCP standardization is just one factor in technology adoption, not a single decisive issue.RgdsRod

    Rod, I agree with you about a lot of things, and I admire you. However, JSF adoption is not one of things we agree on. JSF has a larger following than Tapestry, WebWork and Spring MVC. It is second only to Struts (see Dice). A lot of Struts shops are considering it for their next project.

    IBM has incredible JSF support, and amazing JSF/Portlet integration.

    The near future for a lot of IT shops's web development is JSF. That said, there is a lot of oppurtunity for greater Spring/JSF support.

    Seam, written by Gavin King and company, has put the right emphasis on JSF.

    I've used Spring MVC in anger it is a great framework. I prefer JSF.

    Setting Gavin King loose on web development is the smartest thing that JBoss ever did.
  27. Setting Gavin King loose on web development is the smartest thing that JBoss ever did.

    I totally agree :-)

    You should see some of the stuff we've got coming down the pipe yet--

    Jacob (JSF-EG/Facelets)
  28. And partnering with BEA doesn't mean BEA will push it onto its customers, no one wants to depend on a third-party, especially on the little guys.
    Do you imagine that Alfred Chuang (BEA CEO) and Mark Carges (CTO) would spend valuable time in keynotes talking about something that they didn't want to promote to their customers? I can assure you that BEA are serious about this, and are putting a lot of effort into preparing the support offering (in partnership with Interface21). Trying to second-guess what BEA are doing when they are very clearly telling you exactly what they're doing (and spending money doing it and promoting it) seems rather strange. After all, BEA World is an important means of BEA communicating with their customers.
    Anecdotal evidence is interesting but the reality is that unless this is blessed by some standard group like a jcp, you won't find a lot of shops that'll commit to it.
    The reality is that a lot of shops are committing to Spring, or did so a while ago, and benefiting greatly from doing so. Solid evidence of savings and other benefits is a powerful argument for senior managers, and very often it is they who are driving Spring adoption. I could cite many more large enterprises and government organizations besides those three. So I can understand the rationale for your speculation, but it is just speculation. The reality on the ground is quite different.Look at the history of Struts. It was never standardized, but become a de facto standard far more widespread than EJB or many JCP standards. JSF, OTOH, has still to reach anything like the same level of acceptance. So JCP standardization is just one factor in technology adoption, not a single decisive issue.RgdsRod
    Rod, I agree with you about a lot of things, and I admire you. However, JSF adoption is not one of things we agree on. JSF has a larger following than Tapestry, WebWork and Spring MVC. It is second only to Struts (see Dice). A lot of Struts shops are considering it for their next project.IBM has incredible JSF support, and amazing JSF/Portlet integration.The near future for a lot of IT shops's web development is JSF. That said, there is a lot of oppurtunity for greater Spring/JSF support.Seam, written by Gavin King and company, has put the right emphasis on JSF.I've used Spring MVC in anger it is a great framework. I prefer JSF.Setting Gavin King loose on web development is the smartest thing that JBoss ever did.

    I've used Spring MVC in anger it is a great framework.

    was suppose to read

    I've used Spring MVC in anger and it is a great framework. I prefer JSF because of its component model.
  29. IBM has incredible JSF support, and amazing JSF/Portlet integration.The near future for a lot of IT shops's web development is JSF.

    Please tell me you are not serious about IBM offering great JSF support ?? The way their RAD tool handles the GUI linkage to the code generation is just horrible. The codes it spits out is hardly humanly readable, messy and the JSF visual editor itself looses syncage with the code regularly... So sorry having used it for real i cant see much greatness about IBM's tool nor the JSF implementation they have cooked up..

    Greetz
    leo
  30. IBM has incredible JSF support, and amazing JSF/Portlet integration.The near future for a lot of IT shops's web development is JSF.
    Please tell me you are not serious about IBM offering great JSF support ?? The way their RAD tool handles the GUI linkage to the code generation is just horrible. The codes it spits out is hardly humanly readable, messy and the JSF visual editor itself looses syncage with the code regularly... So sorry having used it for real i cant see much greatness about IBM's tool nor the JSF implementation they have cooked up..Greetzleo

    It is also impossible to get WSAD and RAD to generate clean portable code. We ended up hand editing all JSF files. Such a waste!!!

    IBM's JSF implementation also looks like a cheap wrap over Sun's Reference Implementation, which is terrible.
  31. BEA adds support to Weblogic for Spring[ Go to top ]

    And partnering with BEA doesn't mean BEA will push it onto its customers, no one wants to depend on a third-party, especially on the little guys.
    Do you imagine that Alfred Chuang (BEA CEO) and Mark Carges (CTO) would spend valuable time in keynotes talking about something that they didn't want to promote to their customers? I can assure you that BEA are serious about this, and are putting a lot of effort into preparing the support offering (in partnership with Interface21). Trying to second-guess what BEA are doing when they are very clearly telling you exactly what they're doing (and spending money doing it and promoting it) seems rather strange. After all, BEA World is an important means of BEA communicating with their customers.
    Anecdotal evidence is interesting but the reality is that unless this is blessed by some standard group like a jcp, you won't find a lot of shops that'll commit to it.
    The reality is that a lot of shops are committing to Spring, or did so a while ago, and benefiting greatly from doing so. Solid evidence of savings and other benefits is a powerful argument for senior managers, and very often it is they who are driving Spring adoption. I could cite many more large enterprises and government organizations besides those three. So I can understand the rationale for your speculation, but it is just speculation. The reality on the ground is quite different.Look at the history of Struts. It was never standardized, but become a de facto standard far more widespread than EJB or many JCP standards. JSF, OTOH, has still to reach anything like the same level of acceptance. So JCP standardization is just one factor in technology adoption, not a single decisive issue.RgdsRod

    Will all due respect, I hope you're not naive enough to beleive BEA has suddenly awoken to the beauty of Spring. It's simply a buisness move aimed at their competitors. Sun has open sourced their app. server, IBM bought gluecode and BEA is loosing market share.

    They can't open source their app server, so what are they to do? buy JBoss? but who can stand Fleury? even IBM passed on him. Their move is squarely aimed at leapfrogging the others (because, honestly, who isn't considering lightweight containers) and entering the next battle field. And the quickest way to do that was to claim they're now making their app server play well with Spring, the most popular of them all out there.

    Keynotes mean nothing, the old days of standing by what you said yesterday are long gone. Want proof? Listen to past JavaOne keynotes, the world was promised the moon and all we got was JBoss' lame attempt at mimicking the napoleon dynamite nerd!

    I honestly beleive this is a good move for Spring, but parterning with a has-been is not what's going to get it on the map. Spring, or the idea of lightweight containers is where j2ee is going, and I think the comparaison with Struts is apples-to-oranges. Struts was born out of frustration for the *lack* of equivalent frameworks, Spring is a replacement for EJB [http://www.springframework.org/docs/reference/ejb.html].

    The JCP may not be the "single decisive issue" for adoption, but it's certainly what will get it adopted not just by BEA but all of the j2ee-certified vendors, which make up most of the j2ee market. Look at hibernate.
  32. BEA adds support to Weblogic for Spring[ Go to top ]

    Will all due respect, I hope you're not naive enough to beleive BEA has suddenly awoken to the beauty of Spring. It's simply a buisness move aimed at their competitors.
    You speak as if business moves are bad. Sure, we can see what BEA stands to gain from the relationship. I'd be worried if I couldn't see what they had to gain from it.
    Keynotes mean nothing, the old days of standing by what you said yesterday are long gone. Want proof? Listen to past JavaOne keynotes, the world was promised the moon and all we got was JBoss' lame attempt at mimicking the napoleon dynamite nerd!
    You implied that BEA were unlikely to put much effort into promoting Spring to customers. I cited keynotes by BEA's top executives as examples of what they are saying to their customers. Sure, things change over time. But BEA are vigorously doing what their recent keynotes have mentioned. Btw if you need further proof of BEA's intent to communicate directly to customers about Spring, I've already been contacted by a couple of BEA regional managers with questions about Spring and whether we have any information they can give to their customers.
    Spring, or the idea of lightweight containers is where j2ee is going, and I think the comparaison with Struts is apples-to-oranges. Struts was born out of frustration for the *lack* of equivalent frameworks, Spring is a replacement for EJB [http://www.springframework.org/docs/reference/ejb.html].
    Spring is many things. One of those things is a compelling replacement for most uses of EJB. But it wasn't the raison d'etre of Spring. But like Struts, Spring largely did new things that did not exist in the JCP or in other frameworks. Looking at JEE 5, a few of those things are appearing, but generally with a very reduced level of sophistication.

    Rgds
    Rod
  33. A few weeks ago, i read a quote from a JBoss employee that sounded like they wouldnt expect any real outcome of the BEA/I21 deal announced weeks ago. Seems he was wrong on this. For me as a Spring user, this is really good news. It means I21 get stronger to keep on the high quality development on Spring. It also means that Spring gets access to larger corporations because there is a "known" backing company now.

    I am actually working for one of the largest telcos in the world (big BEA customer) and this announcement definitely helps the architects to push Spring even further. I am sure most of you know that worldwide operating companies have departments whose sole job is to evaluate and approve frameworks for usage inside the organisation. These people needs to get assured that Spring is not one of those unmaintained and undocumented frameworks living their sad life in some dirty corner of sourceforge. BEA can definitely convince those people.

    Some other comments to topics in this thread.

    JSF: i cant share the oppinion of Rick. Perhaps this will be the first framework failing to reach the masses, even though it has big vendor support. I am "forced" to use it at the moment and i dont see too many people around me having fun working with it. I wont place any bet on the future market acceptance.

    Spring: I still read those "Spring is there to replace EJB" comments. This is really not the full truth. It "could" replace EJB for some projects but in most big ones, its an additive.

    Coffins: I dont know who is putting nails into someones coffin but from a business perspective, its unlikely that IBM, SUN or BEA get nailed (hope nailed has not the same double meaning in the US as here in germany) anytime soon. And if i can chose if i want to run a service based or a license based company, there is no doubt what model i would chose. But this doesnt imply that JBoss couldnt get big and successfull. As i said somewhere else, i dont think their product is bad, but they should start hiring PR or product management people. Compare Bills comment with the one from Shane Pearson. When just comparing those comments, who do you think is the best person/company to partner with? But from TSS perspective, its good that JBoss is what it is.

    Marc Logemann
    http://www.logemann.org
  34. As i said somewhere else, i dont think their product is bad, but they should start hiring PR or product management people. Compare Bills comment with the one from Shane Pearson. When just comparing those comments, who do you think is the best person/company to partner with? But from TSS perspective, its good that JBoss is what it is.Marc Logemannhttp://www.logemann.org

    I agree. And the first thing that this PR person should do is keep the JBoss people from posting! When you compare the posts from say the Spring guys vs. the JBoss guys, the JBoss guys seem to have a chip on their shoulders.
  35. BEA adds support to Weblogic for Spring[ Go to top ]

    Will all due respect, I hope you're not naive enough to beleive BEA has suddenly awoken to the beauty of Spring.
    This is a really simple one word answer: customers

    We actually talk to them and listen to what they want. BEA's move to support Spring and other open source frameworks is in addition to standards like J2EE, Web Services, XML, etc. This all comes back to our goal of providing customers the best overall run-time, tools and enterprise products that support their requirements to be successful in their business.

    And to provide this support we simply went straight to Interface21 as the logical source. Spring support with WebLogic is in addition to support of other standards (i.e. EJB3) so that customers have the ability to combine open source and standard based frameworks that best meet their requirements today and in the future.

    Cheers,
    Shane
  36. BEA adds support to Weblogic for Spring[ Go to top ]

    Will all due respect, I hope you're not naive enough to beleive BEA has suddenly awoken to the beauty of Spring.

    This is a really simple one word answer: customers

    We actually talk to them and listen to what they want. BEA's move to support Spring and other open source frameworks is in addition to standards like J2EE, Web Services, XML, etc. This all comes back to our goal of providing customers the best overall run-time, tools and enterprise products that support their requirements to be successful in their business.

    And to provide this support we simply went straight to Interface21 as the logical source. Spring support with WebLogic is in addition to support of other standards (i.e. EJB3) so that customers have the ability to combine open source and standard based frameworks that best meet their requirements today and in the future.

    Cheers,
    Shane
  37. Independent of licensing and model, BEA's technology strategy is aligning with the bizarre instead of the cathedral. Buying Ratonal and building collaboration(read off-shoring support) into its products, IBM seems to be going for the cathedral. To hedge it's bet though, buying gluecode and support for Geronimo allows IBM to play against JBoss. A two front war. I think BEA can only support one front at this time. As an aside, the only thing bizarre about JBoss is its public relations practices.
  38. A huge number of large enterprises are already heavily using Spring in production with excellent results. Spring is already part of the mandated standard architectures in many huge enterprise. For example, in the last month I have spent significant time with three clients who are standardizing on Spring: 1. a top 10 global investment and retail bank; 2. a huge government institution that is a household name worldwise; 3. a European institution that handles millions of mission-critical financial operations per day. Interestingly, those are all WebLogic or WebSphere accounts; all have evaluated open source application servers and found that (at least as yet) they don't meet their needs. (Yet, interestingly, two of them make some use of Tomcat.)But certainly, the validation of BEA will help to break down those barriers to adoption that remain in a minority of large enterprises. From the feedback I've received, not just those using WebLogic, either, although of course it is more significant if a client already has a relationship with BEA. Remember that BEA are used to supporting mission-critical systems. For them to "certify" Spring is far more than marketing; it reflects a lot of testing work and shows that they are confident that enterprise-class customers can safely use Spring. You can't make money supporting flaky software.But it's important to note that what BEA is doing is more recognizing the reality on the ground (large enterprise customers using or wanting to use Spring) than promoting Spring for its own sake. Which is a good thing; companies should listen to their customers.RgdsRod
    Anecdotal evidence is interesting but the reality is that unless this is blessed by some standard group like a jcp, you won't find a lot of shops that'll commit to it. Spring has 1 implementation coming out of 1 "vendor", and this in the eyes of the average CIO won't cut it. And partnering with BEA doesn't mean BEA will push it onto its customers, no one wants to depend on a third-party, especially on the little guys. The only route left is the one hibernate took, standardize the core and sell support on add-ons and extra features without breaking compat.

    Struts is an excellent example of a non-standard framework being adopted by the masses. Hibernate is another example.

    In the last 2 years, I have spoken to many, many VPs of engineering, VPs of development, director of developments, arcitects, developers, etc. I'd say 3/4s of them adopted Spring after hearing the value proposition.

    Spring is an easy sell.

    It may be a while before EJB3 becomes available to many WebLogic/WebSphere IT shops. First, it has to be implemented by BEA/IBM, then large corporations can take years before switching to the next version of an application server.

    Spring/Hibernate (Spribernate) works with WebLogic and WebSphere today. Of all the frameworks, it is the most like EJB3. (I stole that line of reasoning from one of Rod's talks).

    Most CIOs are not concerned about issues like which low-level framework developers use. It just is not on their radar. They care about the big picture IBM WebSphere or BEA WebLogic or ..., SOA architecture, components, etc.

    Spring has higher demmand as a job skill than Hibernate (according to Dice). Spring has come into its own.

    Spring adoption and impact on enterprise development is a lot more than Anecdotal evidence.
  39. BEA adds support to Weblogic for Spring[ Go to top ]

    A huge number of large enterprises are already heavily using Spring in production with excellent results. Spring is already part of the mandated standard architectures in many huge enterprise. For example, in the last month I have spent significant time with three clients who are standardizing on Spring: 1. a top 10 global investment and retail bank; 2. a huge government institution that is a household name worldwise; 3. a European institution that handles millions of mission-critical financial operations per day. Interestingly, those are all WebLogic or WebSphere accounts; all have evaluated open source application servers and found that (at least as yet) they don't meet their needs. (Yet, interestingly, two of them make some use of Tomcat.)But certainly, the validation of BEA will help to break down those barriers to adoption that remain in a minority of large enterprises. From the feedback I've received, not just those using WebLogic, either, although of course it is more significant if a client already has a relationship with BEA. Remember that BEA are used to supporting mission-critical systems. For them to "certify" Spring is far more than marketing; it reflects a lot of testing work and shows that they are confident that enterprise-class customers can safely use Spring. You can't make money supporting flaky software.But it's important to note that what BEA is doing is more recognizing the reality on the ground (large enterprise customers using or wanting to use Spring) than promoting Spring for its own sake. Which is a good thing; companies should listen to their customers.RgdsRod
    Anecdotal evidence is interesting but the reality is that unless this is blessed by some standard group like a jcp, you won't find a lot of shops that'll commit to it. Spring has 1 implementation coming out of 1 "vendor", and this in the eyes of the average CIO won't cut it. And partnering with BEA doesn't mean BEA will push it onto its customers, no one wants to depend on a third-party, especially on the little guys. The only route left is the one hibernate took, standardize the core and sell support on add-ons and extra features without breaking compat.

    Then let me offer another bullet point. We've talked to customers who've either heard of Spring(just didn't know what it did :-)) or were impressed enough by our presentation and current use that we've won projects BECAUSE of our use of these technologies. I don't believe CIOs care necessarily if something is in JCP. I think that they care more for the botton line.
  40. Rick,
    Okay, let's say you are right. What is Spring's motivation?Also why do you think Hibernate was left out of the example app?Most of my clients that use WebLogic do so with both Hibernate and Spring.SpringJDBC is fine. I think Spring + Hibernate is more prevalent than Spring + SpringJDBC.Why not have both examples? There are some tricks to get WebLogic/Hibernate/Spring working together properly (with certain configurations, like JTA and/or CMT). I have one client that wants to work with Hibernate, EJB 2 SSB, CMT and Spring.

    The motivation on both the part of the Spring team and Interface21, as well as BEA, is that this added value for users of Spring and WLS. Spring and WLS are two excellent products, which ran quite well together before, and run together even better now.

    It's actually always our goal that Spring runs optimally in all environments where it's commonly (or even uncommonly) used, taking advantage of all advanced functionality available. I think we've done an excellent job in general, but given limited resources or limitations forced on Spring by things such as the operations available through the stock JTA interfaces, it's not always possible to take this as far as we'd like to. In this case, BEA stepped up and donated significant development resources of their own to this task. As long as they are sincere, we welcome similar initiatives from other vendors.

    But it's important to point out that users who have no interest in this combination are not impacted in any negative fashion by any of this work or the agreement between BEA and Interface21. Spring still runs well standalone, runs well in other app servers, and w/regards to future direction can go where it makes the most sense for its users.

    As for the question of why Hibernate was not used in the new MedRec examples, I believe it's simply because the old code used JDBC (driven by Entity Beans), and severe time limitations in trying to get this ready by BEAWorld. My understanding is that the MedRec app will continue to evolve, probably including use of O/R mapping. That said, it already uses Spring to a great extent...

    It was very exciting for me to be at BEAWorld this week, and see the excitement and interest on the part of WebLogic users at the idea of using Spring on WLS. Among other activities, on Tuesday I gave a technical session on Spring, along with Eric Shiao and Chris Wall of BEA. I was told this session actually had the second highest attendance of any at the show. While we know many people were using Spring on WLS very successfully before this agreement, the endorsement from BEA, availability of support directly from BEA, and increased ability to take advantage of advanced WLS functionality means a lot for some WLS users...

    Regards,
    Colin
  41. It was very exciting for me to be at BEAWorld this week, and see the excitement and interest on the part of WebLogic users at the idea of using Spring on WLS. Among other activities, on Tuesday I gave a technical session on Spring, along with Eric Shiao and Chris Wall of BEA. I was told this session actually had the second highest attendance of any at the show. While we know many people were using Spring on WLS very successfully before this agreement, the endorsement from BEA, availability of support directly from BEA, and increased ability to take advantage of advanced WLS functionality means a lot for some WLS users...

    I agree. I think WebLogic adding support for Spring is a great boon.
  42. What is Spring's motivation?
    WebLogic is used by a large percentage of enterprise customers. BEA "certifying" Spring and the support relationship will increase Spring adoption amongst those customers, and will improve the experience they have using Spring on WebLogic. More Spring users and (even!) happier Spring users has to be good news :-)

    The Spring team now has access to WebLogic engineers to help resolve any issues we or users encounter on Spring/WebLogic. (If only this had been possible 12 months ago, for example, when Juergen was working on advanced transaction management features!) And this directly benefits Spring, because BEA have some great engineers. For example, we're getting some good feedback and suggestions from guys such as Andy Piper, so we've already shipped some enhancements to Spring remoting in 1.2.5 that resulted from work with BEA but also benefit users on other platforms.

    Of course, we hope that it will also be good business for Interface21. And that's also good for the Spring community, as having a viable economic model behind enterprise open source is crucial for its success. (It's probably good news for all those with Spring skills, too.)

    But to be honest I would have been delighted to work with BEA to further integrate Spring with WebLogic even if I was still an independent consultant. (As an aside, the results couldn't have been as good in that case, as we've needed to involve several Interface21 people, and the work would have been way too much for one individual.) From a technical viewpoint and the point of view of customers, the benefits of the relationship are compelling. The only thing that would have caused us to turn down such a deal would have been if we'd been asked to compromise our independence. This hasn't been the case.

    Rgds
    Rod
  43. BEA adds support to Weblogic for Spring[ Go to top ]

    Yes I see a pattern, but it is not a pattern of consolidation. Properietary vendors are scared shitless of open source so they are scurrying for a strategy. Well, not Microsoft, but definately BEA and IBM...As for Microsoft? I think Martin Lamonica had the best analysis of the Microsoft deal.

    This is just FUD for FUDs sake.

    Open source software has existed for years and has been used with commercial software for years. BEA has been an active participant in open source for years and the notion we have no strategy is simply something thrown around by people with other agendas. BEA actively adopts, contributes, and influences open source projects across several different organizations just like we do with standards organizations. More on specifics of our open source participation can be found at: http://dev2dev.bea.com/opensource/

    In addition, BEA went into great depths on this topic at Java One earlier this year and again this week at our user conference. The open source movement is something that is good for the industry as it creates a community of interest that drives innovation through participation. However, commercial software will continue to be a exist along side open source alternatives as customers have requirements for products, features and support that create market opportunity for both the development and business models.

    Shane Pearson
    VP, Product Management
    BEA Systems, Inc.
  44. Yes I see a pattern, but it is not a pattern of consolidation. Properietary vendors are scared shitless of open source so they are scurrying for a strategy. Well, not Microsoft, but definately BEA and IBM...As for Microsoft? I think Martin Lamonica had the best analysis of the Microsoft deal.
    This is just FUD for FUDs sake.Open source software has existed for years and has been used with commercial software for years. BEA has been an active participant in open source for years and the notion we have no strategy is simply something thrown around by people with other agendas. BEA actively adopts, contributes, and influences open source projects across several different organizations just like we do with standards organizations. More on specifics of our open source participation can be found at: http://dev2dev.bea.com/opensource/ In addition, BEA went into great depths on this topic at Java One earlier this year and again this week at our user conference. The open source movement is something that is good for the industry as it creates a community of interest that drives innovation through participation. However, commercial software will continue to be a exist along side open source alternatives as customers have requirements for products, features and support that create market opportunity for both the development and business models. Shane PearsonVP, Product ManagementBEA Systems, Inc.

    I don't believe what he said is entirely accurate, but is it FUD?

    To me FUD is something like "Don't use BEA or you will loose all of your hair and your friends will not like you".

    What he said is JBoss is hurting BEA market share in his own unique Bill way.

    Are you contesting this point?
  45. I am contesting the so nicely put phrase on the "no strategy" topic which does not leave a good impression on BEA. At a minimum it is not accurate or uninformed.

    In terms of market impact there is no question that open source, and JBossas part of OSS, has had impact on the application server market. Whether JBoss is directly or indirectly impacting BEA market share is an interesting discussion given this is not a single market, but one with several segments of customers with diverse requirements. But that is a different discussion then what is the topic of this current thread.

    Cheers,
    Shane
  46. BEA adds support to Weblogic for Spring[ Go to top ]

    Yes I see a pattern, but it is not a pattern of consolidation. Properietary vendors are scared shitless of open source so they are scurrying for a strategy.
    Yeah yeah, you've been saying that for years. You were going to put BEA and IBM out of business ("nuke the field" I think was the term).

    Thing is, you keep regurgitating it but it's not happening.

    Here we are, five years later, BEA and IBM are still here, hitting their targets regularly, making Wall Street happy, innovating, moving up the stack and growing every quarter.

    But surely this will end any day, now. After all, they are competing against a free product, how could they survive?

    Right?

    --
    Cedric
  47. Yes I see a pattern, but it is not a pattern of consolidation. Properietary vendors are scared shitless of open source so they are scurrying for a strategy.
    Yeah yeah, you've been saying that for years. You were going to put BEA and IBM out of business ("nuke the field" I think was the term).Thing is, you keep regurgitating it but it's not happening.Here we are, five years later, BEA and IBM are still here, hitting their targets regularly, making Wall Street happy, innovating, moving up the stack and growing every quarter.But surely this will end any day, now. After all, they are competing against a free product, how could they survive?Right?-- Cedric

    Well put!
  48. BEA adds support to Weblogic for Spring[ Go to top ]

    After all, they are competing against a free product, how could they survive?

    Right?

    -- Cedric

    Yes, they are 'surviving' and adjusting :-)
  49. BEA adds support to Weblogic for Spring[ Go to top ]

    Properietary vendors are scared shitless of open source

    Let us know when you pass BEA or IBM in revenue. Until then, STFU.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Transactional Caching
  50. Properietary vendors are scared shitless of open source
    Let us know when you pass BEA or IBM in revenue. Until then, STFU.

    Peace,
    Cameron Purdy

    I think there's exaggeration going on by both parties, but the underlying point is that both ends are meeting in the middle with their own strategies-- IBM and BEA aren't seeing as big of a return on investment while O/S is only starting to see a return on investment.

    -- Jacob
  51. Properietary vendors are scared shitless of open source
    Let us know when you pass BEA or IBM in revenue. Until then, STFU.Peace,Cameron Purdy
    I think there's exaggeration going on by both parties, but the underlying point is that both ends are meeting in the middle with their own strategies-- IBM and BEA aren't seeing as big of a return on investment while O/S is only starting to see a return on investment.-- Jacob

    Amen. WebLogic and WebSphere are a long way from dead!
    There is some impact of JBoss or IBM would not have bought Glue Code.

    EJB3 looks a lot like what you get with Hibernate/Spring combinations. EJB3 has IoC and Interceptors just like Spring.

    JBoss has the microcontainer that can run (one day whatever than means) in WebLogic and WebSphere and provide EJB3 style persitence, IoC and Interceptors (AOP light).

    If you think, WebLogic and WebSphere are dead.

    Go to dice and look at job opennings...

    J2EE 12,286
    WebLogic 2,068
    WebSphere 2,538
    Tomcat 734
    JBoss 458
    EJB 1,244 (classic EJB almost 5 times bigger than Spring)
    Spring 254
    Hibernate 378 (classic EJB 4 times bigger than Hibernate)

    Spring is great, but it is not the de facto standard or the standard (although I feel it should be the de facto standard).

    EJB3 closes the gap a bit (between standard J2EE and Spring style J2EE), and when WebLogic, and WebSphere support EJB3, EJB3 will be adopted in droves.

    Gavin was smart to move EJB3 towards Hibernate. It is great for EJB and it is great for developers that will be stuck "eating the elephant again". It is good that EJB3 has some of the features that can be found in Spring.

    I'll continue to use Spring with EJB3 and JEE 5.
  52. "Dead"[ Go to top ]

    WebLogic and WebSphere are a long way from dead!

    Actually, nobody in this thread claimed that either WebLogic and WebSphere are "dead". And, in fact, I've not heard anyone make such a claim in *any* public forum. Careful of strawmen ;)

    But note that middleware product lines do not need to "die" to lose relevance. I'm thinking of two vendors who were very sexy 5-10 years ago (one in the middleware space, and one in the RDBMS space), who both still make plenty of money, have plenty of customers, but no longer really make an impact upon the industry at large. (I won't mention names so as not to be rude to people I know who work at these companies.)
  53. "Dead"[ Go to top ]

    WebLogic and WebSphere are a long way from dead!
    Actually, nobody in this thread claimed that either WebLogic and WebSphere are "dead".True.

    The words used by your colleague were "scared shitless", an expression that I hadn't heard since fifth grade.
    (I won't mention names so as not to be rude to people I know who work at these companies.)
    You don't really need to, Bill is doing a fine job at it.

    --
    Cedric
  54. RE: "Dead"[ Go to top ]

    WebLogic and WebSphere are a long way from dead!
    Actually, nobody in this thread claimed that either WebLogic and WebSphere are "dead". And, in fact, I've not heard anyone make such a claim in *any* public forum. Careful of strawmen ;)

    You are correct sir. But they did talk about some nameless person talking about "nuke-ing the field", which usually causes death to those in the field.

    See Cedric post where he claims to quote Bill
    Cedric Beust says:
    <blockqoute>
    Yeah yeah, you've (Bill) been saying that for years. You were going to put BEA and IBM out of business ("nuke the field" I think was the term).
    Besides if I misspoke, I can firmly blame it on the Grey Goose Screwdriver I was drinking while writing the post (it was Friday night after all).
  55. RE: "Dead" Coffin implies death[ Go to top ]

    Gavin,

    You said no one mentioned death.

    Bill said the following:
    I'll spell it out for you: IBM/BEA/Sun's actions are in response to open source competition, while Microsoft saw the partnership as a way to put yet another nail into the coffin of IBM's middleware business.

    This is why I said WebLogic and WebSphere were not "dead".

    You see a coffin (at least in the U.S.) is reserved for dead people. You only put nails in a coffin if the person is dead.

    Thus, Bill's strawman implies the immediate death of WebSphere. Thus, I responded as I did. ;)

    BTW Brillant job on Seam. I hope it takes off.
  56. RE: "Dead" Coffin implies death[ Go to top ]

    Gavin,You said no one mentioned death.Bill said the following:
    I'll spell it out for you: IBM/BEA/Sun's actions are in response to open source competition, while Microsoft saw the partnership as a way to put yet another nail into the coffin of IBM's middleware business.
    This is why I said WebLogic and WebSphere were not "dead".

    OK, my bad, I didn't notice that bit of hyperbolae from Bill.
  57. RE: "Dead" Coffin implies death[ Go to top ]

    Gavin,
    Gavin,You said no one mentioned death.Bill said the following:
    I'll spell it out for you: IBM/BEA/Sun's actions are in response to open source competition, while Microsoft saw the partnership as a way to put yet another nail into the coffin of IBM's middleware business.
    This is why I said WebLogic and WebSphere were not "dead".
    OK, my bad, I didn't notice that bit of hyperbolae from Bill.

    No problem. You are still the king of all Java. :o)

    BTW I was using EJB 2.x (CMP/CMR) and was quite happy with it. I met this guy (Gavin King) at a conference who told me why Hibernate was better. Shortly after, I spoke at JavaOne on using XDoclet and EJB 2.x together. Then on my very next contract, I started using Hibernate, and never went back to EJB 2.x. The people who hired me for this contract saw the talk on using EJB CMP/CMR with XDoclet and hired me to help them with a Struts/EJB/CMP CMR project. I convinced them to use Hibernate instead (I also tried to convince them to use WebWork instead of Struts to no avail). I've been using Hibernate ever since.
  58. Properietary vendors[ Go to top ]

    Properietary vendors are scared shitless of open source
    Let us know when you pass BEA or IBM in revenue. Until then, STFU.

    Ahem. So are you saying that large companies never fear the competition of smaller more efficient upstarts? Wow, that's a strange and ahistorical view of the capitalist economy :-)

    And are you claiming that large commercial software vendors, and in particular BEA, are not seeing impact to their business from the advent of open source? Double-wow, it must be comfortable under that rock there Cameron ;)

    True, open source companies will most likely not pass the current revenue of the giants anytime in the immediate future, *even* as they start to pass the giants in market share. But there is absolutely no contradiction there! That's because open source undercuts the traditional pricing models. What is scary about OSS business to the giants is that it makes their existing pricing models for software much less viable, and that makes their whole business models and cost structures less viable. The giants depend heavily upon economies of scale, and the combination of loss of market share and the need to cut prices to keep large strategic clients is certainly affecting their ability to invest in new technology.

    To pretend that OSS isn't causing some very painful readjustments at commercial vendors is just silly.
  59. Properietary vendors[ Go to top ]

    Properietary vendors are scared shitless of open source
    Let us know when you pass BEA or IBM in revenue. Until then, STFU.
    Ahem. So are you saying that large companies never fear the competition of smaller more efficient upstarts? Wow, that's a strange and ahistorical view of the capitalist economy :-)And are you claiming that large commercial software vendors, and in particular BEA, are not seeing impact to their business from the advent of open source? Double-wow, it must be comfortable under that rock there Cameron ;)True, open source companies will most likely not pass the current revenue of the giants anytime in the immediate future, *even* as they start to pass the giants in market share. But there is absolutely no contradiction there! That's because open source undercuts the traditional pricing models. What is scary about OSS business to the giants is that it makes their existing pricing models for software much less viable, and that makes their whole business models and cost structures less viable. The giants depend heavily upon economies of scale, and the combination of loss of market share and the need to cut prices to keep large strategic clients is certainly affecting their ability to invest in new technology.To pretend that OSS isn't causing some very painful readjustments at commercial vendors is just silly.

    Gavin has a good point. I know there are customers that picked JBoss and/or Tomcat b/c it was free and good enough. If JBoss and/or Tomcat was not available they would have gone with WebLogic or its ilk. This does hurt the bottom line a bit, and it forces vendors to innovate (read add value) beyond the spec.

    On the other hand, I have a few clients where JBoss is just not an option.

    I run into JBoss AS a lot more than I use to.
  60. Properietary vendors[ Go to top ]

    Gavin has a good point.

    Let me put the point another way: loss of market share leadership in the *primary line of business* of a company is incredibly damaging to any company in any industry. In the software industry - where economies of scale have traditionally been so important - it is even more damaging than most.

    (Note that some companies in the middleware space do not have middleware as their primary line of business, but several do.)

    Remember, market share is used as a proxy indicator of all kinds of things, including technology leadership and risk of investing in the product or company. I'm trying to think of a single example of a company which lost market share leadership in some software space and then subsequently regained it, and I'm drawing a blank. Does someone have an example of this happening?

    What's interesting to me about the open source companies is that they seem to be relatively less dependent upon scale. They have different cost structures in development, and a different relationship between revenue and market share. Obviously, this varies from company to company, since each have different business models. For example, my feeling is that MySQL would benefit much more from scale than RedHat, with JBoss falling somewhere in between. However, I'm pretty much talking out my ass here, since I really don't know anything at all about the financials of MySQL or RH ;-)
  61. Properietary vendors[ Go to top ]

    I'm trying to think of a single example of a company which lost market share leadership in some software space and then subsequently regained it, and I'm drawing a blank. Does someone have an example of this happening?
    IBM.

    And more generally, any company that has been around for more than ten years and that has had cyclical successes.
    What's interesting to me about the open source companies is that they seem to be relatively less dependent upon scale.
    This doesn't make sense to me.

    JBoss is a service company: it makes money by sending people left and right to assist with open-source problems. It's like IBM's professional services.

    Service doesn't scale well: if you want to grow your business, you need more people.

    Revenue and licensing, on the other hand, can pretty much grow to any imaginable value.

    And either way, the type of business (service or revenue/license) has nothing to do with the type of software used (open source or proprietary), so saying that open-source companies intrinsically scale better than service companies doesn't make any sense.

    --
    Cedric
  62. Properietary vendors[ Go to top ]

    I'm trying to think of a single example of a company which lost market share leadership in some software space and then subsequently regained it, and I'm drawing a blank. Does someone have an example of this happening?
    IBM.

    Hum, not as far as I know ... which software space did they lose and then regain market share leadership in?

    Note that my post is very carefully phrased to refer to a single line of business, not to the general ups and downs of a diversified company like IBM.
    What's interesting to me about the open source companies is that they seem to be relatively less dependent upon scale.
    This doesn't make sense to me.

    Right, that's because you've misunderstood the claim as being about *revenue*, when it was actually about leadership and marketshare and ability to innovate.

    Anyway, I'm not going to argue any further. We will see who is right in the next five years. Personally, I don't meet anyone who really believes that the dominant software licensing models will be the same in 5 years as they are today. But then, I meet a self-selecting group of people :-)
  63. Fantasies of grandeur[ Go to top ]

    Right, that's because you've misunderstood the claim as being about *revenue*, when it was actually about leadership and marketshare and ability to innovate.

    MARKETshare implies a market. A market implies revenue. If open source isn't generating license revenue it's hard to determine how to measure its "influence"; basing it on number of downloads is very inaccurate. Basing it on subscription revenue doesn't completely work, since the BEA's and IBM's of the world don't roll their subscription maintenance numbers into their share figures, and if they did, upstarts would be measured against to a huge legacy base. I suppose statistical surveys might help.

    The "ability to innovate" is an interesting one. Naturally, any small organization has an ability to innovate, and they don't require a lot of capital to do so. The point of license revenue is to provide funding to scale that ability. Consulting and support revenue can only go so far unless your consultants are improving the product in the field; while not an unheard of model, it can be risky.
    Anyway, I'm not going to argue any further. We will see who is right in the next five years. Personally, I don't meet anyone who really believes that the dominant software licensing models will be the same in 5 years as they are today. But then, I meet a self-selecting group of people :-)

    Apparently you are a part of a self-selecting group of people. Sure, licensing models change and evolve, but I hope you're not implying that in 5 years the majority of enterprise software will be open source or not have a license revenue component. Depends what you mean by "dominant" I suppose. Dominant in terms of "amount of money changing hands"? Dominant in terms of "cool people think this is the way to go"? Dominant in terms of "most small businesses do this"?

    In the database world alone, MySQL currently has 1/10th of 1% of Oracle's marketshare by revenue. That's a lot of ground to cover in 5 years -- the hottest open source product ever, being Linux, hasn't even covered that amount of share in the past 5 years. I am an advocate of open source, and hope it grows to be a major competitor to proprietary vendors. But JBoss, Inc. continues to amuse us with its fantasies of grandeur.
  64. Properietary vendors[ Go to top ]

    Some good points there.

    This was quite an amusing article (with the caveat that the Forbes editorial stance is at times based on a deep loathing of open source):

    http://www.forbes.com/home/intelligentinfrastructure/2005/06/15/jboss-ibm-linux_cz_dl_0615jboss.html
  65. Properietary vendors[ Go to top ]

    I'm trying to think of a single example of a company which lost market share leadership in some software space and then subsequently regained it, and I'm drawing a blank. Does someone have an example of this happening?
    IBM.And more generally, any company that has been around for more than ten years and that has had cyclical successes.
    What's interesting to me about the open source companies is that they seem to be relatively less dependent upon scale.
    This doesn't make sense to me.JBoss is a service company: it makes money by sending people left and right to assist with open-source problems. It's like IBM's professional services.Service doesn't scale well: if you want to grow your business, you need more people.Revenue and licensing, on the other hand, can pretty much grow to any imaginable value.Cedric

    Agreed. A product with recurring licensing and maintainance is the business holy grail.
  66. Properietary vendors[ Go to top ]

    What's interesting to me about the open source companies is that they seem to be relatively less dependent upon scale. They have different cost structures in development, and a different relationship between revenue and market share.

    Generally I believe that is not true. Quite the opposite: Open source business models (most of the time) simple do not scale at all. They draw their revenue mainly from consulting or sponsorship (and sometimes from support), so they cannot scale unless their market share explodes which in turn makes consulting cost so paramount for the customer (simply because of the lack of top level consultants/system experts) that they are better of with buying something.

    Also, note that software businesses depend far less on economy of scale than most other enterprises. Capital cost are far less than in a traditional enterprise and a software company can be restructured extremely easily (by hiring and firing people) as compare to a steel mill or an automobile plant.
  67. Properietary vendors[ Go to top ]

    What's interesting to me about the open source companies is that they seem to be relatively less dependent upon scale. They have different cost structures in development, and a different relationship between revenue and market share.
    Generally I believe that is not true. Quite the opposite: Open source business models (most of the time) simple do not scale at all. They draw their revenue mainly from consulting or sponsorship (and sometimes from support), so they cannot scale unless their market share explodes which in turn makes consulting cost so paramount for the customer

    Karle, you base this assumption on what data? What experience? I agree with you that consulting doesn't scale very well, but support and subscription services scale quite nicely. Case in point is Red Hat software. They are what, a $200 million dollar business? And all from being just a software packager. Companies like JBoss and MySQL have an even higher potential at growing revenues because they control both the software and the brand. Really, I wouldn't be so aggressive on these forums if I didn't have the sales data to back up my claims.

    Bill
  68. Properietary vendors[ Go to top ]

    Karle, you base this assumption on what data? What experience? I agree with you that consulting doesn't scale very well, but support and subscription services scale quite nicely. Case in point is Red Hat software. They are what, a $200 million dollar business? And all from being just a software packager. Companies like JBoss and MySQL have an even higher potential at growing revenues because they control both the software and the brand. Really, I wouldn't be so aggressive on these forums if I didn't have the sales data to back up my claims.Bill
    Bill, yes Red Hat is a fairly large business but they are creating their main revenue from providing essentially a shrink wrapped product for the enterprise along with a subscription service. They are essentially the proverbal dwarf on the shoulders of the giant, but how many companies can actually do that? I did not claim that there are no exceptions, most notably MySQL as you mentioned quite correctly. But even a company like JBoss seems not to scale very well from what I am hearing and they are like the 200 pound gorilla of the open source world.
  69. To scale or not to scale[ Go to top ]

    Bill, I base my analysis on 20 years or using Open Source software:-). But really, Red Hat is a fairly large business but they are creating their main revenue from providing essentially a shrink wrapped product for the enterprise along with a subscription service. They are essentially the proverbal dwarf on the shoulders of the giant, but how many companies can actually do that? I did not claim that there are no exceptions, most notably MySQL as you mentioned quite correctly. But even a company like JBoss seems not to scale very well from what I am hearing and they are like the 200 pound gorilla of the open source world.
  70. To scale or not to scale[ Go to top ]

    Bill, I base my analysis on 20 years or using Open Source software:-). But really, Red Hat is a fairly large business but they are creating their main revenue from providing essentially a shrink wrapped product for the enterprise along with a subscription service. They are essentially the proverbal dwarf on the shoulders of the giant, but how many companies can actually do that? I did not claim that there are no exceptions, most notably MySQL as you mentioned quite correctly. But even a company like JBoss seems not to scale very well from what I am hearing and they are like the 200 pound gorilla of the open source world.

    We aren't talking about producing tires here. This is software development. An industry built on innovation from single people. IMHO, building a giant company around supporting corporate marketing and middle management-- yeah, that's the kind of scalability that I want to pay for.
  71. To scale or not to scale[ Go to top ]

    We aren't talking about producing tires here. This is software development. An industry built on innovation from single people. IMHO, building a giant company around supporting corporate marketing and middle management-- yeah, that's the kind of scalability that I want to pay for.

    I hardly believe that a tool like eclipse is the result of "innovation of single people". And you might actually argue that by using eclipse you are funding IBMs middle management (albeit indirectly). Also I am quite sure that people who work in the tire business might have a very different point of view about the innovative potential of their business :-). But essentially, as soon as open source becomes a business it may very much see the need to scale, that is to grow in order to fulfill customer demand or to be marginalized by the open or closed source competition.

    In open source the traditional idea is to scale by either providing consulting around the product or by providing subscription services (essentially support contracts and documentation) for the product.

    Consulting tends to scale rather badly because of the various reason, from the supply of people who are good both with the product and as consultants to the way consulting projects are usually awarded in large organizations. Subscribtions usually need to provide good enough quality in order to compete with closed source rivals, at the same time often with the need to massively underbid the closed source competition which puts a certain limitation to the possibility to scale.

    There are of course success stories in open source that (seem to) scale quite well. Also, the sole programmer who sells the stuff he built in a stroke of genius $10 each scales not too bad either...
  72. To scale or not to scale[ Go to top ]

    I look at it this way, in the area I live in, there are probably 3 or 4 major consulting companies, ranging from 50 to 100 developers at any time. You've never heard of them (probably). Here, we have JBoss, a company of about 150 people that is being placed in comparison with IBM or BEA. There's something to be said for that fact with their business model and the individual employees they have.
  73. To scale or not to scale[ Go to top ]

    I look at it this way, in the area I live in, there are probably 3 or 4 major consulting companies, ranging from 50 to 100 developers at any time. You've never heard of them (probably). Here, we have JBoss, a company of about 150 people that is being placed in comparison with IBM or BEA. There's something to be said for that fact with their business model and the individual employees they have.

    Now really, comparing JBoss with IBM is probably a bit premature. Nothing wrong with thinking big though :-).

    But anyway, you are right, JBoss is currently enjoying a popular product along with (traditionally, almost) offensive marketing. No less to expect from a company running on a considerable amount of venture capital.

    At the end of the day, with the traditional open source business model, the consulting and training revenue will need to cover the companies expenses, that is fund all of the product development, documentation creation, office rentals and so on.

    At the same time both the traditional consulting company as well as the traditional product company may have superior cost structures (better income/expense ratios, continous revenue etc.) Difficult to really be sure though, because an open source company may spend considerably less around maintaining support offerings, documentation, support for old product lines etc. That need not be the case. The support products that - for example - mysql offers seem not to fall short of what some commercial vendors offer.

    Anyway, the real test for any company is the financial reports of the company once it becomes and after it is public.
  74. To scale or not to scale[ Go to top ]

    We aren't talking about producing tires here. This is software development. An industry built on innovation from single people. IMHO, building a giant company around supporting corporate marketing and middle management-- yeah, that's the kind of scalability that I want to pay for.

    mmm.. if we take a look at JBoss, the 'innovation' to me was years ago with Rickard's work on JBoss internals. Apart from that the innovation came from acquisitions: JGroups, Hibernate, jBPM for example.

    It's not easy to innovate. JBoss labs
  75. To scale or not to scale[ Go to top ]

    But even a company like JBoss seems not to scale very well from what I am hearing and they are like the 200 pound gorilla of the open source world.

    Hearing from whom? Karle, you've basically lost all credibility from me with that statement. Can't wait til all our financials are public.
  76. To scale or not to scale[ Go to top ]

    Hearing from whom? Karle, you've basically lost all credibility from me with that statement. Can't wait til all our financials are public.

    Bill, hearing from people working for major blue chip companies that have given up on JBoss cause of an apparent lack of support. Of course there might also be politics involved. But if something like this happens to people who I know have pushed for open source and actually _want_ to work with open source software, there are actually two possible reasons I can think off: the supplier is bizarrely arrogant or the supplier is stretched extremely thin on resources, i.e. the business - at least for the time being - does not scale. Having used JBoss on and off in the past (not the newest version I admit), I do think that you will need a considerably better average skill set among the workforce you need to realise your business model than the usual license revenue based corporation. Looking forward to your financials to prove me wrong (for at least three consecutive years please :-) ).
  77. Sales data[ Go to top ]

    Really, I wouldn't be so aggressive on these forums if I didn't have the sales data to back up my claims.Bill
    Can you post these sales data here then ? E.g. the JBoss Inc yearly turnover for 2004 and the projected growth rate for 2005 ? That should allow us to calculate in which century you might pass IBM's middleware business. Your VCs should be interested in finding this out, right ? :-)
  78. Properietary vendors[ Go to top ]

    Ahem. So are you saying that large companies never fear the competition of smaller more efficient upstarts? Wow, ..

    No, I just told Bill to STFU. His post was idiotic and a disservice to the public image of your company.

    BEA is not "scared shitless" of jboss. Occasionally annoyed, perhaps, but they've been living with (and profiting and growing despite) open source app servers. And they're still 100x the revenue of jboss.

    Peace,

    Cameron Purdy
    Tangosol Coherence: This space available.
  79. Cameron,
    Ahem. So are you saying that large companies never fear the competition of smaller more efficient upstarts? Wow, ..
    No, I just told Bill to STFU. His post was idiotic and a disservice to the public image of your company.BEA is not "scared shitless" of jboss. Occasionally annoyed, perhaps, but they've been living with (and profiting and growing despite) open source app servers. And they're still 100x the revenue of jboss.Peace,Cameron PurdyTangosol Coherence: This space available.

    So bill saying "scared shitless" is a disservice, but you saying "STFU" is not?

    Why the double standard?

    There was some shreds of truth in Bill's statement. I remember a day when I would go to a client and they were using WebLogic. BEA WebLogic was dominant. Everywhere you went... WebLogic.

    I don't see that anymore. I see equal parts: WebLogic, WebSphere, Tomcat and JBoss. Your experience may vary.

    I've even seen a customer or two using Oracle's AS.

    This is not to say that WebLogic is bad. But, there is a lot more competition in this space.

    I applaud WebLogic's support for Spring. To me this makes WebLogic more valuable to Spring users, and validates the use of Spring.

    I wish the JBoss group would be as open-minded about Spring as BEA. There seems to be some NIH there.

    To me, there is no reason JBoss could not support Spring. It fits well in the model and their stated objectives (suport open source enterprise development). So why the one-way campaign against Spring? If I were them I would support both their EJB3 vision and Spring.

    BTW Cameron no need to respond... I know you want me to shut up too.
  80. So bill saying "scared shitless" is a disservice, but you saying "STFU" is not? Why the double standard?

    Bill is an bully. Most of the folks at BEA are too nice to respond, but I don't personally like bullies, and I have found that the Niemoller principle is no less relevant today.
    There was some shreds of truth in Bill's statement. I remember a day when I would go to a client and they were using WebLogic. BEA WebLogic was dominant. Everywhere you went... WebLogic.

    I don't see that anymore.

    First, you are attempting to rationalize the worst type of behavior.

    Second, your argument isn't even logical. The fact that WebLogic is not as dominant as it was in no way supports the hypothesis that BEA is scared s***less.
    Cameron no need to respond... I know you want me to shut up too.

    Rick, please don't go drama queen on me. I just want you to think. Just imagine that you work for BEA, and then re-read the post that I was replying to.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Transactional Caching
  81. So bill saying "scared shitless" is a disservice, but you saying "STFU" is not? Why the double standard?
    Bill is an bully. Most of the folks at BEA are too nice to respond, but I don't personally like bullies, and I have found that the Niemoller principle is no less relevant today.
    There was some shreds of truth in Bill's statement. I remember a day when I would go to a client and they were using WebLogic. BEA WebLogic was dominant. Everywhere you went... WebLogic.I don't see that anymore.
    First, you are attempting to rationalize the worst type of behavior.Second, your argument isn't even logical. The fact that WebLogic is not as dominant as it was in no way supports the hypothesis that BEA is scared s***less.
    Cameron no need to respond... I know you want me to shut up too.
    Rick, please don't go drama queen on me. I just want you to think. Just imagine that you work for BEA, and then re-read the post that I was replying to.Peace,Cameron PurdyTangosol Coherence: Clustered Transactional Caching

    The last statement... I was mostly joking (about you telling me to shut up). I think that Bill gets a bad rap. Bill statement was hyperbole for sure, but I would not invoke the Niemoller principle.

    I think IBM and BEA are capable of defending themselves.

    Drama Queen? Hmmmm.... That sounds like another personal attack. Tsk tsk!
  82. "Undercutting on prices"[ Go to top ]

    That's because open source undercuts the traditional pricing models. What is scary about OSS business to the giants is that it makes their existing pricing models for software much less viable, and that makes their whole business models and cost structures less viable.

    That is not entirely true from what I have heard at a major systems integration consultancy, in some enterprise settings it is cheaper to just license Websphere than to use JBoss.
    Why?
    Because JBoss'es support fees are astronomical and in some cases makes it considerably cheaper to just go ahead and get Websphere instead!

    So undercutting on price? Perhaps in smaller environments at the low-end of the market, but for at least some really large environments, it seems that the traditional "giants" are considerably cheaper than "OSS Businesses".
  83. "Undercutting on prices"[ Go to top ]

    That's because open source undercuts the traditional pricing models. What is scary about OSS business to the giants is that it makes their existing pricing models for software much less viable, and that makes their whole business models and cost structures less viable.
    That is not entirely true from what I have heard at a major systems integration consultancy, in some enterprise settings it is cheaper to just license Websphere than to use JBoss. Why? Because JBoss'es support fees are astronomical and in some cases makes it considerably cheaper to just go ahead and get Websphere instead!So undercutting on price? Perhaps in smaller environments at the low-end of the market, but for at least some really large environments, it seems that the traditional "giants" are considerably cheaper than "OSS Businesses".

    I've worked at companies (as a consultant) that bought JBoss support.

    What you are saying does not match my experience.

    I found JBoss support economical and valuable.
  84. As one who uses WebLogic and Spring, I think this will help validate Spring in a lot of IT shops. I feel Spring is still somewhat grassroots in some larger IT shops. I am surprised at how many J2EE developers I interview don't know about Spring and don't have an opportunity to use it. Bundling it into WebLogic makes it just that easier to leverage.

    Developers/Architects who see the beauty of Spring would probably integrate with Tomcat first. Why use a heavyweight container like JBoss. I think BEA has made it easier for those that want to move to a lightweight container yet still get the benefits of HA, fast JVM, good deployment model, documentation, etc. It's pretty powerful to be a J2EE compliant and Spring compliant stack. Mindshare begets marketshare.

    As for JBoss/Microsoft. That's bad karma on both sides. BEA/Spring, two companies with good karma, well, I can see good things coming from this.
  85. As one who uses WebLogic and Spring, I think this will help validate Spring in a lot of IT shops. I feel Spring is still somewhat grassroots in some larger IT shops.

    I agree this goes a long way to validate Spring with some IT shops. Spring has come into its own several times over. It is becoming the establishment. This is good news for Spring.
  86. Andrew
    Developers/Architects who see the beauty of Spring would probably integrate with Tomcat first. Why use a heavyweight container like JBoss. I think BEA has made it easier for those that want to move to a lightweight container yet still get the benefits of HA, fast JVM, good deployment model, documentation, etc. It's pretty powerful to be a J2EE compliant and Spring compliant stack. Mindshare begets marketshare.
    I think you've struck an important point.

    Certainly open source application servers are having an impact on the market. Mainly JBoss at this point, but Geronimo is likely to become increasingly important, especially now that IBM are making it a key part of their middleware strategy.

    But another major change in the market is that a large subset of applications--even in Fortune 500 companies--don't need an application server and don't want to use one for simpler applications, especially now that Spring is in the picture. A servlet engine such as Tomcat or Jetty or Resin is an ideal choice in these cases, with incredibly quick deployment, ease of development and a low footprint. "The Simplest Thing that can Possibly Work" is sound advice for architectural stack, also.

    BEA seem to be recognizing the second point (that an app server can be overkill), which is an interesting and welcome development. Mark Carges (BEA CTO) spoke at JavaOne about Spring facilitating portability of applications between Tomcat and WebLogic--that's a huge plus for Spring in the eyes of corporate customers, because they are attracted to the idea of choice. If they start with Tomcat, and later need to scale up dramatically or move to distributed transactions, for example, they don't lose any of their investment. And it's interesting to see that BEA are actually embracing the reality that the application server is not the solution for all applications.

    Of course it's also likely to be good business for BEA (and IBM)--as the market for application servers narrows to the top end where customers need maximum performance, advanced clustered administration, robust distributed transaction management, highly reliable and performant messaging etc., their products are much safer from open source competition.

    Rgds
    Rod
  87. Andrew
    Developers/Architects who see the beauty of Spring would probably integrate with Tomcat first. Why use a heavyweight container like JBoss. I think BEA has made it easier for those that want to move to a lightweight container yet still get the benefits of HA, fast JVM, good deployment model, documentation, etc. It's pretty powerful to be a J2EE compliant and Spring compliant stack. Mindshare begets marketshare.
    I think you've struck an important point.Certainly open source application servers are having an impact on the market. Mainly JBoss at this point, but Geronimo is likely to become increasingly important, especially now that IBM are making it a key part of their middleware strategy.But another major change in the market is that a large subset of applications--even in Fortune 500 companies--don't need an application server and don't want to use one for simpler applications, especially now that Spring is in the picture. A servlet engine such as Tomcat or Jetty or Resin is an ideal choice in these cases, with incredibly quick deployment, ease of development and a low footprint. "The Simplest Thing that can Possibly Work" is sound advice for architectural stack, also. RgdsRod

    Indeed. We are weeks away from finishing another project using SSH(Struts, Spring, Hibernate) and this one will run on Tomcat. SSH has a good wrong, so I'm not sure where I'll put the "T", but the customer in question is already a Tomcat shop, so we had no problem convincing them to use Tomcat. And now, we've another bullet point that we can point to to other customers about the success of the open-source stack.

    Our rapid turnover made possible by this excellent open-source technology is really starting to pay real cash dividends. We can point customers to the respective websites, articles like BEA's acceptance and support, and mention how the customers application is built on the shoulders of giants. In addition, we are becoming attractive because the technology seems simultaneously safe, but cutting edge.

    My thanks to *everyone* involved in these technologies.
  88. BEA adds support to Weblogic for Spring[ Go to top ]

    Yes I see a pattern, but it is not a pattern of consolidation. Properietary vendors are scared shitless of open source so they are scurrying for a strategy.
    Why would you say something that's so ill-informed? As an engineer in BEA I can safely say that many of us are actively involved in opensource - and have been for a long time - not least because we think opensource has a lot of good stuff to offer, and lets face it, its a bunch of fun to develop.

    Why is it also so hard to believe that BEA is customer-focused? Sure, we want to make money, but a really good way of doing that is keeping customers happy and giving them what they ask for. Our customers are asking for better opensource support, so why should we deny them that?

    andy
  89. BEA adds support to Weblogic for Spring[ Go to top ]

    Sorry, Bill's comments were supposed to be quoted - not appear as part of my posting!
  90. BEA adds support to Weblogic for Spring[ Go to top ]

    Spring, as great as it is, is just another framework that will be hibernatized (no pun intended) into j2ee sometime in the next few years. As Fleury himself said Sun screwed him and gave Oracle the EJB spec co-chair prize while he gave them hibernate, he had wanted to pull a bigger stunt but Oracle was at the JCP's door with TopLink. It's still the big guys that make the money off the little guy's "innovation", especially in the open source world. They're nothing more than flies on their windshields. The proof is geronimo/gluecode/ibm.
  91. BEA adds support to Weblogic for Spring[ Go to top ]

    It's still the big guys that make the money off the little guy's "innovation", especially in the open source world. They're nothing more than flies on their windshields. The proof is geronimo/gluecode/ibm
    Well, I remember when what's now WebLogic was a startup called Tengah... I think the founders did pretty well. And of course the B, E and the A originally came from Sun. Larry Ellison came from Oracle. While I can understand why there's much to be cynical about in this industry, big companies start out small and small companies with good technology do well. It's not quite as simple as you make out.

    Rgds
    Rod
  92. Larry Ellison came from Oracle.
    Of course, I meant to say, "came from IBM".
  93. Whats the buy in for BEA with this support?

    BEA is the most preferred J2EE server in the market today (Am not good at stats though). With this tag, what made them choose Spring?

    One welcome point observed, as in this discussion, is that the focus is not on the usual and same old EJB applications, but on propreitary frameworks.

    Even in that case, is Spring the best? Is it like it has all the features that any J2EE application can flick from it?

    Obviously, features of these frameworks cannot be applied to all application scenarios. Somewhere or the other, the expectations are going to differ.

    So, as a J2EE server vendor, why does BEA need this torch bearer?

    I see this as a different business proposition. Correct me, if am wrong. I can alwys use any open source product for any of my tier (Hibernate for persistence) instead of the framework suggesting me or rather pushing me.
  94. Rick,

    To answer your questions:
    Do you think Spring is "committed" to WebLogic with this arrangement?
    Easy question. No--neither contractually or otherwise. We prize the fact that Spring is Switzerland with respect to application servers. (Or, indeed, use outside any application server.) Spring users expect that. We value our integrity and independence, and would not enter any deal that would compromise it. BEA understand and respect this.

    Our deal with BEA does not constrain the direction of Spring (or Interface21). All the reaction we have received from the Spring community and our clients (even those not using WebLogic) has been positive. Btw I believe that BEA's interest in Spring was substantially driven by their customers, many of whom were using or wanted to use Spring, so they should be applauded for taking the decision to respond to that.

    If BEA want to work with us to make Spring work particularly well on WebLogic, we are happy: it's good news for Spring users and WebLogic users. I have always believed that WebLogic Server is an excellent product, so feel comfortable that the result is a solid technical platform. It leaves no one worse off, as Spring works just as well as it did before on other platforms. And bear in mind that Spring's architecture naturally lends itself to optimization for particular platforms--for example, as users don't write code that's aware of the implementation of Spring's transaction aspect, they can benefit from platform-specific optimizations in its implementation without the risk of platform lock-in.

    From the contact I've had with BEA staff in a range of levels and roles (business and engineering) I believe that they are sincere about their interest in open source (which is not limited to Spring, by the way). So I believe that cheap shots--while predictable--are unwarranted.
    Do you see similar capabilities being provided for other application servers?
    Quite likely, yes. We would be happy to work with other application server vendors who have a sincere interest in cooperation. And remember that Spring already works well out of the box on other platforms using J2EE standard APIs, regardless of what value adds may be available on any particular platform.

    Rgds
    Rod
    Interface21 - Spring from the Source
  95. Rick, To answer your questions:
    Do you think Spring is "committed" to WebLogic with this arrangement?
    Easy question. No--neither contractually or otherwise. We prize the fact that Spring is Switzerland with respect to application servers. (Or, indeed, use outside any application server.) Spring users expect that. We value our integrity and independence, and would not enter any deal that would compromise it. BEA understand and respect this.Our deal with BEA does not constrain the direction of Spring (or Interface21). All the reaction we have received from the Spring community and our clients (even those not using WebLogic) has been positive. Btw I believe that BEA's interest in Spring was substantially driven by their customers, many of whom were using or wanted to use Spring, so they should be applauded for taking the decision to respond to that.If BEA want to work with us to make Spring work particularly well on WebLogic, we are happy: it's good news for Spring users and WebLogic users. I have always believed that WebLogic Server is an excellent product, so feel comfortable that the result is a solid technical platform. It leaves no one worse off, as Spring works just as well as it did before on other platforms. And bear in mind that Spring's architecture naturally lends itself to optimization for particular platforms--for example, as users don't write code that's aware of the implementation of Spring's transaction aspect, they can benefit from platform-specific optimizations in its implementation without the risk of platform lock-in.From the contact I've had with BEA staff in a range of levels and roles (business and engineering) I believe that they are sincere about their interest in open source (which is not limited to Spring, by the way). So I believe that cheap shots--while predictable--are unwarranted.
    Do you see similar capabilities being provided for other application servers?
    Quite likely, yes. We would be happy to work with other application server vendors who have a sincere interest in cooperation. And remember that Spring already works well out of the box on other platforms using J2EE standard APIs, regardless of what value adds may be available on any particular platform.RgdsRodInterface21 - Spring from the Source

    Glad to hear it.
    So I believe that cheap shots--while predictable--are unwarranted.

    I am unaware of any cheap shots that I took at WebLogic. If I did, I apologize it was unintended. I've been using WebLogic since before EJB 1.0 final. I've used WebLogic 4.5, 7 and 8.1 in anger.
  96. Rick
    So I believe that cheap shots--while predictable--are unwarranted.
    I am unaware of any cheap shots that I took at WebLogic. If I did, I apologize it was unintended. I've been using WebLogic since before EJB 1.0 final.
    I wasn't referring to you making cheap shots (you didn't), but other posters in this thread. Apologies for any misunderstanding.

    Rgds
    Rod
  97. Sun's JCP[ Go to top ]

    I guess that means people need alternative to Sun's JCP, JSRs.
    They gave us EJB, JSF ... and some good stuff.

    .V
  98. This has been a good discussion. I've really enjoyed it.

    It may be a day or two before I join in again.

    Again, it would be nice if JBoss could support Spring the way BEA does.

    Rick Hightower
    CTO, ArcMind Inc. JxEE, JSF, Spring, Hibernate: Training, consulting, and Mentoring
  99. great[ Go to top ]

    This has been a good discussion. I've really enjoyed it.It may be a day or two before I join in again.

    That's great news because I'm tired of you kissing everyone's ass.
    You have really grown as a speaker (like 1000%). It is like you are a different person. Good work
    Rod, I agree with you about a lot of things, and I admire you.
    No problem. You are still the king of all Java.
  100. RE: great[ Go to top ]

    This has been a good discussion. I've really enjoyed it.It may be a day or two before I join in again.
    That's great news because I'm tired of you kissing everyone's ass.
    You have really grown as a speaker (like 1000%). It is like you are a different person. Good work
    Rod, I agree with you about a lot of things, and I admire you.
    No problem. You are still the king of all Java.

    Rod, Bill and Gavin have done some amazing things. I get a lot of benefit from software they have written. I truly admire their accomplishments.

    Bill gets a lot of criticism. I saw his first talk on AOP at the first TSS symposium. I saw his last talk at the last TSS symposium and was totally impressed. My comment was honest.

    I have no business relationship with Rod, Gavin or Bill where I need to show them deference. I do this out of respect and awe of their accomplishments.
  101. Thanks a lot for a very nice comparison article Spring vs. J2EE! I especially like the diagrams which show the same application implemented with both *pure* technologies as long as this is possible. Until now there is an absence of such a clear comparison. I've searched for such a comparison between Spring and J2EE in the programming style and now I found it... ;-)

    My conclusion for the Business Logic Layer (Services Tier in the diagrams):

    1. Spring is following the "weak type" programming style. Everything are Spring Beans (POJOs), which
    can be configured as entities, services, etc. It still miss the MDB functionality (because the diagram shows that we still need MDB) but I think adding this "configuration" would be no problem at all. Also the same with TimerBeans. I categorize Spring as a weak type programming style since it does not offer specialized types for different purposes in business logic implementations.
    -> Pros: easy to begin with since what you need to understand is POJO, POJO and POJO.
    -> Cons: semantically weak. You only have POJOs. Distinction of types is done through the configuration.

    2. J2EE is following the "strong type" programming style. You have there: EB for entities, SB for stateful and stateless services, MDB for async. services and TB for timers. So in this case you have to choose the "type" of your beans to implement your needed business logics.
    -> Pros: semantically strong, you have strong type which can be checked formally.
    -> Cons: difficult to begin with, since you have many specialized types you have to choose from. What is EB, why SSB?

    What is the best choice? This is difficult to answer. It's analog to the question do you like strong type languages like Java or weak type languages (mostly script languages) like Groovy? Do you like to have almost all errors checked in compile time or in the runtime? Each language has it's own place.

    What is you favorites? Any comments?

    Cheers,
    Lofi.
    EJOSA - OpenUSS
  102. Lofi, just for comparison with what JBoss is pushing with the standard EJB3 spec, check out these quick trailblazers if you haven't already: http://trailblazer.demo.jboss.com/EJB3Trail/

    -- Jacob
  103. Thanks a lot for a very nice comparison article Spring vs. J2EE! I especially like the diagrams which show the same application implemented with both *pure* technologies as long as this is possible. Until now there is an absence of such a clear comparison. I've searched for such a comparison between Spring and J2EE in the programming style and now I found it... ;-)My conclusion for the Business Logic Layer (Services Tier in the diagrams):1. Spring is following the "weak type" programming style. Everything are Spring Beans (POJOs), whichcan be configured as entities, services, etc. It still miss the MDB functionality (because the diagram shows that we still need MDB) but I think adding this "configuration" would be no problem at all. Also the same with TimerBeans. I categorize Spring as a weak type programming style since it does not offer specialized types for different purposes in business logic implementations.-> Pros: easy to begin with since what you need to understand is POJO, POJO and POJO.-> Cons: semantically weak. You only have POJOs. Distinction of types is done through the configuration.2. J2EE is following the "strong type" programming style. You have there: EB for entities, SB for stateful and stateless services, MDB for async. services and TB for timers. So in this case you have to choose the "type" of your beans to implement your needed business logics.-> Pros: semantically strong, you have strong type which can be checked formally.-> Cons: difficult to begin with, since you have many specialized types you have to choose from. What is EB, why SSB?What is the best choice? This is difficult to answer. It's analog to the question do you like strong type languages like Java or weak type languages (mostly script languages) like Groovy? Do you like to have almost all errors checked in compile time or in the runtime? Each language has it's own place.What is you favorites? Any comments?Cheers,Lofi.EJOSA - OpenUSS

    I don't agree with that assement at all. Spring, IMO, is less about POJOs and more about interfaces and you don't have to use interfaces. What you call "weak" typing is what I would call coding to interfaces and you are implying that this is wrong.

    In addition, the use of MDBs, IMO, opinion is not an issue of typing at all, but of coupling. Regardless, Spring has direct support for messaging via support in
    ActiveMQ and application server MDBs so I don't understand what disadvantage you think exists.

    Finally, Springs direct support of Quartz and the javatimer should be able to provide any support that a Timerbean provides and all of this without an app server container.

    You comment about specialized types for different purposes in business logic eludes me. Explain.
  104. Lofi
    Thanks a lot for a very nice comparison article Spring vs. J2EE!
    I don't actually see Spring as being an alternative to J2EE. I wasn't responsible for the wording around the "Spring" vs "J2EE" version of the app and don't really agree with the distinction.

    Spring certainly offers the functionality of some J2EE technologies--notably much of the EJB component model--but that is not at all the same as saying that Spring is an alternative to J2EE or aiming to replace J2EE. This is an important distinction, and I actually wrote a book about it :-)
     I categorize Spring as a weak type programming style since it does not offer specialized types for different purposes in business logic implementations.
    -> Pros: easy to begin with since what you need to understand is POJO, POJO and POJO.
    -> Cons: semantically weak. You only have POJOs. Distinction of types is done through the configuration.
    I don't see baking volatile infrastructure concerns into application code as being semantically "strong". I see it as rather "semantically vulnerable to change". I've seldom heard a POJO-based approach characterized as "weak": after all, it preserves strong typing and does away with many of the type casts etc you needed to do dependency lookup with APIs such as JNDI. And of course your comments relate to POJO-based technologies in general; Spring just happens to be the best-known and most sophisticated of them.

    I think a "specialized type" approach--such as entity beans prior to EJB 3.0--is often a design smell, and the industry is tending to move away from it. Spring was just ahead of the curve. A key problem is that infrastructure concern pollutes the domain objects. You want to preserve investment in your application code; you know that the infrastructure environment will change and don't want knowledge of them ingrained throughout your application code. If you have a POJO approach, if the technology changes you needn't rewrite so much of your app. Consider migrating (a) an EJB 2 app to EJB 3; (b) a Hibernate, JDO or TopLink app. Because the latter 3 technologies are basically POJO based, the migration is a lot easier. With the original entity bean approach of very "specialized" objects, the entity beans require huge rework.

    Rgds
    Rod
  105. With the original entity bean approach of very "specialized" objects, the entity beans require huge rework. RgdsRod

    That's true Rod, and JBoss/Everyone knows it. I think where JBoss is drawing comparisons and has been trying to make repairs (in light of the success of the POJO model) is in the EJB 3 spec. It's very hard to draw comparisons on EJB 3, based on the original entity approach.

    As for Strong Type vs. Weak Type Programming style, I think the comparison is missing the mark. Even with strongly-typed annotations, there is always going to be that black-box factor, the same as Spring, in being able to assert strongly typed relationships. From a code management standpoint, I do believe that EJB 3's IoC support will win out, such that concerns can scale with the object, leading to better code tracability without depending on external resources/configs. This is an even bigger factor for smaller projects-- where Seam is tackling the RoR 'market'.

    Cheers,
    Jacob (JSF-EG/Facelets)
  106. Jacob

    I agree, I think the industry is basically moving the same way with the POJO approach. The "specialized type" approach was tried for several years and found wanting.
    From a code management standpoint, I do believe that EJB 3's IoC support will win out, such that concerns can scale with the object, leading to better code tracability without depending on external resources/configs.
    Obviously Spring could trivially support EJB3-style annotations (we've prototyped it and it's only a couple of hundred LOC with no change to the core, because of extensibility hooks in the container) but so far we haven't gone down that route because we disagree. I think the negatives outweigh the potential positives. Annotations aren't really necessary for DI because of introspection; they couple the application objects to the framework; they assume there is a lookup for an object by name; they don't work well for legacy objects; they don't work well when different instances need to be configured differently; tooling can be driven in other ways. So a lot of things we've learned from experience of DI in the last two years mean that I and most of the other Spring committers aren't convinced by the EJB3 model for DI.

    Of course it will be interesting to see what happens with experience of DI annotations in practice, and we'll closely monitor that.

    It's an interesting discussion, but, this thread seems to be getting way off topic. I do"o't think it's the place for an EJB3 vs Spring debate. The original discussion was about POJOs vs "old-style" J2EE, and I think we're in agreement there.

    Rgds
    Rod
  107. Btw we do see a lot of value in the JSR-220 (EJB3) persistence work (Java Persistence API), and will be announcing Spring integration for it shortly after the Reference Implementation is available.
  108. Btw we do see a lot of value in the JSR-220 (EJB3) persistence work (Java Persistence API), and will be announcing Spring integration for it shortly after the Reference Implementation is available.

    That's really great news! Do you know if this will help lead BEA into EJB 3 support, or will it initially lead to microcontainer use within the BEA AS?
  109. Java Persistence API[ Go to top ]

    Jacob
    That's really great news!
    Thanks.
    Do you know if this will help lead BEA into EJB 3 support, or will it initially lead to microcontainer use within the BEA AS?
    That's a question for BEA to answer, and I can't speak for them. I was talking as co-lead of Spring; I don't know what their plans are.

    Rgds
    Rod
  110. The J2EE container maintains a pool of SBs that work concurrently. What is the equivalent in the Spring POJO architecture. Does one need to code their own thread pools?
    Also in mid to large size projects with hundres of objects, doesn't maintaining objects associations in XML become significantly messy?
  111. Spring features[ Go to top ]

    The J2EE container maintains a pool of SBs that work concurrently. What is the equivalent in the Spring POJO architecture. Does one need to code their own thread pools?

    No, one does not (or should ever be) coding their own object instance pools with Spring.

    Spring ships prepackaged integration with the Jakarta Commons Pool project, allowing any Spring-managed POJO instance to be sourced from (by default) a GenericObjectPool. Spring's container accomplishes this by building on its AOP framework to inject dynamic proxies to pooled services, allowing clients to work with pooled objects safely in a transparent manner.

    Alef wrote a good article on this support, you can find it here:
    http://blog.arendsen.net/index.php/2005/07/06/spring-instance-management-part-i-pooling/
    Also in mid to large size projects with hundres of objects, doesn't maintaining objects associations in XML become significantly messy?

    Spring provides several features today to reduce the amount of XML-coding required for externalized system assembly. These features include:
    - Bean definition inheritance, the ability for a child definition to inherit the configuration of its parent
    - Bean auto wiring, which has the container automatically detect how a bean instance should be configured
    - In-line attributes for the commonly used configuration elements (property, ref, etc).
    - Support for merging multiple, independent configuration fragments into a combined context hierarchy, to support independently manageable sets of deployment descriptors for individual subsystems of a large application.

    It is important to note that there is no suggested practice of "wiring everything with XML". Externalized assembly by an IoC container makes the most sense for fairly coarse grained components, and makes those components pluggable and testable. If you are wiring every object association with the container, you should consider why you are doing so.

    You can also expect Spring to offer more powerful programmatic configuration alternatives in future releases, where you will be able to take advantage of built in IDE refactoring capabilities and a richer set of configuration defaults. You can expect us to raise the bar by offering this new functionality without breaking compatibility with existing versions of Spring.

    Regards,

    Keith

    Interface21, Inc.
    http://www.springframework.org
  112. BEA adds support to Weblogic for Spring[ Go to top ]

    The J2EE container maintains a pool of SBs that work concurrently. What is the equivalent in the Spring POJO architecture. Does one need to code their own thread pools?
    It's crucial to pool resources such as database connections (with DataSources). However, such pooling is provided by the server as a whole (or third party products such as Commons DBCP), rather than the EJB component model. Again, it's the distinction between J2EE as a whole and EJB. In general, you do not want to pool instances of stateless service objects, as they're naturally thread safe. However, as Keith points out, it is possible with Spring with POJOs. It's just seldom necessary, so once you have the choice you don't want to pool everything.
    Also in mid to large size projects with hundres of objects, doesn't maintaining objects associations in XML become significantly messy?
    Note also that the alternative is not of zero cost. Consider how many Service Locators wrapping JNDI lookups you would have in a traditional architecture. Also, "autowiring" can significantly reduce the volume of configuration for objects with simpler wiring requirements, enabling the container to learn about your objects and what they require.
  113. Why should user integrate WLS + Spring?[ Go to top ]

    Hi,
    Can anybody focus some light on following queries?

    1. Spring brings in light-weight container and at no cost. WLS brings in bulky container and that too at high cost. In which situations these 2 technologies should be integrated?

    2. Agree that WLS brings in other features which are not part of Spring (messaging, JMX, etc), but why should user consider costly server than just going to other open source technologies?

    Thanks
    -Swarraj.
  114. Why should user integrate WLS + Spring?[ Go to top ]

    Hi,Can anybody focus some light on following queries?1. Spring brings in light-weight container and at no cost. WLS brings in bulky container and that too at high cost. In which situations these 2 technologies should be integrated?

    Well, that was really the point of the whitepaper. For details I suggest you start there. In essence our view is that Spring's lightweight container is fine for development, but for production you will want something with proven RASP (reliability, availability, scalability and performance) features. Also, when you use Spring on WLS you would continue to use the Spring programming model its just some of the underlying infrastructure that is replaced.
    2. Agree that WLS brings in other features which are not part of Spring (messaging, JMX, etc), but why should user consider costly server than just going to other open source technologies?Thanks-Swarraj.

    (Don't forget Servlets here). I think you are probably comparing the wrong things, and that was what I was at pains to point out in the whitepaper. WLS provides quality-of-service (QOS) benfits as well as alternative (J2EE) APIs. A lot of the development effort in WLS is spent on this infrastructure, so even if you don't use the APIs (because you are using Spring say) you still get many of the benefits of WLS. I'm sure other J2EE vendors would make similar claims. As to why WLS as opposed to another opensource application server, well then we get into heated debate over quality-of-implementation and TCO. You will have to decide what your business requirements are and choose appropriately.
  115. Why should user integrate WLS + Spring?[ Go to top ]

    1. Spring brings in light-weight container and at no cost. WLS brings in bulky container and that too at high cost. In which situations these 2 technologies should be integrated?
    Spring is not an application server. The two products don't conflict. However, Spring provides an excellent, productive, way of tapping into WebLogic services.
    2. Agree that WLS brings in other features which are not part of Spring (messaging, JMX, etc), but why should user consider costly server than just going to other open source technologies?
    You should choose your application server based on your requirements. Spring doesn't dictate that choice; in fact, using Spring tends to make applications more portable, so you can exercise your choice more freely.

    Remember that license cost is just one consideration in application server choice; you should consider TCO, and issues such as reliability, performance per unit hardware, scalability, deployment and administrations. In the high end, the leading commercial products such as WebLogic offer capabilities that are not presently available in open source. In the low end, OTOH, you might be best off using Spring with a servlet engine such as Tomcat.
  116. BEA adds support to Weblogic for Spring[ Go to top ]

    After implementation of EJB3, WL will support Spring or not?
  117. BEA adds support to Weblogic for Spring[ Go to top ]

    After implementation of EJB3, WL will support Spring or not?
    A move like this from BEA represents a long-term commitment. Vendors such as BEA typically provide a guarantee of 5 years (+2) support on technologies they support. Thus they're in this for the long haul, and would not be doing this unless they were convinced that Spring is also a long-term part of the future of enterprise Java.

    When BEA supports EJB3, things won't change. As I've mentioned in this thread, Spring will integrate with the Java Persistence API, the most valuable part of the JSR-220 work. Even beyond this, Spring will still provide a clear value proposition for EJB3 users, with the market-leading, most sophisticated Dependency Injection capability and many other features beyond the scope of EJB. And we are committed to ensuring that Spring retains its longstanding leadership in POJO-based middleware.
  118. I am sure there is a rational explaination for this, but I can't seem to figure out the answer.

    It seems many people think owning a company based on a licence model rather than service model is better, because it scales better in terms of revenue and profitability, yet they claim TCO of licence model is lower for customers. How is that possible?
  119. BEA adds support to Weblogic for Spring[ Go to top ]

    Jan,
    I am sure there is a rational explaination for this, but I can't seem to figure out the answer.
    Yes, I believe there is. :)
    It seems many people think owning a company based on a licence model rather than service model is better, because it scales better in terms of revenue and profitability, yet they claim TCO of licence model is lower for customers. How is that possible?
    My take is that a licence-based company needs fewer new employees while scaling, thus keeping costs down. Thus, they can have more customers, each of them paying less, while still enjoying greater revenue and profitability.

    For a service-based company, there's a closer relationship between revenue and costs, making them less capable of reducing prices in order to boost sales.
  120. BEA adds support to Weblogic for Spring[ Go to top ]

    My take is that a licence-based company needs fewer new employees while scaling, thus keeping costs down. Thus, they can have more customers, each of them paying less, while still enjoying greater revenue and profitability.For a service-based company, there's a closer relationship between revenue and costs, making them less capable of reducing prices in order to boost sales.

    In a nutshell this is the theory. On top of this, a license based company has a steady revenue stream regardless of the current consulting market rates, the project pipeline etc. Of cuorse it is a little blue eyed to believe that TCO will really be lower in the licence based software, as long as there is no significant pressure on the supplier, by either a competitor that licenses for less or by a company running a free and open source model.

    Of course both the open source company and the traditional software license company do try to sell consultancy services and training around their product.

    One thing worth noting is that most open source company (in their "consulting division", but maybe also in support and software development) may need employees of a "higher quality" than the traditional license based company, because they are expected to deliver more in depth knowledge, the knowledge around the product is not as formalized and the customer is likely to possess more detailed knowledge of the inner workings of the product. While this is good news for the customer it may well be hard for the company to recruit up to its standards and at the necessary volume to satisfy demand. The license based company may get away with a well organized first and second level support on the other hand.
  121. Well, I'm not quite sure what are you arguing about, guys.

    When you say "open source", it means "open source as BSD/Apache", "...as [L]GPL" or as something like what Caucho does with Resin?

    When you say "software", do you mean application servers, specialized desktop apps like IDEs or other development tools, or server-side apps like JIRA?

    It's just like trying to argue about some assumptions on consumer goods market as a whole, without separating plasma TV screens from chewing gum.
  122. BEA adds support to Weblogic for Spring[ Go to top ]

    Jan,
    I am sure there is a rational explaination for this, but I can't seem to figure out the answer.
    Yes, I believe there is. :)
    It seems many people think owning a company based on a licence model rather than service model is better, because it scales better in terms of revenue and profitability, yet they claim TCO of licence model is lower for customers. How is that possible?
    My take is that a licence-based company needs fewer new employees while scaling, thus keeping costs down. Thus, they can have more customers, each of them paying less, while still enjoying greater revenue and profitability.For a service-based company, there's a closer relationship between revenue and costs, making them less capable of reducing prices in order to boost sales.


    Um, guys, you do realize that traditional software vendors provide support as part of the license, right? Now, certainly the *quality* of this support has traditionally been awful, but one of the following must be logically true:

    (1) Cost to the customer of open source support is lower
     than commerical licenses

    (2) Revenue for OSS vendors is just as scalable
    (3) Quality of support for commercial vendors is of much lower quality

    Since TCO is affected by (3) and (1) taken together (along with other factors like software quality which are irrelevant for the purpose of this analysis), the original post was actually very well-reasoned.

    ie. You can argue that commercial software has competitive TCO, or you can argue that OSS vendors don't scale revenue. But you can't argue both at the same time.

    My view on this is that for OSS vendors, TCO is lower, revenue is lower, but that also costs (especially sales/marketing costs but also development costs) are lower. OSS vendors are simply more efficient than the giants.

    I see a lot of people here making the mistake of assuming that OSS companies are consulting companies. This is simply not true. At least in the case of JBoss, most revenue comes from support contracts. There is no reason to believe that suport contracts are more expensive to scale than software licenses, since licenses include support.

    But, I remain firm in my belief that pure scale (measured in revenue) is much less important to an OSS vendor being able to compete, innovate, capture and retain market share, and generally remain viable than it is to a commercial vendor.
  123. Um, guys, you do realize that traditional software vendors provide support as part of the license, right? Now, certainly the *quality* of this support has traditionally been awful ..

    Gavin, while most companies (technology companies and car companies and all other companies) have poor quality support, it has nothing to do with whether the company gives away their software or not.

    The one thing about companies that make their revenue from support is that they have an incentive to make the support good. The only problem with assuming that explains some difference is that commercial software companies make lots of money from support.
    one of the following must be logically true:
    (1) Cost to the customer of open source support is lower than commerical licenses
    (2) Revenue for OSS vendors is just as scalable
    (3) Quality of support for commercial vendors is of much lower quality

    Can you explain that logic? I honestly don't follow it at all.
    My view on this is that for OSS vendors, TCO is lower ..

    From customers I've spoken to, I know that is not true in our market.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Transactional Caching
  124. BEA adds support to Weblogic for Spring[ Go to top ]

    One of the following must be logically true:
    (1) Cost to the customer of open source support is lower&nbsp;than commerical licenses
    (2) Revenue for OSS vendors is just as scalable
    (3) Quality of support for commercial vendors is of much lower quality

    Gavin, seems to me there are a lot of assumptions here. The most striking is that you seem to imply that the way the support organization works for an open source company is essentially the same as for a company selling software licenses. I am not entirely sure that this is true.

    Also having worked in support and having used support (of a major J2EE vendor) I can truly say that there are some support organizations that actually deliver quite nicely on their promise (if you are persistent enough).

    Also support is not the sole revenue stream for a product company, or put differently the number calls/number contracts ratio will usually be in favor of the license company, creating larger continous revenue and thus allowing for easier scalability. I would suspect that the people buying support from open source companies are more likely to require more 4th level (on site) support, which generally scales only with available individuals.

    Also my general feeling is that in terms of real costs, licensing/support cost is negligible compared to the cost of actual running and managing the software, (continuously) training the people to operate the software, build with and for the software etc.
    But, I remain firm in my belief that pure scale (measured in revenue) is much less important to an OSS vendor being able to compete, innovate, capture and retain market share, and generally remain viable than it is to a commercial vendor.

    I am not entirely sure that the venture capital industry shares that vision :-).
  125. Um, guys, you do realize that traditional software vendors provide support as part of the license, right?

    Perhaps in the shrink-wrapped world, but this doesn't usually carry into the enterprise software world. Vendors typically sell annual support & maintenance (i.e. free full-release upgrades) for a percentage of license costs. That percentage can vary between 15-25%, and can be subject to various discounts, depending on how the deal is structured. This is usually mandatory for the first year after buying a license, and optional thereafter. And there are usually penalties to cancel & renew such contracts.
    Now, certainly the *quality* of this support has traditionally been awful,

    Perhaps. I'll note that the Asssociation for Support Professionals has named BEA as one of the "ten best" support websites, along with Cisco and others... http://www.asponline.com/awards.html
    (1) Cost to the customer of open source support is lower&nbsp;than commerical licenses

    No. More likely, OSS saves customers money by eliminating the license revenue entirely and relying on support/maintenance subscription revenue as the main income stream, supplemented by consulting.

    Interestingly enough, IBM is taking the "two sided war" approach to this -- their big cow is in consulting, and they'll sacrifice license revenue to get it, even though they still charge licenses for WebSphere.
    (2) Revenue for OSS vendors is just as scalable

    OSS vendors lack the cash infusion that license revenue generates. Wall Street traditionally measures software growth through this number, I suppose they'll measure OSS vendors through net-new subscriptions. Enterprise software players also have a lot of leeway to construct specialized deals (including customized terms & conditions) for large accounts. With smaller margins, OSS players have less leeway.
    (3) Quality of support for commercial vendors is of much lower quality
    This is a red herring. JBoss is a commercial vendor just as much as IBM, BEA, or Microsoft. The quality of support THAT A COMPANY IS PAID FOR is completely company-specific and has nothing to do with the underlying licensing model.

    If, on the other hand, you're referring to open source's reputation for having good "free" support on mailing lists, newsgroups, and discussion forums, I have to wonder WHY customers would pay an OSS VENDOR for this?
     OSS vendors are simply more efficient than the giants.I see a lot of people here making the mistake of assuming that OSS companies are consulting companies. This is simply not true. At least in the case of JBoss, most revenue comes from support contracts. There is no reason to believe that suport contracts are more expensive to scale than software licenses, since licenses include support.

    Gavin, I love your work with Hibernate, and think you're a valuable member of this community. But I really think that you are betraying ignorance of the way enterprise software is priced and sold. (But hey, I was pretty ignorant of it too before joining a vendor.)
  126. Support[ Go to top ]

    Guys, all three of you, please explain how it is possible that commercial vendors can deliver low TCO to the customer without spending a lot on delivering support. Quality of support is a critical component of lowering TCO.

    Again, the original poster is correct. It is simply not logically possible that licenses are by nature much more profitable to the vendor, while still being competitive in terms of customer TCO. Think it through! The money comes from the customer! If the vendor is more profitable in one model, it means, necessarily, that under that model the vendor is spending less money delivering services to the customer. This means a higher TCO.

    This should be be so obvious that it should not need explanation.
  127. Support[ Go to top ]

    This was Gavin using my laptop, btw. Probably obvious from the "Guys, ...".
  128. RE: Gavin using my laptop[ Go to top ]

    This was Gavin using my laptop, btw. Probably obvious from the "Guys, ...".

    Are you sure you are not channeling Gavin.....

    I've never seen you two guys together in the same room. Perhaps you are the same person.

    Christavin, Gastian, ...

    Are you guys pair programming?
  129. RE: Gavin using my laptop[ Go to top ]

    I think I just got caught astroturfing.
  130. RE: Gavin using my laptop[ Go to top ]

    I think I just got caught astroturfing.

    I had to look that one up....
    astroturfing: n.
    1. The use of paid shills to create the impression of a popular movement, through means like letters to newspapers from soi-disant ‘concerned citizens’, paid opinion pieces, and the formation of grass-roots lobbying groups that are actually funded by a PR group (AstroTurf is fake grass; hence the term). See also sock puppet, tentacle.

    2. What an individual posting to a public forum under an assumed name is said to be doing.

    This term became common among hackers after it came to light in early 1998 that Microsoft had attempted to use such tactics to forestall the U.S. Department of Justice's antitrust action against the company. The maneuver backfired horribly, angering a number of state attorneys-general enough to induce them to go public with plans to join the Federal suit. It also set anybody defending Microsoft on the net for the accusation “You're just astroturfing!”.

    from http://catb.org/~esr/jargon/html/A/astroturfing.html

    I assume you meant the second meaning since you are not a paid shill.
  131. RE: Gavin using my laptop[ Go to top ]

    I think I just got caught astroturfing.
    I had to look that one up....

    Holy crap. I thought everyone in this forum (especially one as visible and... complimentary... as Rick) knew JBoss and astroturfing were tightly coupled. They may not have invented the practice, but they certainly turned it into an artform.

    Thus, Gavin's comment was actually a bit of sly irony. No, he wasn't actually astroturfing, but I'm sure mentioning it brought back fond memories for his compatriots.
  132. Who cares?[ Go to top ]

    I think I just got caught astroturfing.
    I had to look that one up....
    Holy crap. I thought everyone in this forum (especially one as visible and... complimentary... as Rick) knew JBoss and astroturfing were tightly coupled. They may not have invented the practice, but they certainly turned it into an artform.Thus, Gavin's comment was actually a bit of sly irony. No, he wasn't actually astroturfing, but I'm sure mentioning it brought back fond memories for his compatriots.

    If you look at my post history, I don't post that often (until recently).

    But I will tell you this, I don't know about JBoss and astroturfing. I missed that episode. But I still see a lot of potential astroturfing going on from a lot more than JBoss. I like being independent. I don't have to side with anybody. In fact, in one post I can side with one side, and then in the other post I can side with the other. I have no agenda nor do I have to clear what I say with anybody.

    Well, let's be perfectly honest, everyone has some agenda and bias.

    I will use JBoss, Resin, WebLogic, WebSphere, Tomcat, Oracle AS, etc. as long as I am getting paid to do so.

    I really like Spring. However, I would not think twice about using JBoss Microcontainer if a contract paid more than an Spring contract. I don't work for JBoss or Interface21.

    I really like Hibernate. However, I would not think twice about using Cayenne or TopLink if a contract paid more than a Hibernate contract.

    I really like JSF. However, I would not think twice about using Tapestry, WebWork or Spring MVC if a contract paid more than a JSF contract. (I have done Spring MVC before, and really like it. I really look forward to working with WebWork one day b/c I think there is a lot to learn from Rickard, Patrick and Jason.)

    My loyalty is to my family and things like family not to a framework.

    That said I really enjoy working with JSF, Spring and Hibernate.
  133. Who cares?[ Go to top ]

    I think I just got caught astroturfing.
    I had to look that one up....
    Holy crap. I thought everyone in this forum (especially one as visible and... complimentary... as Rick) knew JBoss and astroturfing were tightly coupled. They may not have invented the practice, but they certainly turned it into an artform.Thus, Gavin's comment was actually a bit of sly irony. No, he wasn't actually astroturfing, but I'm sure mentioning it brought back fond memories for his compatriots.
    If you look at my post history, I don't post that often (until recently).But I will tell you this, I don't know about JBoss and astroturfing. I missed that episode. But I still see a lot of potential astroturfing going on from a lot more than JBoss. I like being independent. I don't have to side with anybody. In fact, in one post I can side with one side, and then in the other post I can side with the other. I have no agenda nor do I have to clear what I say with anybody.Well, let's be perfectly honest, everyone has some agenda and bias. I will use JBoss, Resin, WebLogic, WebSphere, Tomcat, Oracle AS, etc. as long as I am getting paid to do so.I really like Spring. However, I would not think twice about using JBoss Microcontainer if a contract paid more than an Spring contract. I don't work for JBoss or Interface21.I really like Hibernate. However, I would not think twice about using Cayenne or TopLink if a contract paid more than a Hibernate contract. I really like JSF. However, I would not think twice about using Tapestry, WebWork or Spring MVC if a contract paid more than a JSF contract. (I have done Spring MVC before, and really like it. I really look forward to working with WebWork one day b/c I think there is a lot to learn from Rickard, Patrick and Jason.)My loyalty is to my family and things like family not to a framework.That said I really enjoy working with JSF, Spring and Hibernate.

    Well, to me there is more than just upfront costs. Unless a job paid so much that the decision was a no-brainer, I wouldn't want to spend time ramping up on a product unless I thought it had a future. Why? The market is competitive and being a marathon(not a sprint), I looking beyond the current job. I want to make sure that my time is spent being as marketable as possible. If I perceieve that no one is using a tool, I don't want to use it because I wouldn't believe that it will help get my next job.

    In addition, I have enough confidence that I feel that I don't have to learn everything. For example, unless a VB job was paying some astronomical fee, I wouldn't take it because it is paying more than I'm making because I'm not interested. I've seen my salary go up from my early days to now to know that money isn't everything. Unless someone's offering some insane amount, I can afford to be picky and stick to what I enjoy.
  134. Who cares?[ Go to top ]

    I think I just got caught astroturfing.
    I had to look that one up....
    Holy crap. I thought everyone in this forum (especially one as visible and... complimentary... as Rick) knew JBoss and astroturfing were tightly coupled. They may not have invented the practice, but they certainly turned it into an artform.Thus, Gavin's comment was actually a bit of sly irony. No, he wasn't actually astroturfing, but I'm sure mentioning it brought back fond memories for his compatriots.
    If you look at my post history, I don't post that often (until recently).But I will tell you this, I don't know about JBoss and astroturfing. I missed that episode. But I still see a lot of potential astroturfing going on from a lot more than JBoss. I like being independent. I don't have to side with anybody. In fact, in one post I can side with one side, and then in the other post I can side with the other. I have no agenda nor do I have to clear what I say with anybody.Well, let's be perfectly honest, everyone has some agenda and bias. I will use JBoss, Resin, WebLogic, WebSphere, Tomcat, Oracle AS, etc. as long as I am getting paid to do so.I really like Spring. However, I would not think twice about using JBoss Microcontainer if a contract paid more than an Spring contract. I don't work for JBoss or Interface21.I really like Hibernate. However, I would not think twice about using Cayenne or TopLink if a contract paid more than a Hibernate contract. I really like JSF. However, I would not think twice about using Tapestry, WebWork or Spring MVC if a contract paid more than a JSF contract. (I have done Spring MVC before, and really like it. I really look forward to working with WebWork one day b/c I think there is a lot to learn from Rickard, Patrick and Jason.)My loyalty is to my family and things like family not to a framework.That said I really enjoy working with JSF, Spring and Hibernate.
    Well, to me there is more than just upfront costs. Unless a job paid so much that the decision was a no-brainer, I wouldn't want to spend time ramping up on a product unless I thought it had a future. Why? The market is competitive and being a marathon(not a sprint), I looking beyond the current job. I want to make sure that my time is spent being as marketable as possible. If I perceieve that no one is using a tool, I don't want to use it because I wouldn't believe that it will help get my next job.In addition, I have enough confidence that I feel that I don't have to learn everything. For example, unless a VB job was paying some astronomical fee, I wouldn't take it because it is paying more than I'm making because I'm not interested. I've seen my salary go up from my early days to now to know that money isn't everything. Unless someone's offering some insane amount, I can afford to be picky and stick to what I enjoy.

    I agree. The technology would have to have a future. This is the main reason I picked JSF over other frameworks. (More work!)
  135. Who cares?[ Go to top ]

    I agree. The technology would have to have a future.

    That is why the partnership between WebLogic and Spring is significant.
  136. RE: Gavin using my laptop[ Go to top ]

    This was Gavin using my laptop, btw. Probably obvious from the "Guys, ...".
    Are you sure you are not channeling Gavin.....I've never seen you two guys together in the same room. Perhaps you are the same person. Christavin, Gastian, ...Are you guys pair programming?
    Which begs the question: in case one hires a programmer with multiple personality disorder, should he code by himself in a XP environment?

    (sorry, couldn't resist :>)
  137. RE: Gavin using my laptop[ Go to top ]

    This was Gavin using my laptop, btw. Probably obvious from the "Guys, ...".
    Are you sure you are not channeling Gavin.....I've never seen you two guys together in the same room. Perhaps you are the same person. Christavin, Gastian, ...Are you guys pair programming?
    Which begs the question: in case one hires a programmer with multiple personality disorder, should he code by himself in a XP environment?(sorry, couldn't resist :>)

    I think so, and so do I.
  138. Support[ Go to top ]

    Guys, all three of you, please explain how it is possible that commercial vendors can deliver low TCO to the customer without spending a lot on delivering support. Quality of support is a critical component of lowering TCO.
    I can use my own case as example here. We don't make much money on support, and we don't have much to offer in terms of consulting services (note that we do have many consulting partners that extend our platform though, but that is different).

    Hence, we put all our energy into making the product as easy to use and manage as possible, which means less support work for us. This gives us a vastly lowered TCO for the customer compared to both (typical) OpenSource solutions and other vendors who are consulting-intensive.

    After the initial purchase more or less all extra money is spent on getting more functionality, i.e. "something for something". But we might be a special case; I don't know how others deal with this in general.
  139. Support[ Go to top ]

    Guys, all three of you, please explain how it is possible that commercial vendors can deliver low TCO to the customer without spending a lot on delivering support. Quality of support is a critical component of lowering TCO.Again, the original poster is correct. It is simply not logically possible that licenses are by nature much more profitable to the vendor, while still being competitive in terms of customer TCO. Think it through! The money comes from the customer!

    This would only be true if all other factors in the equation would be the same. There are various variables in the equation. Even if you imagine that the license revenue for a closed source product is equal to the one from a support only contract there are still differences. One is that the argument mixes up TCO for the overall industry with TCO for an individual customer, which are dramatically different things (comparable to the difference of a "national economist" with an MBA).

    One of the crucial ones is the amount of support requests per support contract. Another one is the general depth of support requests for the product. Even if the products have the exact same bugs and exact same documentation, it is likely that the support-only open source model is more expensive for the supplier (because a fair amount of people will use the software without paying at all, of course). I tend to believe that the support-only company needs better and higher paid staff and may run into recruiting problems when scaling which in turn limits the recurring funds available for ongoing development.

    Of course, only the future will tell :-).
  140. Support[ Go to top ]

    Guys, all three of you, please explain how it is possible that commercial vendors can deliver low TCO to the customer without spending a lot on delivering support.

    Companies typically do 3, 5 or 10-year TCO studies. They want to know what the software will cost them over that period of time. Sometimes, TCO is just what they pay the vendor, in which case it is:

    licensecost + term * supportcost

    Or if support is included initially, it is:

    licensecost + (term-1) * supportcost

    To provide a customer with a lower TCO, one would reduce the license and/or support cost below one's competitors.

    If an open source company has a higher TCO, then that implies that the support fees for open source software are significantly higher. That may be a reflection of the open source company's own cost structure, since it may cost the company significantly more in order to provide the same relative level of support for the open source product.

    There is no hard and fast rule as to whether open source has higher or lower TCO. There are a lot of extremely (even ludicrously) over-priced commercial software products, and their support is often relative to the list software price (e.g. 25% per year). On the other hand, engineers often make the mistake of thinking of costs only in terms of license costs, which often results in a "roll your own" mentality (as if engineers were free), or in the case of using open source solutions, it results in their organizations picking up rather large and unplanned support bills down the line.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Transactional Caching
  141. The serverside is "stuck in a moment and can't get rid of it". This this the 4th day with no new news. Did the world stop at this announcement?
  142. BEA adds support to Weblogic for Spring[ Go to top ]

    TSS is paused atm, while Karle tries to convince the universe that JBoss is doomed. *yawn*

    STAY METAL!
    Roy Russo
  143. BEA adds support to Weblogic for Spring[ Go to top ]

    TSS is paused atm, while Karle tries to convince the universe that JBoss is doomed. *yawn*STAY METAL!Roy Russo

    Its Karl, Roye, but anyway :-). No I am not trying to convince anyone that JBoss is doomed nor did I claim it is nor did I claim that it is even doing badly financially. I claimed that the open source business model does not scale well - usually and citing notable exception to the rule. No more, no less.
  144. speaking of TCO[ Go to top ]

    Gavin King's Hibernate and Rod Johnson's Spring have made the total cost of ownership much lower than BEA, SUN, Oracle, and IBM's solutions.

    You guys ought to try to quanify the TCO.

    How long does it take for an average programmer to set an app up with Tomcat\Hibernate\Spring and some consulting, compared to setting up an EJB Server from say Oracle with one of Oracle's consultants?

    And in regards to scalability, how many Web2.0 sites with thousands of hits an hour run your run of the mill Lamp offering-a lot.

    Some people need Oracle, BEA and an expensive caching solution. A heck of lot don't.
  145. speaking of TCO[ Go to top ]

    How long does it take for an average programmer to set an app up with TomcatHibernateSpring and some consulting, compared to setting up an EJB Server from say Oracle with one of Oracle's consultants?

    Nice strawman. Why does it require a consultant? How long would it take an average programmer to use Oracle's JDeveloper Java Business Objects or BEA's Workshop controls?
    And in regards to scalability, how many Web2.0 sites with thousands of hits an hour run your run of the mill Lamp offering-a lot.

    Thousands of hits per hour, "doing what" I would ask. Read mostly message-boards like Slashdot? Or fully transactional ordering systems like Amazon.com (which uses BEA Tux and Oracle)? Or perhaps doing things that don't involve the web at all, such as processing telecom bills, running manufacturing lines, or processing banking transactions. Let's not forget that Google is not built on MySQL and PHP, and that Yahoo! runs one of the world's largest data warehouses on.... :gasp: ... ORACLE. Or the thousands of sites running IIS, ASP.NET and SQL Server!

    If a smaller site WERE to do something interesting with infrastructure, i would hope it's not something as boring as LAMP. Ruby on Rails combined with an object or XML database and WS fabric! Come on people, where's the bleeding edge thinking?!

    Nice word dropping with the "Web 2.0" moniker, by the way; it's like we're back in a 1998 time warp again. Traditional multi-billion dollar businesses didn't matter then, and now Web 1.0 businesses don't matter unless they are a poster child for LAMP (in people's minds, anyway).
  146. JBoss recently announced its own lightweight IoC container called: JBoss Microcontainer. JBoss Microcontainer is similar in concept to Spring. The JBoss Microcontainer is an underpinning of JBoss Seam and JBoss Embeddable EJB3. JBoss Microcontainer will be able to run in other application servers like WebSphere and WebLogic.

    JBoss provides its own lightweight IoC container called: JBoss Microcontainer. JBoss Microcontainer is a lightweight, Inversion of Control/Dependency Injection container similar in concept to Spring, Pico Container, and Plexus. It will be very prevalent in JBoss 5.0 due in early 2006.

    This allows JBoss Java EE and JEMS services to run in non-JEE environments like JUnit tests, Swing applications, Tomcat, and more. The JBoss Microcontainer is currently an underpinning of JBoss Seam and JBoss Embeddable EJB 3.0.

     

    One of the goals is to be able to run JBoss Microcontainer in other application servers (WebSphere, WebLogic, Oracle AS, etc.). This could be an additional vector of adoption for JBoss for companies that want to adopt EJB 3, but have standardized on application servers that don't yet support EJB 3.0.

     

    With JBoss Microcontainer, configure POJOs through XML. The Microcontainer provides lifecycle management for these POJOs. Dependency injection is allowed through property or constructor, and the Ioc Container supports declarative creation of lists, maps, and sets. It also provides a complete, pluggable state machine to manage dependencies with support for circular dependencies. Developers can write custom factories which are installed in the IoC container, e.g., construction based on factory methods.

     

    If you have used Spring, most of the above should sound very familiar.

     

     

    The nascent JBoss Microcontainer effort will be evolved to provide more JBoss services that can be used in non-app-server environment. The fully formed version should be available in 2006 as a key underpinning of JBoss 5.0.

     

    Will this increase adoption of JBoss?

    Will this be a serious competitor to Spring?

    What kind of integration with JBoss AOP will this container provide?

    Do you view this is as "more choices are good" or some other way?


    I wonder if this is the reason that the Spring support pages were pulled off the Hibernate site.

    Hmmmm.....
  147. Here is the original posting by Bill...

    http://jboss.org/jbossBlog/blog/bburke/2005/09/29/JBoss_Microcontainer_Embeddable_JBoss.txt
  148. Rick,

    I know you started the original thread, but that does not make this last post of yours any more on-topic. What does this actually have to do with "BEA adds support to Weblogic for Spring".

    If we're not going to bother keeping threads on topic, why bother with separate threads at all? And this from somebody who should know better.

    Sheesh, about 9 out of 10 days I feel like completely giving up on TSS due to the noise factor...

    Colin
  149. Rick,I know you started the original thread, but that does not make this last post of yours any more on-topic. What does this actually have to do with "BEA adds support to Weblogic for Spring".If we're not going to bother keeping threads on topic, why bother with separate threads at all? And this from somebody who should know better.Sheesh, about 9 out of 10 days I feel like completely giving up on TSS due to the noise factor...Colin

    It is a bit off topic. But its interesting.... and somewhat related. I'll try to stay on topic b/c every other post is always on topic.
  150. Rick,I know you started the original thread, but that does not make this last post of yours any more on-topic. What does this actually have to do with "BEA adds support to Weblogic for Spring".If we're not going to bother keeping threads on topic, why bother with separate threads at all? And this from somebody who should know better.Sheesh, about 9 out of 10 days I feel like completely giving up on TSS due to the noise factor...Colin

    Not much... Althought it does seem strange that JBoss is adding an IoC container that can run in WebLogic too...

    It sounds related to me.
  151. so[ Go to top ]

    OSS vendors lack the cash infusion that license revenue generates. Wall Street traditionally measures software growth through this number, I suppose they'll measure OSS vendors through net-new subscriptions. Enterprise software players also have a lot of leeway to construct specialized deals (including customized terms & conditions) for large accounts. With smaller margins, OSS players have less leeway.

    portable universe reviews