From: MikkelFJ <mikkelfj-anti-spam@...>
Date: 2002-09-20T09:19:38+09:00
Subject: Re: Business Objects


"Yohanes Santoso" <ysantoso@jenny-gnome.dyndns.org> wrote in message
news:874rcly45t.fsf@jenny-gnome.dyndns.org...
> This is Off Topic, but what's a business object? Can someone describe
> it in plain, programmer language?

It's a buzzword.

Well, I'm not sure I fully understand what they are, but it goes like:

Suddenly everthing went from PC desktop spreadsheets to client/server  or
C/S - user (client) talks to database (server) (just like in the early days
of computing).
Then came large coorporate WAN and the Internet with many users talking to
one database.
Enter bottleneck.
New buzzword is 3-tier replacing 2-tier (C/S) and multi-tier solutions. User
talks to middle-tier which in turn talks to one or more databases (or other
limited backend resources).

So what exactly does the middle-tier? It implements the business logic that
user requests such as transferring bankaccounts and booking flight seats.

Distributed object models evolve such as COM and DCOM as well as various
Java techonologies such as remote method calls and enterprise beans.
Enter object into middle-tier. These objects are business objects.
The business object controls what happens between the user and the static
datastorage (the database).
It was then learned that these objects were also bottlenecks hogging
resources such as memory and database connections - besides that they didn't
respond well to crashes and load-balancing.

Enter state-less business objects. These objects don't remember much if
anything but knows a lot about reacting doing things in response to
requests. (Related supporting non-business objects remember expensive
resources - such as pooling database connections - these can then  be
efficiently reused).

Thus a user-request provides a user-id to (say) an available bank account
business object. This object does not represent any particular account at
this point - it was just ready on a random server that happened to not be
too busy. The account object then contacts another business object - an
authentication object - which when happy allows the original account object
to initiate the actual transfer in the database backend. The account object
probably doesn't contact the database directly but graps an available
database connection object from a pool. Before writing to the database the
account object contacts a distributed transaction service - which is not a
business object but an infrastructure service - the transaction object
ensures that no other user (or the same user) is trying to update the same
account in parallel. When this is done, the user is given an all-ok and the
account object forgets everything again - ready for the next request.
Obviously a lot of things can go wrong - handling all these scenarios are
part of the business objects task.

Mikkel