Where put Business Logic? on client or server part

[Ales Moukhine]

Hi All!

I decided to use 3-tier architecture, and want to put my business logic on the server side.
But in assignment they said "You must do ... Network server functionality for the database system"


Regards
Ales'

[B Chen]

The network server has nothing to do with business-logic. It just means your database needs to have the ability to be accessible over the network.
You can put the business-logic on either client-side or server-side. Each has its own pros and cons.

[Ales Moukhine]

Originally posted by B Chen:
The network server has nothing to do with business-logic. It just means your database needs to have the ability to be accessible over the network.
You can put the business-logic on either client-side or server-side. Each has its own pros and cons.

Thanx for response,
From this point of view there is no sense put business at server side, it's only the complication.

Are there someone on this forum, who put bisiness on the server side?

Regards
Ales'

[ July 06, 2006: Message edited by: Ales Moukhine ]
[ July 06, 2006: Message edited by: Ales Moukhine ]

[Andrew Monkhouse]

Hi Ales'

Got a few days? Take a look at the topic named "Should lock methods be callable by the client" - it has something like 140 comments on whether logic should be server side or client side.

Regards, Andrew

[Jeroen T Wenting]

There's a choice of options.
If you choose a traditional client/server model you'll have some on either end.
You can also create a thin client application and have everything on the server.
Or you can create a fat client and have nothing on the server.

I decided on the latter approach, my server is aware only of having records to read and write and those records consist of fields of specific data types.
I could plus in another record format and it'd write and read that, it wouldn't care at all.

My network layer similarly knows only that it's given commands and data to send between clients and servers based on the DB interface.
It knows nothing of what those things actually mean, it's only a transport layer.

Everything thus happens inside the client.

[Mihai Radulescu]

Hi Jeroen,

That mean that the "48H" roule is on you on the client ?

[Jeroen T Wenting]

My assignment has no mention of such rules.
But if it had they would be enforced on the client, yes.

[Eva Van Shtock]

It is unwise to put the 48 hour rule only on the client.
If someone changed the system clock on a client machine, you can
kiss your business logic goodby!

I put business logic on both client and server.
In addition to 48 hour, checking for valid currency, dates, etc.

I see no harm in replicating it on the client as I need to guarantee
correctness and in order to do that you have to put it on server.
putting it on client gives more user-friendly approach. For example,
how can I color unbookable rooms?

Eva

[Jeroen T Wenting]

In that case I'd probably have decided on a completely different architecture using a thin client and a fat server rather than the reverse.

[Mihai Radulescu]

Hi ,people

I choose to "have" the 48H roule on te server(an to configuer there). For consitence reasons (the server set the rules, the cliens follw them).

Also if the cilents are using different times(are in different time zones) there will be one single time for all of them the server time.

Eva, good tip the one with the "changed the system clock" an other argument for server side.
Eva, what you mean by

I put business logic on both client and server.

If you have two rules need a way to bring them together and to synchronize them(remeber the "changed the system clock" storry).
In my case I have the rule on server I use it on the client, but is the same rule in both cases. I use the same mechanism when I render the table (color unbookable rooms).

Regards M.
[ July 07, 2006: Message edited by: Mihai Radulescu ]

[Edwin Dalorzo]

From my point of view the server side app should know nothing of the business rules of the client application.

In my approach the server side application just serves data. That is all it does. it is the client the responsible for asking just the data it really needs.

However, as long as the business logic is not combined in the database server application, some might say that it could be a good idea to create some additional server side objects that perform that business logic on behalf of the client application, possibly faster, because this business logic may use local objects instead of remote ones.

I consider this approach dangerous, notwithstanding. Because it does no look like something I would do in real life applications.

Because of the following reasons:

1. If this server side objects are running in the same JVM of the database server. Then your database server is contaminated with business logic that belongs to the client. The execution of these objects will consume the valuable recourses of the database server. This database server may be serving other applications, for instance a Report Application which extracts marketing information from the database. If all the applications locate their business logic in the server side objects running in the database server, the design of the application is compromised.

2. For the server side objects to be justified running in the application server, they should not use remoting. What is the purpose of having a server side object, located in the same JVM of the database server and not taking advantage of direct method execution? Logically, the idea of having part of the business logic in the server side is to overcome the disadvantages of remote execution. This may complicate the design a bit more in order to consume local objects instead of remote ones and it requires an effort not to contaminate the database server with dependencies to the business logic objects.

3. Finally, it is possible to create a three-tier application (not just a two-tier-three-layer application) if we separate the server side objects with the business logic in another application server. Then the client communicates with the applications server, and this one communicates with the database server. But this would complicate the design a lot, and the Sun specification says that a simpler design is better.

Of course, this is just my point of view, and I am just starting with the application. I could change my mind after a few weeks of trying to write a decent piece of software.

[Mihai Radulescu]

Hi Guys


I think I have a small problem with some terms, so I'll explain what my understand by :

business layer - defines what the client can do with out application.
transport layer - only transport some information from A to B.
network server - uses the transport layer to make some features "network available".
data server - provides access to the database resources.

If I put all together I have :
Client (UI) -> business layer -> transport layer -> network server -> business layer (sever side) - > data server -> data raw layer -> database.
My rule(48H or better time rule) is on my business server side layer (what a incredible long term).


From this point of view
Edwin,

on 1

will consume the valuable recourses of the database server.

the servers are most of the times powerful machines, more powerful than a client, so i prefer to load the powerful one.

This database server may be serving other applications, for instance a Report Application which extracts marketing information from the database.

right, for this are the clients (now I have only two a simple and an advance). And strict for a "Report Application" - you can get all the records
or you can get only the available records (only the matches fro your time rule).


on 2.

For the server side objects to be justified running in the application server, they should not use remoting

correct, for "remoting" I use the transport layer.


on 3.

Finally, it is possible to create a three-tier application

I have a 3 tier, and this does not make the things more complicated.



What you guys think about it ?

Regards M
[ July 09, 2006: Message edited by: Mihai Radulescu ]

[Ales Moukhine]

Originally posted by Mihai Radulescu:

business layer - defines what the client can do with out application.
transport layer - only transport some information from A to B.
network server - uses the transport layer to make some features "network available".
data server - provides access to the database resources.

If I put all together I have :
Client (UI) -> business layer -> transport layer -> network server -> business layer (sever side) - > data server -> data raw layer -> database.
[ July 09, 2006: Message edited by: Mihai Radulescu ]

Hi Mihai,


I don't think that dividing business layer into 2 part (server and client) is a good idea.

As it wrote in assignemt, you must provide remote interface for DB (after reading a few topics on this forum, I understand that in this way), and if you decided put business on the server side you also must provide remote interface for it.

And in this case connecting between business and DB remote or local?

I think it's better to have next model : UI(client which call find() and book()) ---> Business(on server with locking and etc.) -> DB(on server)
(---> means remote, -> means local)

But is it good for that assignment?

May be esiest way is enough:
UI(client which call find() and book()) -> Business(on CLIENT-SIDE with locking and etc.) ---> DB(on server)


Still there is no 100% sure what is good in this situation.

Regards.
Ales'
[ July 10, 2006: Message edited by: Ales Moukhine ]

[Mihai Radulescu]

Hi, Ales

Why you think

As it wrote in assignemt, you must provide remote interface for DB

Do you have this issue in your specs ? Or can you post the pice of specs which make you take this decision ?

In my specifiecation I have in my something like :

There are three key parts: the server-side data management system, the client-side GUI, and the network connection between the two.

How you intepret this text ?

Regards M

[Ales Moukhine]

Originally posted by Mihai Radulescu:
Hi, Ales

Why you think


How you intepret this text ?

Regards M

Hi Mihai,

In section "what you must do" i have

- A client program with a graphical user interface that connects to the database
- A data access system that provides record locking and a flexible search mechanism
- Network server functionality for the database system

I think point 3 tell this.

And this :
"Your server must be capable of handling multiple concurrent requests, and as part of this capability, must provide locking functionality as specified in the interface provided above."


Regards, Ales'

[Mihai Radulescu]

Hi, Ales


I also have this line in my specs

Network server functionality for the database system

but this means that you can access your database from other machines. But this does not mean that you must use exact the same interface and that you must use remote access (you can still use sockets).
I chose to provide the same functionality but in a friendly form (I hide the lock and release methods). You have the same architecture the only difference is that you "show" the lock/release method on the client side.

me : UI -> Client -> server -> Friendly -> Data.
you : UI -> Client -> server -> Data

Now the question is : where you put your 48H rule and why ?


Regads M.

[Ales Moukhine]

Hi,
I think i understand your point of view

Originally posted by Mihai Radulescu:

Now the question is : where you put your 48H rule and why ?

I think this rule must be placed inthe server-side, because it's reduce network trafic.
But i don't think it's a good idea to put it into find method, maybe better would be find method wraping with this rule =>

  
public int[] findWith48hRule(String[] criteria){
 call_find_method_from_DB_Interface();
 filtering_the_result_with_48h_rule();
 return filtering_result[];
}
  

But it means that, we put business rule in data-layer

What do you think?

Regards Ales'

[Mihai Radulescu]

Hi, Ales

I think this rule must be placed inthe server-side

Welcome to the club, the network trafic is a good argument.

But i don't think it's a good idea to put it into find method.

True, you can have an other method(s), I have methods pairs now (getAllRecords - getAllAvailableRecords, serachRecords - searchAllAviableRecords).
I propose you an other method name for your "findWith48hRule(..." (something more general) ,the 48H rule can change in the future.

And now regarding :

But it means that, we put business rule in data-layer

I am not an expert I this terms (like business rule or data-layer) but I can make some presumption.

The business rule is the way how you use your application - in your case book(and maybe release), search, getAll, ....
The data layer is something else - is how your application manage/manipulate the information and most of the time is on the end tier.
Between the data - layer and the client is the middle tier and here you can put the business rule (and the time limit rule).

What you understand by business rule ?

Regads M.

[Ales Moukhine]

Originally posted by Mihai Radulescu:

I propose you an other method name for your "findWith48hRule....

I agry, I named it that only for discussion

Originally posted by Mihai Radulescu:
What you understand by business rule ?

Business process contain one or more business rules,
By business rule I understand how I must do some part of bisness process (business transaction), but not talking about how I get data or save it. For example (not exactly from assignment), "booking" process :
1. lock entities
2. change and update hotel entity
3. change and update room entity
4. create and insert new record into history
5. change and update client entity
6. send mail to manager
7. unlock entities

where all positions are business rules

Please ask, if it's confuse

Regards
Ales'
[ July 13, 2006: Message edited by: Ales Moukhine ]

[Mihai Radulescu]

Ok, now I think that I get it.