Beyond the component-based process
In many ways the software component story has been quite unsatisfactory. The original vision of components envisaged a world where precise specifications enabled component reuse in a manner that was independent of the implementation, because the specification provided all the information needed to use the component. A focus on specification would also allow increased quality, automated testing and certification.
Failure in component reuse is not solely a process issue
The reality has been quite different. Apart from some shining examples such as Eiffel's design by contract-based approach, or Catalysis and its variants, which sadly are used only by the cognoscenti, components have been implementation only constructs. More recently Wilde Technologies has started to address the issue in a different manner, by abstracting the component linkages away from the implementation layer, but it's still early days for this approach. Consequently it's really no surprise that reuse of components has never achieved the promise that the early visionaries expected.
It's interesting to observe the way that the component broking industry has supplemented its products and services with a focus on the reuse process. The component brokers found that supply and sales of components were way below the optimistic predictions made in their venture capital proposals, and the only way to survive was to address the issue of guiding their customers in how to reuse components to encourage acquisition. Not surprisingly this became a major revenue stream in its own right, in some cases replacing component broking as the major activity.
Many people now recognize that Web services are in the process of realizing the vision that was originally set for components, because the service has a comprehensive specification that components lack. A Web service has a formal description in the WSDL that allows simple services to be used independently of the implementation, and by the time that the various XML based specification protocols are finalized we will have a full specification that allows services with complex behaviors to be easily reused with no reference to the implementation.
Component or service-based development?
The original vision for component-based development, first articulated some seven or eight years ago, looks remarkably like the service based world that we are now realizing. The component based system:
- Was comprised of various forms of component, from disparate sources conformed to a common interoperability architecture
- Enabled trusted systems by exposing its component specifications
- Enabled incremental delivery and upgrade
Service based systems comply with these attributes completely, however they do have some important additional attributes. They have:
- Established industry wide protocols that free us from the limitations of platform specific component models
- Increased separation by greater rigor in interface specification
- Additional specifications of management and transactional behaviors
- Plus specifications that address the discovery, trust and commercial aspects of the relationship between service provider and consumer
So, where now for components?
Although it is still very early days, we can confidently expect that services will be much easier to reuse than components, primarily because services are reused as units of business functionality, without reference to the implementation. Whilst you might expect the heuristic that "smaller components are easier to reuse" to apply, the reverse will be true because services are a) still relatively fine grain and b) designed to be widely reused from the business perspective. So much of the reuse that might have been achieved at the component level will happen at the service level.
But clearly components are not going away, we still need fine-grained components that can be assembled into service bearing applications. And here the industry persists in looking down the wrong end of the telescope. The enabler of reuse is the comprehensive and precise specification, and there is little or no interest in the industry, apart from the few examples mentioned above, to address this issue.
We have started to see some interest in new wave processes, such as Service Based Development. Indeed we wrote about precisely this subject a couple of years ago. However, whilst it might be possible to clone and evolve component-based processes into a service-based equivalent, this approach would ignore the profound change that is also taking place in how applications are constructed. Service based applications are fundamentally collaborative. Whilst the select few may have focused on the interface in their component-based development, few have realized the importance of service specification as an integral part of business design. It is this view that allows the development of the Service Bus (the specification of semantic applicability) and the identification of supporting services and components, which in many cases will be supplied not just by acquisition, but by business partnership. The alignment with the business process is a profound change away from popular development and integration processes and techniques that are often more strongly influenced by technical considerations than by business needs.
The Service Based Delivery Process is therefore very similar to the original vision of component-based development, not purely about development, but about managing the assembly of collaborative assets to provide a highly adaptive application solution. However the service based process goes beyond this by making the business perspective an integral part of the application architecture. It would not be unreasonable to say that the Service Based Environment will eventually fulfill the original component vision, however it actually goes much farther than was ever envisaged.
In our report, "Where Next for Component-Based Development," Guest Author John Cheesman, co-author of the Addison Wesley book UML Components, addresses the issue of how component based development must evolve to address these issues. This report is available to Silver and Gold Members at:
Copyright CBDi Forum Limited 2002. The CBDi Forum is an analysis firm and think tank, providing insight on component and Web service technologies, processes and practices for the software industry and its customers. To register for the weekly newswire, click here.
Copyright CBDi Forum Limited 2002. The CBDi Forum is an analysis firm and think tank, providing insight on component and web service technologies, processes and practices for the software industry and its customers. To register for the weekly newswire click here.
For more information:
- Looking for free research? Browse our comprehensive White Papers section by topic, author or keyword.
- Are you tired of technospeak? The Web Services Advisor column uses plain talk and avoids the hype.
- For insightful opinion and commentary from today's industry leaders, read our Guest Commentary columns.
- Hey Codeheads! Start benefiting from these time-saving XML Developer Tips and .NET Developer Tips.
- Visit our huge Best Web Links for Web Services collection for the freshest editor-selected resources.
- Visit Ask the Experts for answers to your Web services, SOAP, WSDL, XML, .NET, Java and EAI questions.
- Couldn't attend one of our Webcasts? Don't miss out. Visit our archive to watch at your own convenience.
- Choking on the alphabet soup of industry acronyms? Visit our helpful Glossary for the latest lingo.
- Discuss this article, voice your opinion or talk with your peers in the SearchWebServices Discussion Forums.