<html>
<head>
<base href="https://wiki.asterisk.org/wiki">
<link rel="stylesheet" href="/wiki/s/en/2171/18/9/_/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/Architecture">Architecture</a></h2>
<h4>Page <b>edited</b> by <a href="https://wiki.asterisk.org/wiki/display/~khunt">Ken Hunt</a>
</h4>
<br/>
<h4>Changes (6)</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" >From a very early stage, the Asterisk SCF project team felt that the best way to architect a system that strives to meet the stated goals (scalability, fault-tolerance/high-availability, extensibility and performance) was to build the system as a distributed application. That would mean that the system would be a collection of loosely coupled cooperating components, interacting with each other over well-defined interfaces. This sort of architecture has become common for building applications that need to be scalable, flexible and, most important, support interchangeable components without requiring modification of the standard components. This means that the application is in fact a network of components, which can be structured in nearly an infinite number of ways, and the network can include and be extended by components that were never envisioned by the core system’s designers. <br> <br></td></tr>
<tr><td class="diff-changed-lines" >As documented on the <span class="diff-changed-words"><span class="diff-added-chars"style="background-color: #dfd;">[TOP:</span>Research<span class="diff-added-chars"style="background-color: #dfd;">]</span></span> pages, this decision led to detailed analysis of available low-level communications platforms (messaging and remote procedure call-based), design patterns and development tools. The focus was on choosing tools to base Asterisk SCF on top of that would help meet the stated goals, allow developers to be efficient and productive, and support the system’s requirements for the foreseeable future. After settling on the Ice platform from ZeroC for the components to interact with each other, the next important design task was to define exactly how the components would interact: the system’s Application Programming Interfaces (APIs, or interaction points). <br></td></tr>
<tr><td class="diff-unchanged" > <br></td></tr>
<tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">h3. APIs <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">h3. Application Programming Interfaces (APIs) <br></td></tr>
<tr><td class="diff-unchanged" > <br>Asterisk SCF is, in essence, a set of well-defined APIs and components (executable programs that can be deployed to create an Asterisk SCF system) that provide access to services (functional blocks of the Asterisk SCF system) that implement those APIs. In order to frame the discussion of its architecture, it is helpful to organize these APIs into layers, although this is primarily an organization tool; the layers are not dependent on each other as much as it might appear. Implementations of concepts defined in higher-level layers can directly access any layer beneath them. Elements within a given layer often have association with other elements within the same layer. <br></td></tr>
<tr><td class="diff-snipped" >...<br></td></tr>
<tr><td class="diff-unchanged" >This architecture supports scalability in a number of ways, primarily driven by the system being deployed as small, single-function components. This means that system builders can deploy only the components that they need on a particular system, ensuring that the system’s resources are used as effectively as possible to provide that functionality. <br> <br></td></tr>
<tr><td class="diff-changed-lines" >The ability to deploy additional instances of these components means that capacity can be added and removed on a fine-grained basis. If the system’s existing routing services are able to handle the projected load, but the session <span class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;">managers</span> <span class="diff-added-words"style="background-color: #dfd;">gateways</span> (for SIP sessions, as an example) are not, then more instances of the session <span class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;">managers</span> <span class="diff-added-words"style="background-color: #dfd;">gateways</span> can be deployed, sending sessions to the same routing services. This makes deployment of additional capacity straightforward, and reduces the amount of configuration and administration work required to accomplish those tasks. <br></td></tr>
<tr><td class="diff-unchanged" > <br>h4. Fault-Tolerance/High Availability <br></td></tr>
<tr><td class="diff-snipped" >...<br></td></tr>
<tr><td class="diff-unchanged" >The Asterisk SCF team refers to this feature as “live call failover,” and, at this time, it appears that Asterisk SCF is the first open-source communications platform that is designed to provide this level of fault tolerance. Critical Asterisk SCF service components are themselves separated into multiple parts: those which actually perform the service’s operations and others that are responsible for replicating the entire state of the service component between multiple instances of it. Like the rest of Asterisk SCF, the replication interfaces themselves are defined in Slice; thus the actual mechanism used to facilitate the replication is up to the developer to choose. Regardless of the mechanism chosen, though, the service component can trust the replication component to ensure that its standby replicas are ready to take over at the instant a failure is detected, with absolutely no loss of functionality. <br> <br></td></tr>
<tr><td class="diff-changed-lines" >The first example of this in Asterisk SCF is the SIP Session <span class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;">Manager</span> <span class="diff-added-words"style="background-color: #dfd;">Gateway</span> and its companion SIP State Replicator. The implementation of the replicator at the initial announcement of Asterisk SCF is very simple and not fault-tolerant on its own, but it serves to demonstrate the power of the design. The project team has already been able to demonstrate live call failover with no service disruption of any kind. In fact, the amount of time that the standby SIP Session <span class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;">Manager</span> <span class="diff-added-words"style="background-color: #dfd;">Gateway</span> requires to become active after the operating system notifies it that it must do so is likely to be less time than it takes the network, and the clients talking to the Asterisk SCF system, to realize that the service’s IP address has moved to a different system. <br></td></tr>
<tr><td class="diff-unchanged" > <br>h4. Extensibility <br></td></tr>
<tr><td class="diff-snipped" >...<br></td></tr>
<tr><td class="diff-unchanged" >On a larger level, Asterisk SCF’s architecture addresses extensibility in two major ways: <br> <br></td></tr>
<tr><td class="diff-changed-lines" >* Extension Points - As mentioned, these are interaction points that allow an Asterisk SCF component to influence the operation of another component at a much more detailed level than the normal top-level interfaces implemented by that component, but without having to modify it, or even be aware of how it is implemented internally. It has been quite commonly asked, in the Asterisk community, whether an application developer could make decision about whether a SIP call could be accepted or not before the SIP channel driver has gone through the effort of parsing, validating, possibly authenticating and then deliver the incoming call into the Dialplan. Asterisk’s design makes that sort of interaction somewhat difficult, because by its very nature, the decision-making process requires intimate knowledge of the SIP channel driver’s operations. Thus, developers are often forced to modify the SIP channel driver itself to accomplish their goal. With the Asterisk SCF Extension Point APIs, the SIP Session <span class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;">Manager</span> <span class="diff-added-words"style="background-color: #dfd;">Gateway</span> will expose specific interaction points during the processing of incoming calls, allowing other components to optionally help it decide whether those should be accepted or not. Since the extension Point interface is a published, stable interface, even if the SIP Session <span class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;">Manager</span> <span class="diff-added-words"style="background-color: #dfd;">Gateway</span> is rewritten entirely, even in a different language, a component that utilizes the Extension Points will continue to operate as expected. <br></td></tr>
<tr><td class="diff-unchanged" > <br>* Component Extension through Wrapping - As also mentioned above, since the public interface to any Asterisk SCF component is a set of Slice-defined APIs, it is possible, and fairly straightforward, to write a new component that wraps that component, hiding it from direct use. This new component can expose the identical APIs that the hidden component does, so that consumers of those APIs are totally unaware that the wrapper components exists; but, it will be aware of any operation invoked into the wrapped component and also all operations it invokes to its consumers via Extension Points. The wrapper component can then implement additional or modified behaviors based on its needs, without either of the original components being modified or having any other changes made except for a small amount of configuration during deployment. <br></td></tr>
<tr><td class="diff-snipped" >...<br></td></tr>
</table>
</div> <h4>Full Content</h4>
<div class="notificationGreySide">
<h3><a name="Architecture-Background"></a>Background</h3>
<p>From a very early stage, the Asterisk SCF project team felt that the best way to architect a system that strives to meet the stated goals (scalability, fault-tolerance/high-availability, extensibility and performance) was to build the system as a distributed application. That would mean that the system would be a collection of loosely coupled cooperating components, interacting with each other over well-defined interfaces. This sort of architecture has become common for building applications that need to be scalable, flexible and, most important, support interchangeable components without requiring modification of the standard components. This means that the application is in fact a network of components, which can be structured in nearly an infinite number of ways, and the network can include and be extended by components that were never envisioned by the core system’s designers.</p>
<p>As documented on the <a href="/wiki/display/TOP/Research" title="Research">Research</a> pages, this decision led to detailed analysis of available low-level communications platforms (messaging and remote procedure call-based), design patterns and development tools. The focus was on choosing tools to base Asterisk SCF on top of that would help meet the stated goals, allow developers to be efficient and productive, and support the system’s requirements for the foreseeable future. After settling on the Ice platform from ZeroC for the components to interact with each other, the next important design task was to define exactly how the components would interact: the system’s Application Programming Interfaces (APIs, or interaction points).</p>
<h3><a name="Architecture-ApplicationProgrammingInterfaces%28APIs%29"></a>Application Programming Interfaces (APIs)</h3>
<p>Asterisk SCF is, in essence, a set of well-defined APIs and components (executable programs that can be deployed to create an Asterisk SCF system) that provide access to services (functional blocks of the Asterisk SCF system) that implement those APIs. In order to frame the discussion of its architecture, it is helpful to organize these APIs into layers, although this is primarily an organization tool; the layers are not dependent on each other as much as it might appear. Implementations of concepts defined in higher-level layers can directly access any layer beneath them. Elements within a given layer often have association with other elements within the same layer.</p>
<p>In Asterisk SCF, APIs are groups of related objects and the operations that can be invoked on them (or by them), and are defined using a simple “interface definition language” called Slice (see the Ice page for more details). This allows these APIs to be implemented, both on the consumer and provider ends, in a variety of languages and on many different platforms. In fact, the consumers and providers are not even aware of (and would not be able to take advantage of knowing) which platform or language the other party in an operation request is using.</p>
<p>In this context, it is critical to understand what an API consists of; for Asterisk SCF, there are primarily two types of interfaces that fall into the <em>API</em> category:</p>
<ul>
<li>Remote Operations - This interface type is the traditional consumer / provider model, where the consumer has, via some mechanism, obtained a handle to an object provided by a service component, and can request that operations be invoked on that object – which may involve providing parameters, receiving a return value, and catching exceptions. These operations can be handled using either a synchronous or asynchronous implementation on both the client (consumer) and server (provider) end.</li>
</ul>
<ul>
<li>Extension Points - This interface type is essentially the reverse of Remote Operations. In this case, the consumer has provided a handle to its own object that the provider can use to invoke operations while it is executing operations on its own objects. This allows the consumer to modify, intercept or otherwise affect the provider’s sequence of operations and decisions, at well-defined and documented points. Just like the Remote Operations, Extension Points can be handled either synchronously or asynchronously.</li>
</ul>
<p>Finally, an API versioning system has been created for Asterisk SCF that allows providers (primarily) to support multiple versions of a published API in parallel, with simultaneous usage by consumers that were built against differing versions of the API.</p>
<p><span class="image-wrap" style="display: block; text-align: center"><img src="/wiki/download/attachments/131096/AsteriskSCFArch.png?version=2&modificationDate=1288276473626" style="border: 1px solid black" /></span></p>
<h3><a name="Architecture-APILayers"></a>API Layers</h3>
<p>The Asterisk SCF APIs can be organized into some fairly broadly scoped layers (see the attached diagram for a pictorial representation); although, as mentioned, these layers are not always strictly dependent on each other and components can, and will, exist that consume and provide interfaces in multiple layers at once.</p>
<ul>
<li>Messaging Layer - This layer is primarily provided by Ice itself, along with additional development patterns, libraries and other tools that provide functionality to be used in Asterisk SCF components.</li>
</ul>
<ul>
<li>System Integration Layer - This layer defines interfaces that determine how components will interact with each other at a generic level; this includes such functionality as locating running services, monitoring the health of service components, signaling activation / deactivation of standby status for replicated components and various other common interfaces that should be implemented by all components. The interfaces that exist in this layer provide the type of functionality that is needed to administer an Asterisk SCF system and manage its components.</li>
</ul>
<ul>
<li>System Services Layer - This layer is a collection of interfaces that have broad applicability to many service components, but are not required, or even desired, in every Asterisk SCF component. Components that provide services that implement these interfaces do so to provide resources to the rest of the Asterisk SCF system, and register these resources in the system’s Service Locator. In many cases, the components that implement these interfaces are doing so as a way of mapping an external tool or service into the Asterisk SCF system. As an example, for voice calls, these services could be media format transrating (connecting wideband and narrowband callers) or transcoding (converting between audio encoding schemes).</li>
</ul>
<ul>
<li>Domain Specific Stacks - These stacks are really the heart of Asterisk SCF. Unlike traditional communications platforms, which have generally been designed to supply a single set of similar services and then have additional services types ‘added on,’ Asterisk SCF provides a way to define an entire domain of services that will be used to support a specific type of communications. This allows users who want to deploy Asterisk SCF to mix and match the types of services they want to use without having to include any services they don’t need. It also allows various operations, that appear to be common, to be defined in a domain-specific way so that those operations map more naturally onto the objects involved. As an example, the operation of routing a traditional call, whether it is TDM, VoIP or other technology, is very different from routing a text message; which itself is very different from routing presence information. All of these domains, however, share a common need to route communications between participating endpoints. So, Asterisk SCF will define similar APIs that can be implemented by domain-specific routing components. This similarity will allow an application programmer that wants to control, influence or otherwise interact with these routing operations to use a consistent method for doing so. The stacks can be further sub-divided into:
<ul>
<li>Domain Integration Layer - This layer defines the set of abstractions that define the type of communications in the domain. This is somewhat like defining a language for that communications method, including nouns (objects), verbs (operations and behaviors) and various other aspects. As an example, the Session Oriented Communications layer defines many objects and operations that apply to session-oriented communications. Traditionally, these types of communications may have been referred to as “calls” that provide a two-way audio path for communications; but, in modern systems, they could be various types of sessions, supporting a wide variety (voice, video, text, image) of media, or no media at all. In spite of their differences, sessions all have a variety of operations and behaviors in common, and they all exist to connect endpoints to each other; which necessitates routing “session initiation requests” and connecting the resulting endpoints in some sort of bridge. Because of this commonality, it is possible to define a common set of operations used by generic routing and bridging APIs, and the components that implement them, to establish, connect and tear down sessions, all without having any direct knowledge of the type of session involved or what technology it may be connecting to outside of Asterisk SCF.</li>
<li>Domain Services Layer - This layer is the first layer that consists almost solely of components providing services defined by interfaces in the lower layers. They implement the generic objects and operations in their associated domain. As a group, these components provide the Asterisk SCF world view of that particular domain, allowing higher-level components, and components that live outside of the domain, to interact with all the objects in the domain using common operations. In the Session Oriented Communications stack, for example, the Bridging service exists in this layer, since it provides the ability to interconnect media streams associated with two, or more, sessions; but, it does not need to know which components provided those sessions, or what protocols were used to establish them.</li>
<li>Technology Adapter Layer - This layer also consists primarily of components that provide services defined by interfaces in lower layers. But, since each component in this layer is adapting an external technology of some type into the Asterisk SCF system, the component will undoubtedly expose various interfaces specific to its operations. These could be as simple as configuration mechanisms and as complex as dozens, or hundreds, of Extension Points that allow fine-grained control, from another component, over the logic and decisions made by the component or anywhere in between. This layer is also where most of the state, the information that describes the current communications, in an Asterisk SCF system exists. Because of this, these components are the ones that have the greatest needs for scalability (multiple instances of the component servicing a portion of the endpoints that need service) and failover (multiple instances of the component sharing the same ‘state’ so that one can take over service if the active one can no longer provide it).</li>
</ul>
</li>
</ul>
<ul>
<li>External Technologies Layer - This layer is not wholly part of Asterisk SCF, but it is, in reality, the reason that Asterisk SCF exists. Toolkits like Asterisk SCF exist for the purpose of connecting together endpoints (users, devices, etc.) that speak protocols that provide similar communications mechanisms; and, thus, Asterisk SCF itself must have components that adapt it to be able to interoperate with these endpoints. Given the Domain Specific Service Layer though, these adapters are fairly thin, and provide only the necessary mapping between the external technology’s world view and the Asterisk SCF domain’s world view.</li>
</ul>
<h3><a name="Architecture-ComponentsandtheirInteractions"></a>Components and their Interactions</h3>
<p>Asterisk SCF was designed from the very beginning to be a distributed application. This decision has far-reaching effects throughout the design, but all of them result in a more flexible and scalable environment for users, administrators and, especially, application developers. The design encourages developers to implement services within Asterisk SCF in the smallest possible components and to implement services in separate components, except for testing purposes. In addition, it is quite important that all service components be completely unaware of the location, platform, language or other aspects of the other service components with which they interact. This drives the need to define Asterisk SCF APIs in the Slice language, as these interfaces then become a contract between components that consume and provide the interfaces; they can rely on the fact that if a component states that it implements the required version of a particular interface, then all the operations on that interface will be supported and provide the expected behavior. It also allows service component locations to change, new versions to be installed and replicated components to provide live failover for objects without requiring support from the consumer of the interfaces.</p>
<p>As the Asterisk SCF team delved deeper into the initial design, a new and very powerful capability emerged from this decision. Due to the loose coupling of consumers and providers of services, and the fact that the interfaces between them are completely specified and described in advance, it becomes possible to create wrapper components. These components can sit in front of, or around, a service component and modify interactions with it as needed, without either the consumer or provide of the services being aware of their existence. In effect, they become a proxy for the relevant APIs, but they do not have to be transparent in their operations.</p>
<p>Once this was realized, the goal of building Asterisk SCF’s desired functionality as a set of small components became much more achievable. As an example of the flexibility this provides, the initial set of Asterisk SCF components have no built-in support for authentication of connections (internal connections, not over external technologies) or authorization mechanisms to control what those connections might be allowed to do. Instead, it is planned to build a set of authentication service components that wrap around the existing components, and implement the authentication domain, including such concepts as users, zones and privileges. Since these components can implement both the forward (Remote Operation) and backwards (Extension Points) APIs, they can delve into the logic and decision making of the standard components at a detailed level and implement authorization policies. But, if a particular Asterisk SCF deployment has no need for authentication and authorization, then the entire mechanism does not need to be loaded at all.</p>
<h3><a name="Architecture-Testing"></a>Testing</h3>
<p>The discussion of well-defined APIs and fine-grained components wouldn’t be complete without touching on the topic of testing. In software development, testing can take many forms including unit testing, which tests code at the smallest level possible, frequently below the published API layers; component testing, which tests components and services via their published APIs; and integration testing, which tests collections of components and services as a network.</p>
<p>For this discussion, the types of testing most relevant are component and integration testing. Since components are designed to incorporate only the smallest amount of functionality that makes sense, and the component’s APIs are well defined, it becomes very straightforward to produce test harnesses (additional components) that test the component via those APIs. This allows the component developer the freedom to implement the component’s services in any way that makes sense knowing that the functionality can be completely verified before it is released. It also means that multiple implementations of the component can be produced, possibly written in different languages or taking advantage of particular features of a specific operation system or hardware component, all of which can be tested using the identical test harness to ensure they perform identically under the tests’ conditions.</p>
<p>To some extent, this model can also support test-driven development. If a decision is made to change the APIs for a particular service, it is possible to create a dummy implementation of the new APIs along with the updated test harness. Once the test harness has been written and the team feels it properly exercises the APIs in question, the actual service component can be modified to implement the new APIs, and the developer can incrementally test it since the tests already exist.</p>
<h3><a name="Architecture-MeetingtheGoals"></a>Meeting the Goals</h3>
<p>How does all of this help Asterisk SCF meet its goals? Here they are again, along with some examples.</p>
<h4><a name="Architecture-Scalability"></a>Scalability</h4>
<p>This architecture supports scalability in a number of ways, primarily driven by the system being deployed as small, single-function components. This means that system builders can deploy only the components that they need on a particular system, ensuring that the system’s resources are used as effectively as possible to provide that functionality.</p>
<p>The ability to deploy additional instances of these components means that capacity can be added and removed on a fine-grained basis. If the system’s existing routing services are able to handle the projected load, but the session gateways (for SIP sessions, as an example) are not, then more instances of the session gateways can be deployed, sending sessions to the same routing services. This makes deployment of additional capacity straightforward, and reduces the amount of configuration and administration work required to accomplish those tasks.</p>
<h4><a name="Architecture-FaultTolerance%2FHighAvailability"></a>Fault-Tolerance/High Availability</h4>
<p>In communications applications, availability is typically defined as “the ability for the system to perform its expected functions.” This does not necessarily mean that, for a given operation, the system will never experience an outage or that a particular function might not fail; rather, that if the operation is performed again, it is likely to succeed. And, when measured over an extended period of time, the frequency that a requested function is not performed is very low.</p>
<p>There are a number of scenarios that can negatively affect availability; from the simple needs to update software to equipment failures and the like. For many communications systems, it has become common practice to deploy multiple, sometimes many, instances of key components, along with some sort of request director to ensure that requests are sent to components that are capable of servicing them. This can provide a suitable level of availability for a large fraction of deployed systems. Generally, the complexity of deploying such systems is higher than is necessary.</p>
<p>The separation of Asterisk SCF’s components into functional blocks will ease this sort of deployment by allowing the system builder to only have to deploy multiple instances of the components that are predetermined to be more likely to experience downtime – scheduled or unscheduled. This allows the systems hosting these components to be sized for only that purpose, and to not require any additional resources beyond what the component needs.</p>
<p>The more important aspect of this goal, however, is fault tolerance: the ability of the system to survive an unscheduled service outage with little or no impact noticed by the users of the system. While standard techniques are able to reach availability percents of 99.9% or 99.99%, achieving five-nines or greater availability realistically requires the system to be able to process nearly ever request it is given, and that no functionality the system provides is ever lost due to a failure. Of course, any such system will necessarily include components that are not part of Asterisk SCF itself, so Asterisk SCF cannot solve this problem on its own. The architecture of Asterisk SCF, however, its components and the design techniques employed in their implementations will allow system builders to be able to recover, transparently, from faults that occur in the software itself, the systems it is deployed on, the networks it is connected to and various other factors.</p>
<p>The Asterisk SCF team refers to this feature as “live call failover,” and, at this time, it appears that Asterisk SCF is the first open-source communications platform that is designed to provide this level of fault tolerance. Critical Asterisk SCF service components are themselves separated into multiple parts: those which actually perform the service’s operations and others that are responsible for replicating the entire state of the service component between multiple instances of it. Like the rest of Asterisk SCF, the replication interfaces themselves are defined in Slice; thus the actual mechanism used to facilitate the replication is up to the developer to choose. Regardless of the mechanism chosen, though, the service component can trust the replication component to ensure that its standby replicas are ready to take over at the instant a failure is detected, with absolutely no loss of functionality.</p>
<p>The first example of this in Asterisk SCF is the SIP Session Gateway and its companion SIP State Replicator. The implementation of the replicator at the initial announcement of Asterisk SCF is very simple and not fault-tolerant on its own, but it serves to demonstrate the power of the design. The project team has already been able to demonstrate live call failover with no service disruption of any kind. In fact, the amount of time that the standby SIP Session Gateway requires to become active after the operating system notifies it that it must do so is likely to be less time than it takes the network, and the clients talking to the Asterisk SCF system, to realize that the service’s IP address has moved to a different system.</p>
<h4><a name="Architecture-Extensibility"></a>Extensibility</h4>
<p>In its most basic form, extensibility can be provided by just making it easy for developers to work in their preferred environments, without having to give up any abilities to interact with the application because of their choices. While it is not really part of Asterisk SCF’s architecture, the fact that all the APIs are defined as Slice interfaces means a developer can implement their Asterisk SCF components, or extensions to existing components, in a wide variety of languages (C++, C#, Java, Python, Ruby, PHP, and Objective C) on a variety of platforms (Linux and other Unix-type systems, Microsoft Windows, FreeBSD, Mac OS X, iPhone/iPad) with more on the way. This flexibility means that a developer can build, for example, a session routing service that relies on a Microsoft SQL Server database, in C#, to run on a Windows Server system, and that the remainder of the Asterisk SCF system is not aware of what choices were made. It allows developers to choose the best tool for each problem they are given to address, rather than having to use the toolset dictated by the framework upon which they are building.</p>
<p>On a larger level, Asterisk SCF’s architecture addresses extensibility in two major ways:</p>
<ul>
<li>Extension Points - As mentioned, these are interaction points that allow an Asterisk SCF component to influence the operation of another component at a much more detailed level than the normal top-level interfaces implemented by that component, but without having to modify it, or even be aware of how it is implemented internally. It has been quite commonly asked, in the Asterisk community, whether an application developer could make decision about whether a SIP call could be accepted or not before the SIP channel driver has gone through the effort of parsing, validating, possibly authenticating and then deliver the incoming call into the Dialplan. Asterisk’s design makes that sort of interaction somewhat difficult, because by its very nature, the decision-making process requires intimate knowledge of the SIP channel driver’s operations. Thus, developers are often forced to modify the SIP channel driver itself to accomplish their goal. With the Asterisk SCF Extension Point APIs, the SIP Session Gateway will expose specific interaction points during the processing of incoming calls, allowing other components to optionally help it decide whether those should be accepted or not. Since the extension Point interface is a published, stable interface, even if the SIP Session Gateway is rewritten entirely, even in a different language, a component that utilizes the Extension Points will continue to operate as expected.</li>
</ul>
<ul>
<li>Component Extension through Wrapping - As also mentioned above, since the public interface to any Asterisk SCF component is a set of Slice-defined APIs, it is possible, and fairly straightforward, to write a new component that wraps that component, hiding it from direct use. This new component can expose the identical APIs that the hidden component does, so that consumers of those APIs are totally unaware that the wrapper components exists; but, it will be aware of any operation invoked into the wrapped component and also all operations it invokes to its consumers via Extension Points. The wrapper component can then implement additional or modified behaviors based on its needs, without either of the original components being modified or having any other changes made except for a small amount of configuration during deployment.</li>
</ul>
<h4><a name="Architecture-Performance"></a>Performance</h4>
<p>In the past few years, server-grade systems have begun to be constructed out of multiple and sometimes large numbers of CPU cores, rather than using ever-higher clock speeds. As a result, software design has had to change to be able to take advantage of these systems; this is generally referred to as “manycore” design, and the gurus of software development have published many articles and papers about how best to architect and implement applications in light of this shift in hardware models.</p>
<p>The decision to construct Asterisk SCF systems out of small components that communicate with each other over out-of-process links was no accident. This not only allows the components to be deployed on multiple servers transparently, but it also allows them to be effectively deployed on “manycore” servers and fully utilize those CPU cores. Modern operating systems already employ very effective process and thread schedulers to distribute workloads across the available CPUs, and many applications are heavily multithreaded in order to try to take advantage. However, this method breaks down quickly when the threads have data shared between them, because contention for that data, and the methods required to avoid it, causes the CPUs to waste valuable cycles. In some cases, even well constructed multithreaded applications have been shown to only derive a 50% performance increase when doubling the number of available CPU cores (from four to eight, for example). When the number of cores increases further, the performance benefit continues to decline.</p>
<p>In addition to that effect, though, the Ice platform chosen for the Asterisk SCF system has a significant advantage over many other Remote Procedure Call platforms: it allows components to be loaded into a single process, called collocation, when the performance needs demand it. When this is done, the components communicate with each other directly, without going through the network stack. No changes are required in the components themselves to achieve this, it is purely a decision made by the person deploying the components. As a result, in extreme cases where the interaction between two components is so frequent that using a network link, or even a virtual network link in the case of two components running on the same server, would be an actual constraint, the components can be loaded into a single service container to provide maximum performance.</p>
<h3><a name="Architecture-Conclusion"></a>Conclusion</h3>
<p>The Asterisk SCF design sets a new standard for open source communications platforms. The project team believes the platform will be able to be applied to any size problem, from small office to worldwide enterprise, and will provide the flexibility and extensibility required to support modern communications-based applications.</p>
</div>
<div id="commentsSection" class="wiki-content pageSection">
<div style="float: right;" class="grey">
<a href="https://wiki.asterisk.org/wiki/users/removespacenotification.action?spaceKey=TOP">Stop watching space</a>
<span style="padding: 0px 5px;">|</span>
<a href="https://wiki.asterisk.org/wiki/users/editmyemailsettings.action">Change email notification preferences</a>
</div>
<a href="https://wiki.asterisk.org/wiki/display/TOP/Architecture">View Online</a>
|
<a href="https://wiki.asterisk.org/wiki/pages/diffpagesbyversion.action?pageId=131096&revisedVersion=36&originalVersion=35">View Changes</a>
|
<a href="https://wiki.asterisk.org/wiki/display/TOP/Architecture?showComments=true&showCommentArea=true#addcomment">Add Comment</a>
</div>
</div>
</div>
</div>
</div>
</body>
</html>