Pattern Name: CreateFlexibleMessaging
Aliases: Universal Data Type, Generic Message Channel
Context: Systems exist that communicate for a variety of different reasons. The data that they exchange is configured for the set of problems that the different systems are collectively solving.
Problem: New functions must be supported which have no place in current messaging formats. Each system can be redesigned to support the required functions, but the messaging channel must be adequate to support the new data types as well.
Forces: Current data formats are optimized to support the current set of functions. Adding new types may force current functions to be more inefficient. The systems may require additional infrastructure to support new functions.
Solution: Use a data type that can be converted to the forms that each system and function require. Add a typing component (meta-data) to each message that indicates the category of data as well as any other characteristics that may help administrate the interaction between the systems.
Resulting Context: An extensible data type will enhance the future flexibility and applicability of all the systems involved. The price that is paid by supporting extra infrastructure and transmission bandwidth will easily be compensated for by the gains in ease of use, administration, and viability of the system as a whole.
Design Rationale: Systems designed with only current needs in mind have limited lifetimes. New requirements will make the existing system obsolete, and the ideas that the system embodies will not be as re-usable. The system will not stimulate new functions to appear because it is rigid and unable to accommodate change.
Examples: HTTP, Web Servers and Browsers, String Variables in Scripting Languages
Related Patterns: AlternateHardAndSoftLayers, BeeHive, MultiCaster
-- DavidCymbala
On carrying a type reference in your data: this introduces scalability concerns. Communicating and caching types is an involved business. An alternative is the Perlish method of CompositeTypes. -- PeterMerel
If the types are maintained in a central data space, it's not so bad. Interpreters, the CommonLispObjectSystem, the JavaVirtualMachine, etc. all do this. If the types are distributed, then all hell breaks loose. -- David