Database Reference
In-Depth Information
Typically, an architecture is a more abstract description, while a model is a more
concrete description—similar to the distinction between classes and instances in
object-oriented development environments (see Chapter 11, Section 11.1.4.1 “Object-
Oriented Paradigm”).
Component models provide an array of mechanisms and services for interoperation of
components:
◾
Self-discovery of components enables rendering of information on supported interfaces and
methods to other components. This enables components to publish its capabilities as well as
interact with other components dynamically.
◾
Properties of components determine the state, behavior, or appearance of the component.
◾
Customization of components enables the properties of a component to be set or modified
from within a component or externally by another component/container.
◾
Persistence of components involves the process of saving and restoring a component's current
state.
◾
Event control of components enables a component to create (or generate) an event for another
component or to respond to an event. Predefining various kinds of events can also differenti-
ate the occurrence of different kinds of events.
The principles of distributed system design are quite different from the traditional concepts of
object-oriented design. For instance, not every object is required to be a distributed object.
An enterprise application is constituted of three types of objects:
1. Distributed component that has a well-defined interface and is network addressable so that
it can be searched and invoked over a network
2. Value object that is essentially a data holder and can be passed as a parameter, but cannot be
invoked over a network
3. Local object that is neither passed nor invoked over a network
10.1.3.4 Enterprise Component Architecture as a
Strategy: Service-Oriented View
The component architecture provides an integration framework to help identify and design the
interfaces between business processes and the diverse software assets or components of the enter-
prise. As mentioned earlier, the interface of a component is separated from its implementation; the
interface guarantees the services specified by the component. The consumer of these services can
exclusively focus on the overall solution via a constellation of such interfaces rather than how these
interfaces have themselves been rendered in terms of the specific programming language(s) or the
technology platform(s). As long as the
ensemble
of the interfaces is maintained, the overall solu-
tion is transparent to their implementations or their changes. However, whenever the processes
change, the component architecture should be able to handle the change by unplugging unwanted
interfaces and plugging in the new ones.
A set of services that work cooperatively for a defined business objective is termed as a business
or enterprise capability. Thus, an enterprise component provides interfaces that offer enterprise
