<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: The Business Logic Wars</title>
	<atom:link href="http://www.avromroyfaderman.com/2008/06/the-business-logic-wars/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.avromroyfaderman.com/2008/06/the-business-logic-wars/</link>
	<description>Tricks, Tips, Thoughts, and Rants About Java EE, Oracle ADF, and Web Application Development</description>
	<lastBuildDate>Mon, 14 Jun 2010 09:19:26 -0700</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.6</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Avrom</title>
		<link>http://www.avromroyfaderman.com/2008/06/the-business-logic-wars/comment-page-1/#comment-2528</link>
		<dc:creator>Avrom</dc:creator>
		<pubDate>Wed, 08 Oct 2008 22:37:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.avromroyfaderman.com/?p=69#comment-2528</guid>
		<description>Hi Nathalie,

I agree, the BRE is a fine alternative and one I didn&#039;t discuss.

Fundamentally, it falls under the &quot;Middle Tier&quot; solution, since BRE does run in the middle tier. But there are a few differences from the middle-tier solutions I mentioned above.

The biggest ones are the ones you mentioned, and these are definitely advantages over other middle-tier options: You can change rules without an application redeployment, and the interface is simple enough that you don&#039;t need to be a DB developer, or any kind of developer for that matter, to implement new ones, allowing the analysts who design the rules to implement them too.

The downsides:

1) To actually use the business rules, you have to assert &quot;facts&quot; (either a particular sort of JavaBean or a particular XML message) and recover results, including the error messages (if any). ADF won&#039;t let you do that declaratively, so, like the database case, you&#039;re going to be writing some Java code to invoke the business rules. I think that in most cases, it&#039;s substantially less code, and less nasty code, than getting ADF to play well with DB trigger errors, but it&#039;s not trivial.

2) The BRE does not come as part of ADF; it comes as part of the SOA suite. That means you&#039;re going to have to pay for it. If you have highly volatile business rules and/or really need your business users to be able to change them (or need the SOA suite for some other reason, like wanting to develop SOA applications), it&#039;s worth it. If not... well, you need to consult your budget.</description>
		<content:encoded><![CDATA[<p>Hi Nathalie,</p>
<p>I agree, the BRE is a fine alternative and one I didn&#8217;t discuss.</p>
<p>Fundamentally, it falls under the &#8220;Middle Tier&#8221; solution, since BRE does run in the middle tier. But there are a few differences from the middle-tier solutions I mentioned above.</p>
<p>The biggest ones are the ones you mentioned, and these are definitely advantages over other middle-tier options: You can change rules without an application redeployment, and the interface is simple enough that you don&#8217;t need to be a DB developer, or any kind of developer for that matter, to implement new ones, allowing the analysts who design the rules to implement them too.</p>
<p>The downsides:</p>
<p>1) To actually use the business rules, you have to assert &#8220;facts&#8221; (either a particular sort of JavaBean or a particular XML message) and recover results, including the error messages (if any). ADF won&#8217;t let you do that declaratively, so, like the database case, you&#8217;re going to be writing some Java code to invoke the business rules. I think that in most cases, it&#8217;s substantially less code, and less nasty code, than getting ADF to play well with DB trigger errors, but it&#8217;s not trivial.</p>
<p>2) The BRE does not come as part of ADF; it comes as part of the SOA suite. That means you&#8217;re going to have to pay for it. If you have highly volatile business rules and/or really need your business users to be able to change them (or need the SOA suite for some other reason, like wanting to develop SOA applications), it&#8217;s worth it. If not&#8230; well, you need to consult your budget.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: nathalie roman</title>
		<link>http://www.avromroyfaderman.com/2008/06/the-business-logic-wars/comment-page-1/#comment-2518</link>
		<dc:creator>nathalie roman</dc:creator>
		<pubDate>Wed, 08 Oct 2008 11:44:21 +0000</pubDate>
		<guid isPermaLink="false">http://www.avromroyfaderman.com/?p=69#comment-2518</guid>
		<description>Avrom,

I was wondering why you&#039;re not mentioning the Oracle Business Rules Engine to enable business rule integration in a java application without being a DB developer.

Isn&#039;t this a good alternative as well?
It&#039;s still a little bit fuzzy regarding the ability to change rules at run time with a fancy look &amp; feel which is business friendly.

Kind regards,
Nathalie</description>
		<content:encoded><![CDATA[<p>Avrom,</p>
<p>I was wondering why you&#8217;re not mentioning the Oracle Business Rules Engine to enable business rule integration in a java application without being a DB developer.</p>
<p>Isn&#8217;t this a good alternative as well?<br />
It&#8217;s still a little bit fuzzy regarding the ability to change rules at run time with a fancy look &amp; feel which is business friendly.</p>
<p>Kind regards,<br />
Nathalie</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Avrom</title>
		<link>http://www.avromroyfaderman.com/2008/06/the-business-logic-wars/comment-page-1/#comment-1908</link>
		<dc:creator>Avrom</dc:creator>
		<pubDate>Mon, 08 Sep 2008 13:07:22 +0000</pubDate>
		<guid isPermaLink="false">http://www.avromroyfaderman.com/?p=69#comment-1908</guid>
		<description>The argument being...?

I mean, that&#039;s really the issue. I&#039;m not saying you can&#039;t come up with a lot of points in favor of using the DB, and the more powerful the DB is relative to the rest of your infrastructure, the more powerful at least one of those points, &quot;it takes processing load off of other tiers&quot; is going to be. But I have yet to see an argument that there&#039;s some &quot;generic,&quot; &quot;standard,&quot; &quot;most likely&quot; case for which any of the tiers is best.</description>
		<content:encoded><![CDATA[<p>The argument being&#8230;?</p>
<p>I mean, that&#8217;s really the issue. I&#8217;m not saying you can&#8217;t come up with a lot of points in favor of using the DB, and the more powerful the DB is relative to the rest of your infrastructure, the more powerful at least one of those points, &#8220;it takes processing load off of other tiers&#8221; is going to be. But I have yet to see an argument that there&#8217;s some &#8220;generic,&#8221; &#8220;standard,&#8221; &#8220;most likely&#8221; case for which any of the tiers is best.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Hari Nair</title>
		<link>http://www.avromroyfaderman.com/2008/06/the-business-logic-wars/comment-page-1/#comment-1903</link>
		<dc:creator>Hari Nair</dc:creator>
		<pubDate>Mon, 08 Sep 2008 06:27:17 +0000</pubDate>
		<guid isPermaLink="false">http://www.avromroyfaderman.com/?p=69#comment-1903</guid>
		<description>As u mentioned, - it all depends -

But as a generic case, for a large scale Database system, it is better to put the business logic in database.  Now MYSQL also supports procedures</description>
		<content:encoded><![CDATA[<p>As u mentioned, &#8211; it all depends -</p>
<p>But as a generic case, for a large scale Database system, it is better to put the business logic in database.  Now MYSQL also supports procedures</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: T-Enterprise</title>
		<link>http://www.avromroyfaderman.com/2008/06/the-business-logic-wars/comment-page-1/#comment-4</link>
		<dc:creator>T-Enterprise</dc:creator>
		<pubDate>Tue, 17 Jun 2008 16:59:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.avromroyfaderman.com/?p=69#comment-4</guid>
		<description>Good ways of dealing with business logic.</description>
		<content:encoded><![CDATA[<p>Good ways of dealing with business logic.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
