The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This chapter describes how to start using the Mediation Interface of Cisco Hosted Collaboration Mediation (HCM). You can manage services through a variety of associated requests or operations.
The various requests and operations are explained in Chapter 2, "Understanding Provision Web Service Interface".
This guide also includes feature descriptions, sample Extensible Markup Language (XML) code, typical workflow steps, and other relevant information.
This chapter contains the following sections:
•Mediation Interface Web Services Resources
•TM Forum Shared Information/Data Model Overview
This guide is intended to be a technical resource for application developers who want to use the Mediation Interface to retrieve the data from Cisco Hosted Collaboration Solution (HCS) deployments and implementations.
To use this guide, you need to have an advanced level of understanding of Internet network design, operation, and terminology. You also need to understand the basic concepts of HCM.
You should also understand high-level programming languages such as Java, or an equivalent language. and know the following:
•XML and XML Schema
•Web Service Definition Language (WSDL)
•Web Services
•Socket programming
•Web Services standards:
–WS-Notification
–WS-Enumeration
–WS-Resources
In most cases, the Mediation Interface operations, correlate to HCM operations.
You should have a basic understanding of Cisco HCS.
The Mediation Interface provides the following:
•Single entry point for client systems to issue commands to HCM.
•Ability to:
–Query inventory.
–Retrieve list data using WS-Notification and WS-Enumeration specification recommendations.
The Mediation Interface functional architecture consists of:
•WSDL/XSD files with Simple Object Access Protocol (SOAP) HTTP bindings that expose the NBI requests and XML-based data models for all northbound services.
•The Mediation Interface that receives, tracks, and manages the results of all NBI requests.
The Mediation Interface uses Web Services standards. The client must satisfy the following requirements:
•Must be able to connect to HCM using HTTP or HTTPS.
•To make a request, the client does not have to be Web Services-based; it can be a plain Java client.
All services exposed by the Mediation Interface are defined, using WSDL/XSD with SOAP HTTP bindings and exposed as Web Services.
Requested bulk data is retrieved by WS-Enumeration standard requests and responses.
The TM Forum Shared Information/Data Model (SID) is used as the foundation data model and the version used is Information Framework Phase VIII.
HCM will implement the SID as its common model to create and maintain the data interoperability layer in HCS. HCM reconciles semantic differences among applications through real-time mediation. This enables you to modify or replace components without making major changes to other components in the architecture.
See Figure 1-1 for the TM Forum SID Domains.
Figure 1-1 TM Forum SID Domains
Mapping each application and service interface point-to-point, adds complexity. Mapping to the SID, significantly reduces complexity and provides an inherent layer of abstraction. This ensures consistent interpretation of data across diverse services and data sources, within the HCM architecture.
See Figure 1-2 for an example of the point-to-point integration and SID integration.
Figure 1-2 Integration Scenarios
The domain manager employs Simple Object Access Protocol (SOAP) message patterns to facilitate requests and responses (synchronous). For more information, refer Synchronous Message Pattern.
All domain managers implement the basic request and response SOAP message pattern. A SOAP request can be a list operation. When a SOAP request is submitted for processing, an immediate response is returned.
The response will yield the expected result for the corresponding SOAP request. See Appendix B, "Sample XML API Requests and Responses" for sample expected results.
In all cases, responses are transformed into a standard SID-based structure and returned to the service consumer for processing.