Next: 3.3 Significance of the Up: 3 Position Previous: 3.1 The problem
Next: 3.3 Significance of the
Up: 3 Position
Previous: 3.1 The problem
Components are independently developed software units which can be composed without knowledge how they have been implemented. To use a component, only the knowledge of its specification is necessary, but not their implementation. This is achieved by an interface that hides the implementation and its implementation model, for example its class hierarchy. This is an important step beyond object-orientation, because the interface is decoupled from the implementation by a distinct class. Because the implementation details of a component are inaccessible for the user, there have to be mechanisms to provide information about the component's specification. The same is necessary for the adaptation of a component to individual requirements which must be possible without knowing about their implementation or changing the implementation. To achieve this goal, components offer two mechanisms, introspection and specialization. Introspection allows to get knowledge about the component's specification without knowing its implementation. Java Beans, for example, have two mechanisms which support introspection. Reflection and the BeanInfo class. Reflection makes it possible to know about all methods following a certain naming pattern without further programming. Whereas reflection is a relatively simple, automatic mechanism, the BeanInfo class gives complex information about a bean, but has to be implemented explicitly. Specialization allows the adaptation of a component without access to its implementation. Specialization in Java Beans is supported by property sheets and customizers. Property sheets offer a simple specialization mechanism by setting the parameters of the bean. Complex specializations can be done by customizers. They can be thought of as an assistant, guiding the adaptation of the bean.
Composite applications play an important role in solving the architectural problem of wfms described above. Composite applications consist of an application document, containing components which interoperate using events. They can be found in many component-based frameworks like Java Beans[Jav97] or ActiveX/DCOM [Cha96]. Composite applications can be hierarchical, which means, a composite application can be embedded in another composite application as a component. Event processing within composite applications is done via connectors, which allow the events sent to a sink to be filtered, dependent on the fulfillment of a condition for example. Only when the condition is evaluated as true, the event is propagated. Furthermore, the connector can execute an action in response to an event. At this point, Event/Actions (E/A) and Event/Condition/Action-rule s (E/C/A) can be implemented (see figure 1).
The propagation of events can also used for connecting different composite
applications. Composite applications differ from approaches based on
event-dependencies like the ones described in [CR90], because there are
no global events. Therefore they avoid the problems of these approaches,
such as combinatorial explosion of the event dependencies. The
rule-processing in composite applications should not be confused with
traditional rule-based systems either. Composite applications use only one
rule to process the events sent from one bean to another instead of sending
global events to a global-rule base. Using centralized rule-processing
would create a bottleneck. Furthermore, rule-based systems have many
problems like indeterminism, unpredictable behavior and performance
problems.
The reliability of the event propagation can be enhanced by using
persistent message queues (see figure 2), which assure event propagation
even in case of a system shutdown. Furthermore, asynchronous operations
allowing the integration of disconnected clients are possible.
An example of composite applications are applications built from Java Beans (see figure 3). They use the event mechanism of Java. It consists of the event source, event sink and an optional connector, called the adaptor in Java Beans. The sink indicates its interest in an event by registering itself to the source or an so called adaptor. After registering, the event source can send events to the sink. If the event sink registered an adaptor, it is possible to implement E/C and E/C/A semantics as described above.
In the simplest case, the events in a composite application carry no information, except for type information. However, since events are often implemented as method calls, as in Java Beans for example, they can also carry information from one component to another.
In order to model the behavior of composite applications, it is necessary to represent their hierarchical structure, therefore the composition of models must be possible. Furthermore, conditional event propagation, which is optionally augmented with the execution of actions has to be represented. State-charts [Har88] are a commonly-used formalism for describing the behavior of reactive systems. They augment traditional automata by allowing the creation of hybrid state automata and hierarchical states. This feature can be used to represent the combination of beans in the form of a composite application and the combination of simple composite applications into to more complex ones. Petri-nets [Pet81], for example, do not allow the composition of nets. Therefore, they are not appropriate for the modelling of composite applications. Furthermore, state-charts allow the definition of conditional transitions, which are necessary to represent the connectors (or adaptors in Java Beans).
Rainer Schmidt
