Java servlet on browsers: dying or kicking ?

[Arne Vajhøj]

[snip]

I don't think there is much point in implementing all the business
logic twice - server side in Java and client side in JavaScript. That
would be an awfully waste of money.

But I think I know what you are thinking about. You are talking about
data input validation.
Exactly.

There are good reasons to do that both client side (for smooth UX) and
server side (for security).

Exactly my point.

But the overlap between data input validation and business logic
is pretty small. Most business logic is not data input validation.
And a big chunk of data input validation is really UI and not
business logic.

True. I am tired of Web pages that could catch entry errors, but
do not until I have finished a whole page. It seems that a lot of
people ignore putting any validation in the front-end. I would like
people to think of putting code in both places.

It is generally accepted as a best practice, but I am sure
that it is still missing many places.

But unless server side is node.js or using a smart framework, then
it do means replicating code logic.

Regarding smart frameworks then ASP.NET MVC can generate both server
side and client side checks from same rules (annotations on data class)
and the same can certain JSF 2 implementations using JSR-303 annotations
(Richfaces is one such implementation).

Arne

 

[Arved Sandstrom]

I thought a business logic layer by definition was separate
from UI layer and data access layer.



Arne

I do such a heavy combination of SOA and web app work that I like layers
that work for both. For my purposes Martin Fowler's Service/Application
layer picture (http://martinfowler.com/eaaCatalog/serviceLayer.html)
serves nicely as a starting point.

In that picture business logic is mostly in the Domain/Model layer,
including business rules, and the Service/Application layer consists of
operations that cannot be assigned to any one given domain object.

I see a good, solid Service/Application layer as being one that actually
provides services in the SOA sense. Not web services, but _services_.
These then become available for orchestration in different ways.

In a web app scenario, and I stress that this is *my* approach, the MVC
Model is generally the Fowlerian Service layer (plus everything inside
it) + extra stuff that is perhaps best characterized as a view-model.

Equally well you can provide a web service endpoint thin layer -
basically just the stuff to provide REST or SOAP access to consumers -
that exposes the Service Layer.

Anything can stitch together (orchestrate) the service layer operations
available through either mechanism.

I emphatically don't delineate layers by technology used, or even by
location. A clean, understandable architectural picture can deal with,
and explain, business logic in Javascript on a mobile browser, and also
business logic in a DB stored procedure.

AHS

 

[Arne Vajhøj]

I have this vision of an implementation of a business that exists
totally independently of any external influence ... it's just a thought.

Anything can query the business ... "Do you have one of these and if so
how much is it and do you have any in stock ?"

or "I want to buy this, and I want to pay like this"

and the business can communicate with it's suppliers in a similar way

and the business can

I think you are looking for something loosely coupled - there will
always be a dependency on something behind it.

Arne

 

[Arne Vajhøj]

Hmm, we are talking Weblogic version '3.something or other' here, around
1998 I seem to remember. Eclipse didn't exist, we had IBMs Visual Age
for Java but that was ... truly awful and it certainly didn't have the
ability to generate EJB Deployment descriptors. These were the days when
you had to implement Entity Bean primary keys by hand


Well the earliest reference I can find to xdoclet is 2002 so we probably
didn't have that option.

XML deployment descriptors did not exist in WL 3.x.

They were added in EJB 1.1 released December 1999.

Anyway, I think most early adopters of EJB
would agree that developing EJBs and keeping track of all the files
involved was a frustrating experience.

No - I don't think so.

All the ASP classic developers, PHP 4 developers and students
that spent a week looking at it probably found the descriptors
and interfaces very painful.

For those actually developing J2EE app back then it was an
insignificant part of the work.

Arne

 

[Arne Vajhøj]

I do such a heavy combination of SOA and web app work that I like layers
that work for both. For my purposes Martin Fowler's Service/Application
layer picture (http://martinfowler.com/eaaCatalog/serviceLayer.html)
serves nicely as a starting point.

In that picture business logic is mostly in the Domain/Model layer,
including business rules, and the Service/Application layer consists of
operations that cannot be assigned to any one given domain object.

I see a good, solid Service/Application layer as being one that actually
provides services in the SOA sense. Not web services, but _services_.
These then become available for orchestration in different ways.

The 3 layer model with PL, BLL and DAL are very widely used, but
other models are certainly possible.

A DL and AL makes perfectly sense to me.

But DL and AL will still be separate from PL and DAL just like BLL.

In a web app scenario, and I stress that this is *my* approach, the MVC
Model is generally the Fowlerian Service layer (plus everything inside
it) + extra stuff that is perhaps best characterized as a view-model.

That is how I see M as well.

I emphatically don't delineate layers by technology used, or even by
location. A clean, understandable architectural picture can deal with,
and explain, business logic in Javascript on a mobile browser, and also
business logic in a DB stored procedure.

Business logic can be put in all tiers.

But it may not be equally good design.

Arne

 

[Arne Vajhøj]

I see the _service layer_ as aggregating fine grained business methods
behind a facade. The facade then exposes what are in effect 'atomic'
services that implement a particular subset of the business as seen by
the outside world. As far as external clients are concerned the
interface to the business is clearly defined.

Facade pattern

My question is how can the orchestration of service layer services
outside the system boundary be controlled in a way that would be
guaranteed not to potentially break the [business] rules ?

You need to have context. Either have client send all
context or send a ref to context saved in service layer.

Arne

 

[Gene Wirchenko]

Apologies, I hit the send key by mistake
I blame the spouse for waving shortbread under my nose

Truly a horrible threat to good USENETting.

I love shortbread, too.

Sincerely,

Gene Wirchenko

 

[Arne Vajhøj]

Your point being ?

That this is one of the most widely used patterns.

My question is how can the orchestration of service layer services
outside the system boundary be controlled in a way that would be
guaranteed not to potentially break the [business] rules ?

You need to have context. Either have client send all
context or send a ref to context saved in service layer.

Unconvinced I'm afraid

There are two possible types of actor interaction with a business
Stateless and statefull.

A stateless interaction for example might be a request for currency
conversion, or a free ESTIMATE for goods or services. You may offer
these alongside other free services, Clients can mix and match your
stateless services all they want and it has no impact on your business.

The other type is statefull. These interactions do impact the state of
your business, In 20 odd years of designing and implementing business
systems I have never come across a situation where a business is happy
to allow it's clients to dictate the terms of business in a random and
uncontrollable way. Any control exercised over the combination of
statefull services effectively extends the system boundary so the whole
argument (allowing external orchestration of services) becomes moot.

This is not some academic conjecture on my part but hard experience in
the real world.

I'd be interested to hear what the original responder has to say about
this.

You can't orchestrate on your server without context.

Arne

 

[Arved Sandstrom]

On 12/29/2012 7:22 AM, Arved Sandstrom wrote:

[ SNIP ]

Business logic can be put in all tiers.

But it may not be equally good design.

Arne

There are several schools of terminology here, Arne. I hold to the
school that says that a "tier" is a physical division in a system
(hardware/software) architecture, while a "layer" is a logical division
in a software architecture.

So that's why I said what I said the way I said it, using the words
"layers", "technology" and "location" on purpose. I think that as long
as your business logic is identifiably in a location where it should be,
then you have a sound solution (all other things being equal).

In any case we commonly have business logic in the data tier. A subset
of business logic is business rules, and one category of business rules
is data constraints. And data constraints, as you know, are very often
imposed directly in an RDBMS or managed indirectly through JPA or its
..NET equivalents, to use just a few examples.

Since we - software developers in general - routinely do the above, I
see no reason to demonize business logic in stored procedures either. In
fact, given the efficiency of a modern RDBMS in handling DML it is
frequently the most sensible place to put certain kinds of business logic.

To be honest I've been uncomfortable for a long time with the label and
concept of a "business logic" layer, as opposed to say DALs or
Presentation layers. For example, workflow is a component of business
logic - in order to adhere to orthodoxy you have to then maintain that
every aspect of workflow in web apps, SOA orchestrations or mobile
client apps is still business logic.

Which probably it is - in which case why is Javascript business logic a
bad thing? I've worked in a bunch of shops where to utter Javascript and
"business logic" in the same sentence occasions gasps of horror. And
yet many of these same people have methods, that are directly exposed
through JSF web pages, also doing business logic. I'm not indicating
strongly here what I advocate and what I don't, I'm just saying that
business logic permeates every tier we have, so maybe the concept of a
"business logic" layer needs some thought.

I think at a minimum a developer needs to understand what business logic
is - rules and workflow - and needs to adequately manage where it is. I
think it's less important what tier it's in.

AHS

 

[Arved Sandstrom]

Facade pattern

Your point being ?

My question is how can the orchestration of service layer services
outside the system boundary be controlled in a way that would be
guaranteed not to potentially break the [business] rules ?

You need to have context. Either have client send all
context or send a ref to context saved in service layer.

Unconvinced I'm afraid

There are two possible types of actor interaction with a business
Stateless and statefull.

A stateless interaction for example might be a request for currency
conversion, or a free ESTIMATE for goods or services. You may offer
these alongside other free services, Clients can mix and match your
stateless services all they want and it has no impact on your business.

The other type is statefull. These interactions do impact the state of
your business, In 20 odd years of designing and implementing business
systems I have never come across a situation where a business is happy
to allow it's clients to dictate the terms of business in a random and
uncontrollable way. Any control exercised over the combination of
statefull services effectively extends the system boundary so the whole
argument (allowing external orchestration of services) becomes moot.

This is not some academic conjecture on my part but hard experience in
the real world.

I'd be interested to hear what the original responder has to say about
this.

lipska

How to classify orchestration - what layer to put it in, in whatever
architectural model you've selected - or whether even to use the term
"orchestration" (and by implication to define an orchestration layer),
really needs to be established up front.

I like using Fowler's model because it's pretty neat, and it's
reasonably applicable to both SOA and non-SOA. Without getting religious
about it, if I were to assign orchestration a place in Fowler's diagram,
I'd have to amend slightly what I said in my previous email in this
sub-thread, and consider that the process services that make up the
orchestration layer are also in the Service/Application layer.

To put it another way, if you have true services being made available
(and I actually agree with your description of them as "'atomic'
services that implement a particular subset of the business"), then the
"stitching together" of them that I alluded to is also in the
Service/Application layer. The lower-level more granular services are
solution-agnostic; the process services are particular to a given solution.

So to touch on your observation, yes, the system boundary (the
application boundary) includes the business logic embodied in process
services (workflow etc).

One other comment - I myself probably wouldn't much use the terms
"stateless" and "stateful" at all in this particular discussion. If you
did have a process that combined a number of services, the odds are
pretty good that each individual service would be stateless, that the
process itself would have interaction state, and it would be completely
another issue as to whether this process eventually effected any changes
in business data (state) or not.

AHS

 

[Arved Sandstrom]

They could be generate by IDE's.

Or they could be generated by xdoclet.

And they were not that hard to write manually.

[ SNIP ]

Not _hard_, no, but quite tedious. Hence error-prone. I seem to recall
that back then (10+ years ago) I mostly used JBuilder - I have the vague
memory that it wasn't *that* much fun to do EJBs.

AHS

 

[Arne Vajhøj]

On 12/29/2012 7:22 AM, Arved Sandstrom wrote:

[ SNIP ]

Business logic can be put in all tiers.

But it may not be equally good design.

There are several schools of terminology here, Arne. I hold to the
school that says that a "tier" is a physical division in a system
(hardware/software) architecture, while a "layer" is a logical division
in a software architecture.

That is the definitions of tier and layer I prefer as well.

So that's why I said what I said the way I said it, using the words
"layers", "technology" and "location" on purpose. I think that as long
as your business logic is identifiably in a location where it should be,
then you have a sound solution (all other things being equal).

In any case we commonly have business logic in the data tier. A subset
of business logic is business rules, and one category of business rules
is data constraints. And data constraints, as you know, are very often
imposed directly in an RDBMS or managed indirectly through JPA or its
.NET equivalents, to use just a few examples.

Since we - software developers in general - routinely do the above, I
see no reason to demonize business logic in stored procedures either. In
fact, given the efficiency of a modern RDBMS in handling DML it is
frequently the most sensible place to put certain kinds of business logic.

SP's are certainly a valid option for business logic.

The biggest drawback is the vendor lock-in (unless it is an
open source database, which the SP based solutions rarely are - it
is almost always Oracle/Microsoft/Sybase).

To be honest I've been uncomfortable for a long time with the label and
concept of a "business logic" layer, as opposed to say DALs or
Presentation layers. For example, workflow is a component of business
logic - in order to adhere to orthodoxy you have to then maintain that
every aspect of workflow in web apps, SOA orchestrations or mobile
client apps is still business logic.

Which probably it is - in which case why is Javascript business logic a
bad thing? I've worked in a bunch of shops where to utter Javascript and
"business logic" in the same sentence occasions gasps of horror. And
yet many of these same people have methods, that are directly exposed
through JSF web pages, also doing business logic. I'm not indicating
strongly here what I advocate and what I don't, I'm just saying that
business logic permeates every tier we have, so maybe the concept of a
"business logic" layer needs some thought.

We need to distinguish between client tier vs app server tier and
JavaScript vs other language like Java.

Code running in client tier is cooperative not enforcing in nature.
I see that as a major problem for business logic in many contexts.

It applies equaly to AJAX JavaScript, Java applets, Flash,
SilverLight etc..

JavaScript is a different language than Java. I am not convinced
that it is a good language for business logic. But other may have
different opinions. I will not though that the existence of
new languages like Dart and TypeScript shows that I am not the
only one with such concerns.

That applies equally to client side JavaScript and server side
JavaScript (node.js).

I think at a minimum a developer needs to understand what business logic
is - rules and workflow - and needs to adequately manage where it is. I
think it's less important what tier it's in.

I don't agree.

What tier the business logic is locate in can have huge architectural
impact.

Arne

 

[Arne Vajhøj]

They could be generate by IDE's.

Or they could be generated by xdoclet.

And they were not that hard to write manually.

[ SNIP ]

Not _hard_, no, but quite tedious. Hence error-prone. I seem to recall
that back then (10+ years ago) I mostly used JBuilder - I have the vague
memory that it wasn't *that* much fun to do EJBs.

Maybe not fun, but you got paid to do it.

Arne

 

[Arne Vajhøj]

I was following, and agreeing with you, until this point. However now I
don't understand why you make the OSS vs proprietary distinction.

IMO moving a schema and data between PostgreSQL and MySQL would be no
easier than moving between Oracle and Sybase. I don't see much inherent
difference in stability within a DBMS either: granted that PostgreSQL
specs change relatively little between versions, but the underlying low-
level structure changes are often big enough to require the DB to be
unloaded from the old version and reloaded into the new one. How is this
different from, say, Oracle upgrades?

Worse, some OSS stuff has insufficient attention paid to feature
migration across versions. Leaving aside my bete noir (the egregious 'who
cares what the user wants: this is what WE want' attitude shown by the
Gnome team), I've bitten twice by the failure of PostgreSQL's pgdumpall
utility to prevent confusion between valid data and string delimiters
(delimiter characters, which are chosen by pgdumpall, appearing in data
and not being recoded as hex to prevent confusion). I bugged it once,
got it fixed, and then bugger me, it reappeared two versions later. I
expect bugs of this type to get added to regression tests and hence to
never reappear. If I can do this, so can any OSS project.

The nub of the problem is that, at least with commercial code you
generally get notice taken and the bug fixed or documented as a feature
but sadly, there are OSS projects out there that just blow you off if
their ideas have changed and/or they can't be arsed to do proper
regression testing (WINE, I'm looking at you!).

You are also tied to an open source database, but you are not
tied to the vendor.

That can make a difference.

If you want to get rid of PostgreSQL, then you will have
some cost migrating - just like you will have some cost
migrating from Oracle.

But if Oracle raises their license costs, then you either
have to pay them or pay for the migration.

With PostgreSQL you do not have that issue. You can
always get the same product from somewhere else.

If Sybase decides to drop ASE, then you have to pay for
a migration.

If PostgreSQL team drops it, then somebody else
can take over.

If you depend on an open source database working, then
you should pay for support to get your bugs fixed ASAP.

The most common open source databases have companies
specializing in support of them.

Arne

 

[Arved Sandstrom]

On 12/29/2012 7:22 AM, Arved Sandstrom wrote:

[ SNIP ]

I emphatically don't delineate layers by technology used, or even by
location. A clean, understandable architectural picture can deal with,
and explain, business logic in Javascript on a mobile browser, and also
business logic in a DB stored procedure.

Business logic can be put in all tiers.

But it may not be equally good design.

There are several schools of terminology here, Arne. I hold to the
school that says that a "tier" is a physical division in a system
(hardware/software) architecture, while a "layer" is a logical division
in a software architecture.

That is the definitions of tier and layer I prefer as well.

So that's why I said what I said the way I said it, using the words
"layers", "technology" and "location" on purpose. I think that as long
as your business logic is identifiably in a location where it should be,
then you have a sound solution (all other things being equal).

In any case we commonly have business logic in the data tier. A subset
of business logic is business rules, and one category of business rules
is data constraints. And data constraints, as you know, are very often
imposed directly in an RDBMS or managed indirectly through JPA or its
.NET equivalents, to use just a few examples.

Since we - software developers in general - routinely do the above, I
see no reason to demonize business logic in stored procedures either. In
fact, given the efficiency of a modern RDBMS in handling DML it is
frequently the most sensible place to put certain kinds of business
logic.

SP's are certainly a valid option for business logic.

The biggest drawback is the vendor lock-in (unless it is an
open source database, which the SP based solutions rarely are - it
is almost always Oracle/Microsoft/Sybase).

And that's one of the few disadvantages. The big advantage (shared with
views) is centralization of data access logic - rather than having every
client doing the same D.A. manipulations, you've got complex stuff
bundled in one place.

This also eases the security problem.

On the subject of vendor lock-in, I'm not that worried about it. No
matter what software you pick, whether proprietary and $$$, or gratis
and open source, once you've invested some application effort into a
given product then you have a degree of lock-in. And in my experience
substantial underlying systems just aren't swapped out that frequently.

We need to distinguish between client tier vs app server tier and
JavaScript vs other language like Java.

Code running in client tier is cooperative not enforcing in nature.
I see that as a major problem for business logic in many contexts.

Maybe I'm obtuse, because I don't see the problem. In fact I haven't
wrapped my head around the "cooperative" and "enforcing" labels either.
Let's assume a relatively thick client, so that there's some application
logic to speak of on the client. That client logic could be as complete
as being UI + process logic + a subset of domain logic + an embedded DB
for independent operations, or it could be pretty spare and only have
some UI and a bit of process logic. Either way, when it communicates
across the physical (tier) divide with the server, it's an _internal_
detail. If you've got a proper internal API to handle that physical
boundary then what's the problem exactly?

It applies equaly to AJAX JavaScript, Java applets, Flash,
SilverLight etc..

JavaScript is a different language than Java. I am not convinced
that it is a good language for business logic. But other may have
different opinions. I will not though that the existence of
new languages like Dart and TypeScript shows that I am not the
only one with such concerns.

That applies equally to client side JavaScript and server side
JavaScript (node.js).


I don't agree.

What tier the business logic is locate in can have huge architectural
impact.

Arne

If we're talking tiers and not layers, and let's say we think of the
client, middleware/server, and database/data access tiers, I am hoping
that the decisions to locate business logic in any of those tiers leads
to positive architectural impact - otherwise why are you locating logic
there?

There are known advantages to certain types of logic in any of those 3
tiers. There are also known disadvantages. If the advantages outweigh
the disadvantages then why not put the logic where reason argues that it
should go?

Pure technical arguments aside for why a particular type of logic should
be in the client tier, or middle tier, or in the data tier, some of the
main things I also look at are maintenance impact and future development
flexibility. Are there readily available human resources, now and in
future, that can do new work or maintain old work in all the places that
business logic has been put, or are you creating operational and
maintenance difficulties? Is there a consistent and clear and
well-disseminated policy for why certain logic goes where it does? Is it
less maintenance effort to take care of certain types of data access
logic in the data tier than it would be if it was in the middle tier? It
often is.

I think what has the most negative, anarchic impact when it comes to
where business logic goes is simply lack of detailed thought and
communication.

AHS

 

[Roedy Green]

What is the current state of java servlet support by major browsers ?

Is it a dying technology or still alive and kicking ?

Servlets don't run on browsers. When they render HTML they have no way
of knowing how it was produced. There is nothing browsers can do to
screw up Servlets.

Google is promoting compressed HTML with
http://mindprod.com/jgloss/spdy.html
I suppose at some point Servlet engines that don't support it will be
left in the dust. However, SPDY does not go far enough to get as much
of a boost as you would expect and has some troubles.

 

[Richard Maher]

I emphatically don't delineate layers by technology used, or even by
location. A clean, understandable architectural picture can deal with, and
explain, business logic in Javascript on a mobile browser, and also
business logic in a DB stored procedure.

Hear, hear!

AHS

Cheers Richard Maher

 

[Richard Maher]

On 12/29/2012 7:22 AM, Arved Sandstrom wrote:

[ SNIP ]

Business logic can be put in all tiers.

But it may not be equally good design.

Arne

There are several schools of terminology here, Arne. I hold to the school
that says that a "tier" is a physical division in a system
(hardware/software) architecture, while a "layer" is a logical division in
a software architecture.

So that's why I said what I said the way I said it, using the words
"layers", "technology" and "location" on purpose. I think that as long as
your business logic is identifiably in a location where it should be, then
you have a sound solution (all other things being equal).

In any case we commonly have business logic in the data tier. A subset of
business logic is business rules, and one category of business rules is
data constraints. And data constraints, as you know, are very often
imposed directly in an RDBMS or managed indirectly through JPA or its .NET
equivalents, to use just a few examples.

Since we - software developers in general - routinely do the above, I see
no reason to demonize business logic in stored procedures either. In fact,
given the efficiency of a modern RDBMS in handling DML it is frequently
the most sensible place to put certain kinds of business logic.

To be honest I've been uncomfortable for a long time with the label and
concept of a "business logic" layer, as opposed to say DALs or
Presentation layers. For example, workflow is a component of business
logic - in order to adhere to orthodoxy you have to then maintain that
every aspect of workflow in web apps, SOA orchestrations or mobile client
apps is still business logic.

Which probably it is - in which case why is Javascript business logic a
bad thing? I've worked in a bunch of shops where to utter Javascript and
"business logic" in the same sentence occasions gasps of horror. And
yet many of these same people have methods, that are directly exposed
through JSF web pages, also doing business logic. I'm not indicating
strongly here what I advocate and what I don't, I'm just saying that
business logic permeates every tier we have, so maybe the concept of a
"business logic" layer needs some thought.

I think at a minimum a developer needs to understand what business logic
is - rules and workflow - and needs to adequately manage where it is. I
think it's less important what tier it's in.

I think a perceived problem with your incredibly resonable arguments Arved
is that the primary objective in most (certainly .NET) IT depts today is to
eliminate SQL altogether and nothing to do with user/business requirements.
Your reference to their anathema of Store Procedures and Referential
Integrity to enforce business rules and logic would rule out Code-First
which is the Holy Grail of OO sites. Technology and fashion is paramount
here. Fit-for-purpose can often be a nebulous concept subject to whimsy and
subjectivity

As for vendor lockin it seems that Microsoft .NET is oft automatically
excluded from this category for some reason. And forget about the worry of
including business rules in different layers, I regurlary see the same
business rules and almost identical classes duplicated in project after
solution after application. Code Reuse (like the GAC) just seems to be in
the too-hard-basket. Easy-to-code seems to be the overriding requirement,
just look at ODATA :-(

But let's say they put all the business rules in the Business Layer
implemented in a Java or C# class. Who is going to inforce thos rules from
PHP Perl or Python access?

AHS

Cheers Richard Maher

PS. Applets are alive and well.

 

[Arne Vajhøj]

On 12/29/2012 09:43 PM, Arne Vajhøj wrote:
On 12/29/2012 7:22 AM, Arved Sandstrom wrote:
[ SNIP ]

I emphatically don't delineate layers by technology used, or even by
location. A clean, understandable architectural picture can deal with,
and explain, business logic in Javascript on a mobile browser, and
also
business logic in a DB stored procedure.

Business logic can be put in all tiers.

But it may not be equally good design.

There are several schools of terminology here, Arne. I hold to the
school that says that a "tier" is a physical division in a system
(hardware/software) architecture, while a "layer" is a logical division
in a software architecture.

That is the definitions of tier and layer I prefer as well.

So that's why I said what I said the way I said it, using the words
"layers", "technology" and "location" on purpose. I think that as long
as your business logic is identifiably in a location where it should be,
then you have a sound solution (all other things being equal).

In any case we commonly have business logic in the data tier. A subset
of business logic is business rules, and one category of business rules
is data constraints. And data constraints, as you know, are very often
imposed directly in an RDBMS or managed indirectly through JPA or its
.NET equivalents, to use just a few examples.

Since we - software developers in general - routinely do the above, I
see no reason to demonize business logic in stored procedures either. In
fact, given the efficiency of a modern RDBMS in handling DML it is
frequently the most sensible place to put certain kinds of business
logic.

SP's are certainly a valid option for business logic.

The biggest drawback is the vendor lock-in (unless it is an
open source database, which the SP based solutions rarely are - it
is almost always Oracle/Microsoft/Sybase).

And that's one of the few disadvantages. The big advantage (shared with
views) is centralization of data access logic - rather than having every
client doing the same D.A. manipulations, you've got complex stuff
bundled in one place.

This also eases the security problem.

On the subject of vendor lock-in, I'm not that worried about it. No
matter what software you pick, whether proprietary and $$$, or gratis
and open source, once you've invested some application effort into a
given product then you have a degree of lock-in. And in my experience
substantial underlying systems just aren't swapped out that frequently.

We need to distinguish between client tier vs app server tier and
JavaScript vs other language like Java.

Code running in client tier is cooperative not enforcing in nature.
I see that as a major problem for business logic in many contexts.

Maybe I'm obtuse, because I don't see the problem. In fact I haven't
wrapped my head around the "cooperative" and "enforcing" labels either.
Let's assume a relatively thick client, so that there's some application
logic to speak of on the client. That client logic could be as complete
as being UI + process logic + a subset of domain logic + an embedded DB
for independent operations, or it could be pretty spare and only have
some UI and a bit of process logic. Either way, when it communicates
across the physical (tier) divide with the server, it's an _internal_
detail. If you've got a proper internal API to handle that physical
boundary then what's the problem exactly?

It applies equaly to AJAX JavaScript, Java applets, Flash,
SilverLight etc..

JavaScript is a different language than Java. I am not convinced
that it is a good language for business logic. But other may have
different opinions. I will not though that the existence of
new languages like Dart and TypeScript shows that I am not the
only one with such concerns.

That applies equally to client side JavaScript and server side
JavaScript (node.js).


I don't agree.

What tier the business logic is locate in can have huge architectural
impact.

If we're talking tiers and not layers, and let's say we think of the
client, middleware/server, and database/data access tiers, I am hoping
that the decisions to locate business logic in any of those tiers leads
to positive architectural impact - otherwise why are you locating logic
there?

Yes.

My point is that where is important or at least can be important.

There are known advantages to certain types of logic in any of those 3
tiers. There are also known disadvantages. If the advantages outweigh
the disadvantages then why not put the logic where reason argues that it
should go?

I agree.

But I was giving specific reasons why a specific type of logic
should not be in a specific tier.

I think what has the most negative, anarchic impact when it comes to
where business logic goes is simply lack of detailed thought and
communication.

Again very true.

But it does not really change anything.

Arne

 

[Arne Vajhøj]

I think a perceived problem with your incredibly resonable arguments Arved
is that the primary objective in most (certainly .NET) IT depts today is to
eliminate SQL altogether and nothing to do with user/business requirements.
Your reference to their anathema of Store Procedures and Referential
Integrity to enforce business rules and logic would rule out Code-First
which is the Holy Grail of OO sites. Technology and fashion is paramount
here. Fit-for-purpose can often be a nebulous concept subject to whimsy and
subjectivity

In both the Java and .NET world ORM's with no SQL are popular.

And in my opinion they are a very good choice in a majority of cases.

But they are not a good choice in all cases.

And using an ORM does not in any way preclude putting well let me
call it integrity logic instead of business logic in the database -
constraints, triggers and views work fine in this environment and
even SP's can work in some cases.

As for vendor lockin it seems that Microsoft .NET is oft automatically
excluded from this category for some reason.

True. But the price tag of that is not so bad. The biggest risk is
that MS change direction.

And forget about the worry of
including business rules in different layers, I regurlary see the same
business rules and almost identical classes duplicated in project after
solution after application. Code Reuse (like the GAC) just seems to be in
the too-hard-basket. Easy-to-code seems to be the overriding requirement,
just look at ODATA :-(

Trying to put all business logic in application tier certainly do not
protect against all bad things.

And it is a lot easier to duplicate classes between different
systems than it is to duplicate the production database without
being caugth.

But let's say they put all the business rules in the Business Layer
implemented in a Java or C# class. Who is going to inforce thos rules from
PHP Perl or Python access?

Nobody.

In that case business rules in the database is a solution to a problem.

Another solution would be to go SOA and only let one service access
the database and let the rest interact with that service.

(I am pretty sure that the success rate for the first solution is better
than for the last solution, but SOA will also improve over time)

PS. Applets are alive and well.

It is alive.

Well? It is far behind several alternatives in usage.

Arne