Four
communication styles
This page is published under the terms of the licence summarized in the footnote.
Abstract
The paper discusses four styles for communication between applications (or application components if you prefer).
However, the communication styles are universal, and apply to communication between people as well.
The communication styles are presented in a sequence ranging from tightly-coupled to loosely-coupled.
The paper is adapted from a Microsoft paper called “Integration Topologies” you can probably find on the internet.
Connected
communication styles
Direct broker / Introduction agent
Disconnected
communication styles
Indirect broker / Mediator / Message broker
Appendix:
Publish/Subscribe mechanisms
The two connected communication styles below are relatively tightly-coupled.
The source/sender application knows the address of the target/receiver application.
Only one receiver receives a particular message.
Often, the sender or receiver has to transform the message format in some way.
Examples: used when one application makes a local or remote procedure call (RPC) to another.
Strengths: simple to implement, fast performance.
Weaknesses: each connection is coded separately, which can lead to duplication of transformation and routing code between applications.
Endpoint changes, when target addresses or protocols change, are costly.
The direct broker coordinates communication between source and target endpoints
It determines the location of a target application.
It establishes initial communication between endpoints.
Thereafter, the two endpoints communicate directly, or via client-side and server-side proxies (as in the Proxy pattern, Gamma etc. 1995).
The direct broker or introduction agent pattern is used in:
· Microsoft Distributed Common Object Model (DCOM)
· Common Object Request Broker Architecture (CORBA)
· Microsoft .NET Framework Remoting
· Universal Description Discovery and Integration (UDDI).
Microsoft's Distributed Common Object Model
(DCOM)
DCOM is example of the Distributed Objects style that uses a direct broker.
Suppose a client object on a source server wants to create and use a server object on a target server.
DCOM locates the target server by using configuration information stored in the registry.
DCOM creates a client-side proxy on the source server and a server-side proxy (or stub) on the target server.
Subsequent communication occurs directly between the proxies using point-to-point connections.
Commonly, the DCOM broker does more work than the server object.
Common Object Request Broker Architecture
(CORBA)
The CORBA standard specifies how an Object Request Broker (ORB) should work.
The standard has multiple implementations; one Distributed Objects style implementation uses a direct broker.
Assuming the server has registered with the naming service, the ORB:
· sends a UDP broadcast on its local subnet to find a naming service (using a bus-based logical topology)
· stores the location of the first naming service that responds to this request
· asks the naming service or the location of the target server
· sets up a client proxy and a server proxy (or skeleton).
All subsequent communication occurs directly between proxies, using a point-to-point connection.
.NET Framework Remoting
Remoting is another example of the Distributed Objects style that uses a direct broker.
The interaction diagram is the same as DCOM; it involves server and client-side proxies.
But it does not directly use a naming service to register and locate endpoints.
Instead of retrieving the server location from the registry, the URL for the server is passed as a parameter to the Activator.GetObject()method.
The channels are registered and the proxies are set up.
All subsequent
communication occurs directly between proxies, using a point-to-point
connection.
The Universal Description Discovery and
Integration (UDDI)
The UDDI specification defines a SOAP-based Web Service for finding and registering Web Services.
At run time, a UDDI server can act as a direct broker between client and server Web Services.
The client Web Service requests the UDDI server to find a server Web Service.
The UDDI server locates the target Web Service and returns its location and configuration to the client Web Service.
The client Web Service then communicates directly with the providing Web Service.
The three disconnected styles below create what is often referred to as a hub-and-spoke applications architecture.
Here, applications do not communicate directly with each other, but communicate instead through some kind of mediator.
This is similar to the Mediator pattern (Gamma etc. 1995) which "keeps objects from referring to each other explicitly, and it lets you vary their interaction independently".
The mediator decouples source applications from target applications.
· Encapsulates, coordinates and controls communication between endpoints
· Registers endpoints (an application is registered or registers itself with the mediator).
· Determines the location of a target application.
· Can transforms data formats: convert messages sent by source applications into the formats required by target applications.
· Forwards communication (likely to be message based) from source/sender endpoint to target/receiver endpoint
The source/sender application sends the logical name of the target/receiver application to the mediator.
The mediator uses the logical name to look up the target application address and pass the communication to the target application.
In the Message Broker variety of the Indirect Broker pattern, communication is exclusively by messages.
Strengths: decouples source and target applications (compared with point to point).
Useful when you need to control communications.
Weaknesses: slower performance than a connected pattern.
This is a highly decoupled Event-Driven Architecture style.
Commonly an Event-Driven Architecture uses a Message Bus with a Pub/Sub mechanism.
The three concepts are separable, but so commonly combined that they are discussed together here.
Message bus
A Message Bus provides three elements:
· A shared infrastructure for sending bus messages to recipients.
· A set of agreed-upon message schemas: a canonical data model.
· A set of common Command messages.
(The notion of a bus originated in the field of electrical engineering where a common bus is used to carry current of a specific voltage and frequency.
The buses found in computer hardware systems include not only common voltages, but also agreed-upon messages such as a data bus and an address bus.)
Publish/subscribe (Pub/Sub)
One or more applications subscribe to receive command or event messages posted by one or more applications.
In the Message Bus context, an application can subscribe to all messages that are addressed to the common bus.
Strengths
Once a Message Bus is established, the cost of adding new applications/nodes is minimal.
Existing publishers and subscribers are unaffected by the addition or removal of others.
Ideally, all applications use the common message schemas and command messages, meaning there is no need for additional translation.
However, on adding a new application to the bus, you may need an Adapter [Gamma95] to encapsulate any translation needed to initially connect with the Message Bus.
Weaknesses
It takes time and effort to create common message schemas, command messages, and shared infrastructure within an enterprise.
Gaining cross organizational agreement to these common elements may be difficult and time consuming, or even impossible.
This is arguably most decoupled style of all.
Event senders and receivers communicate via shared data space.
Senders post events in some kind of data store.
Receivers, when they want an event, look for it in the data store.
There is no need for an active mediator, though all event senders and receivers do need access to the same data space.
Appendix:
Publish/Subscribe mechanisms
The Pub/Sub mechanism is not limited to the Message Bus mechanism.
And Message Bus implementations vary significantly depending on the kind of Pub/Sub mechanism they employ.
There are three Pub/Sub pattern variations:
· List-Based Pub/Sub,
· Broadcast-Based Pub/Sub, and
· Content-Based Pub/Sub.
This pattern advises you to identify a subject and to maintain a list of subscribers for that subject.
When events occur, you have the subject notify each subscriber on the subscription list.
A classic way to implement this design is described in the Observer pattern (Gamma etc. 1995).
When you use this pattern, you identify two classes: subjects and observers.
Assuming you use a push model update, you
· add three methods to the subject: Attach(), Detach(), and Notify().
· add one method to the observer—Update().
All interested observers register with the subject by using the Attach()method.
As changes occur to the subject, the subject then calls each registered observer by using the Notify()method.
An observer works fine if you have created instances of objects that reify all your observers and subjects.
An observer is especially well suited to situations where you have one-to-many relationships between your subjects and your observers.
However, in the context of integration, you often have many observers that are linked to many subjects, which complicates the basic Observer pattern.
One way to implement this many-to-many relationship is to create many subjects and to have each subject contain a list of observers.
If you use this object structure to implement Pub/Sub, you must write these relationships to persistent storage between process executions.
To do so within a relational database, you must add an associative table to resolve the many-to-many dependencies between subject and observer.
After you write this information to persistent storage in a set of tables, you can directly query the database for the list of subscribers for a topic.
Maintaining lists of published topics (subjects) and subscribers (observers) and then notifying each one individually as events occur is the essence of List-Based Pub/Sub implementations.
A very different means of achieving the same result is a Broadcast-Based Pub/Sub implementation.
Broadcast (or Bus) Based
Pub/Sub
In this approach, an event publisher creates a message and broadcasts it to all nodes on the local area network (LAN).
A component on each listening node inspects the subject line.
If the listening node matches the subject line to a subject that it subscribes to, the listening node processes the message.
If the subject does not match, the listening node ignores the message.
Although this hides subscribers from publishers, it is sometimes useful to identify particular topic subscribers.
A coordinating process can do this be sending a message that asks listening nodes to reply if they subscribe to a particular topic.
Responses are then returned by each listening node to the provider to identify the subscribers.
Because each node is responsible for filtering unwanted messages, some authors refer to this as a Pub/Sub channel with reactive filtering.
Both patterns above can be broadly categorized as topic-based because they both use predefined subjects as many-to-many channels.
In a topic-based system, processes exchange information through a set of predefined subjects (topics) which represent many-to-many distinct (and fixed) logical channels.
Content-based systems are more flexible as subscriptions are related to specific information content.
And, therefore, each combination of information items can actually be seen as a single dynamic logical channel.
This exponential enlargement of potential logical channels has changed the way to implement a pub/sub system.
The practical implication of this approach is that messages are intelligently routed to their final destination based on the content of the message.
This approach overcomes the limitation of a broadcast-based system, where distribution is coupled to a multicast tree based on Transmission Control Protocol (TCP).
It also gives the integration architect a great deal of flexibility when deciding on content-based routing logic.
Copyright conditions
Creative Commons Attribution-No
Derivative Works Licence 2.0 21/04/2015 09:34
Attribution: You may copy, distribute and display this copyrighted work
only if you clearly credit “Avancier Limited: http://avancier.website”
before the start and include this footnote at the end.
No Derivative Works: You may copy, distribute, display only complete and verbatim
copies of this page, not derivative works based upon it.
For more information about the
licence, see http://creativecommons.org