Jason Marston

+ Follow
since Aug 03, 2009
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Jason Marston

Probably more relevent when this certification gets updated to JavaEE 6

However, now there is the idea of a Managed Bean in JavaEE. You get all the lifecycle, injection, interceptor and decorator goddies, but, it is not an EJB. It has scope (request, session, application, converation, and so on). All the nice stuff from EJB that we all wanted from Spring. Managed Beans are NOT EJBS.

So now we have a nice way of managing lifecycle, scope and even alternative implementations in different environments, without any of the moaning about using EJBs.

In addition CDI also has events, and is a big part of how the Bean Validation Framework is able to work in all layers of JavaEE.

Just my opinion, but I expect this to be a significant if small part of the future exams.
I have been thinking on this issue of implementing DAOs as EJB3 Stateless Session Beans.

I have come to the conclusion that doing this does not impose any serious dependancy on EJB3 into the solution.

Here is my thinking.

The reasons for using EJB3 to implement DAO are:
  • To inject the EntityManager
  • To make use of CMT
  • To make use of the EJB lifecycle

  • Now, if the instance variable we use to hold the EntityManager can be initialised either via the constructor or via a setter. Then moving to SpringBeans for instance is trivial. If we simply ensure that injected variables can be initialised in some other way as I described. Then there is no need to change the POJOs or Interfaces that are used to implement the DAOs. Spring can also handle transaction boundaries and so on, and of course the lifecycle.

    Thus we are not dependant upon EJB3 at all.

    Of course the things that would need to change slightly are the classes that depend upon the DAOs. However if we were moving away from EJB3 then to be honest those classes would also be EJB3 Stateless Session Beans and I would apply the same guidelines to them.

    Further along the chain. In JSF ManagedBeans. EJB3 Stateless Session Beans are of course injected into them. However once again, with a little configuration using JSF Injection, the (now) Spring Beans can be Injected instead of EJB3.

    This leads me to conclude that if you decide on EJB3 for DAOs then you can always change your mind later without having to alter any code or recompile any classes.

    BTW: When I say I have thought on this. I actually mean I went back to a project I did about a year ago and verified what I remembered. I used the exact aproach I outlined above to enable me to do JUnit and DBUnit tests without deploying my application to a server. I did several combinations over the life of the project starting with just Spring/OpenJPA and finished with OpenEJB/OpenJPA so I could test dependancy injection properly with an EJB3 implementation that was not embedded in an application server.

    Ashu Sharma wrote:Thanks for your input Ronald and Janis.

    My Solution is also similar to that of Ronald's. My Solution comprise of following

    JSP--->Backing Beans--->ServiceLocator---->SessionBeans----->DAO--->Entities

    In class diagram i am planning to show the Session Bean layer and onwards(Boundaries,Controls and Entities only).

    Q. Should i include the backing beans also in the class diagram.

    In component diagram i am showing All the layers starting from JSP to DAO(and entities)

    I am little confused about Sequence Diagram also.

    Q. Should it show the JSF controller servlet

    user--->controllerservlet--->backing bean---> and so on

    or i should ignore the controllerservlet since it is assumed to be there as a part of framework.


    My take on this is:
  • If you use injection you don't need the service locator. (Injection can be shown in a simple annotation)
  • In the class diagram, you show classes that directly relate to or are derived from the problem domain (plus a few orchistrating classes. xxxControler, xxxManager etc). Technology belongs in the Component diagrams
  • In the Component diagram you show all the components, JSP, Session, etc.
  • In the sequence daigrams, you show every class in your design (you may split the sequence diagrams of course to keep the ones representing the use cases simple SSDs)

  • Of course some of the above is different in real life, it seems to me that SUN want the class diagram to be a Technology Independent Design. The Component diagram to reflect the technology design descisions. The sequence diagram to show how all the classes collaborate to get the job done.

    Your language suggests you are using the Rational approach, whilst a good approach, consider if it shows what SUN are asking for on this assignment.

    I don't show on any of my diagrams classes that are a part of the underlying platform or framework I am using. (I show the JSF and the ManagedBean. the FacesServlet is provided and not something you are designing. A simple annotation mentioning the FacesServlet in my opinion should suffice)

    To use your notation I would show

    Actor ---> JSF Page --> ManagedBean --> SessionBean --> DAO --> Entity

    Remember a JSF Page is compiled into a Servlet if it is JSP based. Facelet based JSFs are of course different (and not a core part of JavaEE)

    A final reason I would show the JSF Pages is that the Case Study in the Cade book shows JSPs

    Ashu Sharma wrote:Hi ,

    I need some insight into how to show JSF in component diagram.

    1. Should i show a single component(called JSF) or
    2. Show two component separately - FacesServlet and Backing Beans.


    My opinion that I would show the actual JSPs as JSF and the BackingBean as ManagedBeans. I am sure others would do it differently though. The main reason for my separation of the two is that Multiple pages could use the same ManagedBeans, and of course a single page could also use multiple ManagedBeans. Thus it is a uses relationship.

    Cameron Wallace McKenzie wrote:

    A DAO should never be implemented as a Session Bean. The idea of a DAO is to decouple database access from the design. Making it a Session EJB ties you to an EJB infrastructure. It means if you want to use the same DAOs in a stand-alone application, you'd have to completely re-write your application.

    A DAO can be invoked by a Session bean, and the Session bean could use CMT. I'm sure that's what the original poster means. Nobody would ever recommend implementing a DAO as a Session bean.

    -Cameron McKenzie

    In your article on DAO and Hibernate. You use a Factory to created instances of DAOs specific to an implementation like JPA (I know it was actually Hibernate, but the basic idea is the same). For JPA would you pass the EntityManager into the DAO constructor or handle obtaining the EntityManager within the DAO?

    My thoughs on this are that a DAO is for Data Access. Obtaining the EntityManager is not Accessing Data. I think the Factory would obtain the EntityManager and pass it into the DAO, either in the constructor or using a setter after construction. This would of course make it easy to switch from EJB3 to Spring for instance.

    Even then. How would you obtain the EntityManager in the Factory? Would you make the factory a service (EJB3) and use injection, or use one of the other techniques such as InitialContext lookups?



    John Plaer wrote:

    I assume that there is a purpose of a validation check before adding a component to the current design

    I looked over this in great detail. I think the validation check is to ensure it is a valid combination of components. For instance. The domain model says there must be at least one wall. That is ok as far as the object graph goes. If the validation were only talking about the multiplicities it would not really need to be addressed. I am thinking that when adding a component, there are combinations that would not make sense, like having straw walls with a concrete roof (extreme example I know).

    Then in the complete house design use case there is more validation

    I am guessing something can conform to the associations and multiplicities, but not be a valid house design, for instance only having 1 wall, unless the wall is circular , I am assuming there are other rules as to what combination of components makes a "Valid" house design, rather than just a house design that conforms to the business domain models multiplicity rules.

    In other words the things that make a house design valid are business rules and can change

    I am also assuming that although alternative flows are not shown in these use cases, we are expected to cover them in our sequence diagrams.

    Remember in addition. If we have A (0..1) ---> (1) B. A cannot even exist without an instance of B, always does not just mean always when I hit validate. It means always. Thus there is no way to ever add a roof to a house only to replace a roof as it must always have 1. Likewise we can never just remove a roof. the house design must always have a roof.

    I think I rambled a bit there, but hopefully you get what I am saying

    Another thought.

    I think you will both agree that upon completion of the use case all the constraints on the model (multiplity etc) must be valid right?

    If we start with a new house and just add a wall. Then at the end of the use case the object graph is in violation of the multiplicity as it must have a roof and foundation.

    John Plaer wrote:
    You are absolutely correct Jason, if the multiplicity between object A and B is 1 as well as between object A and C and also between A and D. It does not mean that object B and D should be created first in order to create C.

    I hope you get what i mean here. The problem here is more towards the use case rather than the domain model.

    Lets look at a slightly different example.

    If A and B were 0..1 to 1 and the others were the same. You could have a B, C or D without A, but A would always require one of each of the others.

    A sounds like we are building a complex object.

    In Soldier Job missed a third option in his posting.

    Option 3: When a house is created is has the foundation roof and a wall, when you add a roof or foundation, it replaces the current one.

    I think the phrase "house style" is the key to answering this and to which assumption anyone will choose to make and document.



    John Plaer wrote:

    I can see that a valid house design should have 1 roof and 1 foundation but it does not say that you can not start of by a blank design. and it also does not say anything about the order of components being added. What if someone wants to add the roof at the end by making a choice from a selection of roof types ?

    I assume that there is a purpose of a validation check before adding a component to the current design

    I am going to talk about uml in general rather than this specific assignment. If we have a class A and a class B. An the accosiation between them is a 1 at the B end.

    Then the semantics of the uml multiplicity on the association says A will always have exactly 1 B. If it was allowed at some stage to have an A and not a B, the multiplicity on the association would be 0..1 rather than exactly 1.

    Zhixiong Pan wrote:

    A Synchronous messaging
    B Asynchronous messaging
    C You shouldn't be using messaging at all as it's not transactional.
    D You could use messaging because it is transactional however it's not advised, as the system would never perform well enough for an instant response.

    This is one of the Whizlabs questions and the clue is in the phrasing of the answers.

    B is obviously wrong as you would not get an instant response
    C is wrong because messaging can be transactional
    D is wrong because you have just been told the card validations system is VERY POWERFUL. So the statement that is will "NEVER perform well enough for an instant response" is wrong.

    So the process of elimination leaves us A.

    Syncronous messaging CAN indeed give an instant response. I think you are confusing messaging with asynchronous messaging (fire and forget).



    Edit: I got 100% in this part of the Part 1 exam. I do actually agree that given a choice you would not use messaging, but many existing systems do use syncronous messaging as their interface. If use session beans had been one of the answers it would have been correct.

    A few or the associations in the Domain Model (The ones between Product, House, and it's various components) only have an ordinality on one side of the relationship, and with some the ordinality sits in the middle.

    Would you guys say that we are free to make assumptions about the ordinality at the other end, and which end the documented ordinality is linked to? PROVIDED of course we document those assumptions?