Kevin,

>From an architectual view, I'd say that keeping you business rules layer in a data centric programming language (like VFP) makes more sense than trying to do this in a low level language like Java or .NET. It might pay off when business rules are less static. You can store the business rules in a table, and process them in VFP very clean and quickly. This is much harder to do in .NET or java technologies.
>
>If business rules are going to reside in database tables, you can use SQL Server/Oracle stored procedures to read/process the tables. Many use this approach and find it efficient. You can also use ADO.NET for any subsequent processing of results sets from the back-end.

Note that I'm not saying this is impossible to do in Java or .NET. And of course you can rely on the backend to process the business rules. But if you are talking about a tiered/layered design the business rules layer/tier should be less depending on the implementation of the backend database. Actually you then are merging the data and business rules tiers/layer. This is esspecially cumbersome when the data comes from the upper layers and need to be validated before it is going to be committed.

The power behind VFP is it cursor driven technology that is independed of the database itself and the implementation of your business rules are less depended on the actual database beeing used. You'll have to write less SPs, if any, to overcome the lack of datacentric DML in Java and .NET.

The point I'm getting at is that a data centric language in the business layer makes sense. The layer is about data and validating data (e.g. via SQL SELECT) that comes in via another non database layer (XML ?). VFP is very well equiped to do this job nice and clean without going trough many hoops. For example by converting the XML to cursor and append to an updatable SP cursor. Only a few lines code neccesary and you can concentrate on the logic rather than worrying about the details of implementation (abstraction).

Walter,