Using a service development environment is all about reusing and sharing components to enhance efficiency in all areas of the software development lifecycle. Componentizing service development makes it easier for enterprise developers that are accustomed to their own IDEs (like Eclipse), to develop converged applications.

Componetizing can also provide a means of abstracting away for the developer the complexities of the underlying protocols or APIs. Service Initiation Protocol (SIP) Service Oriented Architecture (SOA) removes the complexities of the SIP protocol by exposing reusable service components as standards-based Web services to external applications.

An example of this would be the supplied components with the Avaya UDS: these components provide abstracted SIP functionality, so that you, as a developer, do not need to understand the signaling involved. You can take advantage of SIP applications integrated with your business applications, quickly incorporating SIP-based real-time session control into your applications without knowing how it works behind the scenes. This allows you to be a SIP developer without becoming a SIP expert: The components in UDS do the work for you.

Another example of a product that includes an Eclipse-based development environment, and which allows you to compose applications using pre-built, reusable components, is the Avaya Dialog Designer. Within the Dialog Designer, the reusable components are called modules. You can create modules yourself or make use of off-the-shelf modules developed by third parties.

The Avaya Dialog Designer provides a drag-and-drop environment for developing and maintaining speech and touch-tone applications. Speech application projects are built by creating a call flow comprising connected nodes. A node can represent a functional piece of code that performs an action, such as playing an announcement, providing callers with a list of options or transferring data. Alternatively, a node can represent a module, which is itself a previously-created speech application project that defines a secondary or inner call flow. The Dialog Designer can be used to create modules by deploying speech application projects to the Dialog Designer reusable modules directory, from where they can be used in multiple applications.

Let's take a look at how the Avaya UDS and shared components work.

SIP SOA in a Nutshell
The service development environment uses shared services functions like any other development environment, but takes away the SIP layer of development. With UDS, SIP transactions are provided in a set of pre-built components as part of SIP SOA. As the developer, you become an assembler of components, some of which are reusable.

SIP SOA is a structured environment, aligned with SOA principles, that makes it easy to build and deploy SIP applications quickly. SIP SOA provides a framework for reusing and managing service components, making them available to multiple applications after components are deployed.

Service Components are pre-built software building blocks that provide specific functionality that you can compose into logical applications. SIP SOA organizes service components in a three-tier hierarchy—Foundation Element Blocks (FEBs), Service Logic Blocks (SLBs) and Business Logic Blocks (BLBs).

Each tier provides a specific class of functionality. FEBs, at the lowest layer of service components, provide SIP layer interaction and control of SIP endpoints, such as user agents and media servers. FEBs protect the application from the underlying application resources or service network, so the application can work across multiple network types and with multiple application or network resources, such as media servers and media gateways.

Figure 1. How a typical application component instigates a call. (Source: Avaya)

The middle tier consists of SLBs that provide reusable "microservices" for specific functionality like creating a conference call or setting up a point-to-point call using third-party call control. The top tier consists of BLBs, which collects and coordinates groups of SLBs into a logical service or application. The BLB also acts as the external interface (exposure object) to the communications application, allowing it to be called by an external application.

In a nutshell, the end-point dialogs are created by FEB components and connected using an SLB component. All you have to do is write a component BLB that asks the SLB to create a call. The Service Components contain both FEBs and SLBs.

To get the big picture of how these components interact, let's look at an example of how a typical application component launches an external application-initiated call in a SIP SOA. First, an external application uses a non-SIP trigger to access an application BLB over Remote Monitoring Interface (RMI) or Service Oriented Architecture Protocol (SOAP) requesting a call be set up between two callees. The application component creates request dialogs and sends them to the Outgoing Dialog Service Component for each callee. Next, the Outgoing Dialog Service creates dialogs between the SIP A/S and each of the callees, and the application component initializes the Call Service to set up the call. The Call Service gets the two callee dialogs and puts them into a call, and then the callees are dialed and invites sent. Further, an external resource like a media server can tap into the services residing on the SIP A/S (See Figure 1).

Now let's explore the shared services in a SIP SOA environment.