Which Layer to use

Hi,

Let's assume that there is a database with a single Customer
Table. Multiple users will access this database via a WebService.



I have


Presentation Layer

------------ ---------

Business Logic Layer

------------ --------- --

Web Service

------------ --------- --

Data Access Layer

------------ --------- -

Database



Whenever a record is opened by a users, their name and a timestamp is
stored in the table. Once a record is opened, users have a choice to
take ownership of that record ( a record can only have one owner).


If the user decides to take ownership of the record, the program will
have to check if the selected record already has an owner. If it
already has an owner (the owner may have been assigned while one user
was browsing the record), then the system should not allow anyone else
to take ownership of the record in question.


Normally I would put this logic in the Business Layer (which is in the
client currently), but then I have to make an extra call(s) to the
webservice, and introduce more roundtrips. Another option would be to
put this logic in the web service itself, or introduce another layer
(which I do not prefer) in the server to implement the business
rules.

Another alternative would be to put this logic in the data access
layer itself ( i am more inclined towards this);


Can anybody please advise me on what alternative to take.

thanks,

Arun

arun <arunairs@gmail.com> writes:
> Let's assume that there is a database with a single Customer
> Table. Multiple users will access this database via a WebService.
>
> I have
>
> Presentation Layer
>
> Business Logic Layer
>
> Web Service
>
> Data Access Layer
>
> Database
>
> Whenever a record is opened by a users, their name and a timestamp
> is stored in the table. Once a record is opened, users have a choice
> to take ownership of that record ( a record can only have one
> owner).
>
> If the user decides to take ownership of the record, the program
> will have to check if the selected record already has an owner. If
> it already has an owner (the owner may have been assigned while one
> user was browsing the record), then the system should not allow
> anyone else to take ownership of the record in question.
>
> Normally I would put this logic in the Business Layer (which is in
> the client currently), but then I have to make an extra call(s) to
> the webservice, and introduce more roundtrips. Another option would
> be to put this logic in the web service itself, or introduce another
> layer (which I do not prefer) in the server to implement the
> business rules.

Based on this description, it sounds like the interface to your
service (whether implemented as a Web Service or through some superior
alternative) needs to include:

Customer getCustomer(<search-criteria>)
Token takeOwnership(Customer customer)

(The Token might be a boolean or a copy of the updated customer object
and may be null or false if the ownership request failed.
Alternatively, an exception mechanism might be used.)

The implementation of this interface can be in either the service
layer or another layer on the server side. If you control the
client-side business logic layer, you could put this logic in the
service proxy.

> Another alternative would be to put this logic in the data access
> layer itself ( i am more inclined towards this);

I think you might be focusing too much on the layers, which are
merely conceptual, and not enough on the services you need to
provide. If the layering helps you decompose the problem, great. If,
as all too often happens, the layers become reified as actual software
artifacts, they can overly constrain development without providing
corresponding value.

Regards,

Patrick

------------------------------------------------------------------------
S P Engineering, Inc. | Large scale, mission-critical, distributed OO
| systems design and implementation.
pjm@spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)

Responding to Arun...

> Let's assume that there is a database with a single Customer
> Table. Multiple users will access this database via a WebService.
>
>
>
> I have
>
>
> Presentation Layer
>
> ------------ ---------
>
> Business Logic Layer
>
> ------------ --------- --
>
> Web Service
>
> ------------ --------- --
>
> Data Access Layer
>
> ------------ --------- -
>
> Database

If you are going to use a RAD layered model, I am a bit confused about
the location of the Web Service layer. I would expect web services to be
associated with the Presentation layer. Are you suggesting that the user
has a thick client where presentation and business live and that client
talks to the DB via the Data Access layer through web services?

If so, one could argue that it really goes between Data Access and DB
since the Data Access is really a logical entity that exists to convert
Business Layer representation (e.g., a User object) into Database
representation (e.g., Tables). IOW, if the client is thick, then I would
expect that <problem-specific> conversion to be done on the client side.

That dichotomy segues to my main point. Web Services is really an
implementation issue for supporting infrastructure. The other layers
represent an organization of the logical design of the application,
which would be the same if the app used a browser, GUI, or smoke
signals. So I am not sure Web Services is an appropriate layer at all.

[In a non-RAD application one might well have a Web Services subsystem,
but it would be a peer of a Data Access subsystem. But non-RAD
applications are designed in a fundamentally different way from a
systems engineering perspective so one doesn't use a RAD layered model
at all.]

> Whenever a record is opened by a users, their name and a timestamp is
> stored in the table. Once a record is opened, users have a choice to
> take ownership of that record ( a record can only have one owner).
>
>
> If the user decides to take ownership of the record, the program will
> have to check if the selected record already has an owner. If it
> already has an owner (the owner may have been assigned while one user
> was browsing the record), then the system should not allow anyone else
> to take ownership of the record in question.

If it were simply an issue of one user at a time having write access,
this would be a standard problem for DB mechanisms like two-phase
commit. That would be primarily a Database layer issue, though the Data
Access layer might need some notion of related issues like opening and
closing DB transactions.

In your case, though, the ownership is persistent across DB accesses and
transactions. In addition, the rules defining it are business policies
that exist in the problem space (a single owner always) and need to be
captured in the application solution. So the Business Layer needs to
deal with those rules and keep track of the problem space notion of
ownership. The ownership is recorded in the DB normally, but that is
quite mechanical.

So when a user wants to take ownership the Business Layer has a specific
sequence of steps:

(1) Check if the record is owned.
(2) If not, assign the owner
else, inform the user it cannot be owned

Now executing that business logic may require specific DB accessing
techniques, such as locking the record containing the ownership field
for (1) until (2) is resolved. That is the kind of processing (e.g.,
opening and closing update transactions) the Data Access Layer
understands because it exists to access the DB.

So the solution is actually spread across two layers; one just separates
the concerns by having the Business Layer deal with the business logic
while the Data Access Layer deals with the DB access logic.



--
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH