Database Reference
In-Depth Information
Surely, the list is not complete, but we believe that even a short enumeration clearly indic-
ates the master object behind each of them. At first glance, the list looks obvious, so why
have we mentioned these items? This is because we would like to analyze the common
regularities associated with these event types. At least two of them can be easily spotted.
Machine, environmental, and communication (at the service edges) events are most com-
monly synchronous or asynchronous requests. We must receive a transportable form of
the object (EBM/ABM) in order to react to changes on a remote component/layer. Signals
from the embedded Java or hardware sensors are also object-based, as they transport in-
formation about certain changes in an object (for example, the pulse is changed, the
device is booting, the OSGi container is initiated, and so on). These requests are typically
produced (emitted) by a composition initiator (or just the initial sender in simple cases).
Security and business logic events can also be propagated by a request from the current
object handler, where the change occurred. The object handler is not exactly the
application-object owner (or entity service) that could be any of the current composition
members, processing EBO according to business logic (or security policy logic in the case
of security, or both). In this case, when we have complex compositions (business logic) or
lots of environmental data (security logs) to analyze, we have to deal not only with the ob-
ject itself, but with the object's environment as well (please see the figure in Chapter 5 ,
Maintaining the Core - the Service Repository , in the Message section). Simply put, some
changes can go undetected or even misinterpreted if we only take into account a single ob-
ject's visible changes without the object's context. Ultimately, some complex changes can
be registered only by analyzing the context's information during an extended period of
time, and this is true for environmental events as well. Thus, the time-driven object-hand-
ling activation (after event recognition) is the second type of event-driven service activity
initiation. The main difference with request-driven realization is that for time-driven activ-
ation, we need a special type of service agent.
These agents were depicted in the figure in the Automated recovery concepts section in
Chapter 8 , Taking Care - Error Handling , and so we can count at least three major agent
groups:
• Event collectors
• Event aggregators
• Event analyzers
The first type of agent group most commonly is a set of individual adapters/sensors, col-
lecting object change metrics from various sources; we use different colors (deep green)
to indicate that they have little potential of being reused. You will have to add a new ad-
Search WWH ::




Custom Search