In our case there is a customer demand to move to a web 2.0 interface. With this in mind we are trying to move the business logic out of the forms as part of the 11g upgrade before migrating to a web 2.0 system whether it be built in Java via jdev or another platform.

Where is the best layer to put the business logic that would aid us in later life. At the minute we all the tables, packages views etc under one db schema. we have pll with code and fmbs have heavy code in them.

We have started to shift all code into the database but are we best actually creating services and moving the code outside the database.

I guess you are using oracle 6i forms with 10g forms in that case
Nothing to worrya about migrating from 10g system to 11g.
Your all code in fmb and rdf will remains same. The Web2.0 interface uses applet to shows your fmb forms inside this applet container and works fines as works in 6i form. So after migrating you can also continue with developing forms and reports as earlier with very few changes in your forms and report . So overall your business logic and packages/views/pll will remain same.

Only you have to configure the new Application Server to run the Web2.0 interface and on client side the Jinitiator will automatically iintall on first run to support java environment for Applet.
It is very easy and very helpful. Also if you migrate your forms to 11G then you will have additional facility of javascript in your forms.

So go ahead with migrating if above the case.

Please Don't forget to mark this post as correct/helpful. This will help in replying many others too.

We have started to shift all code into the database but are we best actually creating services and moving the code outside the database.

Why do you want to move things outside of the database? Is there a reason to do so? There is nowhere written that webservices must not call stored procedures, and the only thing you would acomplish by that is that stored procedures called from forms need to call the webservice instead which will add an additional layer of complexity.

Leave things in the database where it makes sense and use those stored procedures in your webservices, by that you'd have