I have been talking with people about the evolution of programming paradigms - moving from procedural designs to object-oriented, to component based and now to service oriented. In each move, fundamental reasons can be found on why the developer community chose to make the transition. In looking at the evolution, it is apparent that a couple of common things drove it each time: 1) The desire to create small, manageable modules (division of labor) 2) The desire to increase reusability.
In the early days of object-oriented programming people held great promise for reuse, yet little came of it. A similar story can be told about component based development (CBD).
Reusability through web services appeared to be promising - but so did the others. Before saying why it will work this time maybe it is worth identifying what the obstacles were in previous attempts. The first thing that pops to mind is that reuse in OO and CBD were tied to either a programming language or a vendor platform (e.g. COM, JavaBeans). It is clear that reuse will not work when there is a programming language dependency. It is equally clear that it won't work when the interface technology is promoted by the vendor minority.
Beyond language and interface dependencies, some other issues pop up:
- Reusability via the integrated framework (think Swing, AWT, etc.)
- Lack of knowledge on decoupling techniques
- Immature component registries
Web Service will clearly take away the 'language' and 'platform' issues, but will the other problems be addressed as well?
No comments:
Post a Comment