The concept of a service-oriented architecture (SOA) is a key part of the OsEra equation. In our business-driven approach to SOA, the application service interfaces provided by information systems correspond closely to the business services those systems support. In effect, the service manager components from the PIM system architecture provide technical implementations as application services of appropriate business services defined in the CIM.
Work roles in the CIM that ultimately carry out business services. In the PIM, we must, therefore, specifically include components in the system architecture that implement the work roles being supported by the system.
For example, consider the Receivables Management work role. As shown in Figure 4, this work role provides two business services: Customer Order Establishment and Receivables Establishment. Assuming that both these business services are to be automated in the system architecture, we should have two corresponding service manager components in the PIM corresponding to them. This is shown in Figure 6.
In addition to the service manager components implementing the business services, Figure 6 shows additional supporting components added in the PIM. These include an explicit Receivable Scheduler in the application tier for the triggering of recurring receivables as well as components for data management and the presentation of a user interface. There is also an explicit role for a human Receivable Specialist to participate in the process, via the user interface. Even in a highly automated process, human participation is generally required for monitoring and approval, and to make any necessary manual entries to handle unexpected situations. This human participation be clearly accommodated in the PIM.
The EDOC notation used in Figure 6 is consistent with that used in the CIM for showing role decomposition and collaboration. However, the UML notation is a much more familiar one to systems implementers, an important intended audience for presentation of the PIM. Therefore, the enterprise has expressed a preference for PIM models to also be expressible in UML.
Figure 7 shows the same model as in Figure 6, but in UML 2 notation. In this notation, the work role from the CIM is represented as a UML composite component. The composition of this component is then a collaboration of system components in the PIM. Protocols in the EDOC notation become ports on components in the UML 2 notation.
Service Manager Components
Service manager components are defined to implement the activities from a work role related to a specific business service. For example, as can be seen in Figure 4, the activities in the Receivables Management work role can be divided in to those that support the Customer Order Establishment business service and those that support the Receivables Establishment business service. Customer Order Establishment is supported by the Establish Unfilled Customer Order activity, which should, therefore, be implemented by the Customer Order Service Manager. The remaining activities support Receivables Establishment and should be implemented by the Receivables Service Manager.
The CIM information model is a conceptual model of business information. For the PIM, it is necessary to have a model of the actual messages used to pass data between system components. Just as the system component interactions are designed explicitly to support business processes, the data model of messages is traceable to the model of business information represented by those data. While the CIM-level information model provides a conceptual formalization of the business vocabulary, the messaging model records logical design decisions on the actual structure of messages to be interchanged by components.
Just as the CIM information model represents remembered as well as flowing information, the PIM also includes models of the persistent data that is managed by data manager components. This persistence model records logical design decisions on what data needs to be stored and how it is managed by the data manager. The persistence model also balances the messaging model. The messaging model represents what data is sent, and the persistence model represents what data is stored within each data manager component for future messages to reference.
This direct representation of the connection between the persistent data and message data, related by a logical information model, is an exceptional feature of our approach.
Platform Specific Model (PSM)
The PSM is the model based representation of OsEra components as they will be deployed on a specific infrastructure—or platform. The PSM is the lowest level of model in the MDA stack and the direct precursor the platform specific implementation (or PSI). A platform, combined with a model provides for an “Executable Architecture”. The PSM for SOA utilizes the Enterprise Service Bus.