<html>
<head>
<base href="https://wiki.asterisk.org/wiki">
<link rel="stylesheet" href="/wiki/s/2030/1/7/_/styles/combined.css?spaceKey=TOP&forWysiwyg=true" type="text/css">
</head>
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
<h2><a href="https://wiki.asterisk.org/wiki/display/TOP/API+changes+to+support+adjunct+routing+components">API changes to support adjunct routing components</a></h2>
<h4>Page <b>edited</b> by <a href="https://wiki.asterisk.org/wiki/display/~khunt">Ken Hunt</a>
</h4>
<br/>
<h4>Changes (2)</h4>
<div id="page-diffs">
<table class="diff" cellpadding="0" cellspacing="0">
<tr><td class="diff-snipped" >...<br></td></tr>
<tr><td class="diff-unchanged" >Figure 3 shows the Adjunct Router in use. The primary routing service, when one (or more) Adjunct Routers has been registered, will forward session routing calls first to each registered Adjunct Router. If the Adjunct Router returns a proxy (as opposed to null), it is assumed to have routed the session, and so the main routing service simply returns the returned proxy. This approach allows the Adjunct Routing component to make its own determination about which operations it processes, and which it ignores. Since it is using the same interface as the primary routing service, it has all the information forwarded to it that the primary routing service has. <br> <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">The second sequence fragment shows a case where the Adjunct Router doesn't handle the operation, so it returns null and the primary routing service handles it. <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">The second set of sequences (starting with message 2.0) shows a case where the Adjunct Router doesn't handle the operation, so the Adjunct Router returns null and the primary routing service handles the request. <br></td></tr>
<tr><td class="diff-unchanged" > <br>This process supports chaining of routing services if desired, as the interfaces are compatible with the Chain of Responsibility design pattern. <br></td></tr>
<tr><td class="diff-snipped" >...<br></td></tr>
</table>
</div> <h4>Full Content</h4>
<div class="notificationGreySide">
<div class='panelMacro'><table class='infoMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/information.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>This page describes a proposed design change to the Asterisk SCF API's related to routing to support one or more adjunct routers.</td></tr></table></div>
<h4><a name="APIchangestosupportadjunctroutingcomponents-Overview"></a>Overview</h4>
<p>An adjunct routing service is another routing service (i.e. separate and distinct from the routing service identified to the system via the Service Locator as the primary routing service) that registers itself with the main routing component and takes over routing responsibilities from the main routing component under rules of it's own deciding. This design provides Asterisk SCF with a means to introduce Adjunct Routing Services into the system with modest changes to the existing APIs. </p>
<p>The goals of this design:</p>
<ol>
<li>Minimize the complexity of additional logic for components that use the routing service.</li>
<li>Provide a flexible mechanism applicable to a wide variety of Use Cases.</li>
<li>Meet the previously defined goals in a remote-call efficient manner.</li>
</ol>
<h4><a name="APIchangestosupportadjunctroutingcomponents-APIChanges"></a>API Changes</h4>
<p>The API changes required by this design are highlighted in the class structure diagrams of Figures 1 and 2. Figure 1 introduces a GetEndpointLocators() operation to the LocatorRegistry interface. This, along with the new EndpointLocatorRegistryEntry class used to hand back EndpointLocators along with the ids used to register them, will allow an Adjunct Router to create a mirror copy of the system's available endpoint locators if it so chooses. Of course, an Adjunct Router could also choose to simply invoke the primary routing service's lookup() operation whenever it needs to look up an endpoint. </p>
<p>To fully support mirroring the cache of EndpointLocators, the LocatorRegistry also provides support for the new listener interface (via the add/remove listener operations.) </p>
<div class='table-wrap'>
<table class='confluenceTable'><tbody>
<tr>
<td class='confluenceTd'><span class="image-wrap" style=""><img src="/wiki/download/attachments/9568443/RoutingClassStructureDiagram-AdjunctRouting.png?version=2&modificationDate=1290469551871" style="border: 1px solid black" /></span></td>
</tr>
<tr>
<td class='confluenceTd'><div class="" align="center"><b>Figure 1. Changes to AsteriskSCF::Core::Routing</b></div>
</td>
</tr>
</tbody></table>
</div>
<p>Figure 2 shows the changes to the SessionCommunications APIs. The first change is that all of the session routing operations now return a proxy to the SessionRouter interface that actually performed the routing. Components using the routing service are responsible for tracking the RoutingService to use for an established session for future routing operations based on this returned value. </p>
<p>The next change is the new operations for adding/removing an Adjunct Router. These operations are provided in a separate interface so that all SessionRouter implementations aren't required to support AdjunctRouting. </p>
<div class='table-wrap'>
<table class='confluenceTable'><tbody>
<tr>
<td class='confluenceTd'><span class="image-wrap" style=""><img src="/wiki/download/attachments/9568443/Session-AdjunctRouting.png?version=2&modificationDate=1290535741357" style="border: 1px solid black" /></span></td>
</tr>
<tr>
<td class='confluenceTd'><div class="" align="center"><b>Figure 2. Changes to AsteriskSCF::SessionCommunications</b></div>
</td>
</tr>
</tbody></table>
</div>
<p>Figure 3 shows the mechanics of how we would expect an Adjunct Router to be added to the system. </p>
<p>The optional fragment at the top of the sequence would only be executed if the particular implementation used/required a mirrored copy of the registered system EndpointLocators. The Adjunct Router passes a proxy to itself to become registered with the main routing service. Of course, an external component could coordinate the registration just as well. </p>
<div class='table-wrap'>
<table class='confluenceTable'><tbody>
<tr>
<td class='confluenceTd'><span class="image-wrap" style=""><img src="/wiki/download/attachments/9568443/Adjunct+Router+Registration+Sequence.png?version=2&modificationDate=1290535735423" style="border: 1px solid black" /></span></td>
</tr>
<tr>
<td class='confluenceTd'><div class="" align="center"><b>Figure 3. Adjunct Router Registration</b></div>
</td>
</tr>
</tbody></table>
</div>
<p>Figure 3 shows the Adjunct Router in use. The primary routing service, when one (or more) Adjunct Routers has been registered, will forward session routing calls first to each registered Adjunct Router. If the Adjunct Router returns a proxy (as opposed to null), it is assumed to have routed the session, and so the main routing service simply returns the returned proxy. This approach allows the Adjunct Routing component to make its own determination about which operations it processes, and which it ignores. Since it is using the same interface as the primary routing service, it has all the information forwarded to it that the primary routing service has. </p>
<p>The second set of sequences (starting with message 2.0) shows a case where the Adjunct Router doesn't handle the operation, so the Adjunct Router returns null and the primary routing service handles the request. </p>
<p>This process supports chaining of routing services if desired, as the interfaces are compatible with the Chain of Responsibility design pattern. </p>
<div class='table-wrap'>
<table class='confluenceTable'><tbody>
<tr>
<td class='confluenceTd'><span class="image-wrap" style=""><img src="/wiki/download/attachments/9568443/RoutingSequenceDiagram-AdjunctRouting.png?version=2&modificationDate=1290535750208" style="border: 1px solid black" /></span></td>
</tr>
<tr>
<td class='confluenceTd'><div class="" align="center"><b>Figure 4. Adjunct Router Usage</b></div>
</td>
</tr>
</tbody></table>
</div>
</div>
<div id="commentsSection" class="wiki-content pageSection">
<div style="float: right;">
<a href="https://wiki.asterisk.org/wiki/users/viewnotifications.action" class="grey">Change Notification Preferences</a>
</div>
<a href="https://wiki.asterisk.org/wiki/display/TOP/API+changes+to+support+adjunct+routing+components">View Online</a>
|
<a href="https://wiki.asterisk.org/wiki/pages/diffpagesbyversion.action?pageId=9568443&revisedVersion=10&originalVersion=9">View Changes</a>
|
<a href="https://wiki.asterisk.org/wiki/display/TOP/API+changes+to+support+adjunct+routing+components?showComments=true&showCommentArea=true#addcomment">Add Comment</a>
</div>
</div>
</div>
</div>
</div>
</body>
</html>