Remembering the Future

via Stu Charlton . . . Services do not assume that the developer of one service has any authority to change the implementation another service. It assumes that in any distributed system, each participating service is autonomous, allowing each to evolve independently of the other. Autonomy has tremendous implications for how these systems should be designed, and can lead to some new and difficult challenges for building globally optimized systems. Certainly there will be cases when one can control the implementation of another service. A new application may require several services, all freshly developed. Some organizations may have the ability and will to modify existing services where necessary. Those cases cannot be the basic assumption, however, because services want to enable economic benefits of widespread composition, distribution, and re-use, both on the corporate network or the Internet. . . . Controlled software integration Most traditional distributed systems that use COM, RPCs, or even message queue systems are used under controlled environments. Controlled environments imply that there is an ability to modify the implementation of any number of components to integrate them together and support ongoing requirements. . . . Autonomous software integration Autonomous integration assumes that each participant in a distributed system evolves independently from the other. Other components are assumed to be open for extension, but not available for modification. This enables re-use both within and beyond an organization. It too requires standard contracts and schemas among participants, but the message format contains extensible metadata, allowing it to be self-describing. This allows schemas to be defined as loosely coupled smaller fragments of larger messages. A participant can choose to ignore any part of a message that it does not recognize or care about. While published schemas must remain basically immutable, participants are free to evolve by introducing new schemas or compatible changes to existing schemas. The above description is just as easily attributable to past descriptions of "distributed components" or even "object oriented" programming. The difference this time, however, is that the focus is on the shape and standards of the space "in between" software. Prior approaches focused on the language and programming model. The component wars of the 1990's demonstrate that autonomously integrated software really needs to be independent of programming model. . . .