Show Posts
1
General Board / Re: EJB and UML modelling
« on: September 24, 2002, 05:53:46 am »
"I personally have never done EJB, but if you have a simpler method could you breifly explain how you are modeling EJBs. I am curious what the <<session>> or <<entity>> actually represent."
Here's a very poor description of EJB's, off the top of my head:
EJB's are used in multi-tier Java applications - they are based on the server.
As you know, a regular class often represents a real world concept. Sometimes, the real world concept is data rich. Perhaps an on-line bookstore would have a class called "Book". If you make this class an Entity EJB, the programmer will (almost) automatically get features such as persistence, threading, transactions, etc, etc - without having to do much work. So in this example, the details of the books in our system can be automatically stored on a relational database (and updated, deleted, etc) - without any need for messy JDBC calls in your class.
An EJB Session bean is quite similar, except they are often used as a "processing" class; they don't hold persistent data. In the book store example, perhaps we have a "Credit Check" process. This could be modelled as a class, and made into a session EJB. Again, you get some features for free - transactions, load balancing, etc. All provided by the server.
So that is EJB is a very poor nutshell. One detail I have hidden here is that an EJB isn't just a single class in Java - you actually have to write three separate files:
* The Home Interface
* The Remote Interface
* The Bean Implementation
One is the meat of the class, the other two are really just "housekeeping" classes.
So, for the "Book" EJB example above, we'd need to write three Java classes. (see any EJB book for the techie details of the three files). They would be called BookHome, Book, and BookBean.
BUT - when I am modelling, it is enough (for me) to just have a single class on my diagram, called "Book". I will tag it with a stereotype to remind myself it will need to be coded using the three files described above.
Your mileage may well vary - code generatation etc. My goal is always to keep the diagrams simple, clean, understandable and maintainable.
PhilR - thanks for the point about the name clash! I'd forgotten about Boundary, Entity and Control. I'll check the profile and find out the official stereotypes!
Here's a very poor description of EJB's, off the top of my head:
EJB's are used in multi-tier Java applications - they are based on the server.
As you know, a regular class often represents a real world concept. Sometimes, the real world concept is data rich. Perhaps an on-line bookstore would have a class called "Book". If you make this class an Entity EJB, the programmer will (almost) automatically get features such as persistence, threading, transactions, etc, etc - without having to do much work. So in this example, the details of the books in our system can be automatically stored on a relational database (and updated, deleted, etc) - without any need for messy JDBC calls in your class.
An EJB Session bean is quite similar, except they are often used as a "processing" class; they don't hold persistent data. In the book store example, perhaps we have a "Credit Check" process. This could be modelled as a class, and made into a session EJB. Again, you get some features for free - transactions, load balancing, etc. All provided by the server.
So that is EJB is a very poor nutshell. One detail I have hidden here is that an EJB isn't just a single class in Java - you actually have to write three separate files:
* The Home Interface
* The Remote Interface
* The Bean Implementation
One is the meat of the class, the other two are really just "housekeeping" classes.
So, for the "Book" EJB example above, we'd need to write three Java classes. (see any EJB book for the techie details of the three files). They would be called BookHome, Book, and BookBean.
BUT - when I am modelling, it is enough (for me) to just have a single class on my diagram, called "Book". I will tag it with a stereotype to remind myself it will need to be coded using the three files described above.
Your mileage may well vary - code generatation etc. My goal is always to keep the diagrams simple, clean, understandable and maintainable.
PhilR - thanks for the point about the name clash! I'd forgotten about Boundary, Entity and Control. I'll check the profile and find out the official stereotypes!