Java Reference
In-Depth Information
This has led to the identification of a number of general-purpose archi-
tectures that frequently occur in software programs, e.g. pipes
filters, black-
board, data-centred, event-driven, client
server and layered architectures.
Software architecture reuse is based on the definition of “architectural
styles”, that is the recurring organizational and structural patterns and
idioms used in architectural design (Abowd
et al
. 1993; Garlan 1995). An
architectural style provides a specialized component vocabulary (e.g. the
terms client, server, application server, etc.), a connector vocabulary (e.g.
pipes, data stream, etc.) and a set of rules to build a specific topology using
components and connectors.
Architectural styles improve the communication between designers,
which can refer to a shared terminology for reusing design solutions.
Unfortunately, systematic reuse of concrete architectures and designs is
more difficult than code-level reuse, since a design is not worth much in
itself as a reusable artifact; the design, with its tradeoffs and consequences,
must be understood by the software developer so that the necessary adap-
tations and changes can be performed. Since software architectures are
usually domain independent, no guidance is given to the developer for
choosing the right architecture for the specific application to be developed.
-
7.2
■
Communication mechanisms
The components of an object-oriented architecture interact with each other
to carry on the function of the system. An important step in the definition of
the architecture is the selection of the communication mechanism. In this
part of the topic we consider three main mechanisms.
1
Method invocation
. It is the basic communication mechanism offered by
all programming languages. According to this mechanism, a single func-
tionality is performed by a method. Whenever that functionality is
required the method is invoked. The method behaves like a subroutine: it
delivers the functionality and eventually returns the result. The invoker
and the invoked components are closely coupled.
2
Event-driven
. With this approach a component receives notification that
an event has occurred within the system. In response to the event notifi-
cation, the component can perform some actions. This approach decou-
ples the component that notifies an event and the one that receives the
event notification and allows the components to evolve independently.
3
Message-based
. According to this communication paradigm a component
requiring a service sends a message to the component that provides that
service. The provider component receives the message, parses the
message, performs the corresponding service, and sends back a message
with the result. This approach allows the components to evolve indepen-
dently but forces them to adopt a common communication language and
protocol.
