«

On 12/28/2012 07:02 PM, Arne Vajhøj wrote:
> On 12/28/2012 4:08 PM, lipska the kat wrote:
>> On 28/12/12 20:22, Robert Klemme wrote:
>>> On 28.12.2012 18:50, lipska the kat wrote:
>>>> I spend much of my working life translating a clients business
>>>> processes
>>>> into something that can run on a computer and the trend is now more
>>>> than
>>>> ever away from a strictly web based process and towards systems that
>>>> are
>>>> completely independent of delivery mechanism.
>>
>>> This sounds exactly like the use case JEE was intended for.
>>
>> Well yes, I remember early days writing EJB deployment descriptors by
>> hand. What a hideous nightmare that was.
>
> 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

On 12/31/2012 6:06 PM, Arved Sandstrom wrote:
> 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).

> 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

On 12/31/2012 7:08 PM, Arved Sandstrom wrote:
> On 12/28/2012 07:02 PM, Arne Vajhøj wrote:
>> On 12/28/2012 4:08 PM, lipska the kat wrote:
>>> On 28/12/12 20:22, Robert Klemme wrote:
>>>> On 28.12.2012 18:50, lipska the kat wrote:
>>>>> I spend much of my working life translating a clients business
>>>>> processes
>>>>> into something that can run on a computer and the trend is now more
>>>>> than
>>>>> ever away from a strictly web based process and towards systems that
>>>>> are
>>>>> completely independent of delivery mechanism.
>>>
>>>> This sounds exactly like the use case JEE was intended for.
>>>
>>> Well yes, I remember early days writing EJB deployment descriptors by
>>> hand. What a hideous nightmare that was.
>>
>> 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

On 12/31/2012 8:46 PM, Martin Gregorie wrote:
> On Mon, 31 Dec 2012 19:29:41 -0500, Arne Vajhøj wrote:
>> 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).
>>
> 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

On 12/31/2012 08:29 PM, Arne Vajhøj wrote:
> On 12/31/2012 6:06 PM, Arved Sandstrom wrote:
>> 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.

>> 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.

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 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

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

On Tue, 25 Dec 2012 01:04:23 +0800, "SL@maxis" <>
wrote, quoted or indirectly quoted someone who said :

>
>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.

--
Roedy Green Canadian Mind Products http://mindprod.com
Students who hire or con others to do their homework are as foolish
as couch potatoes who hire others to go to the gym for them.

"Arved Sandstrom" <> wrote in message
news:JfBDs.90567$...
>
> 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

"Arved Sandstrom" <> wrote in message
news:nUoEs.1$...
> 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.
>>
>> 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.

On 1/1/2013 8:22 AM, Arved Sandstrom wrote:
> On 12/31/2012 08:29 PM, Arne Vajhøj wrote:
>> On 12/31/2012 6:06 PM, Arved Sandstrom wrote:
>>> 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.
>
>>> 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.
>
> 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 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.
>
> 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

On 1/4/2013 7:22 PM, Richard Maher wrote:
> "Arved Sandstrom" <> wrote in message
> news:nUoEs.1$...
>> 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.

> 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