At 10:46 AM 4/11/00 +0200, you wrote:
> > Are we advocating that the business interface, that is used for local
> > objects, have RemoteExceptions listed for all methods. It will have to
> if it
> > is also to be used for the RemoteInterface. This seems strange considering
> > that we are now dealing with local state/details objects are implying that
> > they are remote. This really is going to cause confusion for the client
> side
> > developer. Maybe I am reading this wrong. Maybe what people are really
> > saying is that the bean and state objects are implementing the common
> > business interface.
>
>I believe you hear people saying different things. Toms solution is
>having bean and state objects implementing the same interface. I think
>it is probably a very good solution when you are looking at the need for
>rapid change from EJB to non-EJB that they obviously are facing. (Did I
>get you right Tom?)
Some thoughts for your consideration...
In the GemStone iGrocer, aka FoodSmart, example J2EE app, it is our entity
beans and domain objects that implement the same business interface. Our
state objects generally implement a subset of the business interface
(getters and setters, a few other things), but they generally aren't
extremely behaviorful. I suppose one rationale for that is that we expect
the bulk of the complex business logic to run in the application
server. We do have a few cases where a state holder has more complex behavior.
When we do use entity beans, they tend to just wrap a graph of domain
objects anyway (domain objects are implemented as regular old Java
classes). In most cases, our entity bean classes don't encode a lot of
state or behavior because they end up just delegating to their underlying
domain object(s). We made a conscious decision to represent our domain
model as plain old Java objects - instead of entity beans - since we can
wrap a domain object with an entity bean if and when we need an entity bean.
>However, the discussion started out when Laird came up with his
>proposition of how to work more abstractly with the EJB implementation.
>To me the most interesting use for that is to wrap entity beans, as I
>for one am not too sure they suit my needs in every situation. The good
>part for me would be to have a clean interface with an implementation
>layer that either redirects calls to entity beans or works with an
>object database. In the end it will help me to keep my design between
>different system versions.
Have a look at the reified layer called "DomainLayer" (and its
implementation DomainLayerImpl) in the iGrocer/FoodSmart application. I
think this is similar to the idea to which you're referring.
The domain layer permits us to hide from (session bean) clients (a) whether
a given domain abstraction is represented as an entity bean or a plain old
java object and (b) where and how objects or their state is persisted. How
domain objects are represented to clients (encapsulated in an entity bean
or not) is the responsibility of a policy called the "encapsulation
policy", to which the domain layer indirects. How and where domain objects
are persisted is the responsibility of the persistence layer, to which the
encapsulation policies indirect; it can deal with object or relational
databases.
Basically, our session beans have no idea where or how objects are
persisted, and don't care whether they are dealing with an entity bean or a
plain java domain object.
By changing a few properties in a property file, it's possible to switch
iGrocer from using OODB to RDB for persistence, or from using entity beans
to not using entity beans, etc.
Note that iGrocer has this flexibility specifically because we want an easy
way to study the relative merits and performance of J2EE architectural
variants (i.e., it wouldn't necessarily be part of a production system).
If you're interested in looking at our approach, the source code for
iGrocer is available for download at
http://www.gemstone.com/javasuccess/. Let us know what you think; we're
certainly open to new ideas.
>Whichever way you wrap things you will end up with an interface that
>either throws RemoteException or catches it and throws a local
>exception, which could be a better thing to do. Some people would catch
>it and not do anything, but I normally try to be a nice guy. :-)
>
> > One thing to consider before moving totally away from entity beans and to
> > session beans with OO databases. Entity beans should not be just data
> > holders they should do some useful work on their internal state and help
> > reduce the amount of the data sent across the network.
>
>No doubt about it, I agree totally with your argument in the case where
>modification can be kept centrally. I'm just concerned about situations
>where you need different levels of state. The travel industry is a good
>example where the standardized EJB solution probably will falter.
I like the idea of wrapping domain objects in entity beans (if you're going
to use entity beans...). In other words, locate the state and "useful"
behavior in a domain object and then wrap the domain object with an entity
bean when needed, allowing the entity bean to delegate to its underlying
domain object.
With respect to different levels of state, if I understand what you're
referring to, we struggled with that issue a bit, too. Ultimately, we
tried a pattern called "Three Levels Of Domain Object
Interface". Essentially, this means that (where it's warranted) we define
"identity", "state" and "behavior" interfaces for a given domain
abstraction. This approach has its good and bad points, but generally
works well.
The identity interface represents the identity of the domain object,
declaring operations for getting the domain object's keys or unique ID,
plus a method to represent the domain object as a formatted String. It
would be typical to use this "breadth" of interface if you just needed to
display the object in a pick list.
The state interface represents the state of the domain object, declaring
operations for accessing and mutating the domain object's state. This is
the breadth of interface that would be used when you need to actually edit
the object.
The behavior interface represents the behavior of the domain object,
declaring operations modeling meaningful behaviors from the problem
domain. Here's where the "complex" behavior comes in.
There's an inheritance relationship between these interfaces. Using the
"Food" abstraction from the iGrocer app as an example (indented means
"extends"):
FoodIdentity
FoodState
FoodBehavior
With respect to implementations of these interfaces... The Food domain
class implements FoodBehavior. The Food entity bean remote interface
extends FoodBehavior. So, FoodBehavior is the "business interface" and
FoodIdentity and FoodState are subsets of that business interface.
Again, only where it's warranted, we also have different granularities of
state objects; we call them holders. For example, we might have the
following little hierarchy of Food state objects:
FoodIdentityHolder (implements FoodIdentity)
FoodStateHolder (implements FoodState)
When we just need to display a Food in a list, we can build a simple
FoodIdentityHolder (light-weight, fast to create). For use cases that
involve updating a Food, we create a FoodStateHolder (heavier-weight,
slower to create). In a lot of cases, creating a state holder actually
means you create a little graph of state holders (a root object and its
contained objects).
This gives us some control over the level of state that is distributed to
clients (the goal being to minimize the amount of state being distributed
to only what a client needs).
Best Regards,
Dave Muirhead
GemStone A3T Team
>Regards
>
>/Marcus
>
>Marcus Ahnve
>Sun Java Center
>Sweden
>
>===========================================================================
>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".
