Edward Peters

When you implement functionality that has to be shared across a wide range of clients you will use a SessionBean that runs in a EJB container (not entirely unlike a COM object on a MTS!). The container will take care of nasty things like transaction handling, caching and pooling. That's about all there is with EJB's, you can build perfectly sound (enterprise) applications by using SessionBeans only. In fact a lot of vendors did not implement EntityBeans with their EJB 1.0 container.

EntityBeans offer you a framework for persisting your datamodel. You will not have to code your data layer (in theory and as long you're using a SQL database to persist) yourself, which is called CMP (and CMR). When your data is not on a SQL database you will have to use BMP. But the only good reason to use BMP I can think of, is re-using the EntityBean interface and thereby making it remote.

With that reason, I do not see much sense in giving an EntityBean a remote interface. Instead I will advise to use EntityBeans with local interfaces (advance: better handling of CMR), which can be operated on by SessionBeans (design pattern: SessionFacade).

My point: SessionBeans are the important thing. EntityBeans (especially as of EJB2.0 and in combination with a SQL database) can be handy in persisting your datamodel and at the same time reduce your LOC (which I consider a good thing).

Edward Peters, SCEA

PS I consider your question Can any one tell me that why do i use an entity bean if i can provide persitence in my session bean itself a very good one.
[ July 21, 2004: Message edited by: Edward Peters ]

1) What is the average exp. that ranchers do have before taking the SCEA?
7 years (after 4 years of formal IT education)
2) If you have a formal IT education, what is the most usefull course you had, that you think helped u doing ur job?
OOD, although a lot has changed since then in this field
3) What is the best Architecture/design book you have ever read?
"Patterns of Enterprise Application Architecture" by Martin Fowler
("Refactoring, Improving the Design of Existing Code" by the same author will make you a better designer)
4) Do you really learn a lot after the first, say 1-2 years of j2ee experiance in case you read all the patterns books (all look the same anyway) and you mainly design web apps. and thus "always the same story"
Definitely YES. Although I agree to be very selective, Gang of Four should be your basic knowledge.
5) PLEASE tell us about your experiances, the best architecture you have ever made, and how may design patters you usually use per project (4 or less, 4-12, more then 12)
Simple = good, less = more. Use Design Patterns whereever you can, not as often as you can! Good design will produce less code and probably uses less design patterns.
6) A project failure exp. due to bad acrchitecture It does not have to be urs just some arch. u have seen (and maybe had to refactor)
I think bad architecture expresses itself mostly not in project failure, but in troublesome maintenance afterwards.

Same for me, I passed December 23th. When I contacted Prometric I received the same email in response, in which they thanked me for my continued patience in this matter. I considered this a very serious insult. Further more the email stated that Prometric is tracking all affected candidates
(using their corrupted database?), which I think is just not true. Is there anyone out there who has been contacted by Prometric about this?
Finally the email tells me that they do not know when this problem will be resolved. I think that if you do not know WHEN this problem will be resolved, you actually do not know HOW to resolve this problem. And when you do not know how to do your work, you are ... unprofessional.

Hello Edward,
I also passed SCEA in December (23th) and until now I saw no sign of any processing in the i-7 database. It is not as much the paper certificate I cannot wait for, it is the possibility to publish my certificate by e-mail I need. An e-mail I sent to <who2contact@central.sun.com> about this has been unanswered now for almost two weeks.
The way matters are taken care of is totally unacceptable for a large, profressional company. They should at least keep their customers properly informed when things are not working out properly. Simply a message on the website could have solved this. Further more all problems seem to have started with the migration of the certification database. I find this a real shocker, almost like an oil company that cannot deliver because they've run out of oil! Maybe they have difficulties in finding enough certified personnel...

I agree with showing the business domain in the class diagram only. I myself let even the session fa�ades out of the class diagram. (but then I got only 42 points out of 44...)
In my opinion a UML diagram must represent just one idea and you choose the diagram that models that idea best. So you use a class diagram which is good at showing relations for modelling the business domain. And you use a component diagram as the 'recipe' of your application, showing which and how application components use eachother. (As I probably would prefer a deployment diagram to describe the system deployment )
By asking for a class and a component diagram (and sequence diagrams) Sun, I think is actually asking for specific ideas about the architecture thereby ruling out the possibility for countless variations of diagrams.

John,
I do think that EntityBeans can be used in the situation of the case study. If you look at the Customer Component Diagram you can see that the CustomerDAO does not use any subsystem to persist the account information.
Problem however is that the account information is aggregated from Customer, Address and CreditCard object(s). To solve this you can use the Composite Entity design pattern (see http://java.sun.com/blueprints/patterns/CompositeEntity.html). While I think that with EJB 2.0 this is a good solution (using CMP and CMR), with EJB 1.1 this solution involves quit a lot of coding.
I think that Mark Cade with EJB 1.1 in mind chose for the simplest (thus best) solution, but with EJB 2.0 EntityBeans are a viable solution.
Edward Peters

Hello,
While currently working on the assignment and using the Case Study from the Cade book as an example, I got a few questions:
1. The Case Study does not use the form instance name/class name in the sequence diagrams. Is this common practice or should the diagram show the instance name when the system uses a particular instance?
2. Is it neccesary to show the front end objects, like the JSP's and the front controller in the sequence diagrams? I know in real life I don't, but maybe this is a bad habit I should change.
Basically what I want to know: Is the style used in the Cade diagrams the (only) one accepted by the examiners?
Answers on this topic will be appreciated.
Kind regards,
Edward