- Objectives
- The Black Box Perspective
- Facets of Observable Dependencies and Behaviors
- Example: Sales Order Service
- Characterizing Observable Dependencies and Behaviors
- Some Composites May Not Be Suitable for Black Box Characterization
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Some Composites May Not Be Suitable for Black Box Characterization
For the black box approach to work, the component must appear to be a coherent whole. For a monolithic self-contained component, that’s not a problem. But for a composite, a component comprising other components (Figure 5-21), some conditions must be satisfied for it to be treated as a black box:
){kind=link}
Figure 5-21:Black Box Perspective
- It must (to all appearances) be managed as a single unit.
- It must have a single organization responsible for its operation.
- Access to the constituent parts must be exclusively through the interface(s) of the black box. Note that this does not preclude exposing a sub-component’s interface as one of the composite’s interfaces.
Key indicators that the composite is not a black box include
- Different organizations are responsible for operating (starting and stopping) different parts of the composite.
- Decisions to start and stop the composite are separate from decisions to start and stop its component parts.
- A component part can be accessed directly via its own interfaces, interfaces that are not declared to be part of the composite’s interfaces. This is particularly important when the constituent component is stateful.
An example of a component that should not be treated as a black box is a service (interface) wrapping the functionality of a stateful back-end system that other solution components access directly. In this situation, state changes made via the service interface may be visible through the back-end system’s interface, and vice versa. Characterizing the observable behavior of the service will not explain the state changes that are visible through the service interface but did not originate as the result of a service interaction.
Any of these conditions make it important for the user of the composite to be aware of the composite’s architectural structure—aware of those components that are independently accessible or managed. Under such circumstances, you can’t treat the composite, including its component parts, as a single entity—a black box. Instead, each of the components becomes a black box in its own right. The context and usage scenarios for the “composite” then indicate how these supporting components collaborate with the composite.