Weighing options when going the open source J2EE route

Discussions

News: Weighing options when going the open source J2EE route

  1. David Berlind, on ZDNet, has written a blog entry on elements to consider when using open source with J2EE, and mentions making choices for open source application servers, centering on JBoss, and focusing attention to companies like SourceLabs and SpikeSource to verify that the software choices work together.

    One of his points is that insourcing J2EE development is a difficult undertaking - with the definition of "insourcing" being "writing your own J2EE container." Therefore, integration should be left to other vendors, such as JBoss, SourceLabs, or SpikeSource (or their other competitors).

    However, he mentions that SpikeSource, in particular, targets JBoss, Geronimo, and Pramati (a recent addition) - and not JOnAS. Alan Williamson, at SpikeSource, said that JOnAS was on the list for evaluation, adding "JBoss is still king; it's what people ask for."

    What do you think?
  2. JOnAS[ Go to top ]

    As author of the first book on JOnAS, Objectweb member and founder of a company providing services/training for JOnAS, I would say that JOnAS just lack some marketing...
    Of course, I see more often Jboss than JOnAS but more and more clients are now searching for JOnAS and that's why our business is growing :)

    Just let some time to JOnAS, the ecosystem surrounding this product is quite "new", we are starting to organize and some key players are appearing
  3. Yes, yes,
    the professional support is important for Open Source,
    specially to persuade the large customers to use Open Source for critical systems, but...

    I did migrate (time ago) applications from WebSphere to Jonas and then from Jonas to JBoss. And I can tell that the J2EE brand does not means much. Migrating is hard.
    If you coding for WebSphere (with WebSphere Studio for example) the code is hard to migrate to JBoss, and if you coding for JBoss (for XDoclet for example) you code will not migrate to WebSphere (xdoclet does not support CMP in websphere) and so on.

    Your applications must to run in JBoss but you must to have the chance to come back to WebSphere or WebLogic, or to migrate to Jonas your applications. If not your will be lock in JBoss (as in propietary case).

    I think that is a important point on migrate from propietary J2EE server to Open Source ones.

    There are some options to achieve this portability:
    * Does not use J2EE apis, use instead Spring, Hibernate, etc.
    * Use a good MDA platform (with support for both open and propietary servers)
    * Use framework that generate portable J2EE applications as http://www.openxava.org
  4. There are some options to achieve this portability:
    * Does not use J2EE apis, use instead Spring, Hibernate, etc.

    Then J2EE has failed, because the complexity and verboseness of the system (not necessarily the API, but specifically the descriptors) is specifically designed around portability to different containers and back ends.

    When you use Spring and Hibernate, you're taking your app server with you, when you code against J2EE, you're not. That's why Spring is so "portable". Spring/Hibernate converts a generic Servlet Container into a server with more "J2EE like" elements.

    But of course, it's not J2EE. They reinvented all of those wheels. Note I'm not criticizing Spring et al or those who choose platform, just trying to distinguish the details when folks say it's more portable.

    If I wrote my "J2EE" app using Servlets, Spring, and Hibernate, it would port quite easily from Tomcat to Weblogic to Websphere simply because it doesn't use ANY of the features those platforms provide.

    However, if someone, perhaps, forked Spring or forked Hibernate into Bounce and ColdSleep, after a year, you may well have a hard time porting your Spring/Hibernate solution to a Bounce/ColdSleep solution because there probably aren't any overarching documents or standards that would apply to both implementations (I mean, they forked for some reason afterall).

    And this just brings to light the question of how important is portability at container level?

    I don't know. We haven't ported our WLS app to JBoss or anything else. I'm sure we could (with some pain no doubt) but we haven't bothered yet. It may be more important to others.
  5. ...the complexity and verboseness of the system (not necessarily the API, but specifically the descriptors) is specifically designed around portability to different containers and back ends.

    Except for the format of the CMP-RDB mappings, which were (inexplicably) left as vendor-dependent by the specs to-date. And that's the area that customers typically have trouble migrating in their apps. Fortunately the EJB 3.0 spec has addressing this as one of its main goals.

    I completely agree that apps written to Spring and Hibernate are "portable" to other app servers only in the sense that you don't really migrate; you take Spring/Hibernate with you. In the same regard, a Windows .NET application is "portable" to any Wintel server box. :) In each case, there is only one provider/implementation of the framework that your app talks to...with similar pros and cons to that.

    Randy
  6. I don't agree.

    J2EE hasn't failed, but EJB, at least < 3.0, has, at least if you subscribe to the Spring philosophy, which I do.

    Spring makes use of many J2EE features, including resource management (adapters), JDNI, the web container of course, and the EAR format, as well as deployment.

    It can be used in an EJB container, but that is of course not what Spring was designed for.

    But J2EE != EJB, as Rod Johnson (and Juergen Hoeller) have so nicely pointed out (about 300 times ;) ) in their book "J2EE development without EJB".


    Personally I think that these different types of containers are a problem in the J2EE design. The differences between container types largely revolve around the invocation mechanism (web/http, jms(or other event-based invocations in j2ee 1.4) or rmi/iiop). There should just be one container type, and how you modularize your application should be left up to the architect/designer, not be dicated by protocols.

    And Spring gives you that freedom, when you pick the most flexible container type, the web container.

    - Erwin
  7. I always to like to do like this. Just to keep things simple.

    1) Design my data, the result is value object. Use Hibernate do OR mapping. I use class diagram only for this case.

    2) I model all my business logic as interface. Use small interface compose bigger interface. Value objects are parameters for interface methods.

    3) Interface can be implemented by EJB, JMS, Web Service ... Same idea as Weblogic Control concept. It is only interface that really matter, all the rest is just academic ...

    4) If you want, I have ant task to generate EJB, JMS, Web Service, RMI, 4 version of API at once for free ... :)

    Basically tomcat + hibernate + Apache aix Web Service + JSF is enough.

    Container who cares, plain java class is as good as any thing.
  8. I don't agree. J2EE hasn't failed, but EJB, at least < 3.0, has, at least if you subscribe to the Spring philosophy, which I do.

    Spring makes use of many J2EE features, including resource management (adapters), JDNI, the web container of course, and the EAR format, as well as deployment.

    No, Spring/Hibernate turns your generic Servlet container into an Application Server. Without Spring/Hibernate, Tomcat, for example, is a Servlet container. With Spring/Hibernate it's an app server.

    Tomcat brings very little to the party save a threading model and the HTTP stack. Spring/Hibernate provides resource management, persistence, transactions, remoting (Hessian, et al), mail, JMS? Spring bundle in JMS yet? I know it provides access.

    Is it a J2EE app server? No, but it's still an app server with many of the same services. It's simply a Java App Server, like the early stuff from Borland, BEA, and IBM before J2EE consolidated them all.
    But J2EE != EJB, as Rod Johnson (and Juergen Hoeller) have so nicely pointed out (about 300 times ;) ) in their book "J2EE development without EJB".

    No, EJB is but a component of J2EE, but J2EE != Servlets either, and that's the primary component that Spring leverages. Not JNDI, not JCA, not JAAS, not JTA, and, of course, not EJB.

    If I were advertsing for an expert in J2EE, and someone showed up being an expert in Spring -- he's not getting the job.
    Personally I think that these different types of containers are a problem in the J2EE design. The differences between container types largely revolve around the invocation mechanism (web/http, jms(or other event-based invocations in j2ee 1.4) or rmi/iiop). There should just be one container type, and how you modularize your application should be left up to the architect/designer, not be dicated by protocols.

    Then, again, J2EE has failed. Because that's the kind of things it was supposed to consolidate and commoditize.

    In J2EE you make those decisions based on the container you choose, because the J2EE container has made all of those choices and is one way they are discriminated. At that point, porting becomes a deployment problem, not a coding problem.

    BEA uses their proprietary T3 protocol to give them some performance edge, but in fact, neither my client, nor my servers objects care about that protocol. Change the app server connection properties in my client, and the jars they see, and they'll happily use RMI to Suns server or whatever.

    Of course, the deployment issue is complicated (as noted by the mention of the server specific CMP descriptors), but that's a side effect of the fact that, again, these deployment descriptors are where the portability and implementation specific bits go, not within the source code. Certainly if you rely on container specific features and let them bubble into your "portable" code (i.e. the Java source), that just exacerbates the porting problem, but I think it's the complexity of the problem plus the desire of vendors to distinguish their offerings that adds to the overall issue.
    And Spring gives you that freedom, when you pick the most flexible container type, the web container.

    "And Ford gives you that freedom when you pick the most flexible color -- black."

    Again, I'm not slamming Spring -- it's a good thing, both for the users, and for its affect on helping simplify J2EE as well (it certainly has had influence on 3.0).

    But it's solving the problem in an entirely different way than J2EE is, mostly by proving a "single implementation" solution, rather than a specification supporting multiple implementations. That means if you are unhappy with Spring in some way, someone else can't really come out with a "better Spring" and you can't expect your application to work with it, particularly where your code rubs against Springs bits directly.

    Yes, you can code much of your app away from Spring, you can do the same in J2EE, but J2EE was designed as an integration and consolidation platform to help you make your apps as platform agnostic as practical. For example, if you use CMP, your code is ambivalent as to how that persistence is done -- JBoss may use Hibernate, Sun may use a JDO system, Oracle may use the guts of Toplink, another may well be using an OODBMS.

    If, with Spring, you choose iBatis, and then wish to switch later to Hibernate, you have some code to rewrite.

    But again, perhaps we've learned that we don't care about or need a compatability layer as thick as J2EE for our applications.
  9. Perhaps we've learned that we don't care about or need a compatability layer as thick as J2EE for our applications.

    Hum... We probably wouldn't be here discussing all this if we didn't have a common technology we all share. One technology, many vendors, J2EE is the price to pay for it. Before anything else, J2EE is a standard, which happens to tanslate into a piece of technology. It's that standard that enables us to share our experience, different way to do things, how we use those frameworks we love to hate, etc.

    The community built around it is J2EE's greatest asset and M$ has not achieved to match this depite their huge customer base. If it weren't for J2EE, we would have the BEA way, the IBM way, the Sun way, and guess what? none of this: we would have the .Net way and that's it.
  10. This discussion seems to miss Spring's focus quite a bit. Spring is an application framework, not an application server, and it is so in a very generic and flexible fashion. In particular, it isn't focused on servlet containers by any means. There are some important distinctions to make here.
    Spring/Hibernate turns your generic Servlet container into an Application Server.

    No, it does not. At least not if defining an application server as a provider of base system services, such as classloader management, thread management, connection pooling, XA transaction coordination, JMS messaging.
    This is what an application server is at heart, and this is what you pay your application server vendor for.

    Essentially, all of J2EE falls into the system service category - except for certain EJB facilities. Only the latter are what Spring competes with, for example providing declarative transactions on application objects. Spring does so in a flexible fashion, with pluggable backend.

    Spring does not, however, provide the backend system services. Instead, it uses the existing system services of a particular environment, for example the JTA subsystem and JCA connection pools of a J2EE server. Spring simply provides a convenient and flexible way to tap into those services, without getting tied to specific backends.
    Without Spring/Hibernate, Tomcat, for example, is a Servlet container. With Spring/Hibernate it's an app server. Tomcat brings very little to the party save a threading model and the HTTP stack.

    Tomcat itself already is an application server, to some degree - a basic J2EE web application server. It provides thread management and classloader management, and of course the entire HTTP stack. It also provides the application deployment unit: a standard J2EE WAR file.

    So arguably, Tomcat brings a lot to a Spring/Tomcat party. Spring mainly provides the end-to-end component management within the application. As a separate decision, you might add Hibernate or iBATIS as data access strategy. Such persistence libraries are quite different in nature to Spring, but that's not my topic here.
    Spring/Hibernate provides resource management, persistence, transactions, remoting (Hessian, et al), mail, JMS? Spring bundle in JMS yet? I know it provides access.

    Spring provides application-internal resource management based on existing connection pools and existing transaction coordination backends. This does not compete with a J2EE server's resource and transaction management facilities at all: J2EE provides the backend, Spring simply provides a convenient frontend.

    Regarding JMS, Spring - of course - just provides convenient application-level access to an existing JMS provider. That might be a J2EE server's JMS subsystem or a standalone JMS provider. Again, Spring provides the frontend here, integrating with a pluggable, external backend.
    Is it a J2EE app server? No, but it's still an app server with many of the same services. It's simply a Java App Server, like the early stuff from Borland, BEA, and IBM before J2EE consolidated them all.

    No, it's not comparable to early Java app servers at all. Summarizing the above: Spring provides frontend services within an application, while J2EE is all about backend services at the global server level. This is a straightforward synergy, not a competition.

    Essentially, Spring is for overall J2EE what a web application framework (such a Struts) is for a Servlet container. In a Struts-based web application, Struts provides the frontend technology, running on top of a Servlet container backend. The relationship between Spring and a full J2EE server is quite analogous.

    Finally, Spring does not focus on Tomcat by any means. Where did that assumtion come from in the first place? Many Spring applications run on full J2EE, for example on WebLogic, and we put a lot of effort into supporting that. Other Spring applications happily run on Tomcat. It all depends on the application's system service needs.

    Juergen
    http://www.springframework.org
  11. For example, if you use CMP, your code is ambivalent as to how that persistence is done -- JBoss may use Hibernate, Sun may use a JDO system, Oracle may use the guts of Toplink, another may well be using an OODBMS. If, with Spring, you choose iBatis, and then wish to switch later to Hibernate, you have some code to rewrite.

    That's not an issue with Spring, that's an issue with your chosen persistence strategy. Please don't throw Spring and Hibernate/iBATIS/etc into the same bucket here: Spring is completely agnostic about the persistence strategy that your prefer to choose.

    You can - of course - use CMP, in particular EJB3 persistence, within Spring: This will give you all the benefits that a standard persistence API has, such as switching the persistence backend without recoding. No need to include a full ORM implementation within your application deployment unit in this case.

    If you instead prefer to use a specific product such as iBATIS within Spring, that's your decision. Spring gives you the choice, providing full support for all of those persistence strategies: both standard APIs such as JDO and (as soon as available) EJB3 persistence, and specific products such as Hibernate, TopLink and iBATIS SQL Maps.

    iBATIS is very different from Hibernate and JDO, so of course you need to rewrite if you switch from one to the other. That's not surprising and actually desirable: Those persistence tools differentiate themselves through their specific approach, specific API and specific configuration format - that's their very point!

    Juergen
    http://www.springframework.org
  12. ... If not your will be lock in JBoss (as in propietary case).I think that is a important point on migrate from propietary J2EE server to Open Source ones.There are some options to achieve this portability:* Does not use J2EE apis, use instead Spring, Hibernate, etc.* Use a good MDA platform (with support for both open and propietary servers)* Use framework that generate portable J2EE applications as http://www.openxava.org

    An alternative is to use the J2EE AVK (Application Verification Kit) to ensure your apps. are portable. It's free and easy to use.

    Details here : http://java.sun.com/j2ee/verified/avk_enterprise.html

    Download here : http://java.sun.com/j2ee/avk/

    Rich Sharples
    Sun Microsystems
    http://blogs.sun.com/roller/page/sharps
  13. Java server face is too young and too simple for professional use.

    So for professional use, you always need some vendor specific UI frame work. For example,
    1) Weblogic netUI
    2) SAP NetWeaver web dynpro
    3) Oracle has also its own.
    4) Even documentum has its own wdk .
  14. Java server face is too young and too simple for professional use. So for professional use, you always need some vendor specific UI frame work. For example,1) Weblogic netUI2) SAP NetWeaver web dynpro3) Oracle has also its own. 4) Even documentum has its own wdk .

    I wondered who was causing all the problems. :)

    Really, while JSF is young and not perfect, it is more than definitely ready for "professional use".
  15. When complaining about JSF, you should remember that it is just a specification. Oracle ADF is actually implementing that specification. If the products using the spec are not good, it is not necessarily JSF's fault. MyFaces has been good enough for us for professional use.

    But it's nice to hear that JSF is not too complex, but simple :)
  16. Carbon AS - J2EE Application Server[ Go to top ]

    We are in the process of developing a J2EE Application Server called Carbon AS, http://sourceforge.net/projects/carbonas/ . We are inviting talented developers to be a part of our team. If you like to be a part of our development team, kindly drop me a mail : carbon_developers@yahoo.com