as a distributed object technology, corba provides tremendous flexibility for implementing robust enterprise information systems composed of distributed components. in large-scale deployment, these components run in multiple servers located in multiple hosts of different operating systems.
the corba architecture facilitates integration of these distributed components and defines a mechanism for obtaining the required object references.
in particular, the corba programming model requires that remote object implementations be published so client processes can locate them. to provide this directory capability, omg defines two specifications: naming service and trader service, both of which specify the interfaces for object references registration, lookup, and management. many directory service packages are commercially available and generically implemented. but a robust enterprise implementation must meet a number of requirements: scalability, reliability, availability, and more, all of which require intimate understanding of the problem domain. since the generic implementations of the directory service arent able to address those requirements, a smart location service is needed to achieve system robustness.
building a location service, however, consumes time and resources, and can also get in the way of other development. in this article, i outline the steps that allow a location service to be incrementally built, tested, and released into a development environment in baby steps, unintrusively.
to begin, ill discuss factors that influence the decision for building a location service, then define an implementation plan. to wrap up, ill discuss a sample application in an enterprise architecture integration (eai) effort.
system robustness
when building an enterprise information system, the architecture team is tasked with requirements that describe architecture robustness. system robustness comes in many forms. in general, a good design seeks to balance five essential elements: scalability, reliability, a... 下一页