Greg, from your description and drawing, it appears that BobBean does know
about JimBean because BobBean has the API called getJim, and JimBean knows
about BobBean because it has an API getBob. Thus your statement regarding
encapsulation and BobBean not knowing about JimBean and JimBean not knowing
about BobBean, might not be correct.
With the above said, it appears that while BobBean does not know about the
relationship of the value in relation to JimBean, there exists a
Constraint(BobBean bob, JimBean jim) such that bob.getValue() >
jim.getValue(). With this in mind, you can implement the following:
public class ValueConstraint {
public static void checkConstraint(BobEntity bob, JimEntity jim) throws
ValueConstraintException {
if (bob.getValue() <= jim.getValue())
throw new ValueConstraintException("Constraint violated");
}
}
You would have the following definitions in BobEntity (remote):
public Long getValue();
public void setValue(Long value);
Now functions in BobBean (implementation bean) would like this (CMP2.0):
public void abstract setInternalValue(Long value);
public Long abstract getInternalValue();
public Long getValue() {
return getInternalValue();
}
public void setValue(Long value) throws ValueConstraintException {
setInternalValue(value);
ValueConstraint.checkConstraint((BobEntity) context.getEJBObject(),
getJim());
}
You would have similar code in JimBean, except referencing BobBean.
Later, the ValueConstraint can be augmented to make all kind of calls out to
the rule engine, and expose the business constraints to the client. This
way, they are not coded into your application. However, this demonstrates
the example.
There have been some efforts to allow you to insert a proxy between vendor's
EJBObject implementation, and your bean. Once you can do that, you can call
a pre and post condition functions before and after each method. You could
also devise a mechanism which allows you to "register" call back
methods/objects which could be executed before and after a particular
function call. Thus such a constraint, could be registered at a later time
without having to make any code changes.
We are doing something similar to this in our application development today.
I would like to hear any comments regarding this solution.
-AP_
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Greg Lowe
Sent: Wednesday, August 01, 2001 5:43 PM
To: [EMAIL PROTECTED]
Subject: Modelling Relationship Constraints in EJB
Hello all,
I have been researching relationships between entity beans. Especially into
the area of applying constraints between properties on different beans.
I found the container managed relationships in the EJB2.0 spec interesting.
But I am not convinced that they will solve some important problems.
+ Lets look at this hypothetical example
----------- Bob-Jim (1..1) ------------
|BobBean | <----------------------------------> | JimBean |
| getJim()| constraint: | getBob()|
| +value | bob.value > jim.value | +value |
----------- ------------
There is a Bean called Bob and a bean called Jim. both have a
single property called value.
There is a bi-directional, one to one relationship between bob beans and jim
beans.
+ How can we make sure the constraint will always hold?
If the client modifies jim.value then we must validate it against bob.value,
and vise-versa.
+ How should we implement the constraint?
>From an encapsulation point of view The BobBean should not know about the
JimBean (vise versa). Therefore relationship should be modelled as a
seperate object which uses the BobBean and the JimBean.
+ How does the relationship object intercept the calls to set property
methods?
Use the Observable pattern. If we look at the JavaBeans API(not EJB) there
is some interesting functionality defined. A bean may add a
VetoableChangeListener. Using this change listener you can add Vetoable
change listeners to specific properties. This is exactly the behaviour we
require.
A VetoableChangeListener allows a property change event to intercepted. And
if the change causes an invalid state the change can be cancelled.
+ How can we implement this Pattern inside a Container?
Is this pattern something that we must implement from scratch? Or are there
features of the container which we can use?
Now this is the tough bit, which I am working on at the moment.
Any ideas would be appreciated
Greg.
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
