About the Multi-Tiered Business Components Architecture

Any J2EE application has up to three separate logcal tiers:

A client tier containing code that runs on the client and with which a user interacts
A web tier containing code that generates a user interface on an application server
A business tier containing the business logic

The business services and MVC model is the business tier; the MVC view and controller generally operate on one of the other two tiers.

When Oracle ADF Business Components provide business services, it is easy to rearrange these three separate tiers into several different deployment configurations:

Java client in local mode: Both the business tier and the client tier run on the end-user's machine
Java client in remote mode: The client tier runs on the end-user's machine, and the business tier runs in an EJB container on an application server
Web client in web module mode: Both the business tier ) and the web tier run in a web container on an application server
Web client in remote mode: The web tier runs in a web container on an application server, and the business tier runs in an EJB container on the same or another application server

Oracle ADF Business Components is deployment-configuration independent, which means that you can switch between local/web module and remote deployment configurations with no change in code.

This is a marked improvement over other programming styles. Without Oracle ADF Business Components , you would have to plan your entire application around your deployment configuration--an application designed around EJBs would look entirely different from an application with the model, view, and controller in the same container or JVM. With Oracle ADF Business Components, you can program and invoke a business components EJB and a locally deployed business components archive in exactly the same way.

Choosing a Deployment Configuration

When you choose the configuration of your business components application, ask yourself the following questions:

Is it more important to me to have a thin client or a client with a complex user interface?
Using a web client will take most of the load off of the client machines: The web server will do all of the processing, and the client machine will only need to render HTML. A Java client, on the other hand, requires the client machine to run Java but allows for real-time interactivity and a complex user interface.
Is network speed more of a concern than machine speed?
Deploying business components remotely takes much of the weight off of the machine processing your client code. The cost of this is more trips over the network, as your client code accesses your business components EJB. If your client code is executing on a fast, centralized machine such as a web server, saving network trips by deploying to the web module may be worth the increased processing demands.

Advantages of Tier-Independence

Tier-independence gives you multiple advantages:

You can prototype your application with the convenience of local or web module deployment and then move to a remote configuration if you want, and you won't need to change any code.
You can easily deploy and benchmark your application in multiple deployment configurations to see which gives you the best performance and scalability.
Instead of devoting extensive project resources to EJB architecture, you can let Oracle ADF Business Components deal with issues of cross-tier communication for you.

Maintaining Tier-Independece

The business components framework is organized around interfaces in the oracle.jbo package, such as oracle.jbo.ApplicationModule, oracle.jbo.ViewObject, and oracle.jbo.Row. By coding your client to these interfaces, rather than the classes that implement them, your code can stay tier-independent. If, for example, you choose to deploy your business components as an EJB, you can use the same client code you used for testing when your business components were deployed locally, because the interfaces are always accessible in the client tier. The business components framework handles all issues of cross-tier communication for you.

The interfaces in oracle.jbo are implemented by classes in the package oracle.jbo.server. For example, oracle.jbo.ApplicationModule is implemented by oracle.jbo.server.ApplicationModuleImpl. You should not directly call methods on these implementation classes, because if you deploy remotely, these classes will not be available on the client tier. Invoking the classes would prevent you from ever deploying your application remotely. Instead, you should call methods on the interfaces.

Similarly, when you create your own application module and view object classes, you should not call methods on their implementation classes. Instead, you should export methods to create custom interfaces that contain them. These interfaces extend oracle.jbo.ApplicationModule or oracle.jbo.ViewObject and are also always accessible in the client tier. When you downcast a business component, always downcast to your interface, never to your implementation class. For more information, see the related topics list.

Avoiding Tier-Independence

You may decide that you do not want to use Oracle ADF Business Components' abilities to manage tier-independence. You can do this by deploying as a particular sort of EJB session bean, called a service session facade. For more information, see the related topics list.