There are of course many differences in the technical implementation of Web Services, EJBs, and CORBA objects... but there are not that many conceptual differences. Yes, formatting parameters with XML did open the door of programming language neutrality much wider, but is XML really the killer concept leading Web Services to triumph where EJBs and CORBA objects faltered?
The lasting value of any component technology isn't really due to technical merit (think back on the original Visual Basic components)... it is due to the philosophy and mind-set associated with those who use the components. If the community of users adopts the "right" attitude, the technology will flourish despite technologically superior alternatives (think how long the Mac survived despite under-powered CPUs).
EJBs and CORBA didn't succeed in fostering the "right" attitude for success. Authors crafted components... but those who used the components frequently didn't "get it". Most EJBs ended up tightly bound to specific applications... languishing as just another tier in an "N-tier" application.
The success of SOA is going to hinge on whether or not programmers really grasp the difference between traditional and Composite Applications. Many will grumble that they've been "composing" applications for years by wiring together components. That's true... but the devil is in the details.
There are components, and then there are components. There's wiring components together, and then there's wiring components together. Composite Applications in the SOA context have very specific ideas on what constitutes a component and on how they should be wired together.
SOA is about satisfying business needs, and most of what business needs concerns understanding and improving business processes. I am fairly sure that you have heard the term "Continuous Process Improvement". (CPI) ... but in the event you haven't, CPI is what makes winning companies win. CPI is what propelled Japan's industries from bombed out shells to Global Domination.
Composite Applications enable continuous process improvement. Traditional applications all too often "cast the process in stone". Although software is theoretically easy to change, the sad reality is that many companies are "stuck" with their applications due the the high cost (and risk) of making changes.
Components in Composite Applications closely map to steps in Business Processes. Components are wired together to build processes, but the wiring is "loose". Think plugs and sockets instead of solder.
The "right"type of components and the "right" method for connecting them together go a long way towards enabling Continuous Process Improvement, but it's still not enough:
If you can't see it, you can't fix it.
"It" in this case refers to the activities or services that constitute a Business Process. Composite Applications are not a bunch of Web Services with point-to-point wiring. Composite Applications rely on orchestration engines to coordinate the flow of information between components... enabling rapid change of these applications. Enabling change is a big plus... but how do you know what to change?
Continuous Process Improvement relies on metrics. Monitoring leads to Analysis leads to Improvement. If you don't have the metrics, your attempts to improve a process are based on hunches rather than facts... and that's where the orchestration engine comes in by enabling the efficient gathering of process relevant metrics.
With process relevant metrics, processes can be analyzed, proposed changes can be simulated, and Process Improvement can truly be Continuous... (assuming that your Composite Applications can evolve quickly)
In the final analysis that's the only reason why business care about all of this SOA stuff... improving their businesses.
No comments:
Post a Comment