Since we have business rules should the architecture of the system have middle-ware?

No, although it's not uncommon to have middle-ware. But whether or not to have middle-ware depends on more than just having business rules.

And if we will have middle-ware does the architecture have to be N-tiered?

Strange question. Are you considering to have just middle-ware, without a front-end or a back-end? Otherwise, if you have front-end, middle-ware and back-end, you have a 3-tier architecture.

What languages should the middle-ware be written in?

That depends on many things, but not the fact it's middle-ware. It depends mainly on your problem set, and your programmer set. Another factor will be possible third party software.

Would the middle-ware contain the business objects?

If you have business objects, and you're going to implement business rules in your middle-ware, then that would be the logical place for them. But if you don't have business objects, the answer would be no.

The original "developer" implemented the business rules in PL/SQL and triggers. Is this a bad thing?

Perhaps. Perhaps not. It depends what the business rules are. If it's a system to control traffic lights, PL/SQL might not be the right choice. For some financial applications, it might be a right choice.

I feel that our "team" should only be responsible for the back-end and the middle-ware so do we need to be concerned about client/model views?

I'd look for better programmers if my programemrs had such a narrow view. Even if you focus on the back-end, you still need to interface with the middle-ware - after all, the back-end isn't a goal on its own. The end goal is always the total product, and you should never ever forget that.

I assume you mean "client/server model" in you last sentence. You need to be concernced about a "client/server model" if that's the interface you are going to use between the middle-ware and the back-end. If you are going to use a different model, get concerned about that model.

Should the business-objects contain the SQL to extract the data and manipulate it, then store that resulting data back to the database, or should the business objects call store procedures to do this?

Stored procedures will give you some great advantages - it separates the logical view of the data (which your programs have), and the physical layout in the tables. I prefer my code to not touch the tables directly. It could also give you some performance advantages, as stored procedures are compiled only once - and only need to be recompiled if the database goes down, or when they are reloaded.

I am using terms correctly?

You sound like you are a manager who just came out of a meeting, having heard a ton of new buzzwords.

How can we know you used the terms correctly? You used a lot of terms, but you don't say what you mean by them. Perhaps you mean by "business rules" and "middle-ware" something totally differnent than the rest of world does.

And of course how can I sell my boss on using Perl for parts of this system?

What makes you think Perl would be a good choice anyway? If your team consists of mostly people knowing Java and C++, and nothing else, Perl doesn't seem like a good choice to me. If your boss thinks it's far more difficult to hire new, capable, Perl programmers than capable Java programmers, Java might be a better choice. If there are a lot of ready made C libraries available that will do most of the work, C might be the better choice.

If you have to ask here how to get your boss to approve the use of Perl, it seems to me that you can't think of enough reasons yourself. And if you can't think of enough reasons to go for Perl, Perl might not be the right choice.

Abigail