In some organization I worked for web applications are developed basing all the business logic in Database stored procedures. For example, use html for view and servlet as controllers to divert the client request to appropriate Database stored procedures.

What are the advantages and disadvantages of this kind of designs? In my opinion if the business logic highly depends on the database than better follow this kind of design!!!!!

In theory, the pros and cons are as so: 

Pros:


One place to contain all of the business logic
Possibly faster applications because multiple SQL queries and such can be performed in one "round trip" to the database
Trivial to make use of the stored procedures from multiple applications


Cons: 


A DBA will be required for performance tuning
All developers will have to be very well versed in your particular SQL dialect(T-SQL, Pl/SQL, etc)
SQL code isn't as expressive and thus harder to write when covering higher level concepts that aren't really related to data
A lot more unnecessary load on the database


Now, practically, only a fool would have all business logic in the database. 


Very few developers will be able to create a consistent stored procedure interface that works easily across applications. Usually this is because certain assumptions are made of that calling application 
Same goes for documenting all of those stored procedures
Database servers are generally bottlenecked enough as it is. Putting the unnecessary load on them just further narrows this bottleneck. Intricate load balancing and beefy hardware will be required for anything with a decent amount of traffic
SQL is just barely a programming language. I once had the pleasure of maintaining a scripting engine written as a T-SQL stored procedure. It was slow, nearly impossible to understand, and took days to implement what would have been a trivial extension in most languages
What happens when you have a client that needs their database to run a different SQL server? You'll basically have to start from scratch -- You're very tied to your database. Same goes for when Microsoft decides to deprecate a few functions you use a couple hundred times across your stored procedures
Source control is extremely difficult to do properly with stored procedures, more so when you have a lot of them
Databases are hard to keep in sync. What about when you have a conflict of some sort between 2 developers that are working in the database at the same time? They'll be overwriting each others code not really aware of it, depending on your "development database" setup
The tools are definitely less easy to work with, no matter which database engine you use. 


So, to objectively answer the question. In most cases, stored procedures are only needed in some cases. For instance, if you have a report to generate where you need to do a lot of conditional processing across a couple of big tables, you wouldn't want your application to be making a couple hundred SQL queries to the database. You'd want to make a stored procedure so you didn't have the network lag overhead. And, you'll usually only want to make stored procedures otherwise for when clients want to run a custom-ish query across your database. Stored procedures and views can make this easily possible without your clients being a database whiz. 
