This chapter provides an overview of the Harmony solution and client connectivity architecture. It contains these sections:
· Harmony Solution Architecture
· Client Connectivity Architecture
Harmony Solution Architecture
The OpenMethods Harmony solution is comprised of several components working together to provide a rich and powerful integration between an Agent Desktop application, such as a CRM, and the underlying Telephony and Multimedia platforms.
The Harmony Integration Server (HIS) is the core of the solution and hosts the CTI platform integration, workflow, and queue adapter components. It also provides client connectivity to the agent desktop adapter components.
The Eclipse Equinox OSGi platform forms the foundation of HIS and supports the orchestration of components and services. Each element that makes up HIS exists as an OSGi bundle that publishes services for other elements to use and consumes the services provided by others.
Interaction Processors are those components responsible for managing and manipulating interactions. There are two types of Interaction Processors hosted within the HIS platform: CTI Integrations and Queue Adapters. CTI Integrations specialize in the visual delivery of interactions to an agent desktop as well as enabling third-party call control. A Queue Adapter is responsible for monitoring third-party multimedia platforms and injecting external interactions into a CTI for routing and agent selection.
Client Connectivity Architecture
Agent desktop applications today are built using a wide range of technologies from thick clients written in .NET or Java to thin web-based clients powered by HTML and JavaScript. As a result, HIS supports several ways for agent desktop integrations to communicate, each tailored toward specific technologies and client capabilities.
Agent desktop integrations can communicate with HIS over HTTP or through a low-level socket protocol. Although most client technologies are capable of using any or all of these methods of communication, some methods are more suited to a particular technology or are geared towards less feature rich integrations or rapid development. For example, web-based clients can leverage the HTTP capabilities inherent to the technologies they use.
As Figure 2 illustrates, some forms of communication are also flexible from a deployment perspective. The HTTP channel can be managed as an embedded component within the HIS container or deployed as a separate process on the same or different server. This flexibility is key to supporting the wide range of customer environments.
Connectivity Components
HIS client connectivity is provided by a set of Transport providers, each with their own Protocol handlers, all interacting with the Network Core. A client connects to HIS over one of the available Transport mechanisms, such as HTTP. During the initial connection, the client and Transport negotiate which Protocol will be used. Once a protocol is selected, the client will be registered with the Network Core and can begin making requests and receiving events.
Network Core
The Network Core component tracks the Network Services and Resources available within the HIS container and facilitates client access to those Network Services and Resources. Clients can query the Network Core for which services and resources are available and monitor their status. Clients cannot use or receive events from a Network Service or Resource until they have been bound to it. A service or resource binding forms a persistent connection between the client and that object and enables the delivery of messages to and the receiving of events from it. The creation and management of these object bindings is handled by the client in the case of a Direct Protocol, or by the Protocol itself for Managed Protocols.
Network Service
A Network Service is a long-lived component hosted within HIS and represents a specific set of features or capabilities offered by that HIS instance. Each Network Service accepts client requests in the form of messages and generates messages in response to a request and events as they occur. A Network Service may also have additional capabilities exposed through one or more Network Resources. An Interaction Processor provides access to CTI functionality and is a good example of a Network Service. It allows a client to create a new agent session as a Network Resource and bind to it, which offers even further capabilities such as call control.
Network Resource
A Network Resource is similar to a Network Service in that clients can make requests to it and the resource will generate response and event messages. However, unlike the long-lived nature of Network Services, a Network Resource is often transient. It typically represents a limited set of capabilities offered to a single client or group of clients. The Interaction Processor used in the example above, created a new Agent Session Network Resource dedicated to the client making the initial login request. This separation allows each client to limit the amount of information it might receive through events or responses to only those related to it.
Transport vs. Protocol
The concepts of Transport, how information is received from and delivered to a client, and Protocol, how that information is structured, are separate and distinct within the domain of HIS client connectivity. Client communication is performed using a combination of the two concepts. A client will use a single Protocol over a particular type of Transport.
Transports
The two types of Transports supported are HTTP and TCP/IP sockets. Each of these Transports offers unique benefits and challenges for client application developers. It’s important for the correct Transport to be selected when developing a client application. The technology used to build the client, as well as any performance constraints or allotted development time, should guide the choice of Transport.
HTTP Transport
HTTP access to HIS can be provisioned one of two ways. In the embedded model, a slimmed-down version of the Jetty web server is hosted within the HIS container. The protocol servlets are registered with the embedded server and talk directly to the Network Core through its OSGi service API. The external configuration consists of a java servlet compatible web server or application server with the protocol servlets installed as a web application. The external protocol servlets then communicate with HIS through the TCP/IP socket based Transport and appropriate protocol. In both environments, HTTPS is supported for secure communication between the client and HIS.
TCP/IP Socket Transport
The low-level nature of the socket-based Transport provides the highest available performance for clients. This performance comes at the cost of increased complexity and the need for advanced developer skills. The socket Transport adds very little overhead to the message Protocol used. It is also near real-time as communication between the client and HIS is bi-directional. Events generated by HIS can be pushed to the client directly, instead of the client needing to poll for those events as happens for the HTTP Transport. Security can be enabled using TLS.
Protocols
The decision of which Protocol to use is also important when developing a client application. The choice of Protocol could reduce development time but limit the capabilities of the client application or make the inclusion of new features more difficult. The HIS message Protocols are separated into two families: Direct and Managed.
Direct Protocol
The Direct Protocol provides a low-level messaging scheme that tightly maps to the Network Core API and the APIs provided by the Network Services and Resources it manages. The direct protocol is built into the Network Core component and is always available regardless of which Transports or Managed Protocols are available.
When using the Direct Protocol, the client is expected to handle all the details of Service and Resource binding. Although this protocol is more complex than the Managed Protocols, it allows unfettered access to any and all features provided by those Services and Resources.
Managed Protocol
A Managed Protocol presents a high-level request scheme that abstracts the underlying Network Core and Network Object APIs. It is typically targeted at a specific Network Service and/or Resource. For example, a client using the Third-Party Call Control Managed Protocol would simply make requests like Log In, or Answer Call and those requests would be delivered to the appropriate service or resource by the Managed Protocol implementation. The client would be unaware of the details surrounding the binding and management of those network objects. Although a Managed Protocol might be applicable to different Transports, the implementation of the protocol will be unique for each Transport supported.
0 Comments