<#160#> Open<#160#> Communications are distinguished from other communication
paradigms by the separation of the idea of <#161#> service<#161#> from the idea of
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:
The type of service defines the semantics provided by the underlying
protocol. Thus we might define:
Type of Service.
Quality of Service.
and so forth.
The Quality of service defines the <#167#> reliability<#167#> and
<#168#> performance<#168#> of the
underlying protocol. Thus we might define
and so on.
We can refine Type of service further to include the semantics of the
actual service interface:
This can be
Best attempt messaging
We can also refine the notion of types of service for services like
messaging and request/response:
Synchronous or Asynchronous
Blocking or Non-blocking.
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
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.
At most once
At least once