When you develop a business components project, you should think of it as having three separate logical tiers: client code, the business logic, and the database. However, these three logical tiers can be deployed in multiple physical configurations. Client code can appear anywhere you can write Java code (for example, a GUI application, a JSP, or an Enterprise JavaBean). In addition, the business logic you create using Business Components for Java is tier-independent: You can deploy your application modules to multiple platforms without changes in your business components or client code.
You can deploy business components and client code anywhere you can deploy Java. However, there are four especially common deployment configurations:
Client Code | Business Components |
---|---|
Java client on client machine | On client machine |
Java client on client machine | As an EJB session bean or CORBA server object |
Servlet/JSP in the web module of a server (accessed through a browser) | In the web module |
Servlet/JSP in the web module of a server (accessed through a browser) | As an EJB session bean or CORBA server object |
When business components are deployed as an EJB session bean or CORBA server object, the configuration is called remote deployment. Tier-independence means you can switch between deploying business components remotely and deploying them in the web module or on the client machine without any changes to your code.
This is a marked improvement over other programming styles. Without the business components framework, you would have to plan your entire application around your deployment configuration--an application designed around EJBs would look entirely different from a client/server application with no separate physical business logic tier. With the business components framework, you can program and invoke a business components EJB and a locally deployed business components archive in exactly the same way.
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 servlet or JSP client code 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.
Tier-independence gives you multiple advantages: