A key feature of Business Components for Java is the ability to create an application module component that can be deployed to numerous different configurations. Because there is no need for special server-side or client-side code, clients have seamless access to the application module.
You can ensure that tier-independence is guaranteed by making sure your client programs only use:
The basic client interfaces in the oracle.jbo package like ApplicationModule, ViewObject, Row, and so on.
OR
When you mark custom methods for export, the client interfaces of your custom application modules or view objects in the generated your.package.common sub-package of your project.
Failure to abide by this discipline will limit your client code to run in the same Java VM as your middle-tier application module. You may be in violation of this interface-based client programming model when:
Your client code contains an import statement that creates a dependency on any classes from the oracle.jbo.server package
Only the oracle.jbo and oracle.jbo.domain framework packages belong in client code if you want to ensure tier-independent client code.
Your client code contains code which casts an interface like ViewObject to its implementation class ViewObjectImpl
Casts of this kind will break the tier-independence of your client. The appropriate way to access a method in a tier-independent manner is to:
Create a custom method on your ViewObjectImpl subclass for your view object.
Mark the custom method as Exported in the View Object Wizard.
JDeveloper's Business Components for Java design-time wizards will automatically create the necessary tier-independent custom interface for your view object (or application module) in a package named your.package.common. This .common sub-package is named this way because it contains interfaces that are common to both the client and the server tiers of your application. You can then write client code that casts to this custom interface in order to access custom methods in a tier-independent manner.
Note: A general rule of thumb is that direct access to *Impl classes is permissible inside another *Impl class; however, access or casting to *Impl classes in client code accessing an application module should be avoided.