Collaboration by contract
Recently someone who should have known better asked me what's all the fuss about components? He said, "surely a component is just an API". I responded to this with another question saying, "suppose you want to use a Win32 API, what do you need to use it?" He said, "well I would want to see the code, because that's the only way I can know for certain what the behavior of the operating system will be."
This conversation reminded me that not everyone understands what a component is, and how easy it is to talk at cross purposes. I explained that ideally you should be able to use a component without understanding the internals. A component offers two perspectives - its internals, which should only be seen by the designer, and the externals, which should provide all the information needed in order to use it. Basic stuff, you may say, but unfortunately few people, projects and products implement this concept. One reason for this is because components have been adopted as implementations of technologies such as COM, CORBA and EJB's, which are simply packaging concepts. This view of the world was reinforced by UML, although this may change soon. A second reason is that it takes effort to deliver real implementation transparency.
The extra effort required is to create a specification of the external view. This is not a new idea; as long ago as 1950 none other than Alan Turing himself gave a talk entitled "Checking a Large Routine" in which he said, "How can one check a large routine in the sense that it's right? In order that the man who checks may not have too difficult a task, the programmer should make a number of definite assertions which can be checked individually, and from which the correctness of the whole program easily follows." Further, proponents of assertion based design will say that whilst the assertion based specification is an overhead, it can have accompanying advantages in reduction in testing effort, easier reuse and of course quality components.
Design by Contract
Many readers will be familiar with Bertrand Meyer, who refined the assertion based approach into the Design by Contract method and the Eiffel language. The basic idea is that a component and its clients have a contract with each other. The client guarantees certain preconditions before calling a method, the component guarantees certain postconditions after the call. If the pre- and postconditions are included in a form that the compiler can check, then any violation of the contract between caller and component can be detected immediately. The prime focus of the approach is to deliver reliable software.
Design by Contract has wide theoretical acceptance. It is an intrinsic component of the Catalysis Approach, perhaps the most influential of all component methodologies. However its usage has to date been relatively limited, the most prevalent use being in the Eiffel language. I recently reviewed the latest Eiffel products which provide integrated support for the .NET environment (report reference below). There is also some movement in the same direction in the Java environment; Java 1.4 includes a simple assertion capability that provides the essential language integration on which others may build checking mechanisms. In the report I conclude that this design approach for tightly coupled components addresses key issues that organizations have today of quality and trust, and that perhaps after many years in the wilderness, it's time may be coming sometime soon.
Loose coupled component contracts
The reason that tight coupled component design techniques have not gravitated more rapidly towards assertion based approaches is simply that it is not essential. Most components are assembled and tested by the same design team, and the need for specification formality is entirely optional. However by definition (at least external) Web services have to be implemented in a manner that guarantees implementation transparency. The provider does not have any visibility of the consumer applications and vice versa, so Web services protocols have to provide a comprehensive external view of the service.
The initial description protocol WSDL enabled relatively simple stateless interactions, but with the recent introductions of various BPM, Transaction and Coordination protocols we are acquiring capability which allows sophisticated multi-party transactional interactions. What's interesting is to consider whether these protocols will support assertion based specification, as a proven approach to designing high integrity interactions between components.
BPEL4WS and WSCI support for contracts
BPEL4WS is the business process flow language that replaces IBM's WSFL and Microsoft's XLANG and must be the leading contender to become at least the de facto industry standard. It provides a comprehensive structure for describing a business process in detail and it is also the obvious place to describe assertions. However, whilst the language could support assertions through extensibility, there is no first class construct in the grammar.
WSCI is an interface description protocol and is intended to be the external, observable specification of a Service. When it was initially announced earlier this year there was support for the protocol, but more recently it seems there is a little bit of competitive spirit creeping into the protocol development process. However as a pure specification of the interface, we might have expected WSCI to provide explicit contract assertions, but like BPEL4WS the protocol is more general purpose. Using properties it would be quite possible to implement pre- and post-conditional logic, but this would be entirely optional.
The conclusion we draw is that BPEL4WS and WSCI are both focused on non-functional and procedural contracts, and they provide no explicit support for the "business contract" level of abstraction. This is confirmed by Collaxa, a company providing standards-based orchestration, that advise developers could easily create their own rule meta model and BPEL scenario to emulate rule/constraint functionality.
Once again, it seems that we are set to reinvent the wheel. Whilst the XML description protocols provide a comprehensive specification, they do not go the extra mile to create a contractual structure that requires provider and consumer to declare their business responsibilities in a prescribed manner. It may be argued that the protocols are general purpose, and they support a variety of interaction patterns. However we would respond that it is critical that the XML protocols support high integrity interactions and that an optional first order construct that enabled assertions would be a strong encouragement to providers to address integrity issues in their designs.
Without assertions as a first order construct, the business contract will be hidden in the complexity of the overall business process, as opposed to being an explicit property of the service. Also, unless it is an integral part of the language, automation is also more difficult. Of course the more general purpose the protocols are, the more opportunity there is for tools vendors to provide additional and differentiated support for matters such as integrity. However this would be a proprietary layer. We will be reporting in more detail on this area in the November CBDI Journal and will be addressing interaction patterns and how the new protocols assist or otherwise.
Please let us have your comments and feedback. Please send to firstname.lastname@example.org.
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.