Home

News: Q&A: Steve Harris on Java middleware, EJB 3.0, SOA standards

  1. In this three part interview, Steve Harris, vice president of the Java Platform Group at Oracle, discusses the future of Java middleware, the need for greater interoperability and how vendors are differentiating their products around performance, reliability and mangeability.

    He also talks about Oracle's EJB 3.0 reference implementation, new Eclipse initiatives around BPEL, JSF and EJB tooling,and takes a look at emerging standards around SOA, such as JBI, Service Component Architecture
    and Service Data Objects.

    Part 1: Harris on EJB 3.0, Java EE 5, the future of middleware

    Part 2: Harris on loose coupling, SOA design and management

    Part 3: Harris on JBI, Service Component Architecture, Service Data Objects

    From the interview:
    Harris: One of the key things we are doing is we are the co-spec lead on EJB 3.0 (the Java EE 5 solution for Enterprise Java Beans). EJB 3.0 is focused on really simplifying the development experience for EJB. EJB is an incredibly complex specification, so it has this reputation for being difficult for developers to evolve. It is really focused on simplifying that, and does it by using annotations to annotate what we call plain old Java objects. That metadata about the Java class is easy to tag and use.

    The EJB 3.0 reference implementation is provided by Oracle. If you go to the Sun Glassfish project on Java.net and you look at the work that is being done on the next generation of EJB 3.0, what you'll see is Oracle.toplink. What we've done is take our existing TopLink product, which is the basis for persistence in our existing release of products, and provided that production quality offering of ours as the reference implementation for EJB 3.0.

    The only one that comes remotely close to what we're doing in the space is JBoss through their Hibernate stuff. EJB is influenced by Hibernate and TopLink as a solution. But every programmer is going against the reference implementation delivered through Sun's reprogramming against Oracle code that provides the reference implementation.

    Threaded Messages (26)

  2. why?[ Go to top ]

    The more I see of EJB3, and I have printed out the entire 400+ page spec, the one that refers to other specs like "JAX-WS" in passing, the less I see the point in it.

    Sure, EJB-annotated POJO classes may persist against multiple implementations of the spec, but then there is the need to create .par archives, the problem that the annotations only address a subset of options (hence the hibernate extensions), the fact that testing EJB apps is so much harder than hibernate (unless you use the hibernate embedded EJB engine). And the Web Service model somehow turns a stateless session bean into a WS endpoint. There are better ways to do web services, but enterprise Java is still stuck in the old world.

    So, I must ask: Why? If you use hibernate for your persistence you get database independence, and although, yes, you are stuck with one implementation, that implementation will be consistent on production boxes as for developer boxes. It junits nicely, embeds well and integrates with spring.

    So what else is needed?
  3. why?[ Go to top ]

    Steve, as Sahoo pointed out, you don't need .par for EJB3. Plus, the EJB3 persistence spec is pretty complete; the hibernate extensions aren't as required (always?) as you've made them sound.

    Nothing against Hibernate, of course.

    Plus, testing EJBs with EJB3 is trivial; you just, you know, use the classes. The discovery mechanism is up to the container to get right.
  4. why EJBs ?[ Go to top ]

    there is spring, webworks, jdo, JTA or simple JDBC, web services.
    EJB is now becoming like a EGO factor now than simplicity.
    Annotations - why to introduce something new to cover something ugly.
     Just get rid off EJBs completely ansd stop this meaningless , senseless complication.
    Every year the first few lines in ejb specs say - we are here to try to make it simple. The very fact that every year you feel it, that means it still is complicated and newer versions arent helping. There is very little value added by EJBs compared to the cost.

    STOP EJB madness ... Just stop it ...
  5. EJB3[ Go to top ]

    there is spring, webworks, jdo, JTA or simple JDBC, web services. EJB is now becoming like a EGO factor now than simplicity. Annotations - why to introduce something new to cover something ugly.  Just get rid off EJBs completely ansd stop this meaningless , senseless complication. Every year the first few lines in ejb specs say - we are here to try to make it simple. The very fact that every year you feel it, that means it still is complicated and newer versions arent helping. There is very little value added by EJBs compared to the cost. STOP EJB madness ... Just stop it ...

    First of all you have several parts to EJB, first there is the EJB3 entity beans, which is sort of a simplified toplink and/or Hibernate.
    And believe me it is simpler, instead of having extensive xml files you just set the annotations where necessary and you are set.
    Secondly there is the session beans, which are just a java class an interface and a marking annotation which defines the bean as session bean and defines the scope and if it is remoted. Thats it.
    As for the containers. Ejb3 entity beans do not need containers, you can run them standalone if you have a containerless implementations (Hibernate for instance already has an EJB3 API which runs containerless in beta)

    As for the session beans, there also exists already a containerless API.
    I hated EJB before, due to the complicated structures, deployment issues etc.. but EJB3 simply is great
  6. EJB3 pros and cons[ Go to top ]

    I kind of agree with both ends.
    EJB3 is much simpler to implement than previous releases
    of EJB (see 2.0, 2.1). Anyway, they've released a facility
    already used by the industry through the extensive use of
    XDoclet; we were using annotations to auto-generate EJB
    descriptors and interfaces for long, so it's just about
    "standarizing" our own choices.
    To publish simply by annotating a class has many advantages,
    but getting completely rid of descriptors might result in
    having to recompile our EJBs anytime changes are required.

    I agree that today, trying to make EJB evolve might result
    in a complex, unnecesary maybe (just maybe) does not worth it.

    I'm not to use EJB3 as my persistence choice, we've (and many
    others might have too) built our own persistence API through
    interfaces and adapters and we're currently using hibernate
    for our persistence work.
    I agree it would be nice to have a common industry standar
    like EJB3 for developers to work consistently, but
    I don't think it's going to happen, EJB just left us
    a really bad taste.

    When everyone seems to evolve to web-services, I still
    encourage the use of EJB for communications because of
    performance issues related to the overhead generated by
    SOAP, because being disconnected in many cases, lack of
    standard transaction model, etc; but yet, you can still
    simply publish your EJB's or business classes like WS
    using Axis or some other WS engine.
  7. EJB3 and Hibernate[ Go to top ]

    So many of us use Hibernate (me included)
    one interesting thing for me is, that the migration from Hibernate to EJB3 is somewhat seamless and painless.
    First you can start to use the Hibernate Annotations, then you can move the Session handler to the Hibernate entity manager seamlessly, and as soon as you are there, you basically already have arrived at EJB3.

    I am personally thinking about having my legacy projects still on Hibernate and slowly moving the current ones and the future ones towards EJB3, the advantages compared to plain Hibernate usage are there (better tooling support, at least to a big degree exchangeable implementations, altough probably given the quality of Hibernate not needed)

    The container isse is a non issue, since at least the jboss implementation of EJB3 entity beans run container less, because they are just a thin wrapper on top of Hibernate.


    As for the session beans, we have to wait and see, they are definitely easy to use, and frameworks like Seam show how good they can be. It just depends on the container situation, if you can use it or not. But as it seems, containerless implementations also will be there.
  8. I will argue for both sides as well.

    On one side, I like SLSB. EJB3 does make it simpler. For SLSB (even for EJB 2.0), all application server (WebLogic 8.1, JBoss, WebSphere 5.1) implementatios hehave about the same. One can move SLSB code from one EJB Container to another without much effort.

    But I can't say the same for EJB 2.x entity Beans. Subtle difference in transaction, deployment implemention can turns thing from bad to nightmare. Just take a look at the IBM's specific deployment descriptor .xmi files for CMP you will know what I mean, especially if you already have the SQL Schema and Entity Bean, and try to do "meet-in-the-middle".

    So my question is the same, besides for the sake of "standard specificiation" why should we go through such migration from one implementation to another implementation ? It seems adoptting one implementation (i.e. Hibernate) would be make the transition from one App server to the next Server much simpler.

    I guess, someone may want a competitive offer, or better commercial support etc.

    What's the other benefits ?
  9. I will argue for both sides as well. On one side, I like SLSB. EJB3 does make it simpler. For SLSB (even for EJB 2.0), all application server (WebLogic 8.1, JBoss, WebSphere 5.1) implementatios hehave about the same. One can move SLSB code from one EJB Container to another without much effort.But I can't say the same for EJB 2.x entity Beans. Subtle difference in transaction, deployment implemention can turns thing from bad to nightmare. Just take a look at the IBM's specific deployment descriptor .xmi files for CMP you will know what I mean, especially if you already have the SQL Schema and Entity Bean, and try to do "meet-in-the-middle". So my question is the same, besides for the sake of "standard specificiation" why should we go through such migration from one implementation to another implementation ? It seems adoptting one implementation (i.e. Hibernate) would be make the transition from one App server to the next Server much simpler. I guess, someone may want a competitive offer, or better commercial support etc. What's the other benefits ?

    This is what is wrong with document-driven specs. Anything left uncovered is an implementation detail, and you can be sure they will b eimplemented differently. this is why I like using single-implementation products like hibernate, log4j, spring -you get consistency, wherever you go.
  10. Screencast[ Go to top ]

    Ruby on Rails gain fame quickly through their screencast.

    Could the Oracle create a screencast of him downloading and installing an Oracle development environment and create an application using EJB and SOA in about a half hour?
  11. Screencast[ Go to top ]

    Ruby on Rails gain fame quickly through their screencast. Could the Oracle create a screencast of him downloading and installing an Oracle development environment and create an application using EJB and SOA in about a half hour?


    Probably not.

    But if you like, I will create a screencast of me creating a whole Seam application using Hibernate Tools in approximately five minutes :-)
  12. Taking the Bait[ Go to top ]

    Go ahead Gavin, we'd love to see your stuff. I think that will be a big WOW factor that would grab the industry's attention, including top level executives and stakeholders.
  13. http://www.jboss.com/products/seam/EclipseCVS.html
  14. Screencast[ Go to top ]

    Could the Oracle create a screencast of him downloading and installing an Oracle development environment and create an application using EJB and SOA in about a half hour?
    First, installing Oracle's development environment (JDeveloper) requires less than a minute. It's just unzipping and it comes with an embedded server too, so you do not have to configure an external J2EE server and an IDE.

    For more info, you can look at http://www.oracle.com/technology/products/jdev/index.html

    Second, we already have a step-by-step guide to build EJB3 app from JDeveloper and if you want to do it yourself (configuring project, session bean, entity and running a client) you should not take more than 15 minutes.

    http://www.oracle.com/technology/products/jdev/101/tutorials/ejb_30/ejb_30.htm

    If you just want to look at a viewlet then see http://www.oracle.com/technology/products/jdev/101/viewlets/101/ejb30entitybeanviewlet_viewlet_swf.htm.

    The only thing that's missing in these is the JSR-181 annotations to expose a WS. You can just add @WebService annotation for the interface and deploy that to the server and that will expose your EJB 3.0 SLSB as a web service. So, yes, if you add that to the mix yourself, install, configure, development of service should take less than 30 mts and not just a screen cast (:

    Third, do you know that all three winners at JavaPolis RAD Race used Oracle JDeveloper and Oracle ADF . You can see the results at http://www.radrace.org/en/JPed_2005/JPwinners_2005.html

    By the way, do you know that JDeveloper costs nothing and is FREE!

    You can download at http://www.oracle.com/technology/products/jdev/index.html

    -Debu Panda
    Oracle
    http://debupanda.com
  15. Screencast[ Go to top ]

    The viewlet link is not working
  16. Screencast[ Go to top ]

    It works in IE.

    No I didn't know some of those things. Thanks
  17. Screencast - EJB 3 and JSF[ Go to top ]

    ok, I took the challenge and created a small screencast that you can watch here:
    https://strtc.oracle.com/imtapp/app/arc_pb_hub.uix?mID=40788447&src=app/arc_hosted&action=pb
    (you need to enable pop-up for this site though).

    It shows a basic development process for an EJB 3.0 + JSF application in 3 minutes.
  18. Screencast - EJB 3 and JSF[ Go to top ]

    Thanks. That's pretty impressive.
  19. I am getting an error[ Go to top ]

    ok, I took the challenge and created a small screencast that you can watch here:https://strtc.oracle.com/imtapp/app/arc_pb_hub.uix?mID=40788447&src=app/arc_hosted&action=pb(you need to enable pop-up for this site though).It shows a basic development process for an EJB 3.0 + JSF application in 3 minutes.

    Internal Server Error
    The server encountered an internal error or misconfiguration and was unable to complete your request.

    Please contact the server administrator, you@your.address and inform them of the time the error occurred, and anything you might have done that may have caused the error.

    More information about this error may be available in the server error log.

    Oracle-Application-Server-10g/10.1.2.0.2 Oracle-HTTP-Server Server at strtc.oracle.com Port 443
  20. RE: I'm getting an Error[ Go to top ]

    You need IE to playback this screencast.
    It works for me.

    But you can also try this URL:
    https://strtc.oracle.com/imtapp/app/arc_pb_hub.uix?mID=40788742&src=app/arc_hosted&action=dl
    which will download the screencast as an exe.
  21. I am getting an error[ Go to top ]

    Internal Server ErrorThe server encountered an internal error or misconfiguration and was unable to complete your request.Please contact the server administrator, you@your.address and inform them of the time the error occurred, and anything you might have done that may have caused the error.More information about this error may be available in the server error log.Oracle-Application-Server-10g/10.1.2.0.2 Oracle-HTTP-Server Server at strtc.oracle.com Port 443

    Werner,
    I tried couple of times and I had no problem. May there was a temporary hiccup in the server when you tried to access the link

    -Debu
  22. The IE[ Go to top ]

    did the trick, the video is indeed impressive.
  23. If the video doesn't work...[ Go to top ]

    Try this demo instead: http://www.oracle.com/technology/products/jdev/viewlets/1013/jdev_overview_xp_viewlet_swf.html
  24. Great, more COD; confuse, obfuscate and disempower
  25. JSF and EJB tooling
    Where is it in this material? JSF tooling info especially.


    Marina
    http://www.servletsuite.com
  26. JSF tooling[ Go to top ]

    They probably are referring to the Eclipse sideproject which in the long run will be merged with the WTP, do not expect too much there yet, they are currently in the first third of what they are planning for the first major release.
  27. See:
    http://www.oracle.com/technology/jsf/eclipse/index.html
    for the JSF project
    and
    http://www.eclipse.org/dali/
    for the EJB 3 project

    If you want to see what Oracle can do already in terms of JSF and EJB 3.0 tools you don't have to wait for the Eclipse projects - you can download the Free Oracle JDeveloper 10.1.3 EA1 that already has these.