Specifications
for the business objects components
Component
types
We
divide our business components in three
categories:
1)
Entity Components (BO - Business Objects)
This components are representing the
"entity" in our framework. An
entity can be e.g. a student. We don't use
the fine-grained component model. Instead
we use a coarse-grained component
model. This means that a student can be
used as a component but not the student's
name. This components will be represented
by the EntityBeans.
"In general, an entity bean should represent
an independent business object that has
an independent identity and life cycle,
and is referenced by multiple enterprise
beans and/or clients. A dependent object
should not be implemented as an entity bean.
Instead, a dependent object is better implemented
as a Java class (or several classes) and
included as part of the entity bean on which
it depends."
In this case our student component is independent
and our student's name component is dependent
on student.
2)
Association Components (RO - Relationship
Objects)
It is important to define the association
in our components model. An association
component is only apply to the entity component.
In the association we'll only make the primary
key of each associated components persistent.
This components will be represented by the
EntityBeans.
For
example: An assistant can work in many faculties
and a faculty can employ many assistants.
So this is what we called n:m association.
This is the most common association you
can have. For this purpose we have make
a new component called AssistantFaculty,
which has a facultyId and a semesterId as
the associated keys and also a assistantFacultyId
as the primary key. For ease of use we provide
the Assistant component and Faculty component
instead of the ids.
So
this means:
...
Assistant getAssistant...
Faculty getFaculty...
...
instead of
...
String getAssistantId
String getFacultyId
...
It
is afterall easier to have an access to
the object directly instead of doing a "finder
method" in the home interface first.
3)
Workflow - Helper Components (WO - Workflow
Objects)
The Workflow - Helper components (we use
the term helper and workflow for the same
thing) are used to model the process available
in the business objects (also called as
"business processes"). This components
will be represented by the SessionBeans.
For
example: A student can apply for a login.
This process "apply login for student"
will be implemented as a helper component.
Within this component you can access to
one or more entity components.StudentHelper
component is the helper/workflow component
for the Student entity component.
Figure
1 shows us how to use these three types
of components all together. Never access
the BOs and ROs directly from the client!
You should only access the WOs from the
client. This makes it easier and faster
to modify and customize the "workflow"
of the whole system.
Figure
1: Components in OpenUSS
Component
names
Please
follow these rules for naming the EJBs:
BO
Components
-
Interface XXX for the business object
entity
- Interface
XXXObject for the EJBObject interface
- Interface
XXXHome for the EJBHome interface
- Class
XXXBean for the implementation of EntityBean
- Class
XXXPK for the implementation of PrimaryKey
for the EntityBean
RO
Components
- Using
a compound name between the entity components.
For example: The AssistantFaculty component
shows us the association beetwen Assistant
component and the Faculty component.
WO
Components
- Interface
XXXHelper for the business object helper/workflow
- Interface
XXXHelperObject for the EJBObject interface
- Interface
XXXHelperHome for the EJBHome interface
- Class
XXXHelperBean for the implementation of
SessionBean
Articles
and Literatures
|