Case Studies
SOA Prototyping: Avoiding Pitfalls
Traditionally, when two companies embark on a merger, there is a complex and time-consuming process governing the sharing of sensitive information and documents. In the past, such a transaction would require the parties to physically move the documents to a neutral location for review by lawyers. There, a security officer would monitor and control access to the documents. One of Chariot Solutions' clients has virtualized this process - providing online spaces where access is programmatically monitored and controlled, and changes tracked securely.
With the service gaining popularity and being leveraged by thousands of companies worldwide, the provider identified new vertical markets whose regulatory requirements would allow them to benefit from its secure virtual information spaces. A next-generation release of the product was planned to streamline and simplify other document-intensive business processes. The new version would support additional vertical markets and their associated business models and document types.
With a successful legacy system already deployed, the company realized that the new system would need to gradually replace the old one - as opposed to a sudden switchover from old to new. Since the migration would be over time, there would be instances when a company would have "spaces" on both the old and new platforms, so the data associated with the legacy platform had to be kept available at all costs. But with the new platform involving a different, more complex database structure to support multiple verticals, the disparate security requirements between the two systems posed a set of daunting challenges.
For example, if a user with access to secure spaces on both platforms left a client company, that person would have to be disabled in both environments. Ideally, disabling this user in the old environment would automatically and immediately disable him/her in the new one as well.
Navigating a Large, Complex Course
The client determined that a Service Oriented Architecture (SOA) might provide a solution for maintaining the data between the two disparate systems. Then they engaged Chariot Solutions to prototype a mechanism that would ensure a consistent security scheme across both platforms, and to provide a migration path from the legacy platform to the new, multi-faceted system.
Mule was selected as the Enterprise Service Bus for the project. Mule, a widely used open source integration platform for moving and managing data between disparate enterprise systems, supports a wide range of integration challenges. It is routinely leveraged to securely and reliably move mission-critical enterprise data. For this reason, it is emerging as the messaging backbone of choice for many of the world's most high-performance, multi-protocol environments.
Chariot knew that this would require an XA transaction. An XA transaction is global by nature, and spans multiple resources. The only protocol that supports XA transactions "out of the box" is the Java Message Service (JMS). This messaging standard enables reliable, asynchronous distributed communication between application components based on J2EE. However because these transactions dealt with security data this project required a guaranteed update across all data sources. If the update failed on one system then all systems must all rollback. A synchronous protocol was required.
Chariot's architects understood how to configure JMS to behave in a synchronous fashion. They also understood that when a JMS message is sent within the scope of an XA transaction the recipient does not "see" the message until the transaction is committed. This meant that the requirement to propagate the updates across multiple systems within the scope of a single XA transaction could not be met.
Leveraging work done in it's SOALab Chariot developed a prototype based on Mule and JMS to demonstrate the challenges and present possible approaches. The most viable solution was the introduction of compensating transactions. This, however, presented even greater challenges in terms of performance and maintainability due to the complexity of the business rules governing the data. Ultimately it was recommended that the client opt for a more traditional data replication strategy involving the Java Remote Method Invocation (RMI) API.
The most important aspect of Chariot's involvement in the project was the ability to rapidly prototype the clients use case. Doing this early in the development cycle enabled the team to recognize where the pitfalls and hurdles would be and enabled the system to be designed correctly. Chariot's expertise in SOA and the associated platforms and tools allowed the client to make informed architectural decisions in advance of the new platform's scheduled deployment - ensuring a smooth transition.
