The WSO2 platform provides all the capabilities to address two common architecture patterns — Master Data Management (MDM) and Event Driven Architecture (EDA).
The integration of these two powerful ideas allowed a System Integrator (and WSO2 customer) to refactor and modernize their architecture in their latest release, and roll that out smoothly to their customers. The new architecture centered around the MDM and EDA patterns. Built-in facilities enabling MDM and EDA patterns played a factor in choosing the WSO2 SOA-based Middleware Platform.
The existing application software includes a number of RDBMS data repositories, exposed through application-level APIs from various systems. Requirements for the new architecture included the reuse of the existing data as well as support for updates to the existing data stores from messages originating in the new architecture. Even though existing data was reused, the existing data model was not proving a good fit with the new architecture. Therefore converting the data to a new data model also became a key requirement. The MDM pattern fulfilled these two requirements by connecting to the data repositories and converting the data into a universal data model.
The WSO2 platform sports a number of features useful for implementing MDM. The OxygenTank article Implementing MDM Patterns on WSO2 SOA Platform describes a pattern called Service Adapters that applied neatly to this situation, leveraging the legacy APIs for data access. The adapters were coded in Java and deployed in the WSO2 Application Server. WS-Transfer facilitated transformation of the data models and exposed the new universal data model through XML Web Services.
The message exchange pattern (MEP) used to integrate the application components was pub-sub (publish and subscribe), bringing EDA into the picture. Pub-Sub extends the loose coupling of a SOA, allowing new data sources to be integrated by a simple publish/subscribe operation. The WSO2 Enterprise Service Bus’s native support for the WS-Eventing standard allows it to act as an event broker, while extending mediation capabilities to any pub-sub interaction as well as providing all the QoS controls available within the ESB.
By introducing a controller into the architecture, more sophisticated event flows are possible, controlled by business processes and rules. In this architecture, the controller was implemented by using WSO2 Application Server and WSO2 Business Process Server, and combined standard JAX-WS based services and rules defined in BPEL.
Dynamic discovery emerged as a key requirement to avoid tightly coupling of service endpoints. The combination of WS-Discovery support and a compatible service deployer, endpoint availability is published as each service is deployed.
Integration of a Registry/Repository was identified as a key requirement to store service and configuration metadata as well as to enable dynamic metadata look-up. These facilities are provided by the WSO2 Governance Registry, which in addition to a metadata store hosts the topic store for topic-based event subscriptions.
The logical architecture solution above maps to a variety of deployment patterns for different clients of the system integrator, meeting their individual demands for scalability, high availability, infrastructure constraints, and so forth.
The application of aspects of Event Driven Architecture to the problem of Master Data Management adds flexibility and increases the advantages of loose coupling so prized in modern SOA solutions. We hope the pattern described above gives you some ideas of how your current integration challenges can be approached.
Asanka Abeysinghe, Director of Solutions Architecture
Asanka’s blog: http://asanka.abeysinghe.org/