How to Define a Protocol for Object Transportation Klaus Marquardt Käthe-Kollwitz-Weg 14, D-23558 Lübeck, Germany Email:
[email protected]
Abstract In distributed systems, objects are transported and addressed via network connections. A protocol for object transportation helps to cross the mismatch between objects with state and behavior, and a flat transport presentation. There are different strategies for approaching such a protocol definition. The choice of an appropriate process does not only have a technical impact, but also determines management practices and influences the team structure. This paper introduces the two major definition process patterns, PROTOCOL-FIRST DESIGN and PROTOCOL-FOLLOWS-APPLICATION DESIGN. Their impacts on management, team structure, implementation, integration and maintenance are compared in detail. A number of definition practice patterns balance the strengths and weaknesses of the fundamental positions.
Introduction Most complex systems are faced with the necessity to transport data between different nodes or devices using a network or simple peer-to-peer connections (like serial interfaces). Each application needs to define which kind of data it would like to exchange, and which action the transported information should initiate. The challenge of an object protocol definition is to match application objects with a flat network message presentation. The definition of remotely initiated actions is the topic of a related paper [Marquardt]. Within distributed software, the process how a protocol is defined is at the heart of the development process, and predestines further development. You can specify your application level protocol using one of two basic approaches. Either you follow a protocol-centric process and plan an early explicit development step as in PROTOCOL-FIRST DESIGN, which may include the selection of an existing protocol standard; or you choose a responsibility-centric approach and define your application objects first and allow each of them to define a small protocol part on its own, as in PROTOCOL-FOLLOWS-APPLICATION DESIGN. Both positions solve the same problem with a different weight between similar forces, thus showing different advantages and liabilities. The consequences cover both management and technical issues, and are compared with respect to several aspects to support a project lead’s decision. As always, real life’s wisdom lies in compromises. Any project shipping products with a long product cycle would like to gain all advantages: a development free of restrictions and at a fast pace, delivering stable products and a reusable protocol definition. A collection of definition practice patterns allows you to balance the fundamental process positions. Some of them focus on process, others on technical solutions: •
PROCESS PER SCOPE helps you distinct different areas within your project, and select the most appropriate process for each part of the project;
•
TRANSITION OF VIEW helps you to change your process during the projects’ course, and is especially useful for the definition of new proprietary protocols that may be published after project completion;
•
MANUFACTURER Record adds technical flexibility to your protocol, and allows you to evolve a published protocol to some extend;
•
EXTERNAL PACKER introduces a technical separation between your application domain objects and the protocol definition and allows for independent evolution of them;
•
INTERPRETABLE PROTOCOL gives you a technical option to allow unrelated devices to access an otherwise application specific protocol.
All of these definition practice patterns can be combined with each other and help you to adjust the benefits and liabilities of the fundamental process patterns to your situation. The definition of a protocol requires consideration of a lot of technical issues. On application level these contain shallow versus deep copy of object hierarchies, object identification and associations, and creation of new objects versus update of existing objects. Apart from the application you also need to care for sessions, a uniform presentation, and performance considerations. For a discussion of these and further topics please refer to the literature (such as [Riehle+]).
Process Pattern: Protocol-First Design Also Known As Context
Central Protocol Definition, Protocol Backbone You are constructing a system that is distributed among different processors or processes. The devices or nodes within your project may be inhomogeneous with respect to their CPU’s, computer languages or available services. Further extensions to your system are foreseen, or you need to interface to existing systems using an already defined protocol. You have a solid understanding of the application domain. The system shall be implemented using object-oriented techniques, or a mixture of different techniques. The development team is possibly large and distributed. You are about to start development.
Problem
Data needs to be updated consistently between different processors. Services that are running on a different processor need to be accessible. Though only flat messages can be transported, objects need to be transmitted or be accessible across this message presentation.
Forces
•
The protocol has to be published for access by other parties.
•
The development process must support separated or distributed teams.
•
The protocol definition process implementation of a specific device.
•
Different aspects of the application and its technical infrastructure should be developable independently.
•
System parts must be tested in isolation.
•
The system evolves, and additional knowledge is gathered during its development.
should
not
influence
the
Solution
Define the protocol first. Let the application follow. All messages between the processors are defined before you spend major effort in application design or production code. Each processor in development must conform to the protocol. Use an existing protocol standard when you find an appropriate one, and publish you selection and selection criteria. If you need to define a protocol on your own, involve participants from all related development groups. It covers all application aspects, the system’s use cases and its key objects. As the protocol defines the features and usability of the system, you should consult developers with extensive domain expertise. The protocol must cover both a wide application range and a sufficient level of detail to be useable. Document the protocol and release it before the actual development phase begins. The released protocol becomes the backbone of the application. The application creates and interprets the protocol messages and initiates appropriate actions. To keep the domain specific application objects technically independent of protocol related issues, you might want to create a translation unit that interfaces between application objects and the protocol.
Consequences
PROTOCOL-FIRST DESIGN offers important benefits. J It inherently supports the publication of the protocol, as the protocol definition document is its major result. J The boundaries between different (sub-) projects and their responsibilities are easy to spot. J Different devices could be developed in parallel with minimal coupling. J You can develop any device without having to deal with a required development or run-time environment, or a prescribed development process. J An external listener can interpret all messages. This allows building semantic network monitors that support debugging. J Test devices can be created in advance of the product. These can serve as a black box reference during test, integration and production. J You can probably use an existing domain specific protocol standard that saves definition effort. Some consequences of PROTOCOL-FIRST-DESIGN may bring you benefits or liabilities depending on your situation. K When this process is not close to your previous process, the change in the way of working and thinking may slow down the development and decrease the team motivation.
K The record contents probably biases your decisions about objects’ roles and responsibilities, which binds you tightly to the protocol and inhibits an independent system analysis and design. However, PROTOCOL-FIRST DESIGN brings some liabilities. L Defining a protocol up front is error prone and tedious, especially among large or distributed teams. L A deep understanding of the domain is required up front. L The protocol cannot be proven to be correct and sufficient for your purpose before the system is actually implemented. L Prepare to revise the protocol and step back through some development phases. Be honest: your first version will not work. L The protocol does not explicitly enforce behavior related to the transmitted data. Different interpretations of this behavior in different devices are a likely cause of integration problems. L Protocol changes are expensive and affect most other software. L Devices may fail to implement the protocol correctly. Implementation
The key decision is whether you prefer this PROTOCOL-FIRST DESIGN process against a PROTOCOL-FOLLOWS-APPLICATION DESIGN process. The protocol as a documented boundary between devices is a great help for separating different projects from each other, and let them evolve independently. It is especially useful to define the protocol early when the hardware is also under development, and you want to keep hardware and software development for each device within one team. Two major risks of this process must be addressed explicitly. They are typical of a process with defined explicit transitions between phases, such as a protocol definition, compared to more lightweight processes.
Counterindications
•
Anticipation of the future. Keep yourself from trying to anticipate too much. Where you are insecure, have incomplete knowledge, or expect late extensions, try to use one or more of the definition practice patterns.
•
Late integration. Keep a focus on integration to prevent the independent proceeding project from drifting apart. Your project plan must foresee early milestones that integrate major components from both sides of each message. Keep in mind that transported data does not describe behavior or responsibilities of the connected components.
An overly tight schedule or insecure project funding is a decisive counter-indication to PROTOCOL-FIRST DESIGN. If you are faced with the necessity to produce usable results as soon as possible, a lightweight process with a focus on immediate customer value will be more appropriate for you. A protocol published before production code is only valuable when it can be used independent of the particular project. In this case try to establish a separate project for the definition of the protocol.
Known Uses
Telecommunication protocols. Protocols in telecommunication networks are often the result of committees that have worked for months or years. They allow different vendors and providers to inter-operate and use the same network and infrastructure. ASTM [ASTM], HL7 and other published and standardized application level protocols are designed in workgroups. These protocols let otherwise unrelated devices exchange data. Some protocols have become standards in their domain and are supported by virtually any respective product, like HL7 in the domain of patient data management systems. Embedded systems that consist of several processors often define the protocol early in the system development. However, these protocols are typically proprietary and not published.
Related Patterns
PROTOCOL-FOLLOWS-APPLICATION DESIGN. While PROTOCOL-FIRST DESIGN is common in embedded systems, PROTOCOL-FOLLOWSAPPLICATION DESIGN is typically applied in Client/Server systems. PROCESS PER SCOPE helps you to overcome the problems with integration and development speed for some identified parts of your project. TRANSITION OF VIEW allows you to do PROTOCOL-FOLLOWSAPPLICATION DESIGN during the initial project phase, with faster software evolution while you are still learning about your application. MANUFACTURER RECORD gives your defined protocol room for extensions after its publication and helps you to reduce the protocol maintenance costs. EXTERNAL PACKER helps you to separate your application object analysis and design from the protocol specification. It also allows your application to connect to an already existing protocol that you decide to use.
Process Pattern: Protocol-Follows-Application Design Also Known As Context
Growing Protocol, Peripheral Protocol Definition You are constructing a system that is distributed among different processors or processes. The devices within your project are homogenous with respect to their computer languages and available services. A distribution mechanism can be anticipated or is already defined. You have no requirements to interface to other systems. Your domain knowledge is limited, and important key application objects are waiting to be discovered. The system shall be implemented using object-oriented techniques. You are about to start development, not much code has been developed so far.
Problem
Data needs to be updated consistently between different processors. Services that are running on a different processor need to be accessible. Though only flat messages can be transported, objects need to be transmitted or be accessible across this message presentation.
Forces
Solution
•
The system evolves, and additional knowledge is gathered during its development. You cannot completely specify it in advance.
•
Different aspects of the application and its technical infrastructure should be developable independently.
•
The limitations of the distribution must not hinder the discovery and late changes to application domain objects.
•
You need to show the project’s progress and integration early and often.
•
Depending on the project’s success, the distribution protocol has to be published for access by other parties.
Define the application first. Let the protocol follow. Define the protocol for each application class separately, and maintain it in the application implementation only. The process does not prescribe any phases, but to make it work you must establish a policy to integrate your system often. Choose PROTOCOL-FOLLOWS-APPLICATION DESIGN when you can use an existing 3rd party distribution mechanism, or when you value system integration over protocol publication. The objects are responsible to define their own transport presentation, probably in collaboration with associated read/write strategies. The protocol is present in code instead of a separate document, and is considered to be a hidden implementation detail. Technically, each application class to be transported is derived from Serializable [Riehle+] or a variant of it. Transport messages consist of one or multiple serialized objects, and are send to a receiving object defined through Transparent Remote Access [Marquardt], e.g. For data synchronization, some remote objects serve as Synchronizer [Silva+].
Consequences
PROTOCOL-FOLLOWS-APPLICATION DESIGN offers important benefits. J Additional objects can be developed and added after parts of the application are ready. No deep domain knowledge is required at project start. You can cope with an unstable specification. J Different aspects of the application and the technical domain can have different development speeds. The problems are solved independent of each other. J Development takes only small steps that are known to be working on top of the previously reached state. J You can build and demonstrate your application without relying on probably not-yet-ready transport mechanisms. J The code is always consistent with the protocol. Misunderstanding or misinterpretation of transported data is avoided by explicit coupling to objects and responsibilities. J You can use an off-the-shelf distribution mechanism that implements the protocol and saves definition and implementation effort.
Some consequences of PROTOCOL-FOLLOWS-APPLICATION DESIGN may bring you benefits or liabilities depending on your situation. K When this process is not close to your previous process, the change in the way of working and thinking may slow down the development and decrease the team motivation. K Shared code among different devices couples their development, but accelerates your system integration. However, PROTOCOL-FOLLOWS-APPLICATION DESIGN brings liabilities. L Distributed teams are hard to manage due to the kind of coupling. L No single instance can decipher all messages. Depending on the implementation, no instance can decipher a particular message alone. L For publication the protocol must be extracted from many discrete implementation files. L The protocol is probably hidden within a 3rd party distribution mechanism. Future users are forced to use the same mechanism. Implementation
The key decision is whether you prefer this PROTOCOL-FOLLOWSAPPLICATION DESIGN process against a PROTOCOL-FIRST DESIGN process. Establish your project as a continuously growing and integrated effort of a collocated team. If the project has a history with respect to protocols, check whether some of the definition practice patterns can help you. If the team is distributed, take measures to bring it together frequently (physically or virtually) so that it can be treated as one team. Avoid a team structure that is organized according to the hardware components of your product, prefer an application driven organization structure instead. Preferably employ a commercial off-the-shelf distribution mechanism to save implementation effort, but be aware that it takes the protocol ownership from you. Consider implementing your own mechanism if it is likely that your product will evolve in the future and be integrated with unrelated software and devices. You need to ensure that the increased development effort is compensated by the future extensibility option. Otherwise you might define a separate protocol in addition to the one defined by your tools, and link your application to it only when you need to. PROTOCOL-FOLLOWS-APPLICATION DESIGN supports a lightweight development process (such as Extreme Programming [Beck]). It focuses on minimal risk and effort, and on immediate customer value.
Counterindications
Your application gathers its main value from connecting to an existing published protocol. When your team or your management is not willing to follow this process, you should not use PROTOCOL-FOLLOWS-APPLICATION DESIGN unless you can afford to spend effort in convincing people. If your team and your management do not trust each other, the project might not survive a longer time without the formal release of defined deliverables.
Known Uses
This approach is common among projects that use a commercial distribution mechanism, such as EJB, CORBA, DCOM or COM+, or a distributed (object-oriented) database. The protocol is generated by the tools, according to the specification of the application domain objects. A textbook example about a traffic control system can be found in [Booch, chapter 12.2]
Related Patterns
PROTOCOL-FIRST DESIGN. While PROTOCOL-FOLLOWS-APPLICATION DESIGN is typically applied in Client/Server systems, PROTOCOL-FIRST DESIGN is more common in embedded systems. Serializer [Riehle+], and Transparent Remote Access [Marquardt]. These provide the technical infrastructure to support the process. PROCESS PER SCOPE helps you to overcome the problems with protocol publication and shared code for some identified parts of your project. INTERPRETABLE Protocol gives you a technical option to allow unrelated devices to access an otherwise application specific protocol.
Consequences of the Fundamental Processes Protocol-First Design Project Structure
Project Coupling
Required Experience
Protocol-Follows-Application Design
J The boundaries between different (sub-) projects and their responsibilities are easy to spot. J You can assign a processor to a separate team, covering both software and hardware.
J Your team organization does not depend on devices or processors. J Software can evolve without depending on hardware or other systems. L Distributed teams are hard to manage.
J Different devices could be developed in parallel with minimal coupling.
J The coupling through shared code simplifies integration. L Shared code among different devices couples them closely.
J Inexperienced OO developers J No deep domain knowledge have a starting topic they are is required at project start. probably familiar with. K When this process is not close K When this process is not close to your previous process, the to your previous process, the change in the way of working change in the way of working and thinking may slow down and thinking may slow down the development and decrease the development and decrease the team motivation the team motivation L A deep understanding of the domain is required.
Protocol-First Design Progress, Tracking
Effort
System Consistency
Software Evolution
Protocol-Follows-Application Design
L Before the system is actually implemented, the protocol cannot be proven to fulfil your needs. L The release of your protocol is no indication for your progress in development.
J Demonstration of milestones is simple, and progress is visible early. J Development takes only small steps that are known to be working on top of the previously reached state. L It is hard to see the protocol behind the application.
J You can use an existing domain specific protocol standard that saves definition effort. J A known protocol can be a strong backbone for the development of a system of independent processors. L Defining such a protocol is tedious, especially among large or distributed teams.
J You can use an off-the-shelf distribution mechanism that implements the protocol and saves definition and implementation effort. J Reusing shared code decreases the development effort of further devices. L Developing code that is shared among different platforms requires increased effort.
J A central protocol definition can address important technical issues, such as shallow versus deep copy, ID mechanism, or little versus big endian. L Devices may have failed to implement the protocol correctly. L Different devices may interpret the protocol-related behavior differently, leading to integration problems.
J The code is always consistent with the protocol. J Misunderstanding or misinterpretation of transported data is avoided by explicit coupling to objects and responsibilities. L There is no way to ensure the consistency of important technical issues, such as shallow versus deep copy or ID mechanism.
K Software evolution is bound to hardware and network connections. L Changes and late additions to the protocol affect most other software.
J Additional objects can be developed and added after parts of the application are ready. J Additional devices and network nodes can easily be added.
Protocol-First Design Software Structure
Performance
Debugging
Testing
Publishing
Protocol-Follows-Application Design
L Large parts of your J Different aspects of the application depend on the application and the technical protocol specification. domain are independent of each other and can have L The protocol determines the different development speeds. location of the remotely available services. J The location of execution of services and application logic L Your object design will likely is transparent to the clients. follow record contents instead of analyzed responsibilities. K Real time issues can be documented. K The performance of the protocol can be specified.
L Real time issues are not explicitly covered. L Performance tuning and bandwidth optimization can not take place on this layer due to the lack of a central instance.
J An external listener can L No single instance can interpret all messages. This decipher all messages. allows building semantic Depending on the network monitors that support implementation, no instance debugging. can decipher a particular message alone. J Test devices can be created in J Classes are testable in isolation. advance of the product. These can serve as a black box J Development takes only reference during test, small steps that are known to integration and production. be working on top of the L The protocol cannot be previously reached state. proven to be correct and sufficient for your purpose before the system is actually implemented. J The protocol can easily be published and referenced.
L For publication the protocol must be extracted from many discrete implementation files. L The protocol is probably hidden within a 3rd party distribution mechanism. Future users are forced to use the same mechanism.
Protocol-First Design Versioning
K Versioning requires a strong set of rules and restrictions. L The code may be inconsistent with the current protocol version definition.
Protocol-Follows-Application Design
K Versioning requires a strong set of rules and restrictions. L All devices or nodes must be updated simultaneously when some protocol implementation part changes.
Practice Pattern: Process Per Scope Context
The project under development consists of several devices with different properties, and connects to devices also used by other projects.
Problem
Neither PROTOCOL-FIRST DESIGN nor PROTOCOL-FOLLOWS-APPLICATION DESIGN is appropriate for the whole project.
Forces
Solution
•
Each connection to an existing device should get the advantages offered by PROTOCOL-FIRST DESIGN.
•
The distribution among new developed devices, which can be seen as proprietary to the project, should get the advantages offered by PROTOCOL-FOLLOWS-APPLICATION DESIGN.
Follow different processes for the integration of different devices within your system. For each device and connection within your system you need to determine which of the forces of PROTOCOL-FIRST DESIGN or PROTOCOLFOLLOWS-APPLICATION DESIGN match your situation better. Divide your project into different sub-projects, that each covers a scope of devices and connections with the same process preference. After you made this division, stick to the appropriate processes. Apply other definition practice patterns where they are useful.
Consequences
J You gain the respective benefits of PROTOCOL-FIRST DESIGN or PROTOCOL-FOLLOWS-APPLICATION DESIGN for each interface between devices. L You need to divide your project and treat its parts differently. L Some developers have to deal with both processes on the same time and suffer from their respective liabilities.
Example
A medical workstation consists of several embedded controllers. For compatibility reasons, it has to interface with other workstations via the previously published Medibus protocol [Medibus]. While the protocol of the internal system connections is evolving with a focus on system integration, the interface to the Medibus protocol is implemented at a single controller. This controller hosts a protocol implementation layer that accesses only application domain objects, not the internal protocol.
Practice Pattern: Transition of View Context
Your project is a distributed application in a homogenous environment. It is an initial development effort, but the used protocol must be published as an essential part of the project’s deliverables.
Problem
You would like to get the benefits of PROTOCOL-FOLLOWS-APPLICATION DESIGN but you need to overcome its liabilities in protocol publication.
Forces
Solution
•
While the project is under way, your forces demand a PROTOCOLFOLLOWS-APPLICATION DESIGN process.
•
You need to publish the final communication protocol.
Change the view on the protocol towards the project’s end. Begin your development applying a PROTOCOL-FOLLOWS-APPLICATION DESIGN process. After you have gathered sufficient application domain knowledge, freeze the protocol object by object. Start to control and document the stable protocol parts. The final protocol becomes published and serves as an interfacing option for future applications. To make sure that the protocol is reusable, you should implement a converter that links the protocol with your application objects.
Consequences
J You maintain the advantages of PROTOCOL-FOLLOWS-APPLICATION DESIGN during the course of the project. J The developed protocol can be published afterwards. K Future development is bound to the published protocol. L You cannot use a 3rd party product for distribution that takes ownership of protocol parts.
Example
The development of an innovative probe analyzer for pharmaceutical laboratories includes the development of PC based control software with a convenient graphical user interface. The protocol between the analyzer and the PC needs to cover formerly unknown aspects. It is defined during the product development using PROTOCOL-FOLLOWS-APPLICATION DESIGN. The market for laboratory analyzers demands that current laboratory information systems (LIS) can easily integrate them into their present environment, for example via Plug-Ins [Marquardt99]. For this purpose the formerly proprietary protocol is published as a part of the analyzers’ technical reference manual.
Practice Pattern: Manufacturer Record Context
Your project includes the definition of an application level protocol.
Problem
The protocol that you define should not only cover your current needs but also prepare for functional extensions.
Forces
•
You must bring your protocol to closure before you can publish it.
•
You cannot anticipate the kind and amount of future requirements.
Solution
Add fields in each defined transport message for custom extension, and reserve complete messages for custom use. Declare minor fields explicitly as optional. Allow subsequent projects to fill the fields and messages with specific meanings, and to leave out non-mandatory fields. To preserve flexibility for extensions to a single message, prepare for a number of additions. When your protocol uses a field separator, you can allow appending any number of fields at the end of the message. Alternatively you can foresee the addition of a string of unlimited length. For protocol extensions that do not fit into the semantics of an existing message, reserve an ID range for additional messages. Consider using a string as message identifier, to avoid that different extensions interfere with each other. When you keep the ownership of the protocol, you might observe how other applications make use of MANUFACTURER RECORDS, and incorporate missing properties as optional fields in future protocol releases. New products can apply Peripheral Protocol Definition on their protocol parts. Later, you could (again) apply Transition of View.
Consequences
J The protocol can be published even with preliminary domain knowledge. J Further development can apply PROTOCOL-FOLLOWS-APPLICATION DESIGN within the range of its specific additions. J You can integrate commonly requested protocol extensions into the next published version of your protocol. K Only protocol additions are possible, no changes. K Keep in mind that you can add application related protocol items, but cannot change the protocol's behavior on the lower, technical levels. L Extensions from different applications may interfere unnoticed, even though a protocol standard was in place. L Extensions from different applications cannot be combined, and not be interpreted by other products. L Timing and performance aspects cannot be changed.
Application
Here is the MANUFACTURER RECORD pattern from a client's point of view. Consider your distributed application is positioned in a domain where standard application protocols are available and commonly used. However, it offers functions beyond the general protocol abilities. How do you introduce functional extensions to an existing published protocol? Occupy additional fields where your extensions fit into the semantical range of a predefined message. Occupy a new message when you add an unforeseen behavior that leaves the scope of any existing message.
Use PROTOCOL-FOLLOWS-APPLICATION DESIGN to define your specific additions. Use TRANSITION OF VIEW when you need to publish your extensions. Example
The ASTM protocol [ASTM] for data exchange among laboratory devices offers applications to implement their manufacturer specific messages. These custom messages are identified by a string, which prevents some accidental interference. The available standard protocol messages contain a large number of optional fields that each implementation is free to neglect. The Hitachi Elecsys analyzer series uses the ASTM protocol. Most optional fields are left unfilled. The analyzers use custom messages to report and exchange the consumption of reagents – a scenario that was not anticipated by the ASTM standard.
Practice Pattern: External Packer Context
Your application needs to interface to an existing protocol that you cannot influence.
Problem
You want to keep your application objects independent of the protocol.
Forces
Solution
•
Your application and the protocol evolve independently.
•
Your application must be able to deal with each protocol message.
Add a distinct software layer that reads and writes protocol messages, and has access to your application objects. This dependency constellation allows you to develop your application at a pace only limited by your understanding of the application domain. The protocol interface can be added or exchanged at any time. The solution is similar to the Serializer pattern [Riehle+], where different implementations of readers and writers can be employed. However, the reader and writer refer to transport messages here, not to serializable application domain objects.
Consequences
J The application does not depend on the protocol definition. J Your analysis and design are not biased by an existing, possibly inappropriate protocol. J Your ability to understand and implement the application drives the project. L The unpacking of protocol message may leave the scope of a single object, adding complexity to your translation layer. L Depending on your business rules, inconsistent intermediate states may occur during message interpretation. This requires consideration of transactional behavior.
Example
A medical workstation has to interface with other workstations via a published standard protocol (like HL7). The workstation enhances the functionality of previously released workstations with innovative features. For this an unbiased analysis of the revised application domain is necessary. After the development team has made sure that the protocol support can be added at any time of the projects course, it decides to neglect any legacy protocol while it still needs to learn about the application.
Practice Pattern: Interpretable Protocol Context
Your project is a distributed application in a homogenous environment. It is an initial development effort in a new application domain.
Problem
The major protocol items the devices exchange, must be accessible by other clients.
Forces
Solution
•
The application must remain flexible.
•
The protocol must be published at least informally.
•
Different protocol versions must be understandable.
Send each data item together with a description what the data means. This description (meta data) should be readable, unique and concise. Issues of different protocol versions can be resolved with a protocol that can be interpreted at least partly. The interpretation requires merely the recognition of key meta data items. Late additions to the protocol result in meta data items that are unknown to the reader, which may ignore them or leave them for interpretation by a human. Use available or emerging standards like XML that help defining and implementing the interpreter and the transmitted data format
Consequences
J The flexibility of PROTOCOL-FOLLOWS-APPLICATION DESIGN can be at project start. J Intermediate protocol versions can be published and interpreted. J Protocol interpretation becomes possible for any listener. L The protocol is rather verbose. L An interpreter requires more development effort than a simple serializer function, and obtains a run time penalty. L The interpreter cannot be completed while development continues.
Example
Most graphical plotters support the HP-IB protocol that defines commands like “pen up” with a two-letter acronym [HP7475]. Advanced plotters define additional commands that are by convention ignored if not recognized.
Conclusion The patterns show the close relation between technical and management issues, when it comes to development of distributed applications. The two fundamental process positions are often deeply rooted within the local development culture. When a team and its leaders are aware of other options and their chances, a number of practices can be found that help to gain a large number of benefits. The collection of definition practice patterns is not complete, there are probably more practices waiting for a description in a pattern form. The technical implementation of object protocols has already been covered in several pattern publications [POSA2], and commercial distribution mechanisms are available and popular. Though they save a lot of effort, the implicitly bought protocols are not always suitable where a high connectivity is required, and where inhomogeneous products from different vendors are expected to inter-operate. So even in the era of off-the-shelf distribution software, defining an application level protocol is a necessary and valuable task.
Acknowledgements Thanks to Klaus Höllerer for his hints and insights, and Thorsten Petersen for his comments on several drafts. Many thanks are due to Manfred Lange, the EuroPLoP 2000 shepherd of this paper, for his detailed and timely comments. The EuroPLoP workshop participants provided valuable comments that helped me to further improve the paper.
References ASTM
E1238 Specification for Transferring Clinical Laboratory Data Messages Between Independent Computer Systems. In: Annual Book of ASTM Standards, Vol. 14.01, American Society for Testing and Materials.
Beck
Kent Beck: Extreme Programming Explained. Embrace Change, AddisonWesley 1999
Booch
Grady Booch: Object Oriented Analysis And Design. With Applications. Second Edition, Addison-Wesley 1994
HP7475
Hewlett-Packard: HP 7475A. Interfacing and Programming Manual, Hewlett-Packard 1983
Marquardt99
Klaus Marquardt: Patterns for Plug-Ins. In: Proceedings of the 4th European Conference on Pattern Languages of Programs, 1999
Marquardt
Klaus Marquardt: Transparent Remote Access. In: Proceedings of the 5th European Conference on Pattern Languages of Programs, 2000
Medibus
Dräger RS 232 MEDIBUS. Protocol Definition. Drägerwerk AG Order No. 90 28 258
POSA2
Douglas Schmidt, Michael Stal, Hans Rohnert, Frank Buschmann: PatternOriented Software Architecture. Volume 2, Addison-Wesley 2000
Riehle+
Riehle, Siberski, Bäumer, Megert, Züllighoven: Serializer. In: Pattern Language of Program Design, Volume 3, Addison-Wesley 1998
Silva+
Silva, Pereira, Marques: Object Synchronizer. In: Pattern Language of Program Design, Volume 4, Addison-Wesley 2000
