<#160#> Open<#160#> Communications are distinguished from other communication
paradigms by the separation of the idea of <#161#> service<#161#> from the idea of
<#162#> protocol<#162#>.
A Protocol implements a required service. How the protocol works is
of no concern to the user, so long as it meets the requirement.
This is in keeping with the ODP notion of transparencies.
We can separate service requirements into two main components:
-
Type of Service.
-
Quality of Service.
The type of service defines the semantics provided by the underlying
protocol. Thus we might define:
-
Messaging
-
Request/Response
-
Streams
and so forth.
The Quality of service defines the <#167#> reliability<#167#> and
<#168#> performance<#168#> of the
underlying protocol. Thus we might define
-
Reliable messaging
-
Best attempt messaging
and so on.
We can refine Type of service further to include the semantics of the
actual service interface:
This can be
-
Synchronous or Asynchronous
-
Blocking or Non-blocking.
We can also refine the notion of types of service for services like
messaging and request/response:
-
At most once
-
At least once
-
Exactly Once
The communications model has implications for the relationship between
the communicating end points. For instance, a very common way of
structuring distributed programs is the <#175#> Client/Server<#175#> model.
Typically, this would employ the request/response communications
model.
Other models include:
A Master/Slave model, usually implemented when
some central system controls subsidiary distributed components (e.g.
in monitoring and control systems).
A Peer relationship, where all systems are both clients and servers.