|
The Half Call design pattern is described using a standard pattern definition
template.
Intent
The actions involved in a call processing can be categorized in two half
calls. One half of the call handles the signaling involved in the originating
end of the call. Other half call component handles the signaling involved in the
terminating end of the call. This partitioning of a call in half call components
simplifies the call design. Consider that a switch were to support N signaling
systems. If half call design pattern is not used, it would have to deal with N x
N call types to support all the signaling interworking call scenarios. With half
call design pattern, each signaling type maps to originating and terminating
half calls. Thus the number of call types to be supported is reduced to 2 x
N.
Also Known As
- End Call Design Pattern
- End Point Protocol Design Pattern
Motivation
Consider the case where a switch has to support the following signaling
schemes:
- SS7 ISUP (ISDN User Part)
- R2 Signaling
- POTS (Plain Old Telephone Service) Subscriber
- V5.2 Subscriber
If half call was not supported, the switch will have to support the following
call types:
- ISUP to R2 Call
- R2 to ISUP Call
- ISUP to POTS Call
- POTS to ISUP Call
- POTS to R2 Call
- R2 to POTS Call
- ISUP to V5.2 Call
- V5.2 to ISUP Call
- R2 to V5.2 Call
- V5.2 to R2 Call
- POTS to V5.2 Call
- V5.2 to POTS Call
- ISUP to ISUP Call
- R2 to R2 Call
- POTS to POTS Call
- V5.2 to V5.2 Call
With half call design pattern, the switch will have to support only the
following call types:
- ISUP Originating Call
- ISUP Terminating Call
- R2 Originating Call
- R2 Terminating Call
- POTS Originating Call
- POTS Terminating Call
- V5.2 Originating Call
- V5.2 Terminating Call
Thus there is a major simplification in the design when half call design
pattern is used.
Applicability
This design pattern can be applied whenever a system needs to support
interworking between different types of protocols. If the design models the
interactions between originating and terminating end points as a single entity,
the interworking design would be complicated by the large number of entity
types. Also, the design would scale very poorly when new protocol type needs to
be supported. In such cases, apply the half call design pattern. The originating
and the terminating protocol end points should be modeled as separate entities
(half calls).
Structure
Instead of having a N x N mesh of protocol end point interactions, this
design pattern implements the system with 2 x N end points. For this design
pattern to work, a standard protocol should be defined between a typical
originating and terminating end point protocol.
Participants
The originating and terminating protocol end points are the main actors in
this design pattern. In some scenarios, an intermediate broker object may have
to be designed to coordinate the interactions between originating and
terminating end points.
Collaboration
The originating and terminating end point protocols use a standard protocol
to communicate with each other. The originating and terminating ends are not
aware of the type of the other end of the protocol.
Consequences
The design becomes simple and it is fairly modular and can be easily scaled
to introduce support for new protocols.
Implementation
If the standard protocol between originating and terminating end points is
not defined properly, it would soon grow in complexity with the addition new
protocol types.
Coming up with this standard protocol is the most challenging part of
implementing this design pattern. Sometimes the implementation of a broker
object helps in simplifying the standard protocol into the incoming and outgoing
protocols.
Sample Code and Usage
Refer to the following links available in Xenon:
Known Uses
The half call design pattern has been in use in implementing telephone
switching systems involving support for multiple signaling protocols.
Related Patterns
None | 