Communication Design Checklist

From Guidance Share

Jump to: navigation, search


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.
Personal tools