Second Thoughts on SOA Architecture
When I first joined this SOA team, I questioned the architecture we were implementing. The application flow is basically linear and uses JMS to pass messages between the various functional components. The components themselves were not designed generic enough to be shared by multiple applications. Like I mentioned earlier, the main driver for rewriting this application was for speed.
The whole thing seemed very unSOA-like to me. Since none of the components were reusable outside this application, why not code the entire project in a "traditional" way? This approach would improve performance, replacing the overhead of multiple marshal/unmarshal operations needed for JMS with direct function calls.
My perspective changed (a little) recently when we needed to add new functionality to the system. We could have modified one of the existing components to implement the new feature. Functionally, it made sense to keep this related logic together in a single module.
The main problem with this approach is that we would need to retest the component to ensure we didn't break anything that was already working (and fully tested). Interestingly, this is where the SOA approach worked to our advantage. An alternative implementation would involve simply creating a new, stand-alone component and inserting it into the proper place in the flow - eliminating the risk in modifying already working code.
The second approach plays to the main strength of SOA - it's inherently extensible. Stand-alone services can be combined, inserted, or deleted without affecting the overall stability/reliability of the individual components - all the while gaining the ability to quickly change the composite application's behavior. While reusability would definitely increase the ROI of developing these components, it shouldn't be looked at as the only benefit of SOA.
*****
A "traditional" application can also be designed in this modular fashion, also allowing new functionality to be plugged in through an additional method call. Here you could realize the speed and the extensible benefits described above. The downside in this approach is the complexity integrating new functionality if it happens to be written in a different language than the main application.
Here again, the loose coupling, inherent in SOA architectures works to your advantage. As long as the new ".Net" service can talk via HTTP, MQ or some other messaging standard - this new functionality can be easily integrated into your Java-based or BPEL composite application (and is more attractive than trying to figure out JNI).
The whole thing seemed very unSOA-like to me. Since none of the components were reusable outside this application, why not code the entire project in a "traditional" way? This approach would improve performance, replacing the overhead of multiple marshal/unmarshal operations needed for JMS with direct function calls.
My perspective changed (a little) recently when we needed to add new functionality to the system. We could have modified one of the existing components to implement the new feature. Functionally, it made sense to keep this related logic together in a single module.
The main problem with this approach is that we would need to retest the component to ensure we didn't break anything that was already working (and fully tested). Interestingly, this is where the SOA approach worked to our advantage. An alternative implementation would involve simply creating a new, stand-alone component and inserting it into the proper place in the flow - eliminating the risk in modifying already working code.
The second approach plays to the main strength of SOA - it's inherently extensible. Stand-alone services can be combined, inserted, or deleted without affecting the overall stability/reliability of the individual components - all the while gaining the ability to quickly change the composite application's behavior. While reusability would definitely increase the ROI of developing these components, it shouldn't be looked at as the only benefit of SOA.
*****
A "traditional" application can also be designed in this modular fashion, also allowing new functionality to be plugged in through an additional method call. Here you could realize the speed and the extensible benefits described above. The downside in this approach is the complexity integrating new functionality if it happens to be written in a different language than the main application.
Here again, the loose coupling, inherent in SOA architectures works to your advantage. As long as the new ".Net" service can talk via HTTP, MQ or some other messaging standard - this new functionality can be easily integrated into your Java-based or BPEL composite application (and is more attractive than trying to figure out JNI).
Comments