Discussions

News: New Article: New Features in EJB 3.1 - Part 4

  1. The EJB 3.1 expert group is working on changes for the next version of the Java EE spec. Here's your chance to get an early look at those changes, and also to provide feedback on the value of those changes from your point of view. Reza Rahman describes those changes and wants to know what you think. Read Article

    Threaded Messages (64)

  2. Link is not working
  3. Sorry, it is working now
  4. Sorry, it is working now
    Thanks for reporting this and no problem... Cheers, Reza
  5. http://www.theserverside.com/news/thread.tss?thread_id=49650#255362
  6. http://www.theserverside.com/news/thread.tss?thread_id=49650#255362
    David, Noted. Please keep in mind, the idea here is to get across WebBeans/EJB 3.1 integration in the simplest, most intuitive way possible, not necessarily write the best markup code. In production code one would expect CSS to do form layout. Reza
  7. didn't mean to pick on you, but it was a good example of bad design (in final form) for the modern web. maybe just leave the table out altogether as it just gets in the way.
  8. didn't mean to pick on you, but it was a good example of bad design (in final form) for the modern web. maybe just leave the table out altogether as it just gets in the way.
    David: No worries, I tend not to jump to conclusions (lose a lot of potential friends that way :-)). As I said, I agree with you about using CSS for positioning/formatting in real world JSF code. The other concern here is that it's impossible to stop people from cutting and pasting code and expecting things to fail gracefully (happens all the time for EJB 3 in Action code). It's always a balancing act writing general purpose technical content that's intended to be easily digestible...:-( Cheers, Reza
  9. I've not followed Seam or WebBeans, so this may be a naive question. But I'm just curious what the value of WebBeans are outside of the JSF environment? Is it merely a DI mechanism? Is it going to be useful for more mundane web programming ala JSP? Or somehow leveraged by other frameworks? Will it work within a Servlet container or only within an EJB container? Just some quick insight about the 10000 foot view of WebBeans outside the JSF content, if any, would be useful.
  10. Will: Excellent set of questions for Gavin & Company. Here's my take on it:
    what the value of WebBeans are outside of the JSF environment?
    The current thought is that WebBeans can be used pretty such on any Servlet based technology, especially those that use some kind of EL. How exactly this will look like I think is still a little fuzzy at this point.
    Is it merely a DI mechanism?
    It's a bit more than that. It's tighter integration of the web and business tiers, better state management through the idea of finer grained contexts on top of the HTTP session context as well as DI and AOP. My personal opinion is that this should really have been a few separate JSRs, but at the end of the day, that's just a technicality. The Caucho Resin folks I had the pleasure of speaking to at JavaOne are essentially treating WebBeans as enhanced DI for Java EE and calling it "Resin IoC".
    Or somehow leveraged by other frameworks?
    Again, I think the thought is to make this general purpose enough so that a wide variety of folks can implement it, including the myriad of exiting Java web frameworks out there...
    Will it work within a Servlet container or only within an EJB container?
    Yes, very likely, ala Resin IoC. You can probably tell I'm impressed by their take on things...nice folks too :-). Cheers, Reza
  11. I'm sure it will become clearer as time goes along, but I think most folks see WebBeans == Seam, and if you're not using, interested in, or looking at Seam, then it's functionality may well be lost on the larger community, even tho it may we have good value to the day to day Java JEE coder, even if they don't use JSF. No doubt that's the intent, I'm sure, getting it out to the wider audience. BTW I wanted to thank you for your 4 articles so far. I think they've been very good.
  12. Will:
    No doubt that's the intent, I'm sure, getting it out to the wider audience.
    I certainly hope so and have been trying to push in this direction. However, I'd make sure by sending your comments to the WebBeans JSR (since I'm not on it, it's somewhat difficult to influence it directly).
    BTW I wanted to thank you for your 4 articles so far. I think they've been very good.
    Thanks a lot for the kind words. I see it as a personal privilege and wish the JCP in general would be more communicative with the community...the least I can do is try to do my part... Cheers, Reza
  13. Validations and Exceptions[ Go to top ]

    Hello Reza, I have been very interested about the new EJB features, especially regarding the web development. I have developed a JSF based application and most of the times the backing bean is a "wrapper" of an entity bean, just used to validate input parameters and put messages in the context. But... how does WebBeans can perform the input validations and treat some business exceptions? (i18n,flow control, etc) Kind regards and thanks for the great job! Bruno Barin
  14. Re: Validations and Exceptions[ Go to top ]

    Bruno:
    how does WebBeans can perform the input validations and treat some business exceptions?
    That's an excellent question. The general idea is to use JSF validators and converters as well as the new Bean Validation JSR headed by Emmanuel. Cheers, Reza
  15. Re: Validations and Exceptions[ Go to top ]

    I have developed a JSF based application and most of the times the backing bean is a "wrapper" of an entity bean, just used to validate input parameters and put messages in the context.
    Just like Hans Prueller, I'm also wondering about the separation issue. It's true that a backing bean is often a thin wrapper of an entity bean, but it does contain some tier specific code. I absolutely don't want to pollute my business tier code with web tier specific things. Probably I need to look more into WebBeans, as a lot of other things sound really promising, but I wonder about these kinds of constructs that I often make use of in backing beans: public void updateFoo(ActionEvent event) { Foo foo = new Foo(); Long ID = someEJB.process(foo); renderNewFooHint = true; FacesMessages.addInfoMessage(event, "some.key", ID); } What I basically do here is setting some flag for the view (e.g. perhaps some informational structure is shown to the user right after a Foo had been created) and adding a specific faces message to the message queue for the component that triggered the action. I might be wrong, but it seems to me such actions are fairly standard practice. If the action is bound directly to a business bean, how am I going to do such things?
  16. Re: Validations and Exceptions[ Go to top ]

    Arjan: You have a perfectly valid point and these are the kinds of things the WebBeans EG should be thinking about. As I mentioned, for such cases, you can always use plain WebBeans components as backing beans and delegate transactional business logic to EJBs. Cheers, Reza
  17. Indeed[ Go to top ]

    Arjan, I agree with your point of view, using WebBeans could be very easy to "broke" the architectural concept of 3 tiers. But as I said most of time our backing beans acts as a "wrapper" to the EJB, performing the boring task to set all attributes to an entity bean. What I feel is we (developers) need a framework that performs the boring task to set attributes to a model object AND the validation tasks should be possible to reuse in another environments like fat clients. Maybe the WebBeans technology would be a solution for that. I really hope so. Summarizing, I would like to leave the boring part of setting and getting the attributes to/from an entity bean and develop "commom" validations to reuse anywhere. I also a bit worried about the quantity of annotations, but this is another question.. and I think this is irreversible in the Java language. Cheers, Bruno
  18. Re: Indeed[ Go to top ]

    But as I said most of time our backing beans acts as a "wrapper" to the EJB, performing the boring task to set all attributes to an entity bean.
    I hear you. It's a frequently reoccurring pattern in Java EE, where first 20 input fields are bound to 20 backing bean properties and then when an action method is invoked, the code inside that method transfers those 20 properties to identical properties on the entity bean. A simple workaround though might be to bind them to an (entity) bean instance that you return from your backing bean. E.g. instead of writing value="#{mybean.property1}, you write value=#{mybean.entitybean.property1}. This already saves you from a lot of getter/setter duplication today. Nevertheless, it would be a great addition if an entity bean could actually be obtained from the entity manager using declarative syntax and thus making it available to EL. That way you could write value="#{entitybean.propertyX} for all your UI components. When the backing bean's action method is invoked, it would then have access to an injected entity bean with all its properties already set. The action method can then perform some view specific logic. This approach basically keeps the backing bean as it is today, but removes the mundane work of duplicating all getters and setters. Essentially it would make the already thin glue code even thinner. Of course, in case where there isn't any view specific logic to be done, the action method might be directly bound to a (stateless) session bean instead of to a backing bean, as in Reza's addBid() example. For me it would be great if the relation could be 3-way. I.e. the entity bean's properties bound to my JSF UI components, the session bean injected with the entity bean and then the backing bean injected with the session bean. In that way my backing bean can do its (small amount of) view specific logic and then delegate the business processing to the injected session bean. btw, a small thing concerning the terminology that I found to be often confusing to new users is the name "session bean" vs "session scoped managed bean". Quite often when I talk about a "session bean", especially in a JSF context, people think I'm talking about the "session scoped managed bean". This is a small problem today, but if session beans are going to be available directly to a JSF page, this naming confusion might become a bigger problem.
  19. Re: Indeed[ Go to top ]

    Arjan:
    For me it would be great if the relation could be 3-way. I.e. the entity bean's properties bound to my JSF UI components, the session bean injected with the entity bean and then the backing bean injected with the session bean.
    This is basically what I recommend for real-life apps. It's a reasonable set of trade-offs. The example I have just keeps things simple so that the code isn't the focus, the framework features are. Cheers, Reza
  20. Re: Indeed[ Go to top ]

    Arjan:

    For me it would be great if the relation could be 3-way. I.e. the entity bean's properties bound to my JSF UI components, the session bean injected with the entity bean and then the backing bean injected with the session bean.


    This is basically what I recommend for real-life apps. It's a reasonable set of trade-offs. The example I have just keeps things simple so that the code isn't the focus, the framework features are.

    Cheers,
    Reza
    Why not simply use the session bean as the backing bean, as Seam enables you to do? Hopefully Web Beans will make this standard and simplify the architecture for Java EE applications.
  21. Re: Indeed[ Go to top ]

    Why not simply use the session bean as the backing bean, as Seam enables you to do?
    Since the EJB3 session bean should be web independent. I typically use session beans to service either requests originating from the web layer or from application clients (Swing or even commandline). The separation that EJB3 offers makes this easily possible. I think a large part of EJB3 is about cleanly separating business and UI logic, with EJB3 representing the business part. "Why not simply use the session as the backing bean?" Hmmm... why not embed business code directly in the JSP page again. Like when you open a tag and then between a and a you open a and dump your 200 line business rules code right there between a . That was always easy, right? (note the 'slight' sarcasm) Seriously, as said before, if there happen to be no 'web specific' things you need to do in your backing bean (like directly modifying UI components, queuing faces messages, setting flags for rendering, providing programmatic forward URLs, clearing web session scoped caches, etc), -THEN- it might be ok to use the session bean directly as a backing bean. But all the things I mention above -do- happen in a typical web application and you don't want to pollute your business code with that. At least, I don't think you would want that.
  22. Re: Indeed[ Go to top ]

    Ian:
    Why not simply use the session bean as the backing bean, as Seam enables you to do? Hopefully Web Beans will make this standard and simplify the architecture for Java EE applications.
    This is indeed a fine approach for the broad range of applications, just not all. Reza
  23. Re: Indeed[ Go to top ]

    Arjan, Actually I use the approach you've described, but I can't see too much difference between that pattern and the use of WebBeans. Ok, in theory the tiers are well defined but in practice is the same way of work. I agree with you that would be better if the entity beans could be accessible in the UI and could be used in the backing beans via injection. That approach would be great and the tiers will be well defined. Cheers, Bruno
  24. But I'm just curious what the value of WebBeans are outside of the JSF environment?
    A good question. The simplest answer is that it is relevant anywhere that EL is used. EL is currently mainly used in JSF. However, there are some Frameworks (Seam & Spring Web Flow) that use some form of EL in order to work. This includes things from page flows to business rules to passing data around from conversation to conversation and back again. Although Web Beans is not currently slated to work outside of the web container, it is also possible that Web Beans can be used in Data Binding Swing Controls. I believe that it will work within a servlet container and not require EJB. Web Beans could also be a way to standardize bean declarations. Rather than use a proprietary syntax for declaring beans, you could use a standard syntax for bean declaration. At that point you have the option of switching out the bean container (i.e. the web bean implementation). In this respect it might be similar to how JPA has replaced the proprietary ORM definitions.
  25. I believe that it will work within a servlet container and not require EJB.
    This is true, just as Seam does not require EJB or JSF per se. However, the primary goal has been to unify the JSF and EJB programming models. One misconception appears to be that WebBeans somehow replaces EJB (I'm somewhat surprised this hasn't come up yet on this thread). This is not the case, as WebBeans offers complementary services that EJB does not provide and does not duplicate existing declarative services such as transactions, security or asynchronous processing. Cheers, Reza
  26. I'm confused with overlaps between EJB/Servlet and WebBeans specific annotations and DI. Why do we need both of them? If WebBeans covers all types of beans then why not deprecating the old ones and asking people to use the new ones? BTW, do we really need to inject even a utility class like MathUtil? Isn't it over engineering?
  27. Mohammad:
    I'm confused with overlaps between EJB/Servlet and WebBeans specific annotations and DI.

    Why do we need both of them? If WebBeans covers all types of beans then why not deprecating the old ones and asking people to use the new ones?
    You are talking about @Resource, @PersisteceUnit and @EJB? There are two reasons why they are still useful. One is that there isn't a need to always use WebBeans for DI. The other is that these add readability. Personally, I use @In only where it is really needed.
    BTW, do we really need to inject even a utility class like MathUtil? Isn't it over engineering?
    Yes, that particular example is a bit of over engineering. There are some valid cases for plain WebBeans components though, there certainly are in my apps. By and large, my view is that this is an edge case. This is one reason I wanted to make @Component optional on an EJB, just like Resin IoC does. Cheers, Reza
  28. Reza, By providing mutiple solutions for the same problem we are adding more confusion and to some extend even pullotion to the platform. This is against the nature of simplicity. We had Servlet and EJB containers and now we are talking about WebBeans container! IMO, Java really needs a unified, standard and annotation based DI solution across all platforms. This is not specific to EE and I don't understand why JCP and Java community don't push for a DI solution at JVM level. What's wrong with JVM acting as DI container using a simple and samll set of annotations?
  29. Mohammad: What multiple solutions in particular are you talking about? As to the different containers, these really aren't much more complicated that adding yet another third-party API, you don't think? Also, the because of the way profiles are defined in Java EE 6, a "app server" that supports a particular API will already be fully integrated and functional. For example, let's assume that Resin supports JSF, WebBeans, EJB 3.1 and JPA. Because the server would be fully compliant to that profile, you as a developer won't be doing any integration. All you have to do is write to the API and deploy :-). That's what I meant by what JSR a piece of functionality belongs in is just a technicality... As to adding DI to the VM, frankly, I'm not convinced that's really necessary, given that DI might be overkill for a good set of simpler applications and just would add to JVM bloat.. Cheers, Reza
  30. Mohammad:

    What multiple solutions in particular are you talking about? As to the different containers, these really aren't much more complicated that adding yet another third-party API, you don't think? Also, the because of the way profiles are defined in Java EE 6, a "app server" that supports a particular API will already be fully integrated and functional. For example, let's assume that Resin supports JSF, WebBeans, EJB 3.1 and JPA. Because the server would be fully compliant to that profile, you as a developer won't be doing any integration. All you have to do is write to the API and deploy :-). That's what I meant by what JSR a piece of functionality belongs in is just a technicality...

    As to adding DI to the VM, frankly, I'm not convinced that's really necessary, given that DI might be overkill for a good set of simpler applications and just would add to JVM bloat..

    Cheers,
    Reza
    I'm talking about DI solutions provided by Servlet/EJB container and WebBeans container. From installation and configuration perspective, you are right and it might not be a big deal. As I said it adds more confusion specially for new learners. For you it might be easy to choose between @EJB, @Resource and @In. However from a new Java developer perspective I do still believe it's not easy and simple enough. I'm working with a group of experienced .Net developers who have switched to Java recently and feel the frustration when it comes to this kind of decisions they have to make. In regards to DI support at VM level: agree that DI is overkill for a set of simpler applications, but VM already supports a good number of technologies which are not used by a good set of applications. Anyway, thanks for the quick response and your good job in involving the community.
  31. Mohammad:
    For you it might be easy to choose between @EJB, @Resource and @In. However from a new Java developer perspective I do still believe it's not easy and simple enough.
    That's good feedback that again goes back to establishing best practices. I would say you could follow something along the lines of: - Use @In for WebBeans managed components, including EJBs that utilize WebBeans features. - Use @Resource for resources managed outside the WebBeans container such as data sources, JMS destinations, etc. - Use @PersistenceUnit/@PersistenceContext for JPA managed resources. - Use @EJB for EJBs that do not use WebBeans features (probably while not using WebBeans). I would have suggested to use @EJB for all cases, but this is not possible because the WebBeans spec does not have anything in there right now to auto-register EJBs (the way Resin IoC does for example). Cheers, Reza
  32. I'm talking about DI solutions provided by Servlet/EJB container and WebBeans container. From installation and configuration perspective, you are right and it might not be a big deal. As I said it adds more confusion specially for new learners. For you it might be easy to choose between @EJB, @Resource and @In. However from a new Java developer perspective I do still believe it's not easy and simple enough. I'm working with a group of experienced .Net developers who have switched to Java recently and feel the frustration when it comes to this kind of decisions they have to make.
    Right, it's not obvious to me why the DI enhancements and context-sensitive DI couldn't have been added to the EJB 3.1 and JSF 2.0 specs (and other specs that would use DI functionality) instead of creating a new and separate spec. I'm worried about the duplication and confusion also. Randy
  33. I'm worried about the duplication and confusion also.
    Randy: It's not that I'm not worried too, it's just that I see the benefits outweighing the costs. Of course, I would be happy to see DI being defined in the Java EE spec or even the EJB 3.1 spec level instead. However, as I said, I think at the end of the day this is more a technicality than anything else and it's pretty transparent from a developer's perspective... Cheers, Reza
  34. agree that DI is overkill for a set of simpler applications, but VM already supports a good number of technologies which are not used by a good set of applications.
    Personally I believe it's too late. There are basically too many different DI mechanisms in Java already. Just let me give you a list of some of the more important ones, for fun ;-) - Spring - Seam - WebBeans - OSGI (and related mechanisms such as spring-dm service lookup) - JSF managed beans (yup, it's a simple DI mechanism, and yet people use it, JDeveloper for example generates everything based on it) - EJB 3.x - SCA (for creating and using services in a SOA, funny thing is it's actually brand new and pretty good but doesn't use any of the above technologies at all!) Who says we don't need one and only one DI mechanism? Why should osoa guys roll their own DI in year 2008?! Ara.
  35. Ara: Good observation, although I don't necessarily agree with the overall outlook. I think one of the implicit goals of WebBeans has been to standardize the "best of breed" in DI (particularly taking into account EJB 3.x, JSF, Seam and Guice), hence you'll find many familiar constructs that I could not cover in the limited scope of this article. Cheers, Reza
  36. Thanks for this really interesting series of Articles on the upcoming EJB 3.1 Reza. A point I would like to see discussed is the cons of that tight integration of JSF and EJB: I like the current architecture with using the JSPs/XHTMLs as VIEW, the JSF Managed Bean as CONTROLLER (for the web-ui) and the EJB's as BUSINESS LAYER in behind (UI-independent). So what I see what will happen (at least by rather unexperienced developers) is that the 3-tier-architecture could be violated by using such a tight integration as WebBeans provides. I assume it won't take long until I find the first UI-specific code within an EJB... Don't take me wrong - this is just a first thought that came up in my mind when I read your article. What are the experiences of the SEAM people, what do you think?
  37. Hans: I agree with you that this is a real danger from such a tight coupling. One way to avoid this on projects is by mandating that EJBs not be polluted with presentation tier logic. In such cases, plain WebBeans components and not EJBs should be used as backing beans. A counter-point is that some folks are perfectly comfortable with this as they see a three-tier architecture as overkill in the first place. Cheers, Reza
  38. I sometimes wonder about this too. In Seam, you often see “Faces Messages” being used in session beans. I am not exactly sure where you would bind components to if you needed to interact with them? I suspect the session also?
  39. I sometimes wonder about this too. In Seam, you often see “Faces Messages” being used in session beans. I am not exactly sure where you would bind components to if you needed to interact with them? I suspect the session also?
    Serge: I would send your comments to the WebBeans EG. This is the kind of things that the spec should be keeping an eye out for and seeking solutions. Cheers, Reza
  40. In current JSF, there is a "hard" difference between a backing bean and a SessionBean. As with the article and many other exaples of illustrative code, you will see a lot of "layer mixing" in Seam and WebBeans examples. This is for brevity. Neither framework stops you from layering your application as you see fit. Use dedicated "backing" session beans or POJO's for your "controllers" which have "model" beans injected into them. Doing this, you still have the same pattern, but the tiers of your application are more easily integrated with one another and you don't have a lot of configuration to maintain with your code.
  41. Randall: Well said. Cheers, Reza
  42. Hans, Not having used Seam, I think the drive to using EJBs as backing beans is to get the controller working within the transaction context, ideally making it more friendly when working with managed entities via JPA. RIght now, with the common 3 tier architecture you have: View Layer -> Controller -> [transaction wall] Business Layer Using EJBs as backing beans (and, mind, I'm mostly making this up -- I'm not a JSF guy, however...) you get: View Layer -> [transaction wall] Controller -> Business Layer So that means that your controller is no longer, necessarily, responsible for moving entities from the unmanaged state to the managed state. For example, say you have a simple Update form that has Person ID, First Name, and Last Name. During the binding phase, between the View and Controller, the infrastructure fetches the correct entity from the back end, and then set the First Name and Last Name in the Person instance. Since you're already within a transaction, that Person instance is managed (from a JPA point of view), so simply changing those values via binding will change the entity when the transaction commits. Now, all of a sudden, with a appropriate fetching mechanism to get the instances, your "update" method has "no code". All it needs to do is commit. Now, there's no reason you can't still have a 3 tier system (you can always disable transactions at the method level with EJB), but by using EJBs as controllers, you can easily move the transaction barrier farther forward, which can be a benefit for some.
  43. Will: Good point. This is indeed a plus while working with stateful beans as backing beans with an extended persistence context and the WebBeans conversation context (Daoud mentioned this indirectly). Cheers, Reza
  44. you get:

    View Layer -> [transaction wall] Controller -> Business Layer

    So that means that your controller is no longer, necessarily, responsible for moving entities from the unmanaged state to the managed state.
    Your ideas are quite interesting, but in order to make this really work with statefull session beans I think some connection with the conversational scope needs to be made. Otherwise you can't distinguish separate requests to the same page being made from different windows or tabs in the same browser. In a lot of cases, these requests do not belong to the same (EJB) session. The EG is probably on to this already, since a while back Gaving King talked about this when explaining Seam (the famous hotel booking example). Just wanted to mention this here for completeness. Btw, a small technical detail about the term 'controller'. In JSF you actually don't write the controller. It's provided by JSF (through the FacesServlet). Almost by definition, a "backing bean" -is- glue code between the model, view and controller. Otherwise it would just be a mere "managed bean". The backing bean term is purely a convention though, it doesn't really exists as a concrete thing in JSF. In a way though, you could probably say that JSF is a MVC-B framework (Model View Controller with Backingbean) ;)
  45. The EG is probably on to this already, since a while back Gaving King talked about this when explaining Seam (the famous hotel booking example). Just wanted to mention this here for completeness.
    They are :-) Reza
  46. you get:

    View Layer -> [transaction wall] Controller -> Business Layer

    So that means that your controller is no longer, necessarily, responsible for moving entities from the unmanaged state to the managed state.
    I never had a case where the controller (UI) was responsible for moving entities from unmanaged to manged state - this was clearly a concern of the business tier, i.e. on the entry point from UI to business tier, the passed entities were merged into the persistence context again. The example you described where the JSF backing bean is an EJB that "automagically" creates/merges a managed JPA POJO and sets the values received from the JSF form into the POJO and then commits the transaction ... ...this really frightens me. I never would want that a "client" to my business logic / services layer directly is able to perform changes into my persistence tier / model objects. And what about the case you're not only having a JSF based input form, but also a web-service that provides the same functionality to external systems or a backoffice system that is not web-based but has a swing GUI, etc. - then there is no jsf (or not only JSF), so somehow you need this non-UI logic of managing the persistence context, handling the business process, doing the CRUD clearly in the business (and below) tiers. As far as I can see (but admitting never have used seam), this tends into the direction to extremely reduce the efforts of building the (technical) skeleton of a JSF/JPA based web-apps. I believe that in the end this will lead to lots of unmaintainable, "grown" web-apps where the basic three tier architecture is violated and refactoring is simply "hell" or even impossible. (you can believe me - I already had some projects where I had to refactor JSP's that contained everything from view to business logic...). (btw: thanks arjan to clarifiy the terms "controller" and "backing bean" in JSF ... although I tend to call my backing beans "controller" as the faces servlet is transparent in JSF) Hans
  47. Hans: Good points. One of my concerns with the JSF/EJB/JPA integration parts of WebBeans is exactly this dissolution of concerns. I do fear that we'll begin to see business tiers that do not "survive" a presentation tier technology shift because the code is just too close to presentation logic. On the other hand, WebBeans doesn't force you down this path either, so it's a bit of individual choice. For some apps, a three tier architecture might indeed be overkill. In the least, it makes for keeping a close eye on what's getting intermixed with business tier logic... We're covering WebBeans in the next edition of EJB 3 in Action and we'll outline exactly these concerns as best practices. I hope that pure WebBeans/Seam books would do the same too. The trouble is that people seem to have jumped on the bandwagon that less code==better apps. That's not always true...there is sometimes such a thing as good abstraction layers... Cheers, Reza
  48. you get:

    View Layer -> [transaction wall] Controller -> Business Layer

    So that means that your controller is no longer, necessarily, responsible for moving entities from the unmanaged state to the managed state.


    I never had a case where the controller (UI) was responsible for moving entities from unmanaged to manged state - this was clearly a concern of the business tier, i.e. on the entry point from UI to business tier, the passed entities were merged into the persistence context again. (thanks arjan to clarifiy the terms "controller" and "backing bean" in JSF ... although I tend to call my backing beans "controller" as the faces servlet is transparent in JSF)

    Hans
    Hi Hans/Arjan, In MVC terms I prefer to think of the "controller" role in JSF as satisfied by both the FacesServlet (Front Controller pattern) and by the managed beans (controller objects). I don't think of the controller in JSF as a singular concept, rather I see it as a multiplicity of objects with controller behavior. Since you have many views in JSF it is reasonable to have many controllers too, and backing beans fit this role nicely as form controllers. If you are using the Seam framework, then it just so happens that your JSF controller objects are stateful, transactional, EJB components. I don't see why a controller cannot manage persistence for your domain model in this case. In fact, I feel this is getting much closer to pure MVC, where the controller manages/updates the model state, influences view selection, and handles user gestures/events in the view (user interface). Ian Hlavats JSFToolbox - JavaServer Faces for Dreamweaver
  49. And what about the case you're not only having a JSF based input form, but also a web-service that provides the same functionality to external systems or a backoffice system that is not web-based but has a swing GUI, etc. - then there is no jsf (or not only JSF), so somehow you need this non-UI logic of managing the persistence context, handling the business process, doing the CRUD clearly in the business (and below) tiers.
    If you use EJB Session Bean based web services, then the web service code is on the inside of the transaction barrier and EJB is managing your persistence contexts, etc. In Seam, since you're talking to Session Beans, you get all this "for free" as well. This is no different than the common model of the, what's it called, Session In View? Something like that? Where there's some Filter or interceptor or whatever that starts up your transaction for JPA or raw Hibernate, so that when you action code runs (whether in a servlet or some other artifact), you're already on the inside of the transaction barrier. Once inside, all of your persistence object are managed. Then, barring an exception or explicit rollback, your transaction "commits for free" as the request completes. This is in contrast to a classic EJB architecture where your Web code is on the wrong side of the wall. It's not impossible, but most folks don't enlist their web code in to the same transaction as their Session Beans. Kind of defeats the value of declarative transaction management that EJB is so good ath. So, every time you use your Session Beans to return Entities, they come across the transaction barrier in to your action code, and become unmanaged. Now if you're action code is effectively just a simple facade that bundles up requests in to DTOs, tosses them back to the EJB, and then feed the replies to whatever rendering technology you're using, then you're effectively writing marshaling code. But, since modern JPA entity domain objects ARE "Just POJOs", there's a lot of value in being able to use them as combination Entities and DTOs. There's nothing stopping someone from providing a isolation barrier between their requests and their persisted objects. But for many small to medium systems, they simply don't need that extra layer, so being able to work directly with managed entities populated by a framework layer mapping requests in to them directly is a GREAT time and code saver.
  50. Hi Reza, Thanks again for this 4th part :) Here are my thoughts: - For POJO components DI, I'd like to see @Singleton annotation (for the singleton class) along with @Factory (for the getInstance() method) . Thought those are already present in Guice. A good usage would be ease of migration for legacy code since one would have just to decorate the existing classes to get them into a JEE 6 compliant application. - Out of box integration with Bean Validation jsr 303. - And yes I want the Interceptor thing into the whole JEE stack. It's a neat way to get Aspects right into JEE. Here my post: http://kissthedots.blogspot.com/2008/06/ejb-31-new-features-sneak-peek.html @Mohammad: - what old ones are you asking to deprecate? - No it isn't over engineering since we could migrate old applications just by decorating all this stuff with annotations, and to be able to do webbeans with simple POJOs no EJB there. @Hans: This new jsr simplify further your architecture, backing beans becomes your model and the controller is the SessionBean (statefull || stateless) and we are still 3-tiers with less (layers) glue code :) @Reza: Think you avoided talking about the extended scopes as it's irrelevant of the WenBeans-EJB relation, but that something that deserves pointing here, one of benefits is get rid of the OpenSessionInView pattern and emf.merge(). Also transactions management (no more need for joinTransaction()) call as this will be declarative annotations driven. Best Regards, Daoud AbdelMonem Faleh.
  51. Daoud:
    For POJO components DI, I'd like to see @Singleton annotation (for the singleton class) along with @Factory (for the getInstance() method).
    @Produces in the current WebBeans spec is essentially equivalent to @Factory. For singleton beans, you can always use EJB 3.1 singletons.
    Out of box integration with Bean Validation jsr 303.
    I would think this would be the case for most Java EE 6 app servers that support WebBeans.
    And yes I want the Interceptor thing into the whole JEE stack. It's a neat way to get Aspects right into JEE.
    Send your thoughts to the EJB 3.1 EG!
    This new jsr simplify further your architecture, backing beans becomes your model and the controller is the SessionBean (statefull || stateless) and we are still 3-tiers with less (layers) glue code :)
    This is a good point, especially if WebBeans EL supports passing EJB parameters. This is the case in Seam, I would not assume this is the case in WebBeans; it does not address it in the spec. If you think this is important, email the EG... Cheers, Reza
  52. @Mohammad:
    - what old ones are you asking to deprecate?
    Actually they are not that old. I'm talking about @EJB, @Resurce and... When we can use @In to inject all types of dependencies why then we need those type specific ones?
  53. http://manidoraisamy.blogspot.com/2007/11/my-ejb3-wishlist-jpa-undo-webbeans.html
  54. Mani: Your ideas are very interesting, particularly the point about getting Java back-ends ready for RIA/SOA. As you know, EJB end-points already support SOAP and RMI. I was hoping that the support for stateful JAX-WS would go through but it seems there isn't enough interest for that right now. I've also been trying to push for EJB remoting support through JAX-RS in order to support RESTFUL web services in EJB. Cheers, Reza
  55. Hi all, I have not read the fine print yet for EJB 3.1 but I would like to know if anyone here knows if automatic EJB detection at deploy time for web applications is on the agenda for new features? JBoss 4.2 enables annotated EJB3 components to be deployed and detected by the container automatically. I have grown quite accustomed to this feature and was surprised when I learned that other containers require EJBs to be declared in web.xml. See also the Seam documentation (Section 26.1.3. Configuration file changes):
    you need to declare all your ejb's in the web.xml. This is a silly requirement of a number of JEE 5 application servers - for example OC4J and Glassfish.
    Why is this necessary? Any good arguments out there? Or should I ask, who let this one slip past the EJB3 committee? ;-) Shouldn't the EJB3 spec be more forward thinking in this regard? Why require verbose XML when simple annotations will do? It would be nice to see support for automatic detection of annotated EJB3 components for web applications in the upcoming spec. Ian
  56. Ian: You bring up good points. As to the ejb-link ref stuff you mentioned, this will essentially go away once JNDI names are standardized (both local and remote EJBs will have deterministic names that do not need to be explicitly mapped). I agree leaving this up to vendors in EJB 3.0 was really not a good idea. BTW, @EJB in the web tier (of the same application) does work in GlassFish without any additional mappings, so the referenced documentation, if I understand it correctly, is not entirely accurate :-). I'm not sure about OC4J, my co-author for EJB 3 in Action could probably tell you more about that. I vaguely recall that OC4J maps very nicely as well. In fact, as far as I can remember, I think this is only an issue using the EJB 3 plugin for WebSphere 6 (Randy, is this right?). As to auto-detection and hot deployment, the spec doesn't address this yet, but looks like a number of vendors (including GlassFish) may support OSGi strongly, effectively addressing this issue... Reza
  57. Ian:

    You bring up good points. As to the ejb-link ref stuff you mentioned, this will essentially go away once JNDI names are standardized (both local and remote EJBs will have deterministic names that do not need to be explicitly mapped). I agree leaving this up to vendors in EJB 3.0 was really not a good idea.

    BTW, @EJB in the web tier (of the same application) does work in GlassFish without any additional mappings, so the referenced documentation, if I understand it correctly, is not entirely accurate :-). I'm not sure about OC4J, my co-author for EJB 3 in Action could probably tell you more about that. I vaguely recall that OC4J maps very nicely as well. In fact, as far as I can remember, I think this is only an issue using the EJB 3 plugin for WebSphere 6 (Randy, is this right?).
    No, I don't think that is accurate. All appservers presently need some kind of mapping for @EJB and ejb-ref/ejb-local-ref reference definitions over and above what the spec defines. WebSphere provides a spec extension that we call "AutoLink" that automatically maps @EJB, ejb-ref and ejb-local-ref references to a default target EJB in most cases, which can also be overridden by the user defining a custom mapping if they wish. But the custom mapping is only necessary in corner cases where the "best" target cannot easily be determined by default. Randy
  58. Randy: That was my impression. I know for sure that you don't need to do anything in terms of XML mappings in GlassFish and JBoss AS. GlassFish does something similar to the "auto-link" facility you mentioned (as documented here: https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html#mappingRemoteejbdependency). I'd be hard pressed to believe WebLogic and OC4J would not have something similar too... Of course, standardizing JNDI naming puts this all to rest as it really should be :-). Cheers, Reza
  59. As to the ejb-link ref stuff you mentioned, this will essentially go away once JNDI names are standardized (both local and remote EJBs will have deterministic names that do not need to be explicitly mapped). I agree leaving this up to vendors in EJB 3.0 was really not a good idea.
    Reza, first of all thanks for all the feedback you have been providing here in this thread. It's really enlightening :) About the above statement, I take it there originally was a valid reason to leave the JNDI names up to the vendors. I'm just very curious what that original reason was. A lot of the EJB3 spec makes a lot of sense to me actually. I know a lot of people are still skeptical about it, but I must say I'm very impressed with it. But for the JNDI names, they only thing I could think of when I first read that was "Why!?". Would you happen to know the original motivation for it?
  60. Arjan: Thanks for the kind words. It's not surprisingly EJB 3.0 has it's skeptics. After all, "EJB bashing" had become somewhat of a fashion statement for a while, and still is to some degree :-). Now, I'm not saying it wasn't entirely undeserved, I just contend that it's gone a little out of hand, given the importance of this spec to Java EE overall. From what I've been told, they simply ran out of time in terms of standardizing JNDI names. Remember that the changes were quite significant in EJB 3.0, so what they managed to get done in a reasonable time-frame was indeed quite impressive. I'm not sure the EJB 3.0 leadership ever got the credit they deserve for turning things around fairly quickly... Cheers, Reza
  61. MathUtil.round() is static[ Go to top ]

    Why even use @In private MathUtil mathUtil;? MailUtil.round(double, double) is static. It seems pointless to me to make a instance of the class. Or am I missing something? So I agree with Mohammad that this example is indeed over engineered.
  62. Well, most of the concerns I see here are about breaking layers, the 3 tires architecture etc.. I guess WebBeans/Seam don't force you to *NOT* layering your system, if you like to you'll simply get some extra features like DI. Now if you fully embrace the WebBeans/EJB-3.1 way you still have your (logical) layers and you get rid of the glue code since it will be transparently managed for you. I really fail to see any danger here that WebBeans will introduce that doesn't existed for ages.., we've always been dealing with best practices, patterns, blueprints, appfuse etc.. Now about DI, I personally agree that it make a separate spec that would spread to the hole java landscape and don't stick to the EJB island. Same goes for validation. It's good to have those specs in fat clients so moving from Swing to EJB et WS-* wont break the *already* acquired knowledge, after all they are commodities and we've been doing with abstract factories etc.. One last thing regarding the OpenSessionInView thing. I've always considered as a hack provided by some utility framework willing to grow to the standard JEE framework. That was a failure.. And if we want to talk about breaking layers, what a good example. What I really like about the upcoming JEE spec is that it's fully POJO, well with the different JEE profiles, one could write POJOs and later decide to run them as EJB, WebBeans components or even run them in Swing application or unit tests. Also the conversation scope is pure sugar! :) Regards, Daoud AbdelMonem Faleh
  63. Hi, Thanks for your the article and the very enlightning following discusion. I have a question: What is the exact purpose of the @Componant annotation (which doesn't exists in Seam)? If the purpose of the @Componant annotation is to declare a WebBean then what is the advantage of also having a standalone @Name annotation? Can the @name annotation come whitout the @Componant annotation? If not then why not merge the @Componant and the @Named annotions? ex. @Componant(name="placeBid") or better @Componant("placebid") ZC
  64. If not then why not merge the @Componant and the @Named annotions? ex. @Componant(name="placeBid") or better @Componant("placebid")
    I really wonder about that too. In Java EE these kinds of things happen even more in the various XML files. Separate elements are used for every tiny bit of data, which logically could have been attributes. E.g. if you take JSF, you see something like: foo com.something.Foo request Why all those elements? This can be written in a much more compact way when using attributes on the tag. I took JSF only as an example. The majority of the EJB3 XML format and the web.xml format suffer from exactly the same problem.
  65. I have the same concern myself. This is good feedback for the WebBeans EG... Cheers, Reza