Originally posted by Saha Kumar:
Hello All,
I think each entity EJB should only be accessed within one component. So no two UML 2.0 components access the same entity bean. This is what I am designing by.
Any thoughts?
-Saha
Hi Saha,
Well, first, to answer your question, it is not considered a poor design if you access one component (entity bean for example) by two diferent other components (an session bean for example).
Anyway, there are a lot of considerations to do, in order to decide the component dependency at you component diagram. And, talking about your second post, is not considered wrong access one component by only one another component. But do not think that is a kind of rule. Think that is a kind of rule or good technique, is considered wrong.
To effectively create a good design for an application using an component architecture,
you should consider a lot of things before agree with some rule. You should group your pieces of functionalities or use cases into a single main boundarie for the system.
I think that a more detailed explanation are needed ...
, so, let's go ...
Forget UML and J2EE for a moment. Let's talk about how related and coupled are your application services. When you start an project design, you must define wich important use cases are present in the context of your project.
There are two kinds of use cases: Business Uses Cases and Regular Use Cases.
The business use case represents the major vision about the project to ensure what the system must do and why. Threre is nothing technical in business use cases.
"The main purpose of the Business Case is to develop an economic plan for realizing the project Vision. Once developed, the Business Case is used to make an accurate assessment of the return on investment (ROI) provided by the project. It provides the justification for the project and establishes its economic constraints. It provides information to the economic decision makers on the project's worth, and is used to determine whether the project should move ahead." (RUP 2003)
The regular use cases or just 'use cases', are the realization of the business use cases, and they express how the system should perform the user needs given a specific scenario and an actor. Normally, use cases are written peer functionality and they represents the requirements for the application.
Let's go for an example:
----------------- [
Contact Record Application] -----------------
[Business Use Case]: "The record contact application should record all the contact's of an specific user. The person should be able to create an new contact, update an existent, and delete one or more contacts recorded. Moreover, the user also should be able to search recorded contacts given your name and/or id."
You could see in this simple explanation from the user vision about what it wants that you create. There is nothing technical or specific in this explanation, and we can easily identify the application requirements in the text, wich are:
1) create new user
2) update user
3) delete user
4) search user by name or id
When you broke down an business use case to smallers and well defined pieces of functionalities, you are creating the application use cases. Apart from those use cases, you start to define, in terms of details, what and how, each use case must do, from the users perpective. At extremme programming (XP, Kent Beck) we can also call these of user stories.
What the
SCEA assignment gives to you, is those use cases already defined and discussed. As an architect, you should be able to do the next follow lines in order to create an design for an paiyng customer, or, for the SCEA certification. So, pay attemption.
Let's go forward to the application design. The second step is define which are your entities at you application inception view. We can define that this simpliest application has one single entity, that is, the contact. So, let's consider that our contact entity will be represented by one Entity Bean. So, we have created our first application component. Let's call it of 'ContactBean'.
Now, we've seen that our application has four use cases. The first three use cases (create, update and delete contacts) can be grouped into a single object the represents all the related operations. You should agree with the idea of, the create, update and delete actions, represents the requirement of maintain the contact. So let's consider and define, our first boundarie for the application: The maintenance boundarie. This boundarie will group the follwing use cases: create contact, update contact and delete contact.
The last use case talks about an search feature, to promove the seek ability from the system, in order to make the user able to find recorded contacts. If you think for a while, you could see (and agree) that searching is not related with maintenance, and, should be considered out of the maintenance boundarie.
We can create an specific boundarie for this requirement (or group of related requirements), called searching boundarie. So, for now, we have two main boundaries:
- maintenance boundarie
- searching boundarie
That's it. Now that we have all the boundaries defined, we can create an ideal architecture that meet the requirements needs. A good technique well documented from Sun for this, is to create an facade for each boundarie of the system. So, talking about components (and talking about j2ee), we'll have two more components:
- an stateless session bean called MaintenanceFacadeBean
- an stateless session bean called SearchingFacadeBean
Both facades will access a common source of data, which is, our ContactBean.
For a good design, we can define to create local interfaces for the ContactBean, and expose ours facades by remote interfaces. Both facades will maintain an local reference for the ContactBean.
---
So Saha (and JavaRanch), if you could see in this explanation, i've tried to show you and for the others ranchers interessed in the architect certification, that is not a rule that an component is accessed by only one another component. IT DEPENDS OF YOUR DESIGN AND INCEPTION PHASES.
So, just to finish, let's go to learn something useful from this post:
- Facades should be created for each boundarie or view, not by each use case
- Components could be accessed by multiple others components
- Talking about EJB's, facades ALWAYS are remote components, never local
- Take care to do not create too many facades that could minimize the application granularity.
I really want that i could have helped you, JavaRanch!
