How do you model a service broker (or comparable component, for example a workflow handler or a middleware-type component)? On one hand it is clear that the broker is the center point of all services, but on the other hand it is not visible which application produces which service (via the broker). The goal of a broker is simplification of the many relationships between different applications. Sometimes the following modeling pattern is used:
- Figure 5 31: Service broker related to applications - undesired
A disadvantage of this way of modeling is that it is no longer evident which application delivers which service. It is also desirable to hide or unhide the broker (and its service) when required. This is not possible with the above modeling pattern.
The core of the solution is in relating the applications and application services on one hand (the application realizes the corresponding application service), and relate the application services and the broker service on the other hand (the broker service aggregates the application services). The situation described above will then be modeled as follows:
- Figure 5 32: Service broker related to applications - desired
By generating different views (and leaving out certain relationships or showing these in a nested manner), different focal points can be achieved. In the following figures the relationship between applications with and without a broker and the role of the broker are visualized.
- Figure 5 33: Service broker related to applications - views
By modeling a broker and a broker service as shown above, it becomes possible to either show or hide the broker at will, which will improve the insight of the model for different stakeholder groups
Relationships with other good practices
The service broker is part of the application landscape. Refer to good practice ‘Application landscape’.