# About Maintaining Tier Independence by Using Only Interfaces in Client Code

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:

> 1. Create a custom method on your `ViewObjectImpl` subclass for your view object.

> 2. 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.