RE: reference to the database

On Thu, 2004-03-18 at 04:22, Wong Liong Hung wrote:
> > Right. But why not make doSomething a method in an ozone object? Since
> > it is preferred to have all business logic in objects that are used on a
> > client, that may be a better option. That business action either fails
> > (rolls back) or completes successfully (commits). That's all a client
> > shoud be concerned with.
> >
> > > 2. Without using external transaction, how can I rollback the
> > change made to
> > > the a object if c.initialize() failed?
> >
> > You cannot. But again, that logic should be 'encoded' in business
> > objects, and business objects and ozone objects make a fine combination.
> 
> doSomething() is a RMI method called from a RMI client. I don't want to make
> the class which implementing doSomething()an ozone object as I don't need to
> persist the object.
> 
> Also, the class which implementing doSomething() already extends
> UnicastRemoteObject and implements an interface of RemoteObject. And, I use
> only in server side only (by using LocalDatabase); In this case, ozone is
> not required in client side.
> 
> What do you mean by business object? What is the different between business
> object and ozone object? For me an ozone object extends OzoneObject and
> implements interface of OzoneRemote.

For me a business object is an object (either just java or ozone) that
encapsulates business logic. For a bank for instance 

account.transfer(1000, targetAccount);

is business action, which fails (not enough money on account, target
account does not exist) or completes. There is no in between, i.e. there
is no way money is taken from account but not put on targetAccount.

If you translate this into an ozone object, you make transfer() an
update method, which causes the whole transaction to either abort
through an exception or 'commit'. If you were to use client side
software that would have to:
try {
   // start transaction
   account.withdraw(1000);
   targetAccount.deposit(1000);
   // commit transaction
} finally {
   // rollback transaction
}
This is IMHO a sign of bad separation of concerns, which might lead to
code replication, security problems, performance issues and inconsistent
data.

Cheers,
Leo




-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click