|[ Team LiB ]|
Deciding on the Right jCOM Environment Setup
The focus of a well-planned distributed object enterprise implementation should concentrate on the overall needs of an individual application. Such needs can vary widely depending on the nature of the business problem at hand. Some things you might want to take into consideration include the following: Is this application more likely to be I/O intensive or CPU intensive? Will there be considerable database activity? Are there any required processor-intensive tasks such as financial calculations, estimates, planning forecasts, and so on? Do you think it will need to scale and grow as data volume increases and business needs change? As a distributed design, are there any geographical or security issues to take into account? Where do you think the potential bottlenecks are most likely to occur? In the end, what will be the TCO (total cost of ownership) of the intended solution?
Through its strategic partnering with the J-Integra product, jCOM has a proven track record in delivering battle-tested solutions that address such application demands. The product has been designed to be flexible in its configuration and implementation so as to be somewhat customizable to a particular application's requirements.
With that said, to have jCOM perform as you expect, you must familiarize yourself with a number of configuration and setup options.
Whatever your application entails, you'll be using jCOM as the middleware to bridge communication between the COM and Java objects it uses. The configuration decisions you'll make will revolve around the physical location of objects, where they reside within an operating system, and the protocols used to communicate between them.
You'll decide on issues such as whether to use a zero client install. You'll choose among DCOM, native out of process, and native in process modes and whether to bind your objects with early or late binding.
Don't worry about what all of these terms mean right now. We go over them in detail when we look at the advantages and disadvantages found in each approach. By the end of this chapter, you'll not only be able to make an informed decision on how to make jCOM best fit your application, but you'll also be well on your way to seeing it implemented after having a chance to work with some of the provided examples.
|[ Team LiB ]|