Virtual Platforms

Services, like ASR engines, browsers, VoIP gateways, etc., can be grouped (i.e., multiple servers operating within a community) to form a higher density/availability platform for your applications. Because these groups of services do not have to be grouped on the same physical machine, we refer to them as Virtual Platforms. Virtual Platforms can be summarized as containing the following items:

Concept	Description
Group	A collection of Prophecy Servers configured to offer Services to its peers
Server	A physical machine/entity providing services
Service	An individual resource being offered by a Community Member (e.g., ASR, TTS, etc.)
Site	Used to group Servers based on geographical location
Resource	A set of prioritized Services such as the "en-US" (U.S. English) TTS resource
Virtual Platform	The full set of Resources, configured on one or more Groups of Servers, available to an application

Physical vs. Logical

The Virtual Platform model relies on aggregating physical Services into a set of logical Resources. The Prophecy Management Console achieves this by layering its components into three distinct buckets: Physical Servers, Services, and Resources:

A Server's configuration determines the Services it provides.
Groups are created by aggregating multiple Servers, thereby increasing the pool of Services it can provide.
Virtual Platforms further abstract the physical via a set of resources (prioritized Services) from one or more Groups.

Server Configuration

Prophecy is a robust system containing many components. Each component can be configured and tuned to meet the specific needs of the Applications targeting them; however, not all settings are created equal. Some settings must be present when the component is initialized while others can be defined (and even changed) at runtime. For example, the TCP port used for administrative monitoring must be defined on Server startup while the default TTS engine can not only change at runtime, but may even be a function of the call route.

The types of Server configurations are:

Runtime Configuration: defined by a Route and read by the Server at call-time.
Bootstrap Configuration: mostly static configuration items forming the foundation for Server initialization. Bootstrap Settings cannot change at runtime, but normally have very reasonable defaults. Note: these settings do not typically affect an Application's ability to run because they mostly target "lower-level" behavior, such as logging, alerting, memory allocation, and performance.

Services

A Service is a communal (pun intended) resource advertised by a Server or, more specifically, an instance of the Prophecy Runtime. Common Services include voice browsers, text to speech, and speech recognition engines. A Server's Bootstrap Configuration determines the Services made available by it to other members of a community.

Groups

A Group is a cluster of Servers pooled together. A Server can belong to more than one Group, thus donating its Services to multiple pools. Groups offer a level of indirection between physical Servers and a logical set of runtime Services. For Call Routing, the exact physical resource used is a function of the Service's availability at runtime. A Group can consist of Servers as well as other Groups. This allows for recursion and hence an optimal (re)use of defined Groups. There are two types of Groups: those made of the union and those made of the intersection of its members.

Union

As the name implies, defining a Group as a union means all of the members in the Group are included in the union group. Think of this as a logical 'OR.' For example, you can create a Group of all Servers running Windows by creating a union group of the cluster containing all machines running Windows 2003 and the one containing your Windows 2000 servers.

Intersection

Conversely, defining a Group as an intersection means its members must meet a more narrowly defined set of parameters to be included. Think of this as a logical 'AND.' For example, you may choose to create a Group of all Servers running Windows 2003 and using DC power by creating an intersection Group of the cluster containing all Servers running Windows 2003 and the cluster containing all Servers using DC power. This also helps to illustrate how Groups are independent organizational items -- Windows 2003 machines, DC power machines, and Windows 2003 machines using DC power are three separate Groups in our example. Depending on its operating system, adding a new Server to the DC power Group may or may not also add it to the Windows 2003 + DC power Group.

Putting it all together

We should now recognize a Virtual Platform as a prioritized set of cloud services offering great flexibility when an Application requires Services from different parts of a local network. Each cloud/service combination is given a priority used at runtime when a call is first instantiated. The technical nomenclature for this is the Service Resolution Process, which starts when a call request arrives at a Prophecy Server's routing port (or an outbound dialing request is made via the Session Control API). As learned from previous chapters, the number/token is extracted from the request and Prophecy queries the Route record for a list of Services in the current Site capable of handling the request. The resulting Service List is organized into Groups based on priority. If for some reason the the selected Service Endpoint is unavailable, the selection process will continue until the current Group is exhausted, at which point it will continue to the following Group with the next highest priority. This allows for intelligent, fine-tuned load distribution and failover across your Virtual Platform.

ANNOTATIONS: EXISTING POSTS

0 posts - click the button below to add a note to this page

Token Tester

| TOC

| VoIP Settings