Kick off protocol dependence
Tuesday, May 04, 2004 01:50 PM
Most distributed systems encapsulate the protocol details of interprocess communication within the processes or services that use each given protocol. Either that or the details are embodied within some manager class charged with handling communications for a given protocol. Both mechanisms raise the need to redesign, reprogram, recompile, and test whenever a new protocol is needed. Depending upon the amount of coupling between the protocol-dependent code and the services themselves, there is usually a fair amount of interdependencies created, leading to potentially difficult couplings to deal with when the underlying communication infrastructure changes.
Designing for protocol independence
A
service-oriented architecture (SOA) depends on a minimum amount of
interdependencies between services. This loose-coupling must propagate
all the way to the protocol layer of the architecture. Thus
communication infrastructure used within an SOA should be designed to
be independent of the underlying protocol layer.
Code reusability becomes one of the most important benefits derived from a well-designed protocol-independent communication framework, since the code that uses the framework will not be tied to the protocols used. Transparent replacement of the underlying protocol is also a very important benefit derived from a protocol-independent design. This facilitates deployment of a new protocol without the typical redeployment headaches such as server restarts and frustrated clients.
Patterns for protocol independence
- Business Delegate: Hides underlying implementation details of a business service, such as lookup and access details.
Example: A wrapper Java Bean which aggregates multiple objects and presents an easily understood business interface - Remote Proxy or Surrogate: Acts as a stand-in for objects which exist in a different tier.
Example: RMI's stub class design - Adapter or Wrapper:
An Adapter provides transparent access to disparate objects or services
by converting requests and possibly responses from one interaction
interface to another.
Example: Java's Portable Object Adapter - Broker: Decouples business tier objects from objects and services in other tiers.
Example: CORBA's ORB environment - Factory:
Instantiates objects at runtime based on dynamic configurations.
Factories are often instantiated objects designed around the Strategy
pattern or Bridge pattern.
Example: RMI's custom socket factory environment
Protocol abstraction layer
One of the most important pieces of technology in a protocol-independent framework is a protocol abstraction layer. Among other benefits, a protocol abstraction layer allows access to services from multiple, simultaneous protocols; hides protocol details from the service developer; and facilitates transparent protocol replacement. Figure A illustrates this concept:
| Figure A |
 |
| Protocol abstraction layer |
There are currently no comments for this post.