Communication Design Checklist

From Guidance Share

Contents 1 Design Considerations 2 Message-Based Communication 3 Asynchronous and Synchronous Communication 4 Coupling and Cohesion 5 State Management 6 Message Format 7 Passing Data Through Tiers - Data Formats 8 Interoperability Considerations 9 Performance Considerations

Design Considerations

• Unmanaged code is used for communication across AppDomain boundaries.
• Message-based communication is used when crossing process or physical boundaries.
• Round trips are minimized when accessing remote layers.
• Data types that cross physical boundaries are serializable.

Message-Based Communication

• Partially connected scenarios are supported by storing messages and sending them, when a connection becomes available.
• Design appropriately handles a scenario when a message response is not received.
• Acknowledgements are used, to force the correct sequencing of messages.
• A synchronous programming model is used, if message response timing is critical for your communication.
• Custom communication channels are used, only if the default channel does not meet your requirement

Asynchronous and Synchronous Communication

• An asynchronous communication model is used, unless you must guarantee the order in which operations take place, or you use operations that depend on the outcome of previous operations.
• Platform features are used for asynchronous in-process method calls.
• Existing asynchronous calls are wrapped in a component that performs synchronous communication to support synchronous communication.
• Local caches or message queues are used, to store messages for later delivery in case of system or network interruption.

Coupling and Cohesion

• A message-based technology such as ASMX or WCF is used, when loose coupling is important.
• Standard protocols such as HTTP and SOAP are used, when implementing a loose-coupled web service interface.
• Services and interfaces contain only methods that are closely related in purpose and functional area.

State Management

• State is only maintained, if it is absolutely necessary.
• State information is stored in durable data stores in a stateful programming model within a component or service.
• If you are designing an ASMX service, the Application Context class is used to preserve state.
• Extensible objects provided by the platform are used when designing a WCF service.

Message Format

• Binary serialization is used to preserve type fidelity.
• The design can detect and manage messages that arrive more than once (idempotency).
• The design can detect and manage multiple messages that arrive out of order (commutativity).

Passing Data Through Tiers - Data Formats

• If performance is important, custom objects are used to pass data between tiers and to hand serialization.
• DataSets are used if your application works mainly with sets of data, and needs functionality such as sorting, searching and data binding.
• Scalar values are used if your application works primarily with instance data.

Interoperability Considerations

• Standard protocols such as SOAP are used enable communication with a wide variety of platforms and devices.
• The design considers the scenario when target systems might be protected by firewalls that block some protocols.
• The design considers scenario when target systems might not understand platform-specific types, or might have different ways of handling and serializing types.

Performance Considerations

• Chatty interfaces are not used for cross-process and cross-machine communication.
• Façade pattern is used to provide a coarse-grained wrapper for existing chatty interfaces.
• Custom classes are used to implement efficient serialization.
• Network roundtrips are minimized by passing data as a single unit, for example by using the Data Transfer Object pattern.
• The design minimizes the volume of data sent to remote methods.
• XML is only used when you need to pass large amounts of data over the network.