Components That Mediator Uses
Mediator requires inputs from the following components to process requests and to enforce policies:
Service providers
Service consumers
CentraSite Mediator configuration options in
Integration Server Virtual services
Virtualized APIs
Virtual OData services
Service Providers
Service providers are the applications and systems that provide services that are exposed as web services in your SOA architecture. They consist of legacy systems, ERP systems, CRM systems, or other systems. The services provided by service providers can be leveraged throughout the SOA system by service consumers.
Service Consumers
A service consumer is an application, system, or technology that makes web service calls on a native service for the data and tools necessary to complete a specific task. For example, a service consumer could be a web form that is used to retrieve customer data from a service provider. Consumer applications are one type of service consumers that are kept synchronized with Mediator.
CentraSite
CentraSite provides the design-time environment that you use to create or reference all the assets of your SOA-based application including, virtual services, policies, consumers, XML schemas, BPEL processes, and so on. These assets, as well as the service providers' web services are published to CentraSite's UDDI registry or repository. The web services can be imported from many places including Integration Server.
In addition, you use CentraSite to view run-time events and performance metrics.
For details on CentraSite, see CentraSite User’s Guide.
Mediator Configuration Options in Integration Server
You need to configure some or all of the following Mediator configuration options in Integration Server Administrator:
The communication parameters required for
Mediator to exchange data with
CentraSite.
The SNMP destination for sending run-time events.
Mediator uses SNMP traps to capture events that you can send either to
CentraSite SNMP server or to a third-party SNMP server.
The email destinations for sending monitoring alerts or for logging transaction payloads.
The endpoints used for load balancing routing, if you want to distribute requests among multiple endpoints.
The keystores and truststores that are required for message-level security. They provide SSL authentication, encryption or decryption, and digital signing or verification services for all message content that
Mediator sends.
The HTTP or HTTPS ports on which
Mediator and the deployed virtual service are available.
The service fault responses that are returned to consuming applications.
You can configure
Mediator to act as a Security Token Service (STS) client.
Virtual Services
Virtual service is an enhanced copy of a service provider's web service and acts as the consumer-facing proxy for the provider's web service. You configure virtual services in CentraSite and deploy them to the Mediator server.
At design time, you virtualize a web service (make a copy of it) and then specify additional metadata that defines:
A
target type. A target type is the type of server or PEP application to which the virtual service is deployed.
Mediator is a target type.
A
target. A target is an object that represents a specific instance of a target type, for example, a specific
Integration Server that hosts
Mediator.
The consumer applications that is allowed to access the virtual service.
The transport protocol that the consumer application must use to communicate with the virtual service.
The virtual service's routing protocol that specifies how the virtual service routes the service requests to the native service endpoint. For HTTP or HTTPS requests, you can select the following routing protocols:
Straight Through routing (to route requests directly to the native service endpoint).
Context-Based routing (to route specific types of messages to specific endpoints according to the context-based routing rules).
Content-Based routing (to route specific types of messages to specific endpoints based on the specific values that appear in the request message).
Load Balancing routing (to distribute requests among multiple endpoints).
Any optional transformation files to transform the request or response messages.
Any optional
Integration Server services to pre-process or post-process the request or response messages.
The policy or policies for the virtual service.
For details on virtual services, see CentraSite User’s Guide.
Virtual Service Definitions
When you deploy the virtual service to a Mediator server, Mediator generates an XML document called a virtual service definition (VSD). The VSD defines the virtual service for Mediator and contains all the resources required to deploy the virtual service to a Mediator server, including the policy that applies to the service. You cannot edit the VSD.
Virtual Service Synchronization
When a virtual service is created and published to the CentraSite UDDI registry or repository, its WSDL contains no concrete endpoint until it is deployed to at least one instance of Mediator. After the virtual service is deployed to Mediator, Mediator updates its WSDL with an endpoint that points to the virtual service’s location on Mediator. Then the virtual service location is updated in CentraSite. This action synchronizes CentraSite and Mediator.
After the virtual service WSDL is deployed from CentraSite to Mediator and the WSDL with the new endpoint is redeployed to CentraSite, Mediator is aware of the endpoint of the virtual service, what policies to enforce, routing and load balancing requirements for the virtual service, and what event and performance data to send back to CentraSite. This event and performance data can be monitored in the CentraSite monitoring interface.
Additionally, CentraSite knows the new endpoint of the virtual service. A consumer application that is authorized to view the CentraSite UDDI registry or repository and to use the virtual service can locate the virtual service in the registry and invoke it.
Virtualized APIs
CentraSite's Application Programming Interface (API) Management platform enables enterprises to do the following:
Selectively externalize their new and existing assets as APIs across various channels.
Monitor the interface's lifecycle with an integrated infrastructure.
Ensure that the needs of developers and application using the API are met.
APIs are the new distribution channel for CentraSite assets. With an integrated infrastructure, you can:
Securely expose your APIs to external developers and partners (that is, any external entities with which your enterprise interacts such as, suppliers and vendors, dealers and distributors, customers, government agencies, trade organizations, and so on).
Provide design-time and run-time governance capabilities to the APIs.
To support the distribution channel, CentraSite API Management enables developers, architects, and business developers to:
Publish the right APIs into their organization's central registry.
Discover APIs and use them to assemble new applications.
Manage the entire process of creating, publishing, deploying, and retiring APIs.
Obtain detailed information about an API, including the list of its consumers, its technical support contacts, its disposition in the development lifecycle, usage tips, and performance data.
Control access to
CentraSite and to the metadata for individual APIs listed in the registry.
Impose mandatory approval processes to ensure that APIs accepted into the SOA adhere to organizational standards and policies.
Get notifications on the APIs they use.
Model the lifecycle process associated with each API and specify the events to be triggered when an API transitions from one lifecycle state to another.
For details on Virtualizng APIs, see CentraSite User’s Guide.
Virtual OData Services
An OData service is a query data access protocol for data centric services that have advantages of HTTP, REST, and ATOM principles. It combines simplicity of REST style approaches with SOAP style formalism to describe service interfaces, data models, and semantics. You configure OData services in CentraSite and deploy them to a Mediator server.
OData services are the new distribution channel for CentraSite assets. With an integrated infrastructure for CentraSite and Mediator, you can:
Perform auditing of data access
Restrict access based on authorization information
Restrict query predicates and functions
Perform traffic management
Perform authentication and authorization
Request transformation
Perform OData orchestration or filtering
Restrict batch operations
Get notifications on the OData services they use
For details on virtual OData services, see CentraSite User’s Guide.
