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
CategoryPattern