Business Logic - in Middleware or Database?
798 views
Skip to first unread message
John Flack
Oct 12, 2010, 8:52:36 AM10/12/10
to ADF Enterprise Methodology Group
This subject came up in this thread -
http://groups.google.com/group/adf-methodology/browse_thread/thread/6463b0687fabfe8b,
and has a few interesting comments already. But I thought I'd start a
new thread for it, and leave the original thread for introductions.
My two cents -
I love it when a client gives me clear instructions on what they want
done, how they want it to look, and how it should make life easier for
them. I hate it when a client wants to tell me how to do it. That is
what a client is doing when they say "all business logic in the
middleware, none in the database, no PL/SQL". I know that some
clients must be pacified no matter how stupid their requirements,
because the client is important to the business. But I hope I have a
good enough relationship with my clients that I can gently ask,
"Why?" Why is this important to you? What is the business reason
behind this request? What do you hope to accomplish?
Often, there is a sound reason behind the request, but a misconception
that moving business logic to the middleware will accomplish the
goal. For instance, the client may fear that they won't be able to
get the PL/SQL experts they need to maintain the application if most
of the logic is written in PL/SQL. Can we assure them that Oracle
will be supporting PL/SQL for a long time and that PL/SQL skills are
easy to find?
Maybe they don't like Oracle's licensing and support costs, and want
to be able to easily move to a different database? Can't argue with
that, but maybe we can encapsulate some of the database logic so it is
easy to rewrite in a different database's procedural language. Or
move them to Enterprise DB, which has significant Oracle PL/SQL
compatibility.
Some "experts" will tell clients that business logic in the database
performs badly. Or they may have had a disaster application with a
lot of database logic that was written badly. Can we do a test case
to prove what performs the best?
http://groups.google.com/group/adf-methodology/browse_thread/thread/6463b0687fabfe8b,
and has a few interesting comments already. But I thought I'd start a
new thread for it, and leave the original thread for introductions.
My two cents -
I love it when a client gives me clear instructions on what they want
done, how they want it to look, and how it should make life easier for
them. I hate it when a client wants to tell me how to do it. That is
what a client is doing when they say "all business logic in the
middleware, none in the database, no PL/SQL". I know that some
clients must be pacified no matter how stupid their requirements,
because the client is important to the business. But I hope I have a
good enough relationship with my clients that I can gently ask,
"Why?" Why is this important to you? What is the business reason
behind this request? What do you hope to accomplish?
Often, there is a sound reason behind the request, but a misconception
that moving business logic to the middleware will accomplish the
goal. For instance, the client may fear that they won't be able to
get the PL/SQL experts they need to maintain the application if most
of the logic is written in PL/SQL. Can we assure them that Oracle
will be supporting PL/SQL for a long time and that PL/SQL skills are
easy to find?
Maybe they don't like Oracle's licensing and support costs, and want
to be able to easily move to a different database? Can't argue with
that, but maybe we can encapsulate some of the database logic so it is
easy to rewrite in a different database's procedural language. Or
move them to Enterprise DB, which has significant Oracle PL/SQL
compatibility.
Some "experts" will tell clients that business logic in the database
performs badly. Or they may have had a disaster application with a
lot of database logic that was written badly. Can we do a test case
to prove what performs the best?
John Stegeman
Oct 12, 2010, 12:05:44 PM10/12/10
to ADF Enterprise Methodology Group
John,
Well said.
If a client ever told me "the business logic must be done in
<fill_in_the_blank_here>," my first, second, third, and fourth
questions would be, "Why?"
Any of the following answers would be dismissed out-of-hand:
1). The "other choice" has poor performance (usually, this is the
"Java guys" dinging the database).
2). We want to be database independent. Unless you're developing a
commercial package, this is usually something that everyone thinks
they want but no-one actually needs. As you rightly point out,
database independence is not in-and-of-itself a reason to force
business logic into the middle tier.
3). "Because I said so."
Any of these reasons would certainly bear further investigation:
1). We have a corporate standard and all of our apps are done that
way. Not that just because "this is how we do it" means "this is
correct," but because if there is a corporate standard, sometimes it's
best to play along, even if it's a suboptimal decision for the case in
hand.
2). We have a rules engine that we use across the business.
3). We have a large base of legacy code that does business logic and
we want to re-use it.
4). We need to integrate with a COTS package, and that's the way they
do it.
Yes, I have my preference where business logic should be, but it can
be either in the DB or in the middle tier so long as it is done
consistently, correctly, and in a way that does not prevent the
application from meeting its performance criteria. However, there is
one thing that I will never compromise on and that is that any
referential integrity and uniqueness *must* be done in the database.
I've seen so many applications attempting to do things like this in
the middle tier and getting it horribly wrong (and it's certainly easy
to do) - especially in a multi-user environment. To be fair, I've seen
people do it horribly wrong in the database as well (ahem
http://forums.oracle.com/forums/thread.jspa?threadID=1556775), but
using declarative RI in the database (meaning PK, UK, FK) is the right
way to go - the database *must* get these right, otherwise you
wouldn't be using that database, would you?
John
Well said.
If a client ever told me "the business logic must be done in
<fill_in_the_blank_here>," my first, second, third, and fourth
questions would be, "Why?"
Any of the following answers would be dismissed out-of-hand:
1). The "other choice" has poor performance (usually, this is the
"Java guys" dinging the database).
2). We want to be database independent. Unless you're developing a
commercial package, this is usually something that everyone thinks
they want but no-one actually needs. As you rightly point out,
database independence is not in-and-of-itself a reason to force
business logic into the middle tier.
3). "Because I said so."
Any of these reasons would certainly bear further investigation:
1). We have a corporate standard and all of our apps are done that
way. Not that just because "this is how we do it" means "this is
correct," but because if there is a corporate standard, sometimes it's
best to play along, even if it's a suboptimal decision for the case in
hand.
2). We have a rules engine that we use across the business.
3). We have a large base of legacy code that does business logic and
we want to re-use it.
4). We need to integrate with a COTS package, and that's the way they
do it.
Yes, I have my preference where business logic should be, but it can
be either in the DB or in the middle tier so long as it is done
consistently, correctly, and in a way that does not prevent the
application from meeting its performance criteria. However, there is
one thing that I will never compromise on and that is that any
referential integrity and uniqueness *must* be done in the database.
I've seen so many applications attempting to do things like this in
the middle tier and getting it horribly wrong (and it's certainly easy
to do) - especially in a multi-user environment. To be fair, I've seen
people do it horribly wrong in the database as well (ahem
http://forums.oracle.com/forums/thread.jspa?threadID=1556775), but
using declarative RI in the database (meaning PK, UK, FK) is the right
way to go - the database *must* get these right, otherwise you
wouldn't be using that database, would you?
John
John Flack
Oct 12, 2010, 12:55:36 PM10/12/10
to ADF Enterprise Methodology Group
Fortunately, most relational databases support the types of business
logic that, I agree with John, MUST be done in the database. That is
- FK, PK, UK. The SQL DDL syntax for these is practically identical
in every database that supports ANSI SQL. Even check constraints are
usually supported. Beyond that, I wish more databases (I'm talking
'bout you, Oracle) would support CREATE ASSERTION. The worst triggers
I ever see are usually attempts to do what an ASSERTION would do
correctly and efficiently.
> people do it horribly wrong in the database as well (ahemhttp://forums.oracle.com/forums/thread.jspa?threadID=1556775), but
logic that, I agree with John, MUST be done in the database. That is
- FK, PK, UK. The SQL DDL syntax for these is practically identical
in every database that supports ANSI SQL. Even check constraints are
usually supported. Beyond that, I wish more databases (I'm talking
'bout you, Oracle) would support CREATE ASSERTION. The worst triggers
I ever see are usually attempts to do what an ASSERTION would do
correctly and efficiently.
Chad Thompson
Oct 12, 2010, 12:52:15 PM10/12/10
to adf-met...@googlegroups.com
This really is probably the 'best' reason (from the viewpoint of a client) for sticking with one approach or the other - particularly if the client does not have a 'mixed' system. (i.e. all Java, a strong background in Forms, etc.)
Even though PL/SQL is not that difficult to learn (or find resources for), introducing PL/SQL (or any new technology for that matter) does involve a level of investment in learning how to develop, deploy, maintain that they might not be familiar with. Introducing a different technology (be it PL/SQL one way or middleware the other) involves a heavy bit of 'sales' work, even for tasks that might be relatively simple.
John Stegeman
Oct 12, 2010, 1:48:49 PM10/12/10
to ADF Enterprise Methodology Group
Chad,
I'll agree with you that "we have lots of skills in technology <x> and
not in technology <y>" as being something to consider when making this
type of a decision. What this means is that "most" or "the typical"
companies (if there is such a thing) implementing ADF systems would
opt for a PL/SQL-based approach. I think that it's still true that the
largest uptake of ADF is in companies that are very Oracle and Oracle
Forms-centric.
I really do think that there is no "right answer" but there are plenty
of wrong reasons for choosing one approach over the other and there
are even more ways to do the right thing in the wrong way.
John
I'll agree with you that "we have lots of skills in technology <x> and
not in technology <y>" as being something to consider when making this
type of a decision. What this means is that "most" or "the typical"
companies (if there is such a thing) implementing ADF systems would
opt for a PL/SQL-based approach. I think that it's still true that the
largest uptake of ADF is in companies that are very Oracle and Oracle
Forms-centric.
I really do think that there is no "right answer" but there are plenty
of wrong reasons for choosing one approach over the other and there
are even more ways to do the right thing in the wrong way.
John
DJCampbell
Oct 26, 2010, 5:05:41 AM10/26/10
to ADF Enterprise Methodology Group
Hi,
First post - just testing the water....
For what it's worth, I would have said that in principle, it's better
that process-control is done in the middleware, but the actual
detailed number crunching can be done wherever you like so long as
it's properly encapsulated, decoupled from and exposed to the process-
control. It would be nice if it were generally done consistently, but
flexibility is important too - horses for courses. Following this
principle, the lower-level components could be replaced, upgraded, re-
sourced without impacting the overall flow/operability. I wouldn't use
any strong words like 'must', but I'd propose that this would be best
practice.
On 12 Oct, 13:52, John Flack <Jo...@smdi.com> wrote:
> This subject came up in this thread -http://groups.google.com/group/adf-methodology/browse_thread/thread/6...,
First post - just testing the water....
For what it's worth, I would have said that in principle, it's better
that process-control is done in the middleware, but the actual
detailed number crunching can be done wherever you like so long as
it's properly encapsulated, decoupled from and exposed to the process-
control. It would be nice if it were generally done consistently, but
flexibility is important too - horses for courses. Following this
principle, the lower-level components could be replaced, upgraded, re-
sourced without impacting the overall flow/operability. I wouldn't use
any strong words like 'must', but I'd propose that this would be best
practice.
On 12 Oct, 13:52, John Flack <Jo...@smdi.com> wrote:
> This subject came up in this thread -http://groups.google.com/group/adf-methodology/browse_thread/thread/6...,
Jang Vijay Singh
Oct 30, 2010, 4:16:22 AM10/30/10
to ADF Enterprise Methodology Group
Just my few pence:
1. The big wave towards the 'business logic in the middle tier'
approach seems to have followed with the increasing adoption of an
object oriented approach.
Java in the middle tier is OO while PL/SQL isn't.
The thick DB group might pounce on this one but this is a historical
fact.
2. Individual snippets of code might perform better in the database.
On the flip side, it CAN lead to too many round trips to the database
which can counter balance any benefit.
In my experience, a well designed application avoids any more DB calls
than necessary and a middle tier approach seems to facilitate that.
Crucial in an interactive application.
On Oct 26, 10:05 am, DJCampbell <darren.campb...@accaglobal.com>
wrote:
1. The big wave towards the 'business logic in the middle tier'
approach seems to have followed with the increasing adoption of an
object oriented approach.
Java in the middle tier is OO while PL/SQL isn't.
The thick DB group might pounce on this one but this is a historical
fact.
2. Individual snippets of code might perform better in the database.
On the flip side, it CAN lead to too many round trips to the database
which can counter balance any benefit.
In my experience, a well designed application avoids any more DB calls
than necessary and a middle tier approach seems to facilitate that.
Crucial in an interactive application.
On Oct 26, 10:05 am, DJCampbell <darren.campb...@accaglobal.com>
wrote:
John Flack
Oct 31, 2010, 10:37:54 PM10/31/10
to ADF Enterprise Methodology Group
PL/SQL has some object oriented features, though I think there is room
for improvement in the OO features. It is true that JEE programmers
have enough languages - Java, Javascript, XML, JSF, CSS ... to learn
without adding PL/SQL to the mix. Really, I don't have a problem with
putting business logic in the middle tier, with a few exceptions. It
has already been mentioned that primary keys, unique keys, and
referential integrity are chief among those exceptions - these simply
CAN'T be enforced adequately in the middle tier. Fortunately, you
don't have to know PL/SQL or even stick with Oracle to do this.
Generating surrogate primary keys is also best left to the database
IMHO.
One thing to consider is what besides your application will be able to
get to the database? Will you be using some end-user reporting
tools? Do you have power users who might get in with SQL*Plus, SQL
Developer or TOAD? Are there applications besides the one you are
developing that can use your database? If anything but your
application can change the data, you will want at least the most
crucial business rules to be built into the database tier to protect
it. Some rules I like to have in both the database tier to protect
the data no matter how it is changed, and in the client tier to give
users immediate feedback.
Finally, the more the particular rule needs to access data in the
database, the closer it needs to be to the data. For instance, if you
have a regular expression to be used to validate data, that only needs
the data to be validated and can easily be in the middle tier. A
cross validation between two fields that are likely to both be in the
middle tier at the same time can probably be done there too. A look
up of data that doesn't change frequently can usually be done there,
but volatile data to be queried each time it it used might be better
in the database. And something that does substantial database
changes, like writing an audit trail, will usually perform better in
the database.
for improvement in the OO features. It is true that JEE programmers
have enough languages - Java, Javascript, XML, JSF, CSS ... to learn
without adding PL/SQL to the mix. Really, I don't have a problem with
putting business logic in the middle tier, with a few exceptions. It
has already been mentioned that primary keys, unique keys, and
referential integrity are chief among those exceptions - these simply
CAN'T be enforced adequately in the middle tier. Fortunately, you
don't have to know PL/SQL or even stick with Oracle to do this.
Generating surrogate primary keys is also best left to the database
IMHO.
One thing to consider is what besides your application will be able to
get to the database? Will you be using some end-user reporting
tools? Do you have power users who might get in with SQL*Plus, SQL
Developer or TOAD? Are there applications besides the one you are
developing that can use your database? If anything but your
application can change the data, you will want at least the most
crucial business rules to be built into the database tier to protect
it. Some rules I like to have in both the database tier to protect
the data no matter how it is changed, and in the client tier to give
users immediate feedback.
Finally, the more the particular rule needs to access data in the
database, the closer it needs to be to the data. For instance, if you
have a regular expression to be used to validate data, that only needs
the data to be validated and can easily be in the middle tier. A
cross validation between two fields that are likely to both be in the
middle tier at the same time can probably be done there too. A look
up of data that doesn't change frequently can usually be done there,
but volatile data to be queried each time it it used might be better
in the database. And something that does substantial database
changes, like writing an audit trail, will usually perform better in
the database.
Mark Robinson
Oct 31, 2010, 10:57:07 PM10/31/10
to adf-met...@googlegroups.com
I've been thinking about and I'm not even sure that I'd refer to PKs,
unique keys and referential integrity as business logic. Sure, you can
implement some limited business logic using those tools, but I don't
think they really count. I like to think of them as data integrity
rules which are simply managed by the persistence layer. That is, they
exist to maintain data integrity, much in the same way an image library
might refuse to write out an image with a negative area.
Mark
Mark
--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com
All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).
Jang-Vijay Singh
Nov 1, 2010, 2:01:51 AM11/1/10
to adf-met...@googlegroups.com
'persistence layer' - i like the phrase.
Database = persistent store of data.
CUNEYT
Jan 21, 2011, 10:37:14 AM1/21/11
to adf-met...@googlegroups.com
Dear All,
As an ADF rookie (ADF Virgin might be better here) coming from PL/SQL and
Oracle Forms background it looks like using ADF Business Components and ADF
Faces will meet the requirements of our client who insists on having the
business logic on the middleware instead of the database. However for
performance issues our client wants us to use Coherence. How can we use
Coherence, ADF BC and ADF Faces together?
Thanks in advance.
Cüneyt Taşlı
--
John Stegeman
Jan 25, 2011, 10:57:49 AM1/25/11
to adf-met...@googlegroups.com
This should be a new thread - but before you do that - search the group's archives. It's been asked before.
John
John Flack
Jan 25, 2011, 11:19:55 AM1/25/11
to adf-met...@googlegroups.com
Yes, John, that occurred to me five seconds after I let the post through. My apologies to the group.
Maiko Rocha
Jan 25, 2011, 12:53:10 PM1/25/11
to adf-met...@googlegroups.com
Has your client already measured the performance issues to the point that is conclusive that Coherence is needed to improve application performance? What is the specific performance issue? Session management? Data Caching? Grid/Cloud Processing? In which scenario they want to use Coherence?
Technically, there's no integration. You need to bake Coherence into your app, be it at the ADF BC, Controller, or UI layer. Specifically with ADF BC the challenge is that it is not possible to simply plugin Coherence to replace or support BC's Entity Cache, or View Object cache (in the case of read-only VOs). Sure you can override base classes yourself to provide programmatic VO support with a Coherence back-end, but at the EO level you will need to re-write the EntityCache yourself - you DON'T want to do that. Remember that Coherence won't provide an easy-to-use, out of the box transactional model, you need to use transactional cache and API.
Coherence is an incredible product, with a different programming model, I even dare to say is a completely different way of design applications and systems. Using it only for simple caching as we know it is not going to give you a good cost/benefit ration. Most of customers using Coherence use core JEE developers to implement their solutions.
First you need to find whether Coherence is needed or not. If it is, by all means use it. It's an incredible product. Just make sure to have your expectations set coming from a Forms/PLSQL/4GL environment that Coherence is not a tool, not a framework, but a library.If you want to know more about Coherence you can watch its channel on YouTube: http://www.youtube.com/user/OracleCoherence
[]s! :-)
Maiko
Cuneyt
Jan 25, 2011, 1:24:53 PM1/25/11
to adf-met...@googlegroups.com, adf-met...@googlegroups.com
Thank you very much. We have a trading application(stocks, derivatives etc) where miliseconds count. Since there won't be any PL/SQL at the DB side and the business logic will be on the midlleware we are worried that the network roundtrips will cause a bottleneck. When we shared our concerns with the client the client told us to use Coherence. Looking at the Oracle documentation I can see that in order to use Coherence we need to forget about ADFbc and use Toplink. Coming from PL/SQL land we are foreigners in the Object Oriented world. ADFbc looks familiar. We don't want to get involved with EJBs and PQL.
Well since we'll need to cache data and Coherence belongs to another world what if we put Oracle Times Ten between our DB and the ADFbc?
Sent from my iPhone
Sent from my iPhone
Maiko Rocha
Jan 25, 2011, 3:01:44 PM1/25/11
to adf-met...@googlegroups.com
I don't think this is a problem of pure caching. Again, this would reduce Coherence to its bare minimum feature. If you have a trading app with strict performance and usually scalability requirements, than you need to think differently. The design of the app won't be in any shape or form close to what you've done before on Forms, PL/SQL, or even most of ADF BC apps. I invite you to watch Cameron's Purdy VP of Development for Coherence talking about programming models:
I'm still not completely convinced on the requirements from your customer, but usually trading applications are mission critical and fast, so I will take that as a good reason, but usually you need to start with measurable data: response time in seconds, transactions per second, network latency, etc. And this is not only related to the app: can your network support the response time you're aiming for?
It looks like Coherence + TopLink is a better fit, but it is not going to be a silver bullet if you still follow standard programming models. You can still leverage ADF bindings and ADF Faces for the UI. The only thing you cannot do is to pick a technology that won't fit the use case just because you feel more comfortable with it.
[]s!
Maiko
Cuneyt
Jan 25, 2011, 4:08:47 PM1/25/11
to adf-met...@googlegroups.com, adf-met...@googlegroups.com
Thank you Maiko.
So you suggest that for the trading app we go with Toplink+EJB and Coherence.
I am worried about Coherence's limitations about not supporting join queries, bulk deletes and inserts. Anyways thanks for the links I'll watch the videos.
I assume that Toplink and ADFbc can coexist. What I mean is while we have the trading app on Toplink we can have the midoffice and backoffice on ADFbc right?
To answer your question about the network we suggested our client to use Oracle Infiniband.
Regards,
Cuneyt
Sent from my iPhone
Maiko Rocha
Jan 25, 2011, 5:30:05 PM1/25/11
to adf-met...@googlegroups.com
You need to figure out what technology stack fits best for your scenario - I have a very shallow view of your issue, so better than take my word for it is to actually question it. For such a critical system a architecture prototype is very handy where you implement a very small subset of the most critical use case; with this you can weigh in expertise required and take specific measures based on performance, load testing, time to develop, product costs, etc. Your requirements need to be measurable which in turn makes them actionable: raw response time, throughput, concurrent users, network latency, perceived response time.
Does the existing app today performs well? Does it need to improve in terms of performance and scalabilty? How much, and by which metrics? Are you hitting any bottlenecks with the current app? What and where are they? You need to consider all of this in your architecture prototype too.
I am worried about Coherence's limitations about not supporting join queries, bulk deletes and inserts. Anyways thanks for the links I'll watch the videos.
This is one of the things you need to consider; by changing the programming model and implementation approach you probably won't need bulk deletes and inserts; at the same time, if you can achieve what you want by using these database features plus ADF BC, and prove the point to your customer again with measurable outcomes, then you can find out that maybe going with an all-middletier approach will be costlier and riskier because you or your team currently lack the specific skills to do it with a new set of technologies.
I assume that Toplink and ADFbc can coexist. What I mean is while we have the trading app on Toplink we can have the midoffice and backoffice on ADFbc right?
Sure, no problems with that.
Reply all
Reply to author
Forward
0 new messages