Information Technology Reference
In-Depth Information
communication. The implementation details of ORB are not visible to the
components. ORBs provide location transparency, programming language
transparency, protocol transparency, and operating system transparency.
The communication between distributed objects and components is based
on interfaces. This enhances maintainability because the implementation
details are hidden. The communication is usually synchronous, although
it can also be deferred synchronous or asynchronous. ORBs are often con-
nected with location services that enable locating the components in the
network. ORBs are complex products but they manage to hide almost all
complexity. More specifically, they provide the illusion of locality—they
make all the components appear to be local, while in reality, they may be
deployed anywhere in the network. This simplifies the development con-
siderably but can have negative influence on performance. A basic outline of
ORB architecture is shown in the next figure.
The differences between messages and interfaces as the method
of integrating are subtle but important. Interface-based integra-
tion requires the specification and implementation of a well-
defined interface that describes the actions that an application
can perform. The interface is associated with an application. Messages
are not associated with any application. In addition, with interfaces, the
actions that can be processed by any application are easy to read and
explicitly stated. Messages, as described previously, inherently hide the
applications that use them. The nature of interfaces usually requires
less processing to decode than a message, and errors are discovered
earlier in the development process. The bottom line is that messages
provide a lower degree of coupling than interfaces at the cost of greater
potential of errors and inability to reuse solutions.
Over the long term, interface-based integration should be easier
to reuse and maintain because the interface is explicitly defined and
visible to the developer while messages can be hidden in the applica-
tions. It does not require looking at the code to see if an application
will respond to a request. Interfaces are self-describing in terms of the
actions that can be taken. With messages, either documentation or code
must be read unless a directory service is provided that maps message
use by application. Interfaces, however, may be more difficult to change
and extend depending on implementation. For example, depending on
the design of a message, control information can be modified with-
out having to change application code. Changes to an interface may
require a compilation of any and all applications to make them effec-
tive. Finally, interfaces require some discipline in the definition of the
interface to allow plug and play.
 
Search WWH ::




Custom Search