8-0 administering mediator

Title Page

Administering webMethods Mediator

Version 8.0

December 2009

Copyright& Docu-ment ID
This document applies to webMethods Mediator Version 8.0 and to all subsequent releases.

Specifications contained herein are subject to change and these changes will be reported in subsequent release notes or new editions.

Copyright © 2009 Software AG, Darmstadt, Germany and/or Software AG USA, Inc., Reston, VA, United States of America, and/or their licensors.

The name Software AG, webMethods, and all Software AG product names are either trademarks or registered trademarks of Software AG and/or Software AG USA, Inc. and/or their licensors. Other company and product names mentioned herein may be trademarks of their respective owners.

Use of this software is subject to adherence to Software AG’s licensing conditions and terms. These terms are part of the product documentation, located at http://documentation.softwareag.com/legal/ and/or in the root installation directory of the licensed product(s).

This software may include portions of third-party products. For third-party copyright notices and license terms, please refer to "License Texts, Copyright Notices and Disclaimers of Third Party Products." This document is part of the product documentation, located at http://documentation.softwareag.com/legal/ and/or in the root installation directory of the licensed product(s).

Document ID: SMG-AG-80-20091204

http://documentation.softwareag.com/legal/



Table of Contents

About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Documentation Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Online Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13What Is Mediator? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Mediation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Policy Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Mediator in the SOA Landscape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Mediator Key Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Service Virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Virtual Service Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Monitoring and Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Message Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Policy Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Service Level Agreement Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Security Policy Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Consumer Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Seamless Integration with CentraSite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Clustering Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Mediator Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Service Providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Service Consumers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19CentraSite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Virtual Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Virtual Service Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Virtual Service Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2. Deploying and Synchronizing Virtual Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Communication Between Mediator and CentraSite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Deploying and Redeploying Virtual Services to Mediator . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Design-Time Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24Deployment Time Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Administering webMethods Mediator Version 8.0 3

Table of Contents

Synchronizing Virtual Service Subscription Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Subscription Update Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Updating Mediator at Start Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Subscription Notification Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27Virtual Service Deployment Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Confirmation Deployment Message Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Mediator Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Synchronizing Consumer Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Synchronization Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29Synchronizing All Consumer Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31Manual Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Undeploying Virtual Services in Mediator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3. Metrics and Events Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Metrics Reported by Mediator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Events Reported by Mediator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Performance Data Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34Intervals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Performance Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Losing Performance Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Run-Time Event Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Event Types Set on Mediator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Policy Violation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Service Level Agreement Alerting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41Identify Consumer Policy Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Enforcing Policies Against Aggregated Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42Alert Destinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Event Destinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44SNMP Destinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44SMTP (E-mail) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Local Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Audit Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4. Clustering and Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Nodes and Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Load Balancers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Subscription Endpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4 Administering webMethods Mediator Version 8.0

Table of Contents

Load Balancer URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50Creating a Mediated Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Configuring Integration Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Configuring the Third-Party Load Balancer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Configuring Mediator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Configuring CentraSite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Deployment and Synchronization in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Role of the Shared Cache in Deployment and Synchronization . . . . . . . . . . . . . . . . . . 53Synchronizing Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Deployment State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Communication During Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Communication During Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55Communication When a Node Leaves a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Processing Service Requests in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Metric and Event Notification in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Role of the Shared Cache in Metrics and Events Notification . . . . . . . . . . . . . . . . . . . 57Senior Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Processing Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Reporting Non-Aggregated Run-Time Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Reporting Performance Data and Aggregated Events in a Cluster . . . . . . . . . . . . . . . 59

Load Balancing Service Providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Round-Robin Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Inactive Endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5. Enforcing Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Actions Mediator Enforces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Transport Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65CentraSite Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Integration Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65Mediator Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Mediator Security Processesing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Selecting a Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Multiple Security Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Enforcing Authentication Policy Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Require HTTP Basic Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Require WSS Username Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Require WSS X.509 Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Require WSS SAML Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Run-Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69


Table of Contents

Enforcing Authorization Policy Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Authorize Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Authorize Against Registered Consumers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Identify Consumer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Enforcing XML Security Policy Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Require Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Require Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Identify Consumer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Require SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74Require Timestamps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Enforcing the Validate Schema Policy Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74When Security Policy Actions Are Violated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6. Configuring Mediator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Before Configuring Mediator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76Configuring Communication with CentraSite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77SNMP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Setting a CentraSite SNMP Destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Setting a Third-Party SNMP Destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Setting Event Notification Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

E-mail Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83HTTP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Keystore Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Viewing and Synchronizing Services Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87Synchronizing Consumer Applications Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

7. Configuring SOAP Over JMS Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Configuring SOAP-JMS Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Creating a SOAP-JMS Web Service Endpoint Alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Creating a SOAP-JMS Provider Web Service Endpoint Alias . . . . . . . . . . . . . . . . . . . 94Creating a SOAP-JMS Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Creating a SOAP-JMS Consumer Web Service Endpoint Alias . . . . . . . . . . . . . . . . . . 96

About Managing SOAP-JMS Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Controlling Thread Usage for SOAP-JMS Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Viewing Thread Usage for SOAP-JMS Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99Increasing or Decreasing Thread Usage for All Triggers . . . . . . . . . . . . . . . . . . . . . . . 100

Enabling, Disabling, and Suspending SOAP-JMS Triggers . . . . . . . . . . . . . . . . . . . . . . . . . 101Built-In Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

A. Advanced Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106pg.3pSnmpSender. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106


Table of Contents

pg.CollectionPool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106pg.CollectionWorkQueue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106pg.cs.snmpTarget. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107pg.csSnmpSender. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109pg.debug. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109pg.delayedRefresher. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109pg.email. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109pg.IntervalPool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111pg.jaxbFileStore. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111pg.keystore. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111pg.lb. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111pg.passman. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112pg.PgMenConfiguration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112pg.PgMenSharedCacheManager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113pg.PgMetricsFormatter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113pg.policygateway. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113pg.proxyLoader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114pg.rampartdeploymenthandler. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114pg.ReportingPool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114pg.ReportingWorkQueue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115pg.serviceReader. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115pg.snmp.communityTarget. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115pg.snmp.customTarget. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117pg.snmp.userTarget. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117pg.vsdTransformer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119pg.wrapperFactory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

B. Server Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122watt.debug. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122watt.net. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122watt.server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123


Table of Contents


About This Guide

This guide is for administrators of webMethods Mediator. It provides an overview of how Mediator operates and explains administrative tasks such as connecting Mediator to CentraSite and configuring security and logging. It also contains explains concepts such as clustering, load balancing, architecture, and monitoring.

Document Conventions

Documentation Installation

You can download the product documentation using the Software AG Installer. Depending on the release of the webMethods product suite, the location of the downloaded documentation will be as shown in the table below.

Convention Description

Bold Identifies elements on a user interface.

Narrow font Identifies storage locations for services on webMethods Integration Server, using the convention folder.subfolder:service.

UPPERCASE Identifies keyboard keys. Keys you must press simultaneously are joined with a plus sign (+).

Italic Identifies variables for which you must supply values specific to your own situation or environment. Identifies new terms the first time they occur in the text.

Monospace font

Identifies text you must type or messages displayed by the system.

{ } Indicates a set of choices from which you must choose one. Type only the information inside the curly braces. Do not type the { } symbols.

| Separates two mutually exclusive choices in a syntax line. Type one of these choices. Do not type the | symbol.

[ ] Indicates one or more options. Type only the information inside the square brackets. Do not type the [ ] symbols.

... Indicates that you can type multiple options of the same type. Type only the information. Do not type the ellipsis (...).

For webMethods... The documentation is downloaded to...

6.x The installation directory of each product.


About This Guide

Online Information

You can find additional information about Software AG products at the locations listed below.

Note: The Empower Product Support Web site and the Software AG Documentation Web site replace Software AG ServLine24 and webMethods Advantage.

7.x A central directory named _documentation in the main installation directory (webMethods by default).

8.x A central directory named _documentation in the main installation directory (Software AG by default).

If you want to... Go to...

Access the latest version of product documentation.

Software AG Documentation Web site

http://documentation.softwareag.com

Find information about product releases and tools that you can use to resolve problems.

See the Knowledge Center to:

Read technical articles and papers.

Download fixes and service packs.

Learn about critical alerts.

See the Products area to:

Download products.

Get information about product availability.

Access older versions of product documentation.

Submit feature/enhancement requests.

Empower Product Support Web site

https://empower.softwareag.com

For webMethods... The documentation is downloaded to...


http://documentation.softwareag.com

https://empower.softwareag.com/KnowledgeCenter/default.asp

https://empower.softwareag.com/Products/default.asp

https://empower.softwareag.com

About This Guide

Access additional articles, demos, and tutorials.

Obtain technical information, useful resources, and online discussion forums, moderated by Software AG professionals, to help you do more with Software AG technology.

Use the online discussion forums to exchange best practices and chat with other experts.

Expand your knowledge about product documentation, code samples, articles, online seminars, and tutorials.

Link to external Web sites that discuss open standards and many Web technology topics.

See how other customers are streamlining their operations with technology from Software AG.

Software AG Developer Community for webMethods

http://communities.softwareag.com/webmethods

If you want to... Go to...


http://communities.softwareag.com/webmethods

About This Guide


1 Introduction

What Is Mediator? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Mediator in the SOA Landscape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Mediator Key Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Mediator Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19


What Is Mediator?

What Is Mediator?

webMethods Mediator is a Web service mediation and policy enforcement application, designed for use with Software AG Service-Oriented Architecture (SOA) products. The application, which is deployed as the WmMediator package that runs on Integration Server, provides an infrastructure for the run-time enforcement of service policies that are defined and managed from Software AG’s UDDI registry, CentraSite.

Mediator serves two primary functions: Serving as an intermediary between service consumers and service providers (mediation) and serving as a policy enforcement point (PEP) that enforces policies defined for a Web service.

Mediation

Through service virtualization, Mediator serves as an intermediary between service consumers and service providers. This means that service requests sent from a service consumer actually go to a virtual service hosted on Mediator for processing rather than directly to the service provider.

Mediation also provides improved interoperability between consumers and providers. Since all requests from the service consumer pass through Mediator, you can make any necessary changes to the message or its protocols before engaging with the provider.

Policy Enforcement

Web services can be modified for specific behavior by amending their definitions with service policies. Policies define the behavior of the services in your SOA system. Mediator ensures that request messages from the service consumer or response messages from the service provider conform to any policies defined for a Web service that is under policy management.

Policies can follow specific standards (for example, WS-Policy, WS-Security, and WS-Addressing) or be custom made. Mediator supports some standard policies and customized policies or policy-like attributes.

Example

In a regular scenario, requests from a consumer application go directly to a Web service that in turn exposes services in a native service provider. In a mediated system, the request goes through Mediator where policies are applied to the Web service and enforced.

For example, a consumer application could be a Web form filled out by a bank employee looking for all the records for a customer: savings, investment, and mortgage. The Customer Data service handles requests for such data, so Mediator applies the policies to the request. The policies it enforces for the service dictate that the employee making the


Introduction

request is eligible to see the mortgage data, but none of the other data requested. The service retrieves the mortgage data from the Financial Holdings service provider and returns it to the consumer application.

Mediator example

Mediator in the SOA Landscape

Mediator is built on the same run-time platform as Integration Server and provides the enforcement of service policies that are defined in and managed from CentraSite. To perform this role, Mediator depends on virtual services, also created and maintained in CentraSite, that are deployed to Mediator through the use of virtual service definitions (VSDs). Once the virtual service is deployed, Mediator performs run-time policy enforcement on the virtual service. As it receives requests, Mediator is responsible to forward them to the service provider (if the request satisfies the security policy) and return the response.

The following diagram shows the run-time interactions of Mediator in the system.


Mediator Key Capabilities

Mediator in the system


Mediator provides several capabilities to your SOA system.

Service Virtualization

Through the use of virtual services, Mediator enables the service consumers and service providers to be loosely coupled. This enables for more flexibility in your SOA system. For more information on the benefits of loose coupling, see “Virtual Services” on page 20.

Step Description

1 A service consumer makes a call to a Web service running on a service provider.

2 The virtual service running on Mediator receives and processes the message.

3 The message is sent to the service provider.

4 The service provider retrieves the required data or performs the proper task.

5 The service provider, through the native service, sends the requested data back through Mediator to the consumer application.

6 Throughout the process, Mediator sends monitoring data through SNMP traps, e-mail, and other means, to CentraSite.


Introduction

Virtual Service Updates

Because Mediator communicates directly with CentraSite, when you make changes to the original virtual service on CentraSite, you can redeploy the virtual service to Mediator. For more information about updating virtual services, see “Communication Between Mediator and CentraSite” on page 24.

Monitoring and Statistics

Mediator enables you to report performance data and statistics to CentraSite for all virtual services that are deployed to Mediator. For more information, see “Performance Data Reporting” on page 34.

Message Transformation

Message transformation is set by the virtual service that is configured in CentraSite and deployed to Mediator. Mediator can use an XSLT file or make a call to an ESB service to transform SOAP messages during the mediation process. For more information about setting this capability, see the CentraSite ActiveSOA documentation.

Note: If the virtual service deployed to Mediator contains an invokeESB assertion, your installation of Mediator must be licensed to invoke ESB services. A product code of SMG indicates that Mediator is licensed to invoke ESB services. For more information about the invokeESB assertion, see the CentraSite ActiveSOA documentation.

Policy Enforcement

You set policies on virtual services in CentraSite. Policies are a sequence of actions that should be carried out by Mediator when a service consumer requests a particular service. These policies can restrict the data sent to service providers or the data returned to the consumer application. For more information about creating policies, see the CentraSite ActiveSOA documentation.

Service Level Agreement Enforcement

You can use service level agreements (SLAs) to monitor and report statistics regarding the performance of virtual services and a particular consumer application. For more information, see “Service Level Agreement Alerting” on page 41.

Security Policy Enforcement

Mediator offers several security policies that keep messages and Web services safe. For more information about security, see “Enforcing Security Policies” on page 63.



Consumer Provisioning

Mediator maintains a list of consumer applications configured in CentraSite that are authorized to use the virtual services deployed to Mediator. You can use these consumer applications to write policies that enforce which consumer applications can send requests or receive responses from the virtual service. You can also associate the consumer applications to specific SLAs. Mediator synchronizes this list of consumer applications at regular intervals, or through a manual process. For more information about consumer applications, see “Synchronizing Consumer Applications” on page 28.

Seamless Integration with CentraSite

Mediator hosts the virtual services that you create and define in CentraSite. Part of defining virtual services on CentraSite is configuring those policies that Mediator will enforce and those consumer applications that Mediator will monitor. When you deploy the virtual service to Mediator, and service consumers make requests of the service provider, Mediator uses service virtualization to mediate and enforce the policies defined for the virtual service. Mediator then reports the collected events and metrics to CentraSite.

Integration with CentraSite

Clustering Support

Clustering enables Mediator to distribute the messages it receives between a set of listed endpoints. Mediator works with a load balancer to properly distribute these messages. For more information about load balancing, see “Clustering and Load Balancing” on page 47.


Introduction

Mediator Components

Mediator works as an intermediary between service providers and service consumers. It requires inputs from different components in the system to process requests and enforce policies. This section describes the inputs and components and how they work together in the mediation layer. This section describes the following:

Service providers (native services)

Service consumers

CentraSite and UDDI

Virtual services

Virtual service definitions

Service Providers

Service providers, or native services, are the applications and systems that house the services that are exposed in your SOA architecture. They can consist of legacy systems, ERP systems, CRM systems, or other systems. The services they provide can be leveraged throughout the SOA system by service consumers.

Service Consumers

A service consumer is an application, system, or technology that calls on a native service for the data and tools necessary to complete a specific task. An example of 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 consumer that are kept synchronized with Mediator. For more information about consumer application synchronization, see “Synchronizing Consumer Applications” on page 28.

CentraSite

CentraSite is the design-time environment for creating virtual services from Web services and the monitoring interface for tracking virtual service usage and performance. CentraSite contains a UDDI registry. This is the registry to which Web services and related virtual services are initially published. The Web services can come from many places, including Integration Server.

For more information about CentraSite’s communication with Mediator, see “Communication Between Mediator and CentraSite” on page 24.


Mediator Components

Virtual Services

In SOA, Web services on service providers are exposed for use by consumer applications. These services enable access to the native systems. Rather than giving consumer applications direct access to the Web services, however, SOA employs the use of virtual services. Virtual services are enhanced clones of actual Web services. They function as proxies for the real Web services that were published to the UDDI registry, the difference being that virtual services invoke the services from which they are cloned.

Virtual services enable for loose coupling between consumers and providers by providing location, protocol, and format independence between the two. This loose coupling means that changes made to either the service providers or consumers do not necessarily require a change in the other. This is because there is no direct connection between the two; instead, they depend upon Mediator for the connection. This means that the Web service that the service consumer invokes is hidden from the consumer application, with Mediator serving as the mediation layer.

In a design-time environment, a Web service is copied, and then its WSDL is enhanced with additional metadata. This enhanced copy is the virtual service. The metadata that is added includes information that defines:

A target type. A target type is the type of server/PEP application with which the virtual service will interact. Mediator is a target type.

A target. A target is a specific instance of a target type; for example, a specific Mediator endpoint.

One or more consumer applications that will use the virtual service.

The specific transport protocol that the consumer application must use to communicate with the virtual service.

Routing and load balancing for the virtual service. When making a call to the actual service endpoint, Mediator supports load balancing between multiple endpoints registered under the load-balanced Mediator.

Incorporated or attached policies.

Event and performance definitions that the target will return. These relate to how the virtual service is functioning.

Virtual Service Definitions

CentraSite sends VSDs to Mediator to deploy virtual services. VSDs are WSDL files that define a specific virtual service and contain all of the resources required for that virtual service to deploy, undeploy, or redeploy. Each virtual service is defined by its own VSD.


Introduction

Virtual Service Synchronization

When a virtual service is created and published to the CentraSite UDDI registry, its WSDL contains an endpoint that points to CentraSite. 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 WSDL for the Web service is redeployed to 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. Then a consumer application that is authorized to view the CentraSite UDDI registry and use the virtual service can locate the virtual service in the registry and invoke it. The request message will go to Integration Server via Mediator.

For more information about virtual service synchronization, see “Communication Between Mediator and CentraSite” on page 24.

For information about setting up CentraSite communication in Mediator, see “Configuring Communication with CentraSite” on page 77.


Mediator Components


2 Deploying and Synchronizing Virtual Services

Communication Between Mediator and CentraSite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Deploying and Redeploying Virtual Services to Mediator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Synchronizing Virtual Service Subscription Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Synchronizing Consumer Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

Undeploying Virtual Services in Mediator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31


Communication Between Mediator and CentraSite

Communication Between Mediator and CentraSite

Because virtual services are created on CentraSite and deployed to Mediator, communication between the two is vital. In addition to deploying, redeploying, and undeploying virtual services, CentraSite must communicate any virtual service updates to Mediator. CentraSite uses the target endpoint you register when creating the target (Mediator) to communicate changes in the virtual services to the instance of Mediator to which it is deployed. Mediator also relies on CentraSite for consumer application updates.

Deploying and Redeploying Virtual Services to Mediator

To deploy or redeploy virtual services, you must design the virtual service in CentraSite and then deploy the virtual service to Mediator.

Design-Time Process

Design-time activities apply only to those services you deploy or redeploy to Mediator. CentraSite is the design-time container for the virtual service. Until deployment or redeployment, there is no interaction with any other components of the architecture. Design-time includes the following steps:

1 You create a virtual service and run-time policy. The service and the policy are stored in the CentraSite repository as assets.

2 You set design-time policies that govern what a user can do (configuring, editing, and deploying) at a specific lifetime state of those assets.

After you have defined the virtual service in CentraSite, the virtual service is ready for deployment or redeployment. For more information about the steps involved in creating virtual services and other assets, see the CentraSite ActiveSOA documentation.

Deployment Time Process

When a user deploys a virtual service to a target, CentraSite generates an XML document, called a virtual service definition (VSD) to communicate the details of the virtual service to Mediator. The VSD defines the virtual service for Mediator and contains the service WSDL and all the run-time policies and resources required for Mediator to deploy or redeploy the virtual service. For an explanation of the elements in the VSD file, see “VSD Elements” on page 79.

After the virtual service is deployed or redeployed, Mediator updates the WSDL with the new location of the virtual service and sends an update to CentraSite that identifies the entry URL of the virtual service on Mediator. CentraSite then updates the virtual service’s deployment state.


Deploying and Synchronizing Virtual Services

At deployment time, CentraSite must communicate with Mediator to deploy VSDs and associated run-time policies. For more information about setting up communication between CentraSite and Mediator, see “Configuring Communication with CentraSite” on page 77.

Deployment Interactions Between CentraSite and Mediator

Step Description

1 When a user deploys or reploys a virtual service, CentraSite uses a notification message to notify Mediator.

2 Mediator retrieves the VSD.

3 Mediator checks the VSD and deploys or redeploys the virtual service.

4 Mediator sends the virtual service status (whether deployed or redeployed) with the endpoint, to CentraSite.

Mediator continues to listen for notification messages that indicate whether the virtual service was updated or deleted since being deployed. For more information about this process, see “Synchronizing Virtual Service Subscription Updates” on page 26.


Synchronizing Virtual Service Subscription Updates

Synchronizing Virtual Service Subscription Updates

When you create and publish a virtual service to the CentraSite UDDI registry, its WSDL contains an endpoint that points to CentraSite. After you deploy the virtual service to Mediator, it updates the WSDL with an endpoint that points to the virtual service’s location. Then the WSDL for the service is redeployed to CentraSite. This action synchronizes CentraSite and Mediator.

Even after this initial synchronization, Mediator continues to monitor CentraSite for updates to that virtual service. Updates to virtual services include deployment and undeployment notifications and other updates that change the way Mediator interacts with the virtual service and CentraSite.

Subscription Update Process

Virtual service subscription updates begin when CentraSite notifies Mediator using a subscription notification message. CentraSite sends subscription notification messages on a regular, timed basis (every two minutes), regardless of service update activity. These subscription notification messages indicate whether the virtual service was added, updated, or deleted. They also indicate the time interval during which CentraSite updates occurred, called the coverage period. The coverage period is important because it defines a time period over which Mediator confirms that the virtual services deployed to Mediator are synchronized with CentraSite and whether to initiate a synchronization effort from Mediator. The coverage period becomes a benchmark that can be used for subscription recovery and consumer application updates. For more information about these uses, see “Subscription Notification Failure” on page 27 or “Synchronizing Consumer Applications” on page 28.

Updating Mediator at Start Up

When you start a Mediator instance, it queries CentraSite to catch up with updates made while Mediator was down. Mediator does this by requesting a list of all services that have a deployment state of deploying, redeploying, or undeploying. These states represent services for which CentraSite is awaiting confirmation from the target (Mediator) to which the service has been deployed, redeployed, or undeployed.

Recovery

If the update to a virtual service fails, Mediator and CentraSite recover. For these cases, Mediator and CentraSite are designed to behave in certain ways so that the process can recover. Recovery from the following scenarios is described below:

Subscription Notification Failure

Virtual Service Deployment Failure

Confirmation Deployment Message Failure



Mediator Failure

Subscription Notification Failure

If Mediator does not receive a subscription notification, CentraSite does not attempt to resend the subscription notification message. Instead, CentraSite waits until the next scheduled notification time before it tries to resend the subscription message. The coverage period of the next message will be extended to include the unconfirmed interval (the coverage start time will remain as the start time of the unconfirmed period) and the message will include all services updated during the expanded interval.

For example, suppose the coverage period, which is 2 minutes, started at 10:02:35. Mediator did not receive the subscription notification message for that time period. In this case, CentraSite would set the end time of the next coverage period to 10:06:35, but it would keep the start time of the coverage period (10:02:35) to ensure that both periods are covered.

Setting the Coverage Period


Synchronizing Consumer Applications

Virtual Service Deployment Failure

If Mediator encounters a problem deploying or redeploying a service, it notifies CentraSite by sending a deployment state of “failed” and a deployment message describing the problem. This failure is also logged to Mediator. In this case, it is up to the CentraSite or Mediator administrator to take corrective action and redeploy the service manually from CentraSite.

Errors during undeployment are different from those for deployment or redeployment because during undeployment the virtual service is removed and therefore no longer exists on Mediator. In this case, when a second “undeploying” request arrives, Mediator recognizes that the service is not currently deployed, logs a message indicating an attempt to undeploy a nonexistent virtual service, and uses a confirmation deployment message to confirm that the status is undeployed.

Confirmation Deployment Message Failure

If the confirmation deployment message call fails, Mediator logs the failure, but does not resend the confirmation message. In this case it is assumed that the CentraSite administrator is waiting for confirmation, and will take some corrective action when confirmation does not occur.

For example, assume that CentraSite is attempting to deploy a new service, or redeploy an existing service, and the deployment succeeds, but the confirmation fails. In this case the deploy state on CentraSite will remain “Deploying,” indicating that it is waiting for confirmation.

The Mediator Administration console includes a Services Sync button to enable the Mediator administrator to manually correct this process anytime Mediator is out of synch with its configuration on CentraSite. See “Viewing and Synchronizing Services Manually” on page 87, for more information on using this feature.

Mediator Failure

If Mediator becomes unavailable during the deployment of a service, CentraSite attempts to deploy the virtual service again during synchronization. The Mediator administration console includes a Services Sync button to enable the Mediator administrator to manually start this process anytime Mediator is out of synch with its configuration on CentraSite. For more information about using this feature, see “Viewing and Synchronizing Services Manually” on page 87.


Consumer applications are the specific users of virtual services in your SOA system. Consumer applications are defined for virtual services in CentraSite. This consumer application information must be transferred to Mediator for use during request processing.



Mediator also uses consumer applications to monitor service level agreement (SLA) conditions. SLAs are run-time policies set between consumers and providers that define the level of performance consumer applications should expect from services. For more information about SLAs, see “Service Level Agreement Alerting” on page 41.

Consumer applications, including the definition of how a particular piece of information in a request context can be used to identify a service consumer as a specific consumer application, are defined in CentraSite. A virtual service can be set to associate with consumer applications. As a result, if the authorize against registered consumer run-time policy action is applied to the virtual service, these consumer applications become the authorization list for the virtual service. For more information about the authorize against registered consumer policy action, see “Authorize Against Registered Consumers” on page 71.

Note: Consumer applications fall outside the subscription notification process, so there are no subscriptions or notifications related to consumer application updates on CentraSite. As a result, consumer applications are updated using a different process.

Each time Mediator receives a notification message, Mediator uses the coverage period of the notification message to make a request for all consumer application information that changed during the interval. If the Mediator instance determines that it is out of synch with CentraSite, it uses the synchronization process to update the consumer application information. This process starts directly after the subscription update process.

Synchronization Process

The basic interaction for maintaining consumer application synchronization is shown in the following diagram.



Consumer Application Synchronization

Step Description

1 During the subscription notification process, CentraSite sends notifications to Mediator every 2 minutes. These notifications report only changes to virtual services and are sent regardless of whether there are changes to report. The notifications do not include any consumer application changes.

Mediator updates the virtual service.

2 Mediator queries CentraSite for any changes to consumer applications that occurred during the coverage period of the notification.

3 CentraSite uses the last changed time stamp to determine whether there were any changes to the consumer applications during the period about which Mediator is querying.

4 CentraSite sends the updated consumer application information back to Mediator.

5 Mediator updates the consumer applications accordingly.



Synchronizing All Consumer Applications

When Mediator starts or determines that there is a time gap between subscription notifications, it requests all the consumer application information from CentraSite. Mediator performs this action because there is no start time to use as a point of reference.

Manual Synchronization

The Mediator administration console includes a manual synchronization button to enable the Mediator administrator to synchronize the consumer applications any time Mediator is out of synch with CentraSite. For more information about using this feature, see “Synchronizing Consumer Applications Manually” on page 88.

Undeploying Virtual Services in Mediator

Mediator undeploys Virtual services when CentraSite sends it an undeploying notification. After Mediator undeploys the virtual service, it sends a confirmation message to CentraSite.


Undeploying Virtual Services in Mediator

Undeployment Interactions Between CentraSite and Mediator

Step Description

1 CentraSite sends an undeploying request to Mediator.

2 Mediator undeploys the virtual service and removes the VSD.

3 Mediator responds to CentraSite with a message to confirm that the service is undeployed.


3 Metrics and Events Notification

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Performance Data Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Run-Time Event Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Service Level Agreement Alerting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Event Destinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44


Overview

Overview

Mediator collects and reports metrics and events for each virtual service deployed in your system. You can configure Mediator to publish metric information to CentraSite based on performance data collected for virtual services. Mediator can also generate events and alarms when selected run-time policies are violated.

Note: If CentraSite is not running or communication is otherwise interrupted when Mediator tries to send metrics or events, the information is lost.

Metrics Reported by Mediator

Mediator collects performance data statistics for virtual services. Mediator aggregates the performance data into metrics and reports them to CentraSite at regular intervals. This is called performance data reporting. For more information about collecting and reporting performance data metrics, see “Performance Data Reporting” on page 34.

Events Reported by Mediator

Mediator sends events when run-time policies set for the virtual service are violated. They are set as part of the run-time policies you set in CentraSite when creating the virtual service. For more information about setting these events, see the CentraSite ActiveSOA documentation.

Mediator reports two kinds of events:

Run-time events. See “Run-Time Event Notifications” on page 37.

Service level agreements. See “Service Level Agreement Alerting” on page 41.

Performance Data Reporting

Mediator collects monitoring and performance data metrics that it publishes to CentraSite at defined intervals, based on performance data collected for virtual services. You define the metrics while creating virtual services in CentraSite.

As Mediator processes requests, it collects metrics for each service. This information is periodically consolidated to minimum, maximum, and average response times and success and failure rates and is sent to CentraSite for display and monitoring. In addition, Mediator sends the date and time range for each metric.

For more information about setting events in CentraSite, see the CentraSite ActiveSOA documentation.


Metrics and Events Notification

Intervals

Mediator tracks metrics by intervals and then aggregates those metrics for reporting to CentraSite. The interval used for tracking metrics is a period of time you set in Mediator during which metrics are collected for reporting to CentraSite.

Mediator only tracks metrics for the current interval. At the end of the interval, Mediator aggregates the metrics and reports them to CentraSite. Once the metrics are reported to CentraSite, Mediator resets its counters for the new interval.

Mediator does not calculate and aggregate metrics across intervals. If Mediator is shut down or the virtual service is undeployed before the current interval expires, the performance data is discarded.

For example, suppose the report interval is set to 2 minutes and Mediator is started at 10:01:35. Mediator begins collecting the data after it is started. At the end of the interval, 10:03:35, the performance data is aggregated and sent to CentraSite.

For information about setting the metric tracking interval, see “Configuring Communication with CentraSite” on page 77.

Performance Data

Mediator reports the following performance data metrics for virtual services during the current reporting interval:

Metric Reports...

Total Request Count

The total number of requests for each service running in Mediator for the current interval.

Success Count The number of successful service invocations for the current interval.

Fault Count The number of failed invocations for the current interval.

Minimum Response Time

The minimum amount of time (in milliseconds) it took each service to complete an invocation in the current interval. This is measured from the moment Mediator receives the request until the moment just before it returns the response to the caller.

Note: This parameter does not include metrics for failed invocations by default. You can include metrics for failed invocations by setting the pg.PgMetricsFormatter.includeFaults parameter to true. For more information, see “Advanced Settings” on page 105.


Performance Data Reporting

Note: If you defined an SLA policy action for a particular consumer and virtual service combination, Mediator tracks separate performance data metrics for each consumer.

Losing Performance Data

Mediator does not store the performance data it collects for each interval. If CentraSite or Mediator shut down, or the virtual service is undeployed before the current interval expires, the performance data is discarded and any information collected since the last reporting interval is lost.

Maximum Response Time

The maximum amount of time (in milliseconds) it took each service to complete an invocation in the current interval. This is measured from the moment Mediator receives the request until the moment just before it returns the response to the caller.


Average Response Time

The average amount of time it took the service to complete all invocations in the current interval. This is measured from the moment Mediator receives the request until the moment just before it returns the response to the caller.


Availability The amount of time that the virtual service was available during the current interval as a percentage. A value of 100 indicates that the virtual service was always available.

Note: Only time when the service is unavailable counts against this metric. If invocations fail due to policy violations, this parameter could still be as high as 100.

Liveness Whether the virtual service was live at the end of an interval. A value of true indicates that the value is live.

Metric Reports...



Run-Time Event Notifications

Mediator generates event notifications when a run-time event occurs. A run-time event occurs any time a run-time policy is violated. Run-time policies define the set of rules and capabilities for virtual services and Mediator. You define run-time policies in CentraSite while creating the virtual service.

Event Types Set on Mediator

You can set Mediator to monitor five types of run-time events:

Life Cycle

Error

Policy Violation

Transaction

Monitoring

Life Cycle

Mediator sends a life cycle event every time Mediator starts or shuts down. You can set Life Cycle enforcement for each instance of Mediator. Mediator sends life cycle events as SNMP traps to the configured SNMP destination. For more information about event destinations, see “Event Destinations” on page 44.

Life Cycle events report the following data:

Error

Mediator sends an error event when a virtual service is invoked and results in an error. You can set error enforcement for each instance of Mediator. Mediator sends error events as SNMP traps to the configured SNMP destination. For more information about event destinations, see “Event Destinations” on page 44.

Parameter Indicates...

Mediator name The name of the Mediator instance reporting the event.

Transaction date

The date the error occurred.

Status Whether Mediator started or shut down.

Alert description

A description of the event.



Error events report the following data:

Policy Violation

Mediator sends a policy violation event every time a virtual service is invoked and the invocation violates a policy that was set for the virtual service. You can set policy violation enforcement for each instance of Mediator. Mediator sends policy violation events as SNMP traps to the configured SNMP destination. For more information about event destinations, see “Event Destinations” on page 44.

Policy violation events report the following data:

Parameter Reports...

Run-time session

The SOAP invocation session in which the event occurred.

Target name The name of the Mediator instance reporting the event.

Contract name The service against which the event was logged.

Consumer The consumer of the service.

Note: This parameter is reported only if the run-time policy includes an identify consumer policy action that associates the consumer to a consumer application. Otherwise, Mediator reports its value as unknown.

Consumer IP The IP address of the consumer.

Transaction date

The time stamp showing the date and time the event occurred.

Run-time error source

The source of the error.

Run-time error description

A description of the error.


Run-time session



Contract name The service against which the event was logged.



Transaction

Transaction events are set in CentraSite for specific virtual services. Mediator sends a transaction event whenever a virtual service is invoked. You can set the virtual service to send a transaction event in any of the following situations:

Any time the virtual service is invoked

Only when the virtual service is invoked successfully

Only when the invocation of the virtual service fails

Transaction events are set in CentraSite as log invocation policies, which specify what to log when a service is invoked.

Mediator can send transaction event notifications to CentraSite (SNMP), third-party SNMP, SMTP, the local log, or the audit log. For more information about event destinations, see “Event Destinations” on page 44.

Transaction events report the following data:

Consumer The consumer of the service.


Consumer IP The IP address of the consumer.

Transaction date


Run-time alert source

The source of the error.

Run-time alert type

The policy violation event type.

Run-time alert description

The policy violation message.


Run-time session


Contract name The name of the service against which the event was logged.





Monitoring

Monitoring events are set in CentraSite for specific virtual services. Mediator sends a monitoring event whenever a set of performance conditions for a service is violated. Monitoring events are set in CentraSite as monitor service performance and monitor service level agreement policies. For more information about monitor service performance conditions, see the CentraSite ActiveSOA documentation.

Note: Monitor service level agreement (SLA) events are similar to monitor service performance policies, but are calculated for a particular consumer and virtual service combination. For more information about SLAs, see “Service Level Agreement Alerting” on page 41.

Mediator sends monitoring event notifications to CentraSite (SNMP), third-party SNMP, SMTP, or local log. For more information about event destinations, see “Event Destinations” on page 44.

Transaction date


Consumer The service consumer.


Consumer IP The IP address of the service consumer.

Request status Whether the transaction resulted in success or failure.

Response payload (optional)

The SOAP envelope and contents of the response payload.

Request payload (optional)

The SOAP envelope and contents of the request payload.

Provider round trip time

The time in milliseconds for the native service provider to perform its part of the request. This is measured from the time the native service provider receives the request from Mediator until it returns the response to Mediator.

Total round trip time

The total round trip time in milliseconds. This is measured from the time Mediator receives the request until the time it returns the response to the caller.




Mediator sends the following parameters as part of a monitoring event:

Service Level Agreement Alerting

Service level agreements (SLAs) are monitor run-time policies set between service consumers and virtual services. SLAs define the level of performance that service consumers should expect from the services. They also define the metrics that are used to gauge that performance. You can use these policies to identify whether a virtual service’s threshold rules are met or exceeded, and how often to send events (whether you want to send the events every time a policy is violated, or only at certain intervals). SLAs can register policies against both aggregate and non-aggregate metrics.

You can configure SLAs in CentraSite for each virtual service/consumer application combination.


Run-time session



Contract name The name of the service against which the event was logged.

Consumer The service consumer.


Consumer IP The IP address of the service consumer.

Transaction date


Monitored attribute

The service attribute being monitored.

Note: If the policy is set to monitor more than one attribute, Mediator reports only the first rule that was violated.

Run-time alert source

The name of the policy action from which it originated.

Run-time alert type

The monitoring event type. This can be either monitor or sla.

Run-time alert description

The message describing the event.


Service Level Agreement Alerting

Identify Consumer Policy Action

SLAs use the identify consumer action to associate Web service requests to a specific consumer application. You must define an identify consumer action for each SLA in order for Mediator to map a Web service request to a specific consumer application. For more information about setting an identify consumer action in CentraSite, see the CentraSite ActiveSOA documentation.

You can set the identify consumer policy action to allow anonymous usage of the virtual services. In this case, Mediator will allow any requests to the virtual service, but it will only enforce SLAs on those requests that Mediator identifies as one of the consumer names associated with the SLA. If Mediator cannot resolve the identity of the consumer application, then Mediator sends a policy violation event to CentraSite (if enabled) and returns the following SOAP fault to the service consumer:

Mediator encountered an error:Consumer could not be identified. Anonymous access is not allowed for this service!

Enforcing Policies Against Aggregated Metrics

For aggregated metrics, Mediator monitors the virtual service invocations made by each consumer application over the course of an interval. At the end of the interval, Mediator aggregates the consolidated to minimum, maximum, and average response times. When an aggregated metric violates the SLA policy, Mediator sends a monitor event to the defined event destination.

The following metrics are aggregated for SLAs:

Metric Reports...

Minimum Response Time

The minimum amount of time (in milliseconds) it took each service to complete an invocation in the current interval. This is measured from the moment Mediator receives the request until the moment just before it returns the response to the caller.

Note: This parameter does not include metrics for failed invocations.

Maximum Response Time

The maximum amount of time (in milliseconds) it took each service to complete an invocation in the current interval. This is measured from the moment Mediator receives the request until the moment just before it returns the response to the caller.




Enforcing Policies Against Non-Aggregated MetricsFor non-aggregated (or counter-based) metrics, Mediator can send events as soon as the policy is violated, without having to wait until the end of an interval. Mediator gathers metrics for virtual service invocations and tracks the consumer application that invoked the virtual service. If you define an SLA policy to use a counter-based metric (for example, fault count), then Mediator generates a monitor event as soon as the policy is violated, without having to wait for the end of the interval.

You can set policies for the following counter-based metrics:

You can set SLA policies for counter-based metrics to trigger a monitor event only the first time a policy is violated or every time a policy is violated. If you set the policy to trigger an event only once, Mediator will send only one alert the first time the policy is violated.

When you set the policy to send a monitor event every time the policy is violated, Mediator sends an event the first time a policy is violated and another each subsequent time the policy is violated. Mediator then sends one more event at the end of the interval. For example, if your policy is set to trigger an event when there are more than three failed

Average Response Time

The average amount of time it took the service to complete all invocations in the current interval. This is measured from the moment Mediator receives the request until the moment just before it returns the response to the caller.


Availability The amount of time that the virtual service was available during the current interval as a percentage. A value of 100 indicates that the virtual service was always available.

Note: Only time when the service is unavailable counts against this metric. If invocations fail due to policy violations, this parameter could still be as high as 100.

Metric Reports...

Total Request Count

The total number of requests for each service running in Mediator for the current interval.

Success Count The number of successful service invocations for the current interval.

Fault Count The number of failed invocations for the current interval.

Metric Reports...


Event Destinations

invocations, Mediator will send a monitor event at the fourth failed invocation. It will also send an invocation at every subsequent failure until the end of the interval. At the end of the interval, Mediator sends another event.

For more information about setting policy frequencies for SLA policies, see the CentraSite ActiveSOA documentation.

Alert Destinations

Mediator can send SLA alerts to CentraSite (SNMP), third-party SNMP, SMTP, or local log. For more information about event destinations, see “Event Destinations” on page 44.

Event Destinations

You can set Mediator to send event notifications to the following destinations:

CentraSite (SNMP). See “SNMP Destinations” on page 44.

Third-party SNMP. See “SNMP Destinations” on page 44.

SMTP (e-mail). See “SMTP (E-mail)” on page 45.

Local log. See “Local Log” on page 45.

Audit log. See “Audit Log” on page 45.

Note: You must enable the event destination in Mediator to send the event notifications.

SNMP Destinations

You must configure at least one SNMP destination in Mediator to report life cycle, policy violation, or error run-time events. For these events, Mediator can send event notifications only to SNMP. You can configure an SNMP destination for transaction and monitoring run-time events, but this is optional.

You can configure any or both of the following types of SNMP destinations:

CentraSite SNMP destination, which uses SNMPv3 user-security model. Communication with CentraSite is required for Mediator to report events to CentraSite.

Third-party SNMP destination, which uses either SNMPv1 community-based security model or SNMPv3 user-based security model

For information about configuring SNMP destinations in Mediator, see “SNMP Configuration” on page 78.



Mediator delivers the webMethodsESB.MIB file to define the SNMP traps that it can produce. If you are using a third party SNMP server, you must import or set up the MIB on all SNMP servers receiving Mediator traps. For information on setting up the MIB on your third party SNMP server, see the documentation delivered with that product.

The MIB file is located in the following directory:

install-dir\webMethods8\IntegrationServer\packages\WmMediator\config\resources

SMTP (E-mail)

You can set Mediator to send an e-mail to a specified address when transaction and monitoring (including SLAs) events are triggered. To use SMTP as an event destination, you must set E-mail as an event destination for the virtual service in CentraSite and then configure the e-mail address in Mediator.

For information about configuring SMTP notifications in Mediator, see “E-mail Configuration” on page 83.

Local Log

You can set the local log as the destination for transaction and monitoring event notifications. If you select this option for the event destination, Mediator writes the notifications to your Integration Server server log. Event notifications posted by Mediator use a product code of MED.

To log event notifications to the server log, you must set local log as the destination while creating run-time policies in CentraSite. When you make local log the destination, you must also select the log level (either Info, Warn, or Error) at which Mediator should send event notifications. Since Mediator uses the Integration Server server logger as the local log, you must also set the logger levels for the Event Logging facility on the Settings > Logging > Edit Server Logger Details screen of the Integration Server Administrator to match those expected by the run-time policy. For example, if a log invocation policy is set to log event notifications when an error occurs, you must set the logging level of the 0001 Event Logging facility in the server log to Error.

For information about setting the local log as the event notification destination, see the CentraSite ActiveSOA documentation. For information about configuring the settings in the server log, see Administering webMethods Integration Server.

Audit Log

You can send transaction events to the Integration Server auditing subsystem by setting it as the destination while creating log invocation run-time policies in CentraSite. For more information about the audit logger, see the webMethods Audit Logging Guide.


Event Destinations


4 Clustering and Load Balancing

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Nodes and Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Load Balancers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Creating a Mediated Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Deployment and Synchronization in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Processing Service Requests in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Metric and Event Notification in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Load Balancing Service Providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61


Overview

Overview

Mediator supports clustering to achieve load balancing. In a load balanced system, calls from service consumers and events and metrics (messages) are distributed among several different instances of Mediator, referred to as nodes. Load balancing provides the following benefits:

Scaling. Clustering provides scaling by distributing message processing across several different nodes.

Reliability. Clustering provides reliability by providing fault-tolerance. For more information, see “Role of the Shared Cache in Metrics and Events Notification” on page 57.

Clustering relies on the clustering feature provided by Integration Server. Each node runs on a separate instance of Integration Server, and so you must configure clustering properly in Integration Server in order for Mediator’s clustering feature to work properly. For more information, see the webMethods Integration Server Clustering Guide.

Nodes and Clusters

Each node is an instance of Mediator running on an instance of Integration Server. When you configure each node the system to communicate with the same CentraSite server, you create a cluster. A cluster is a group of nodes that monitors the same virtual service and sends events and metrics triggered by that virtual service to CentraSite.

Communication

Communication in a cluster is peer-based. In a peer-based cluster, any node in the cluster can perform processing tasks, including processing virtual service requests and CentraSite subscription notifications. However, nodes process messages differently depending on the task as follows:

For deployment and synchronization, where CentraSite sends virtual service and consumer application data to webMethods Mediator, the load balancer selects the processing node.

For processing service calls, the load balancer determines which node processes the service call.

For event and metric notification tasks, where Mediator sends events and metrics to CentraSite, the node that is the first available to process the message does so.

Nodes can perform any task required by messages they receive from CentraSite.


Clustering and Load Balancing

Note: If communication between CentraSite and the cluster is disabled, then the cluster depends on the shared cache for consumer and virtual service definitions. CentraSite cannot deploy, redeploy, or undeploy virtual services or update consumer applications, and the cluster cannot report metrics. However, if you configured the cluster to report run-time event notifications to CentraSite over SNMP, these event notifications will continue if the CentraSite SNMP destination is enabled and configured correctly. For more information about the role of the shared cache for deployment, see “Role of the Shared Cache in Deployment and Synchronization” on page 53. For more information about the role of the shared cache for metric notification, see “Role of the Shared Cache in Metrics and Events Notification” on page 57.

Load Balancers

Clustering in Mediator requires a load balancer. The load balancer is a third-party tool that routes incoming virtual service calls and subscription notification calls from CentraSite to the nodes in the cluster. For Mediator, the load balancer:

Provides CentraSite with a single point of entry to the cluster. This means that CentraSite recognizes only that it is communicating with a single entity rather than several nodes. All communication from CentraSite to the cluster goes through the load balancer: CentraSite sends virtual service and subscription notification calls to the load balancer, and whichever node is prepared to take action processes the message.

Distributes calls from service consumers to the virtual services across the cluster. When a service consumer calls a virtual service, the call is routed by the load balancer to the node prepared to process the call.

Subscription Endpoint

In a clustered system, the subscription endpoint defines the URL of the load balancer. It is the target to which CentraSite deploys a virtual service. The following is an example of the subscription endpoint for the load balancer:

http://hostname:portnumber/ws/ServicesNotificationReceiver

The following subscription endpoint example shows that CentraSite is set to deploy a virtual service to a load balancer with a host name of ExampleHost that receives requests on port 80:

http://ExampleHost:80/ws/ServicesNotificationReceiver

For more information about defining subscription endpoints for virtual services, see the CentraSite ActiveSOA documentation.


Load Balancers

Load Balancer URLs

Load balancer URLs define for CentraSite the endpoints of the nodes in a cluster. When a service is deployed to a cluster, the node that performs the deployment sends the load balancer URL as the new endpoint to CentraSite as part of its virtual service status message.

CentraSite stores this load balancer URL endpoint in the registry. Since all of the nodes in the cluster use the same load balancer URL, CentraSite accepts messages from any node in the cluster as if they came from a single instance of Mediator.

A load balancer URL consists of a host name or IP address and port number of the load balancer as follows:

http://hostname:portnumber or http://IP-address:portnumber

Note: You can also configure the load balancer URL to use the HTTPS protocol.

For example, if the host name of the load balancer is ExampleHost, and its port number is 80, the load balancer URL would be:

http://ExampleHost:80

You must configure all the nodes in a cluster with the same load balancer URL. For information about configuring the load balancer URL for Mediator, see “HTTP Configuration” on page 85.

The following diagram shows how the load balancer works in the clustered system.



Communication with CentraSite through the load balancer

Creating a Mediated Cluster

To create a cluster that includes Mediator, you must configure Integration Servers, a third party load balancer, CentraSite, and instances of Mediator.

Configuring Integration Server

Mediator’s cluster implementation is built upon the Integration Server’s cluster support. You must configure the Integration Servers in the cluster as described in the webMethods Integration Server Clustering Guide.


Deployment and Synchronization in a Cluster

Configuring the Third-Party Load Balancer

You must configure a third-party load balancer to use clustering in Mediator. You must use the load balancer to configure the following:

A virtual network that defines the IP addresses of the nodes

The WS-Context to route calls to the cluster

For information about configuring your load balancer for use in the clustered system, see the documentation for that product.

Configuring Mediator

All Integration Server cluster members must contain identically-configured instances of Mediator. You use the Mediator Administration console to configure each instance of Mediator. For more information, see “Configuring Mediator” on page 75.

Note: You can use the package replication functionality in the Integration Server Administrator to copy Mediator packages to other servers in the cluster. For information about package replication, see the Administering webMethods Integration Server.

Configuring CentraSite

When you configure the virtual service in CentraSite, you must configure the subscription endpoint of the target to point to the load balancer. For more information, see the CentraSite ActiveSOA documentation.


You can deploy, redeploy, and undeploy virtual services and update consumer application information for a cluster the same way you do for a stand-alone instance of Mediator. You will always deploy or remove virtual services and consumer applications from a cluster in the following situations:

Synchronization. This occurs when a cluster receives a subscription notification event or when you manually synchronize the virtual service, consumer application, or both from the administration console of a clustered instance of Mediator.

Initialization. This is the synchronization that occurs when a cluster is started.



Role of the Shared Cache in Deployment and Synchronization

As part of the deployment and synchronization process, the cluster synchronizes the nodes with the shared cache to ensure that tasks are not processed repeatedly. The shared cache enables clusters to share deployment and synchronization information and serves as a repository for all virtual service and consumer application information, such as the following:

Virtual service information and the associated deployment state

Consumer application information using the virtual services deployed to the cluster

The shared cache resides on each node in the cluster. When any node in the cluster processes a deployment or synchronization task, the shared cache of the Mediator that processed the task propagates the data to the shared cache of the other Mediator instances in the cluster, keeping all the nodes in the cluster in synch.

Synchronizing Node

Only a single node in the cluster can process a deployment or synchronization task at any one time. The node that processes this task is referred to as the synchronizing node. A node becomes the synchronizing node by being the first to process a task and can be a different node for each task.

When the load balancer receives updates to virtual services and consumer applications from CentraSite, it selects the synchronizing node to process the updates. Once the synchronizing node gets the updates from the load balancer, it updates the shared cache with the changed information. The remaining nodes in the cluster monitor the shared cache for updates and deploy the virtual services without interacting with either the load balancer or CentraSite.

Deployment State

It is important to ensure that only one node processes updates from the shared cache at a time and that the cluster does not synchronize and deploy virtual services and consumer applications repeatedly. To help with this task, clusters set a deployment state on the shared cache to indicate whether the cluster is currently updating the shared cache.

Any node in the cluster that is going to update the deployment state must first lock the deployment state. Locking the deployment state ensures that other nodes in the cluster do not update or synchronize while another update action is already in progress. It is also used to recover from deployment operations that fail before completed.



Clusters use the following deployment states:

Communication During Initialization

The synchronizing node sets the deployment state to Initializing and retrieves all pending virtual service updates and the current consumer application lists from CentraSite. Any node in the cluster can perform the synchronization and become the synchronizing node, and a different node can be the synchronizing node each time the cluster is synchronized.

The synchronizing node then loads the entire list of virtual services and consumer applications into the shared cache, changes the deploy state to Running, and releases the lock on the shared cache.

Note: No virtual services or consumer applications are written to the shared cache until all are deployed within the synchronizing node.

All the other nodes in the cluster wait until the synchronizing node updates the shared cache. When the update to the shared cache is complete, the shared cache sends events to the non-synchronizing nodes that indicate that the initialization is complete. The non-synchronizing nodes can then refresh from the shared cache.

A deployment state of... Indicates that...

Initializing The cluster is in the process of booting and the shared cache is being initialized with the virtual service and consumer application information for the first time.

Every node in the cluster receives an event when the deployment state changes from Initializing to Running. This indicates to the nodes in the cluster that the cluster has completed starting up and that the nodes must synchronize all virtual services and consumer applications with those in the shared cache. For more information, see “Communication During Initialization” on page 54.

Running The cluster is in synch and is not performing any in-process deployment.

Resynching One of the nodes in the cluster is processing a subscription notification event or manually synchronizing the virtual services or the consumer applications or that a node. This deployment state applies to both full and partial resynchronization for virtual services and consumer applications. For more information about synchronization, see “Deployment and Synchronization in a Cluster” on page 52.



When a cluster is started, it synchronizes all pending virtual service updates and retrieves the latest consumer application list from CentraSite. In order to do this, one node must perform the synchronization. The first node to create and lock the deploy state cache is referred to as the synchronizing node.

If the synchronizing node fails while completing the initialization, the cluster treats this action as if the node is leaving the cluster. For more information, see “Communication When a Node Leaves a Cluster” on page 56.

Communication During Deployment

When a node in the cluster performs an update or synchronization, the shared cache sends an event to each node on the cluster.

The interaction between nodes during deployment is shown in the following diagram:

Deployment in a clustered environment



Communication When a Node Leaves a Cluster

When a node leaves the cluster, the cluster sends the remaining nodes a message indicating that the node is no longer part of the cluster. Like any other task, the node that responds first to this message will process it. The node that responds checks to see if the leaving member was in the process of a deployment operation.

If the nodes in the cluster receive a message indicating that a node left the cluster, and the removed node was in the process of a deployment operation, the following occurs:

1 The responding node locks the deployment state and operates as follows:

2 The lock on the deploy state is released.

Step Description

1 The synchronizing node receives the VSD or consumer application information from CentraSite.

2 The synchronizing node:

a Locks the deployment state.

b Changes the deployment state from running to either initializing or resynching to reflect the current operation.

c Performs the deployment operation.

d Changes the deployment state to Running and releases the deployment state lock.

3 The other nodes in the cluster retrieve the VSD or consumer application data from the shared cache. This ensures that every node on the cluster is synchronized with the same information.

If the deployment state is... The node...

Initializing Makes itself the running node and performs a full synchronization with CentraSite.

Resynching Updates the deployment state to Running, which stops the current synchronization.

Running Does nothing.



Processing Service Requests in a Cluster

Clusters receive service requests from service consumers through the load balancer. When a service consumer makes a call to a virtual service monitored by the cluster, the load balancer receives the message and distributes it to the node that is ready to process it. For example, if the load balancer is configured to use round-robin distribution, the load balancer distributes each virtual service request to the nodes in turn.

Metric and Event Notification in a Cluster

A cluster collects monitoring and performance data and publishes it to CentraSite similarly to that of a single instance of Mediator. The difference is that a cluster distributes processing across all nodes, thereby balancing the notifications between the nodes. For more information about events and metrics processed by Mediator, see “Metrics and Events Notification” on page 33.

Role of the Shared Cache in Metrics and Events Notification

As part of the metrics and events notification process, the cluster uses the shared cache to:

Register the policy actions configured in and received as part of the virtual service definition deployed from CentraSite. Policy actions define Monitoring, SLA, and Log Invocation (Transaction) events. In this case, the shared cache provides a cluster-wide view of cached policy actions for the cluster.

Store aggregated metrics reported by the nodes in the cluster. Once all of the metrics for a particular service are reported to the shared cache, the data can be consolidated to minimum, maximum, and average response times and success and failure rates. This data is stored in the shared cache until it is time to report the data to CentraSite.

Provide fault tolerance for the cluster. Normally, any content stored in the memory of the node as a queued task will still be lost if the node goes down. However, if the run-time events or metrics are written to the shared cache, they can be recovered.

Senior Node

Every cluster contains exactly one senior node that processes the registered list of policy actions on the shared cache and executes events and aggregated metrics. The senior node is responsible for ensuring that all events and metrics written to the shared cache are processed by a node in the cluster. The senior node runs at 15-second intervals in which it scans the shared cache for events and metrics that are scheduled for execution.

When the senior node scans the list of policies and metrics in the shared cache and determines that tasks are in need of processing, it sends a processing event to all the nodes in the cluster. The processing event informs the nodes on the cluster that data must be reported to CentraSite. The first node to respond to the processing event reports the event or metric to CentraSite.



The cluster designates the senior node internally according to which cluster member has been in the cluster the longest. If the senior node becomes disabled, the node left in the cluster that has been part of the cluster the longest takes its place.

Note: The senior node has a different function than the synchronizing node described on page 53. The synchronizing node performs a function for deployment and synchronization and can be a different node for every transaction. The senior node performs functions for event and metric notifications and only changes if the node performing the duties of the senior node is removed from the cluster.

Processing Interval

Because nodes send metrics and aggregated events to the shared cache, they are not sent to CentraSite immediately after a Web service is invoked. This is because the senior node only scans the list of events and metrics in the shared cache at a predefined 15-second interval, called a tick interval.

In addition, you configure the policy actions and metrics reporting tasks to run at their own particular interval (in minutes) as follows:

You set the alert interval for policy actions. You set the alert interval in CentraSite when you create the virtual service. For more information about setting alert intervals for policy actions, see the CentraSite ActiveSOA documentation.

You set the policy interval for metrics. You set the policy interval in the Mediator Administration screens. For information about setting the policy interval, see “Configuring Communication with CentraSite” on page 77.

While the tick interval determines how often the senior node scans the list of policy actions and metrics in the stored cache, the policy actions and metrics cannot be processed until the time interval for each has been met. For example, if the policy interval for metrics reporting is configured to run every 10 minutes, then the senior node processes metrics every 40 tick intervals. This is because there are 4 tick intervals every minute for 10 minutes: so it takes 40 tick intervals before the 10-minute policy interval for the metrics is reached (4 * 15 seconds * 10 = 10 minutes). At that time, the senior node can send a processing event to the nodes in the cluster, and the responding node reports the metrics to CentraSite.

Reporting Non-Aggregated Run-Time Events

All non-aggregated run-time events are processed by the node that mediated the Web service invocation. In this situation, the node that triggers the event sends the event notification directly to CentraSite. Neither the senior node, nor any other nodes in the cluster are involved in the event notification.



Non-aggregated events processed in this way are:

Error

Policy violation

Life Cycle

Reporting Non-Aggregated Events in a Cluster

Reporting Performance Data and Aggregated Events in a Cluster

When performance data metrics or aggregated events are collected by a node in a cluster, that node sends the metric to the shared cache where it awaits processing. The shared cache stores the aggregated metrics and events notifications for each node in the cluster.

Step Description

1 The node produces an event.

2 The node reports the event to CentraSite.



At each interval, the senior node scans the shared cache for the events and metrics stored there. It then notifies all the nodes in the cluster of the stored metrics and events. The first node to respond to the senior node’s notification processes the event or metrics, reporting them to CentraSite and the other nodes in the cluster will disregard the notification. Any of the nodes in the cluster are eligible to send the metrics to CentraSite.

Reporting Performance Data and Aggregated Events

Step Description

1 The aggregated events or metrics are produced by nodes in the cluster.

2 Each node that collected the events and metrics publishes them to the shared cache.

3 At each tick interval, the senior node scans the events and metrics in the shared cache. If the interval for processing the metrics or events has been met, the senior node notifies all the nodes in the cluster that the events or metrics are ready for processing.

4 The first node to respond to the senior node’s notification processes the event or metrics and reports them to CentraSite.



Load Balancing Service Providers

You can configure a virtual service in CentraSite to configure a virtual service to load balance requests between several service providers without clustering. In this scenario, you create a virtual service that uses a load balancing routing protocol and deploy it to a single instance of Mediator. As service consumers send requests, Mediator distributes messages to several different service provider endpoints that are configured in the VSD. For information about creating a load balanced virtual service, see the CentraSite ActiveSOA documentation.

Note: A virtual service that uses a load balancing protocol does not require a load balancer like those used in a cluster. For more information about load balancers in a cluster, see “Load Balancers” on page 49.

This type of load balancing scenario looks as follows:

Service provider load balancing


Load Balancing Service Providers

Round-Robin Distribution

When the virtual service is configured using a load balanced routing type, a single Mediator takes requests and routes them to the service providers in turn, using a round-robin distribution. As Mediator receives requests, it distributes the request to the service provider whose turn it is to process the message.

Note: Mediator does not currently support load balancing requests based on which service provider is the highest performing.

Inactive Endpoints

If a service provider endpoint is down when Mediator tries to distribute a request to it, Mediator considers this endpoint inactive. The endpoint will remain considered inactive for 15 seconds, during which time all subsequent invocations skip that endpoint and are instead routed to the remaining endpoints.

If all of the endpoints are down, then Mediator considers all of the endpoints inactive for 15 seconds and sends an error event to CentraSite (if enabled).

Note: Any subsequent invocations during the 15-second inactive period do not generate an error event. This means that Mediator will send only one error event for each inactive period. However, Mediator will return SOAP faults for all of the failed requests.


5 Enforcing Security Policies

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Mediator Security Processesing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Enforcing Authentication Policy Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Enforcing Authorization Policy Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Enforcing XML Security Policy Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

Enforcing the Validate Schema Policy Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

When Security Policy Actions Are Violated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74


Overview

Overview

Security in Mediator refers to the enforcement of all of the security actions that are part of the run-time policies defined for virtual services. Mediator enforces security actions on both requests or responses. Mediator security actions ensure that the messages between services conform to the security standards defined by the virtual services deployed to Mediator. You set these actions for the virtual services in CentraSite.

Mediator can enforce security actions on messages it receives from service consumers (request messages) and service providers (response messages). Request and response messages must contain the expected security elements being enforced by these actions, and so you must ensure that the service consumer and provider are configured to send the messages in the proper format.

Actions Mediator Enforces

Mediator enforces policy actions in the following categories:

Authentication actions. These actions ensure that only service consumers with the proper credentials can access the virtual service. See “Enforcing Authentication Policy Actions” on page 68.

Authorization actions. These actions ensure that only service consumers with the proper credentials can invoke the virtual service. See “Enforcing Authorization Policy Actions” on page 71.

XML security actions. These actions provide confidentiality (through encryption) and integrity (through signatures) for request and response messages. XML security policies enable for encryption, decryption, and signing of messages. See “Enforcing XML Security Policy Actions” on page 72.

Validate schema action. The validate schema action ensures that messages between messages adhere to a particular XML schema. See “Enforcing the Validate Schema Policy Action” on page 74.

Transport Protocols

Mediator supports the protocols that secure the endpoints of the connections that have access both to Mediator and to the deployed virtual services. Mediator uses transport-level SSL security to secure the endpoints of connections to SNMP, e-mail, and CentraSite servers. Mediator supports the following transport-level protocols:

HTTP

HTTPS

JMS


Enforcing Security Policies

Prerequisites

The following are prerequisites for enforcing security actions.

CentraSite Configuration

Mediator enforces the security actions you define for run-time policies for virtual services. You must add the security actions to the run-time policies you want Mediator to enforce. The security run-time actions you enforce should match the security elements supplied by the request and response messages. For more information about adding actions to run-time policies, see the CentraSite ActiveSOA documentation.

Integration Server Configuration

In order for Mediator to enforce security policies, Mediator relies on the security features provided by Integration Server. You must configure keystores, keystore aliases, truststores, and other components properly in Integration Server. For more information, see Administering webMethods Integration Server.

You must configure the following in the Integration Server Administrator console:

Keystore that contains a valid, authorized X.509 certificate

Note: Mediator can add and remove X.509 certificates used by the keystore during the consumer application synchronization process described in “Synchronizing Consumer Applications” on page 28.

Keystore alias

Truststore that contains the certificate for the certificate issuer

SSL certificate settings

HTTPS port

Users mapped to certificates

JAAS-SAML configuration (optional). For more information, see “Require WSS SAML Token” on page 69.

Mediator Configuration

You must configure Mediator to use the keystore, keystore alias, and trustore that you configured in the Integration Server Administrator console. For more information on setting these values, see “Keystore Configuration” on page 86.


Mediator Security Processesing

Mediator Security Processesing

When Mediator receives an encrypted request, it decrypts the message using a private key. Mediator uses the decryption key alias defined in Integration Server for this purpose. When generating a response message, Mediator encrypts the response using one of the methods as described in “Selecting a Protocol” on page 66.

Selecting a Protocol

Mediator determines which security certificate to use to sign response messages in order as follows:

1 If a signing certificate was included in the message, Mediator uses the same certificate to sign the response/request.

2 If the message contains a certificate with an alias name that matches the consumer name of the certificate from CentraSite.

Note: This requires that the virtual service includes the identify consumer policy action.

3 The Integration Server user name from one of the following:

HTTP authorized token user name in the request

Integration Server user mapped to a certificate (X.59, SAML, WSS-Username, etc.). The request presents a client public key that is mapped to a valid Integration Server user.

Note: This requires that the security element presented in the request corresponds to the proper security policy action defined in the virtual service.

4 The WSS-Username token in the security header. Mediator will use this to look up a certificate with that alias.

5 HTTP Authorization found in the HTTP header. Mediator will use this to look up a certificate with an alias that matches the HTTP auth user name.

6 If none of the above work, Mediator sends a SOAP fault to the sender.

Multiple Security Elements

SOAP allows you to send multiple security elements in the SOAP header of a request or response. When Mediator receives a message with multiple security elements in the SOAP header, it will process the first security element listed. It ignores all other security elements in the request/response.



In order for Mediator to process the security element, the virtual service must be configured with the proper policy actions to address the element. Mediator cannot process any security elements unless the corresponding policy actions are configured for the virtual service.

Mediator uses the mustUnderstand attribute in the security element to determine how to process the request, as follows:

Note: Mediator ignores all but the first security element.

If... Mediator...

the mustUnderstand attribute of the first security element is set to 1 (true)

1 Ignores all other security elements in the request.

2 Performs one of the following.

If the security policy actions are configured for the virtual service, Mediator processes the security element. Continue to step 3.

If the security policy actions are not configured for the virtual service, Mediator sends a SOAP fault (httpStatusCode) with a value of 500 to the service consumer/provider. Processing is complete.

3 Removes the security element from the request or response before sending it to the service provider or consumer.

4 Sends an event if configured to do so and the policy is violated.

the mustUnderstand attribute of the first security element is set to 0 (false)

1 Ignores all other security elements in the request.

2 Performs one of the following.

If the security policy actions are configured for the virtual service, Mediator processes the security element. Continue to step 3.

If the security policy actions are not configured for the virtual service, Mediator ignores the security element. In this case, Mediator sends the security element to the service consumer/provider. Processing is complete.

3 Removes the security element from the request or response before sending it to the service provider or consumer.

4 Sends an event if configured to do so and the policy is violated.


Enforcing Authentication Policy Actions


Mediator uses authentication policy actions to verify that the service consumer has the credentials to access the virtual service. Authentication information, which is included in the SOAP message header, can be saved in X.509 certificates, user name tokens, or SAML tokens, and may include the actual certificates or references.

Require HTTP Basic Token

When the require HTTP basic token policy action is set for the virtual service, Mediator uses HTTP basic authentication to verify the user name and passwords of service consumers against the Integration Server configuration. HTTP basic authentication relies on a user name and password combination to secure messages and endpoints.

You can use HTTP basic authentication for transport-level authentication. The user name and password are encoded in Base64 and contained in the HTTP header, as follows:

Authorization: Basic base64-encoded_user_name_and_password=

If you use HTTP basic authentication with WS-Security, you must ensure that the service consumer that connects to the virtual service has an Integration Server user account. For more information, see Administering webMethods Integration Server.

Requests that supply HTTP basic authentication credentials must provide the proper credentials. Mediator rejects any request that supplies the wrong credentials.

Note: Mediator will process requests that provide no HTTP basic authentication credentials, but the identity for that invocation will be anonymous. This means that the request cannot perform any task that requires authorization.

Require WSS Username Token

When the Require WSS username token policy action is set for the virtual service, Mediator uses WS-Security authentication to validate user names and passwords that are transmitted in the SOAP message header for the WSS username token.

Mediator rejects requests that do not include the username token and password of the Integration Server user that was mapped to the certificate. Mediator supports only clear text passwords with this kind of authentication.

Require WSS X.509 Token

When the Require WSS X.509 Token policy action is set for the virtual service, Mediator uses a WSS X.509 token to validate service consumers.



Require WSS SAML Token

When the Require WSS SAML Token policy action is set for the virtual service, Mediator uses a WSS security assertion markup language (SAML) assertion token to validate service consumers. Mediator supports SAML 1.0 tokens.

Run-Time

When a service consumer sends a request that includes a SAML token to a virtual service, Mediator validates the SAML token to ensure it is valid. If the token is valid, Integration Server uses its included JAAS login modules to process the SAML assertion and map the client public key in the assertion to a valid Integration Server user.

If the service consumer invokes the virtual service without a SAML assertion in the request, then Mediator sends the following SOAP fault to the service consumer to indicate that the request does not match the security policy being enforced:

SAML Token missing in request

Prerequisites

In order to use a SAML token, Mediator requires that you:

Obtain an Security Token Service (STS) provider to generate the SAML tokens. You can use any STS provider that generates SAML 1.0 tokens. The generated SAML token must:

Contain the certificate of the user/client (service consumer) in the assertion

Be signed by the STS

Provide a keystore alias that points to a keystore containing the issuers certificate. For information about providing a keystore alias, see Administering webMethods Integration Server.

Add the SamlAssertLoginModule entry to the is_jaas.cnf file. For more information, see “To add the SamlAssertLoginModule entry to is_jaas.cnf” on page 69.

To add the SamlAssertLoginModule entry to is_jaas.cnf

1 Open the following file:

install-dir\conf\is_jaas.cnf

2 Add the following options and corresponding values to the SamlAssertLoginModule in the WSS_MESSAGE_IS entry as shown below:

Note: The values listed in the following example should be replaced with your own values.

com.wm.app.b2b.server.auth.jaas.SamlAssertLoginModule requisite issuers="SAMPLE_STS" issuers_keystore_alias="sts_jks"



issuers_cert_alias="sts" issuers_clock_skew="0,0" verifySignature=true debug=true;

com.wm.app.b2b.server.auth.jaas.X509LoginModule requisite;com.wm.app.b2b.server.auth.jaas.BasicLoginModule requisite;};

Important! Do not rearrange the order of the login modules listed by default in the is_jaas.cnf file.

3 Set the values for the options as follows:

This option... Specify...

issuers A comma-separated list of issuers from which Integration Server should accept and process SAML assertions.

Integration Server will reject SAML assertions from issuers not configured in this option and will log a message similar to the following to the Error log:

2009-06-09 23:35:38 EDT [ISS.0012.0025E] SAML Issuer (SAMPLE_STS) is not configured; rejecting SAML Assertion.

issuers_keystore_alias The Integration Server keystore alias that contains the certificate aliases for each the issuers defined in issuers.

You must list the clock differences in the same order as the corresponding issuer listed in the issuers option.

issuers_cert_alias A comma-separated list that lists the certificate alias for each of the issuers defined in issuers.


issuers_clock_skew A comma-separated list of the clock differences between you and each of your SAML issuers.




4 Save the file.

5 Restart the Integration Server.

Enforcing Authorization Policy Actions

Mediator uses authorization policies to verify that the service consumer is authorized to invoke the virtual service.

Authorize Users

When the authorize users policy is set for the virtual service, Mediator authorizes consumers against a list of users, groups, or both that are registered as service consumers in CentraSite. Mediator rejects requests that contain a user or group name not defined by the policy.

Authorize Against Registered Consumers

When the authorize against registered consumer policy is set for the virtual service, Mediator authorizes consumers against all application assets registered as service consumers for a service.

In order to associate Web service requests to a specific consumer application, you must define an identify consumer policy action as part of the same run-time policy of which the authorized against registered consumers policy action is defined. For more information about the identify consumer policy action, see “Identify Consumer” on page 72.

verifySignature Whether Mediator should verify the signature. This is set to true by default.

To verify the signature, Mediator uses:

The public key of the issuer if it is included in the assertion.

The certificate from the issuers and issuers_cert_alias options in all other cases.

debug Whether to log data regarding the SAML assertion validation and any related error messages. This is set to false by default.

This option... Specify...


Enforcing XML Security Policy Actions

Identify Consumer

The identify consumer policy action works with SLAs and security policy actions to identify the service consumers attempting to access a virtual service. Mediator uses this policy to ensure that only authorized consumer applications can access a virtual service deployed to Mediator. The identify consumer policy action is used in conjunction with the following policy actions to associate requests and responses to specific consumer applications:

SLAs

Authorize against registered consumers

Require encryption

The identify consumer policy action requires a valid identity through use of a valid authorization token or consumer certificate. For more information on setting an identify consumer policy action for a run-time policy, see the CentraSite ActiveSOA documentation.

Enforcing XML Security Policy Actions

Mediator uses XML security policies to provide signing, encryption, and decryption for the SOAP messages sent between services.

Require Signing

When the require signing policy action is set for the virtual service, Mediator provides signing for responses. Mediator provides support both for signing an entire SOAP message body or individual elements of the SOAP message body.

Mediator uses a digital signature element in the security header to verify that all elements matching the XPath expression were signed. If the request contains elements that were not signed or no signature is present, then Mediator rejects the request.

Mediator uses the signing alias specified in the Administration > General page of the Mediator Administration console to sign the response. For more information, see “Keystore Configuration” on page 86.

Note: You must map the public certificate of the key used to the sign the request to an Integration Server user. If the certificate is not mapped, Mediator returns a SOAP fault to the caller.



Require Encryption

When the require encryption policy action is set for the virtual service, Mediator provides decryption of incoming requests and encryption of outgoing responses. Mediator can encrypt and decrypt only individual elements in the SOAP message body that are defined by the XPath expressions configured for the policy action.

Requests

Mediator requires that requests contain the encrypted elements that match those in the XPath expression. You must encrypt the entire element, not just the data between the element tags. Mediator rejects requests if the element name is not encrypted.

Important! Do not encrypt the entire SOAP body.

Responses

Mediator attempts to encrypt the response elements they match the XPath expressions with those defined for the policy. If the response does not have any elements that match the XPath expression, Mediator will not encrypt the response before sending.

If the XPath expression that resolves a portion of the response message but Mediator cannot locate a certificate to encrypt the response, then Mediator sends a SOAP fault exception to the consumer and a policy violation event to CentraSite.

Identify Consumer

If the identify consumer policy action is present in the same run-time policy as the require encryption policy action, requests are mapped to the consumer name.

For responses, if the identify consumer policy action does not allow anonymous usage, you must define a consumer name alias in order to encrypt responses to specific service consumers.

For identify consumer policy actions that allow for anonymous usage, Mediator does not require a consumer name to send encrypted responses. In this case, Mediator can use one of the following to encrypt the response in the following order, depending on what is present in the security element:

1 A signing certificate

2 Consumer name

3 WSS username, SAML token, or X.509 certificate

4 HTTP authorized user


Enforcing the Validate Schema Policy Action

Require SSL

When the require SSL policy action is set for the virtual service, Mediator ensures that requests are sent to the server using the HTTPS protocol (SSL). The policy also specifies whether the client certificate is required. This allows Mediator to verify the client sending the request. If the policy requires the client certificate, but it is not presented, Mediator rejects the message.

Require Timestamps

When the require timestamps policy action is set for the virtual service, Mediator requires that timestamps be included in request header. Mediator checks the timestamp value against the current time to ensure that the request is not an old message, which serves to protect your system against attempts at message tampering such as playback attacks.

Mediator rejects the request if either of the following happens:

Mediator receives a timestamp that exceeds the time defined by the timestamp element.

A timestamp element is not included in the request.

Enforcing the Validate Schema Policy Action

Mediator can enforce the validate schema policy action for messages sent between services. When this policy is set for the virtual service, Mediator validates XML request messages, response messages, or both against the XML schema referenced in the WSDL.

When Security Policy Actions Are Violated

When a message violates the security run-time policies set for the virtual service, the following actions occur:

1 Mediator sends a policy violation event if you configure Mediator to do so. For more information, see “Setting Event Notification Generation” on page 83.

Note: If there is a log invocation policy set for a virtual service, Mediator can trigger a transaction event even if the message fails due to a security policy action. This can occur when the log generation frequency of the log invocation policy is set to send a transaction event always or only upon message failure.

2 If the request does not meet the proper security run-time credentials, Mediator discards the message and returns a SOAP fault to the consumer.

Note: You cannot recover discarded messages.


6 Configuring Mediator

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Before Configuring Mediator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

Configuring Communication with CentraSite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

SNMP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

E-mail Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

HTTP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

Keystore Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Viewing and Synchronizing Services Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

Synchronizing Consumer Applications Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88


Overview

Overview

Mediator enforces policies on virtual services you set in CentraSite. For Mediator to enforce these policies, you must define parameters for:

CentraSite communication. You must define the communication parameters required for Mediator to send and receive data from CentraSite.

SNMP destinations. Mediator uses SNMP traps to report certain events. You can configure Mediator to send SNMP events to either the CentraSite SNMP server, or a third-party SNMP server.

Keystores and truststores. Keystores and truststores are required for message-level security. They provide SSL authentication, encryption/decryption, and digital signing/verification services for all message content that Mediator sends.

You can configure Mediator with the following optional parameters:

E-mail server and address information. You can configure Mediator to send Transaction and Monitoring event notifications to an e-mail address.

Load balancing protocols. Load balancing enables Mediator to distribute messages it receives between several different endpoints. You can set Mediator to use either HTTP or HTTPS protocols for load balancing.

Before Configuring Mediator

This section describes actions you should perform before configuring Mediator.

1 Install webMethods Mediator as part of the webMethods Integration Server installation. For information about installing Mediator, see the Software AG Installation Guide.

2 Ensure that you have webMethods administrator privileges so that you can access Mediator’s administrative screens. For information about setting user privileges, see Administering webMethods Integration Server.

3 Make sure that the instance of Mediator you are configuring is defined as a target in CentraSite. For information about defining targets in CentraSite, see the CentraSite ActiveSOA documentation.

4 Verify that the Mediator user has the following permissions:

Read/write permissions on the virtual services and consumer applications

Permission to store performance data

5 Start Integration Server and Integration Server Administrator, if they are not already running. For information about starting Integration Server and Integration Server Administrator, see Administering webMethods Integration Server.



Configuring Communication with CentraSite

You must set the parameters described in this section for Mediator to communicate with CentraSite. Configure Mediator as described below to ensure that it does the following:

Retrieves UDDI notifications fromCentraSite to update information about services and consumers that have been deployed, undeployed, or redeployed.

Reports metrics or events to CentraSite.

To configure CentraSite communication

1 Open the Integration Server Administrator if it is not already open.

2 In the Navigation panel, select Solutions > Mediator.

3 In Mediator, select Administration > CentraSite Communication.

4 On the CentraSite Configuration screen, click Edit.

5 In the CentraSite Configuration area, select the Synchronize with CentraSite check box.

6 Set the CentraSite Configuration parameters as follows:

For this parameter... Specify...

Host Name The name or IP address of the machine on which CentraSite is running.

Registry Port The port used to access the CentraSite registry.

UDDI Port The port used for UDDI access to CentraSite.

Target Name The name of the Mediator configured as a target in CentraSite. This name must match the target name defined in CentraSite.

User Name The user name Mediator must use to access CentraSite. Use the following format:

CS-hostname\user-name

Password The password Mediator must use to access CentraSite.

Retype Password The same password you entered in the Password field to verify that you entered it correctly.


SNMP Configuration

7 Click Test Connection.

Note: If CentraSite is not running when you click Save, the Synchronize with CentraSite check box will be disabled. This will disable deployment and synchronization with CentraSite.

SNMP Configuration

Mediator can use the CentraSite SNMP server, a third-party SNMP server, or both to log SNMP events. You can also configure Mediator to send an SNMP trap whenever one or more of the following events occurs:

Lifecycle

Error

Policy violation

Report Performance Data

Whether Mediator should collect and report performance data to CentraSite.

If you select this check box, Mediator makes Publish Interval available.

Publish Interval (minutes)

How often (in minutes) Mediator should report performance data. Enter a value from 1 through 60.

Note: You can only enter data for this parameter if you select the Report Performance Data check box.

If the parameters you entered are... Then...

Correct Mediator displays the following success message:

Connection successful!

Click Save.

Your changes take effect immediately.

Incorrect or there is another problem with the connection

A failure message that lists specific errors you must correct.

Make any necessary changes and try again.




You use the SNMP Configuration screen to define the following SNMP destinations and set event generation options:

CentraSiteSNMP. By default, this is configured to use the SNMPv3 user-security model. To configure CentraSite as the SNMP destination, see “Setting a CentraSite SNMP Destination” on page 79.

Third-party SNMP. By default, this is configured to use the SNMPv1 community-based security model by default, but can also use the SNMPv3 user-based security model. To configure a third-party SNMP destination, see “Setting a Third-Party SNMP Destination” on page 81.

Event generation. To set event generation options, see “To set event notification generation” on page 83.

Setting a CentraSite SNMP Destination

You can set Mediator to use CentraSite as your SNMP destination. CentraSite uses SNMPv3 protocols.

To configure a CentraSite SNMP destination in Mediator



3 In Mediator, select Administration > SNMP.

4 On the SNMP Configuration screen, click Edit.

5 Under CentraSite SNMP Configuration, select the Send TRAPs to CentraSite check box.

6 Set the CentraSite SNMP Configuration parameters as follows:


Host Name/IP Address

The IP address of the CentraSite server.

Note: The CentraSite server must have an SNMP receiver running in order to receive SNMP notifications from Mediator.

Port The SNMP trap receiver port on theCentraSite server that is listening for SNMP requests and packets.

Transport The protocol used by SNMP to send traps. This can be either TCP or UDP. The default is TCP.


SNMP Configuration

7 Click Save.


User Name The SNMPv3 user name to use when connecting to the receiver.

Important! The value you specify must match the security name set on the CentraSite server.

Use Authorization (optional)

Whether an authorization key is required. The default is off.

Authorization Password

The password to be used for authorization. This must also be configured on the SNMP server.

Retype Authorization Password

The same password you entered in the Authorization Password field to verify that you entered the password correctly.

Authorization Protocol

The authorization protocol to use. Mediator supports the following values:

MD5 (default)

SHA

Use Privacy (optional)

Whether a privacy (encryption) key is required. The default is off.

Privacy Password The key to be used for privacy.

Retype Privacy Password

The same privacy password you entered in the Privacy Password field to verify that you entered the password correctly.

Privacy Protocol The privacy protocol to use. Mediator supports the following values:

DES (default)

AES128

AES192

AES256




Setting a Third-Party SNMP Destination

You can set Mediator to use either the SNMPv1 community-based security model, or the SNMPv3 user-based security model. In order to use third-party SNMP destination, you must provide the MIB definition for Mediator’s traps to the SNMP server. This MIB describes the format of the traps.

Mediator uses the community-based model by default. To use the:

SNMPv3 user-based security model, see “To configure third-party SNMP server using the User target type” on page 81 to complete your configuration.

SNMPv1 community-based security model, see “To configure third-party SNMP server using the Community target type” on page 82 to complete your configuration.

To import the MIB for Mediator’s traps

Import webMethodsESB.MIB into your third-party SNMP server. It is located in the following directory:

install-dir\webMethods8\IntegrationServer\packages\WmMediator\config\resources

Note: For more information about importing the MIB into your specific SNMP server, see the documentation for that product.

To configure third-party SNMP server using the User target type




4 On the SNMP Configuration screen, click Edit to make the values available for editing.

5 Under 3rd Party SNMP Configuration, select the Send TRAPs to 3rd party SNMP Server check box.

6 For SNMP Target Type, click User.

7 Set the 3rd Party SNMP Configuration parameters as follows:



The name or IP address of the third-party SNMP server.

Port The SNMP trap receiver port that is listening for SNMP requests and packets.



SNMP Configuration

8 Click Save.


To configure third-party SNMP server using the Community target type




4 On the SNMP Configuration screen, click Edit to make the values available for editing.

5 Under 3rd Party SNMP Configuration, select the Send TRAPs to 3rd party SNMP Server check box.

6 For SNMP Target Type, click Community.

7 Provide the following information:

User Name The SNMPv3 user name to use when connecting to the receiver.

Use Authorization (optional)

Whether an authorization key is required. It is set to off by default.

Authorization Password

The key to be used for authorization. This must also be configured on the SNMP server.

Retype Authorization Password

The same password you entered in the Authorization Password field to verify that you entered it correctly.

Use Privacy (optional)

This flag indicates whether a privacy (encryption) key is required. It is set to off by default.

Privacy Password The key to be used for privacy.

Retype Privacy Password

The same password you entered in the Privacy Password field to verify that you entered it correctly.



The name or IP address of the third-party SNMP server.

Port The SNMP trap receiver port that is listening for SNMP requests and packets.




8 Click Save.


Setting Event Notification Generation

Before you can configure which events to generate, you must configure at least one SNMP destination.

See “Setting a CentraSite SNMP Destination” on page 79 to configure a CentraSite SNMP destination.

See “Setting a Third-Party SNMP Destination” on page 81 to configure a third-party SNMP destination.

To set event notification generation



3 Under Publish Events on the SNMP Configuration screen, select one or more of the following parameters to define which events to publish:

4 Click Save.


E-mail Configuration

You can configure Mediator to send events to an SMTP mail server as e-mail messages.


Community Name The community name to be used to interact with the SNMP receiver. This value must match the value that you set in the SNMP receiver.

Select... To report...

Lifecycle Life cycle events such as Mediator startup and shutdown.

Error Run-time error events that occur during a virtual service invocation.

Policy Violation Run-time policy assertion violations that occur during a virtual service invocation.



E-mail Configuration

To configure event notification through e-mail



3 In Mediator, select Administration > Email.

4 On the Email Configuration screen, click Edit.

5 Under Email Configuration, set the parameters as follows:


SMTP Host Name/IP Address

The address of the SMTP server to be used by Mediator for sending e-mail alerts.

Port The port on which the SMTP server is listening.

User The user name of the e-mail account used to log into your SMTP server.

Password The password of the e-mail account used to log into your SMTP server.

Retype Password The same password you entered in the Password field to verify that you entered it correctly.

From The e-mail address that will appear in the From field of the event e-mail.

If this field is left blank, Mediator generates a default e-mail address composed of the configured target name and hostname of the Integration Server, as follows:

Target-Name@hostname

TLS Enabled Whether to use transport-layer security. If selected, the truststore configured for Mediator must include a certificate in the e-mail server's certificate chain.

This requires that both a keystore and trustore be configured for Integration Server. For information about configuring a keystore and truststore for Integration Server, see Administering webMethods Integration Server.

You must also select the truststore that contains either the e-mail certificate or certificate authority of the e-mail server while selecting the truststore for Mediator. For more information, see “Keystore Configuration” on page 86.

Test Recipient (optional)

The e-mail address of the person that should receive the test e-mail.



6 To test your connection, enter an e-mail address in the Test Recipient field and click Test.

7 Click Save.


Note: If you have configured your event policy to include request payloads, response payloads, or both, Mediator sends them as e-mail attachments. The attachments are compressed using ZIP data compression.

HTTP Configuration

Load balancing enables Mediator to distribute the messages it receives between a set of listed endpoints. You must configure the HTTP and HTTPS protocols in order for Mediator to communicate with the load balancer.

To configure load balancer URLs



3 In Mediator, select Administration > General.

4 On the Mediator Configuration screen, click Edit.

If the configuration is... Then...

Successful Mediator sends an e-mail to the address you entered in the Test Recipient field and displays the following message:

Success! Test email sent to recipient address: Test recipient e-mail address

Not successful Mediator displays an error message.

Reconfigure your e-mail settings and try again.


Keystore Configuration

5 Under HTTP Config, set the parameters as follows:

6 Click Save.


Keystore Configuration

At run-time, Mediator needs to know which keystore/truststore to use. For information about setting up keystore information, see Administering webMethods Integration Server.


Load Balancer URL (HTTP)

The primary HTTP load balancer URL and port number to use.

For the URL, you can specify either the IP address or host name of the load balancer with the port number, as follows:

http://IP-address:portnumber or

http://hostname:portnumber

If specified, all the virtual services hosted in Mediator will use this value.

Load Balancer URL (HTTPS)

The primary HTTPS load balancer URL and port number to use.

For the URL, you can specify either the IP address or host name of the load balancer with the port number, as follows:

https://IP-address:portnumber or

https://hostname:portnumber

If specified, all the virtual services hosted in Mediator (and exposed on HTTPS) will use this value.

Note: The SSL connection will be dropped if the remote server hosting the service is not trusted by Integration Server. To avoid this, you must create a truststore Integration Server and select it as part of the keystore configuration.

For information about configuring a truststore for Integration Server, see Administering webMethods Integration Server.

For information about selecting the trustore as part of the Mediator configuration, see “Keystore Configuration” on page 86.



To configure keystore information



3 In Mediator, select Administration > General.

4 On the Mediator Configuration screen, click Edit to make the values available for editing.

5 Under Keystore Config, set the parameters as follows:

6 Click Save.


Viewing and Synchronizing Services Manually

Mediator provides a user interface in which you can view and synchronize all services currently deployed to Mediator. In addition, you can view the VSD and WSDL of each service.


IS Keystore Name The Integration Server keystore that Mediator should use by selecting one from that list.

This field lists the available Integration Server keystores. If the user has not configured an Integration Server keystore, the list will be empty. If there are existing Integration Server keystores, then this field lists all of them.

Alias (Signing) The signing alias.

This alias is the value that is used to sign the outgoing response from Mediator to the original service consumer. It is auto-populated based on the keystore selected from the IS Keystore Name. This field will list all the aliases available in the chosen keystore.

If there are no configured keystores, this field will be empty.

IS Truststore name The Integration Server trust store used for establishing the HTTPS connection to the target service provider. It should contain the certificate of the service provider.

Note: If you selected TLS Enabled in “E-mail Configuration” on page 83, you must select the truststore that contains either the e-mail certificate or certificate authority of the e-mail server.


Synchronizing Consumer Applications Manually

To view and synchronize services



3 In Mediator, click Services.

4 For any service in the list, click VSD to view the virtual service definition or WSDL to view the WSDL file for the service.

5 Manually synchronize the virtual services with CentraSite by performing one of the following actions:


The List of Mediator Consumer screen shows the consumer applications configured in CentraSite for your system. You can use this screen to view the details of the consumer applications configured in CentraSite and synchronize Mediator with the consumer applications if the two are not synchronized.

To view details of consumer applications



3 In Mediator, click Consumers.

Click... To manually synchronize...

Sync All The state of Mediator with CentraSite by refreshing all virtual services that are in one of the following states:

Deploying

Deployed

Redeploying

Redployed

Undeploying

Sync Pending Services

Both:

All services that are in a pending state (deploying/redeploying/undeploying)

The latest consumer data from CentraSite



4 View the details of consumer applications synchronized with CentraSite by performing one of the following actions:

Note: To hide all consumer application details, click Collapse All. To hide the details for

an individual consumer application, click .

To synchronize consumer applications



3 In Mediator, click Consumers.

4 Click Sync All Consumer Apps.

Click... To view the details of...

All or Expand All of the consumer applications synchronized to Mediator.

An individual consumer application synchronized to Mediator.


7 Configuring SOAP Over JMS Protocols

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Configuring SOAP-JMS Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Creating a SOAP-JMS Web Service Endpoint Alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

About Managing SOAP-JMS Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Controlling Thread Usage for SOAP-JMS Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

Enabling, Disabling, and Suspending SOAP-JMS Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

Built-In Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103


Overview

Overview

Mediator supports sending SOAP over JMS (SOAP-JMS) messages between Web services. Mediator’s support of SOAP-JMS means that you can:

Create SOAP-JMS-based provider Web service endpoint aliases. A provider Web service endpoint alias is used to construct the endpoint reference, the JMS bindings, or both when WSDL is requested for the Web service. The security credentials may be used when constructing a response to a Web service request. SOAP-based Web service endpoint aliases can be used by Mediator or JMS provider Web service descriptors to facilitate SOAP-JMS messaging. For more information, see “Creating a SOAP-JMS Provider Web Service Endpoint Alias” on page 94.

Create SOAP-JMS-based consumer Web service endpoint aliases. A consumer Web service endpoint alias is used at run-time to generate a request and invoke an operation of the Web service. SOAP-based Web service endpoint aliases can be used by Mediator or JMS consumer Web service descriptors to facilitate SOAP-JMS messaging. For more information, see “Creating a SOAP-JMS Consumer Web Service Endpoint Alias” on page 96.

Receive SOAP-JMS messages. A Web service provider receives SOAP messages from a JMS destination using the SOAP-JMS trigger. The SOAP-JMS trigger specifies the destinations on a JMS provider from which the SOAP-JMS trigger will receive messages. You create a SOAP-JMS trigger to receive and send SOAP-JMS messages when you create a SOAP-JMS-based provider Web service endpoint alias. For more information, see “Creating a SOAP-JMS Trigger” on page 94.

Send SOAP-JMS messages. Mediator can use SOAP-JMS to invoke remote Web services and send SOAP response messages to the destination specified in the original request message. Mediator uses this protocol when invoking Web services that use JMS endpoints or when it receives request messages that use the JMS protocol.

Because the behavior and configuration of SOAP-JMS protocols is similar to those of other JMS protocols in Integration Server, you should be familiar with its JMS configuration procedures. For more information about configuring JMS protocols in Integration Server, see Administering webMethods Integration Server.

Configuring SOAP-JMS Messaging

To configure SOAP-JMS messaging on your system, you must:

1 Configure and provide access to an external JMS service provider. You can use webMethods Broker to act as a webMethods JMS Provider, a third-party JMS provider, or an open source JMS provider.

2 Use the JMS service provider to create request and response queues. For more information, see the documentation for your JMS service provider.

3 Specify the JMS client libraries in the Integration Server classpath so that Mediator is able to communicate with the JMS service provider.


Configuring SOAP Over JMS Protocols

4 Create one or more JNDI provider aliases to specify where Integration Server can look up administered objects when it needs create a connection to JMS provider or specify a destination for sending or receiving messages. For more information, see Administering webMethods Integration Server.

5 Create one or more connection aliases that encapsulate the properties that Integration Server needs to create a connection with the JMS provider. For more information, see Administering webMethods Integration Server.

Tip! For this step, it is helpful to modify the default alias provided with Integration Server, DEFUALT_IS_JMS_CONNECTION, to work with your JMS service provider.

6 Configure a SOAP-JMS provider or consumer Web service endpoint alias in Integration Server. For more information, see “Creating a SOAP-JMS Web Service Endpoint Alias” on page 93.

Note: When you configure a Web service JMS provider endpoint, you also create a SOAP-JMS trigger. For more information, see “Creating a SOAP-JMS Provider Web Service Endpoint Alias” on page 94.

Important! You must perform this step before you configure and deploy a virtual service with JMS entry protocol to Mediator.

7 If necessary, edit the SOAP-JMS trigger to better suit your environment. For more information, see “About Managing SOAP-JMS Triggers” on page 99.

8 Create a virtual service that uses either a JMS entry or a JMS routing protocol. For information about creating a virtual service, see the CentraSite ActiveSOA documentation.

Creating a SOAP-JMS Web Service Endpoint Alias

You must create a Web service endpoint alias to identify the endpoint name, description, and transport type. You create an alias for either a SOAP-JMS provider Web service endpoint or a SOAP-JMS consumer Web service endpoint, depending on the JMS protocols specified in the virtual service deployed to Mediator.

For information about creating a provider endpoint alias, see “Creating a SOAP-JMS Provider Web Service Endpoint Alias” on page 94. For information about creating a consumer endpoint alias, see “Creating a SOAP-JMS Consumer Web Service Endpoint Alias” on page 96.



Creating a SOAP-JMS Provider Web Service Endpoint Alias

You must create a SOAP-JMS provider Web service endpoint alias if the virtual service deployed to Mediator uses a JMS entry protocol. A SOAP-JMS provider Web service endpoint alias stores the configuration used to generate the Web service’s endpoint reference (the JMS URI), the JMS bindings, or both in a WSDL file.

The primary information used to build the JMS URI is retrieved from the SOAP-JMS trigger. The SOAP-JMS trigger contains the name of the destination and the name of the JMS connection alias that the trigger uses to connect to the JMS provider. Mediator uses the Web service endpoint alias name to retrieve the JMS URI.

Creating a SOAP-JMS Trigger

When you create a SOAP-JMS provider Web service endpoint alias, you also create the SOAP-JMS trigger. For information about managing SOAP-JMS triggers, see “About Managing SOAP-JMS Triggers” on page 99.

To create a SOAP-JMS provider Web service endpoint alias and SOAP-JMS trigger

1 Open Integration Server Administrator if it is not already open.

2 In the Navigation panel, select Settings > Web Services.

3 Click Create Web Service Endpoint Alias.

4 Under Web Service Endpoint Alias Properties, provide the following information:

5 Under JMS Transport Properties, provide the following information:

In this field... Specify...

Alias A name for the provider Web service endpoint alias.

This will also become the name of the SOAP-JMS trigger.

The alias name cannot include the following illegal characters: # ©\ & @ ^ ! % * : $ . / \ \ ` ; , ~ + = ) ( | } { ] [ > < "

Description A description for the endpoint alias.

Type Provider

Transport Type JMS


SOAP-JMS trigger Name

WS Endpoint Trigger. Integration Server populates this field automatically with all valid SOAP-JMS trigger names.

Delivery Mode (optional)

Whether the JMS transport should be Persistent or Non_Persistent.



6 Under JMS WSDL Options, provide the following information:

7 Under WS Security Properties, if the inbound SOAP request must be decrypted and/or the outbound SOAP request must be signed, do the following:

Time to Live (optional)

The amount of time (in milliseconds) before a message expires. If set to zero, the message does not expire.

Priority (optional) The message’s priority in the queue. You can specify a number from 0 to 9, where 0 is the lowest priority and 9 is the highest.

Reply To Name (optional)

The name or lookup name of the JMS destination where a reply to the message should be sent.

Reply To Type (optional)

The type of message to which containing an empty value. The options are Queue and Topic. Default to empty value.

Note: This parameter is only applicable when performing request-reply.


Include Connection Factory Name in JMS URI

Whether to include the connection factory name in the generated WSDL.

Include JNDI Parameters in JMS URI

Whether to include the JNDI parameters in the generated WSDL.


Keystore Alias Alias of the keystore containing the private key used to decrypt the inbound SOAP request or sign the outbound SOAP response.

Important! The provider must have already given the consumer the corresponding public key.

Key Alias Alias of the private key used to decrypt the request or sign the response. The key must be in the keystore specified in Keystore Alias.




8 Under WS Security Properties, if the signing certificate chain of an inbound signed SOAP message has to be validated, specify the following:

9 Click Save Changes.

Integration Server saves your changes and creates the SOAP-JMS trigger.

Creating a SOAP-JMS Consumer Web Service Endpoint Alias

You must create a SOAP-JMS consumer Web service endpoint alias in either of the following cases:

If the virtual service deployed to Mediator uses a JMS routing protocol.

If the WSDL from the Web service provider does not supply either the JNDI provider or the JMS connection alias information.

You can create a SOAP-JMS consumer Web service alias to include either a JNDI provider alias or JMS connection alias. The JNDI provider alias specifies JNDI settings, such as Initial Context Factory and URL. The SOAP-JMS connection alias can include JNDI configuration information or native configuration information used to access the JMS provider directly.

For information about creating a consumer endpoint alias that includes a JNDI provider, see “To create a SOAP-JMS consumer Web service endpoint alias that includes a JNDI provider” on page 96. For information about creating a consumer endpoint alias that includes a JMS connection alias, see “To create a JMS consumer Web service endpoint alias that includes a JMS connection alias” on page 98.

To create a SOAP-JMS consumer Web service endpoint alias that includes a JNDI provider





Truststore Alias The alias for the truststore that contains the list of CA certificates that Integration Server uses to validate the trust relationship.





6 Under WS Security Properties, provide the following information:






Type Consumer

Transport Type JMS


Connect Using JNDI Properties

JNDI Provider Alias

The name of the JNDI provider alias.

Connection Factory Name

The connection factory JNDI lookup name.


User Name User name used to authenticate the consumer at the JMS transport level on the host server.

Password The password used to authenticate the consumer on the host server.

Retype Password Re-enter the above password.

Partner’s Certificate

The path and file name of the provider’s certificate, which contains its public key.

Keystore Alias The alias of the keystore that contains the private key used to connect to the Web service host securely.

Key Alias The alias of the key in the keystore that contains the private key used to connect to the Web service host securely. The key must be in the keystore specified in Keystore Alias.




To create a JMS consumer Web service endpoint alias that includes a JMS connection alias






6 Under WS Security Properties, provide the following information:





Type Consumer

Transport Type JMS


Connect Using JMS Connection Alias

JMS Connection Alias

The name of the JMS connection alias.


User Name User name used to authenticate the consumer at the JMS transport level on the host server.

Password The password used to authenticate the consumer on the host server.

Retype Password Re-enter the above password.

Partner’s Certificate

The path and file name of the provider’s certificate, which contains its public key.

Keystore Alias The alias of the keystore that contains the private key used to connect to the Web service host securely.




About Managing SOAP-JMS Triggers

Integration Server Administrator provides controls for managing SOAP-JMS triggers and the resources used by SOAP-JMS triggers. Specifically, you can use the controls provided by Integration Server Administrator to:

Increase or decrease the maximum number of server threads used for SOAP-JMS triggers.

Change the maximum execution threads for concurrent SOAP-JMS triggers.

Enable, disable, or suspend one ore more SOAP-JMS triggers.

The following sections provide more information about managing SOAP-JMS triggers.

Controlling Thread Usage for SOAP-JMS Triggers

You can use Integration Server Administrator to limit the number of server threads that SOAP-JMS triggers can use. By default, Integration Server can consume up to 100% of the server thread pool for SOAP-JMS triggers. However, you should leave some server resources available to perform other functions.

Viewing Thread Usage for SOAP-JMS Triggers

Integration Server Administrator displays the number of server threads currently used by each SOAP-JMS trigger on Integration Server.

To view thread usage for SOAP-JMS triggers


2 In the Settings menu of the Navigation panel, click Messaging.

3 Click JMS Trigger Management.

Key Alias The alias of the key in the keystore that contains the private key used to connect to the Web service host securely. The key must be in the keystore specified in Keystore Alias.




Controlling Thread Usage for SOAP-JMS Triggers

Under Individual SOAP JMS Trigger Controls, in the Current Threads column, Integration Server Administrator displays the number of server threads currently used to receive and process messages for each SOAP-JMS trigger. The Current Threads column displays Not Connected if Integration Server is not connected to a JMS provider.

Increasing or Decreasing Thread Usage for All Triggers

Integration Server provides controls that you can use to manage server thread usage by all JMS triggers and SOAP-JMS triggers. You can use the controls to:

Set the percentage of the server thread pool that Integration Server can use for receiving and processing all JMS and SOAP-JMS triggers.

Reduce maximum execution threads by the same percentage across all concurrent JMS and SOAP-JMS triggers. This also decreases the rate at which concurrent JMS and SOAP-JMS triggers process messages.

To increase or decrease thread usage for all JMS and SOAP-JMS triggers




4 Click Edit JMS Global Trigger Controls.

5 In the Thread Pool Throttle field, type the maximum percentage of the server thread pool that can be used for JMS and SOAP-JMS triggers. This includes threads used to retrieve messages from the JMS provider and threads used to process messages. You must enter a value greater than zero.

6 In the Individual Trigger Processing Throttle field, select the value, as a percentage of the configured maximum execution threads value, at which you want to the server to function. Integration Server applies this percentage to the maximum execution threads value for all concurrent JMS and SOAP-JMS triggers.

This value applies to concurrent JMS and SOAP-JMS triggers only.


Notes:

If the Thread Pool Throttle percentage does not evaluate to a whole number when applied to the size of the server thread pool, Integration Server rounds up or down to the nearest whole number.

Serial JMS and SOAP-JMS triggers always process one message at a time. For a serial trigger, Integration Server uses the same thread for receiving and processing a message. The Individual Trigger Processing Throttle does not affect serial JMS and SOAP-JMS triggers.



Concurrent JMS and SOAP-JMS triggers use a pool of consumers to receive and process messages. Each consumer will use a thread from the server thread pool to receive and process a message. A concurrent JMS or SOAP-JMS trigger dedicates an additional thread to managing the pool of consumers. For example, a concurrent JMS trigger configured to process up to 10 messages at a time can use a maximum of 11 server threads.

If the percentage by which you reduce concurrent JMS or SOAP-JMS trigger execution threads does not resolve to a whole number for a JMS or SOAP-JMS trigger, Integration Server rounds up or rounds down to the nearest whole number. However, if rounding down would set the value to 0, the Integration Server rounds up to 1. For example, if you reduce Individual Trigger Processing Throttle to 10% of maximum, a concurrent JMS trigger with a maximum execution threads value of 12 would have an adjusted value of 1 (Integration Server rounds 1.2 down to 1). A concurrent JMS trigger with a maximum execution threads value of 4 would have an adjusted value of 1 (Integration Server rounds 0.4 up to 1).

When you reduce the Individual Trigger Processing Throttle and save your changes, Integration Server does not meet the adjusted maximum by terminating any threads currently executing concurrent JMS and SOAP-JMS triggers. Integration Server enables server threads processing messages for concurrent JMS and SOAP-JMS triggers to execute to completion. Integration Server waits until the number of threads executing for a concurrent JMS or SOAP-JMS trigger is less than the adjusted maximum before dispatching another server thread for that JMS or SOAP-JMS trigger.

Enabling, Disabling, and Suspending SOAP-JMS Triggers

You can manage SOAP-JMS triggers and the amount of resources they consume by changing the state of a SOAP-JMS trigger. A SOAP-JMS trigger can have one of the following states:

Using the Integration Server Administrator, you can:

Enable, disable, or suspend all SOAP-JMS triggers.

Enable, disable, or suspend specific SOAP-JMS triggers.

Trigger State Description

Enabled The SOAP-JMS trigger is running and connected to the JMS provider. Integration Server retrieves and processes messages for the SOAP-JMS trigger.

Disabled The SOAP-JMS trigger is stopped. Integration Server neither retrieves nor processes messages for the SOAP-JMS trigger.

Suspended The SOAP-JMS trigger is running and connected to the JMS provider. Integration Server has stopped message retrieval, but continues processing any messages it has already retrieved.


Enabling, Disabling, and Suspending SOAP-JMS Triggers

You might want to change the state of all SOAP-JMS triggers at once as a quick way of making server resources available. This can be especially helpful in a situation in which Integration Server is functioning under heavy load and additional resources are needed immediately.

You might want to change the state for a specific SOAP-JMS trigger in the following situations:

When a back-end system needs maintenance or is becoming unresponsive, you might want to suspend SOAP-JMS Triggers that interact with the back-end system. When the back-end system becomes available, you can enable the SOAP-JMS triggers.

After suspending or disabling all SOAP-JMS triggers, you might enable specific SOAP-JMS triggers. For example, if the server is functioning under an unusually heavy load, you might first suspend all SOAP-JMS triggers and then gradually enable SOAP-JMS triggers, starting with the SOAP-JMS triggers involved in key processes.

After Integration Server suspends a serial SOAP-JMS trigger automatically because a fatal error occurred during message processing.

The following procedure explains how to use Integration Server Administrator to change the state of all or individual SOAP-JMS triggers.

To enable, disable, or suspend SOAP-JMS triggers




4 If you want to change the state of all SOAP-JMS triggers, do the following:

a Under Individual SOAP JMS Trigger Controls, in the Enabled column, click edit all.

b On the Settings > Messaging > JMS Trigger Management > Edit State screen, in the New State list, select the state that you want to apply to all SOAP-JMS triggers.

5 If you want to change the state of a specific SOAP-JMS trigger, do the following:

a Under Individual SOAP JMS Trigger Controls, in the row for the SOAP-JMS trigger that you want to enable, disable, or suspend, click the text in the Enabled column

b On the Settings > Messaging > JMS Trigger Management > Edit State: triggerName screen, in the New State list, select the state that you want to apply to this SOAP-JMS trigger.


Notes:

If you want to disable a SOAP-JMS trigger, first suspend the SOAP-JMS trigger and wait for all the processing threads complete. Then disable the SOAP-JMS trigger. You can view the number of threads currently used by a SOAP-JMS trigger on the Settings > Messaging > JMS Trigger Management screen.



When you disable a SOAP-JMS trigger, Integration Server does the following:

If the SOAP-JMS trigger is waiting before making a retry attempt, Integration Server interrupts processing for the SOAP-JMS trigger.

If the SOAP-JMS trigger is currently processing messages, Integration Server waits a specified amount of time before forcing the SOAP-JMS trigger to stop processing messages. If it does not complete in the allotted time, Integration Server stops the message consumer used to receive messages for the SOAP-JMS trigger and closes the JMS session. At this point the server thread for the SOAP-JMS trigger continues to run to completion. However, the SOAP-JMS trigger is not able to acknowledge the message when processing completes. If the delivery mode of the message is set to persistent, this can lead to duplicate messages.

The time Integration Server waits between the request to disable the SOAP-JMS trigger and forcing the trigger to stop is specified by the watt.server.jms.trigger.stopRequestTimeout property.

Because administered objects, like destinations, are configured outside of Integration Server, disabling a SOAP-JMS trigger has no impact on the subscription.

If a SOAP-JMS trigger is processing messages at the time it is suspended, the SOAP-JMS trigger will complete processing of those messages. The SOAP-JMS trigger also acknowledges the messages to the JMS provider.

You can use built-in services to enable, disable, and suspend one or more triggers. For information about the pub.trigger:disableJMSTriggers, pub.trigger:enableJMSTriggers, and pub.trigger:suspendJMSTriggers services, see the webMethods Integration Server Built-In Services Reference.

Built-In Services

The SOAP-JMS trigger uses the same built-in services as those used by the JMS trigger. For more information, see the webMethods Integration Server Built-In Services Reference.


Built-In Services


A Advanced Settings

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

pg.3pSnmpSender. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

pg.CollectionPool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

pg.CollectionWorkQueue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

pg.cs.snmpTarget. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

pg.csSnmpSender. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

pg.debug. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

pg.delayedRefresher. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

pg.email. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

pg.IntervalPool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

pg.jaxbFileStore. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

pg.keystore. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

pg.lb. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

pg.passman. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

pg.PgMenConfiguration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112

pg.PgMenSharedCacheManager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

pg.PgMetricsFormatter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

pg.policygateway. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

pg.proxyLoader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

pg.rampartdeploymenthandler. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

pg.ReportingPool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

pg.ReportingWorkQueue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

pg.serviceReader. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

pg.snmp.communityTarget. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

pg.snmp.customTarget. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

pg.snmp.userTarget. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

pg.vsdTransformer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

pg.wrapperFactory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120


Introduction

Introduction

This appendix contains a description of the parameters you can specify in the Mediator properties file (pg-config.properties), which is located in the IntegrationServer_directory\packages\WmMediator\config\resources directory.

You can edit this file only by using a text editor. Before you edit the file, you should first shut down the Integration Server. After you make your changes, restart the server.

Note: Some parameters present in the pg-config.properties file can be edited from the Mediator Administration console. You do not have to restart Integration Server when you change parameters through the Mediator Administration console.

pg.3pSnmpSender.

pg.3pSnmpSender.sendDelayThis is an internal parameter. Do not modify.

pg.CollectionPool.

pg.CollectionPool.minThreadsSets the minimum number of threads Mediator Event Engine data collection work queue minimum thread count. The default is 1.

pg.CollectionPool.maxThreadsSets the maximum number of threads used for the data collection work queue. The default is 8.

pg.CollectionPool.forcefulShutdownSpecifies whether the data collection thread pool should shut down immediately or wait for queued tasks to complete during Mediator shutdown. The default is false.

pg.CollectionPool.poolNameSets the name for the data collection thread pool. The default is CollectionPool.

pg.CollectionWorkQueue.

pg.CollectionWorkQueue.queueCapacitySets the capacity available for data collection tasks stored in the memory work queue. The default is 10000.


Advanced Settings

pg.cs.snmpTarget.

These properties specify the settings for Mediator to use the CentraSite SNMPv3 user-based connection as its SNMP server. The default values for the server are synchronized with the defaults used by the SNMP Event Listener configuration found in the CentraSite web.xml file.

Note: All SNMP settings must match those of the SNMP server. The settings must match what the server is set to receive.

pg.cs.snmpTarget.authProtocolSets the authorization protocol to use for securing SNMPv3 messages. Valid values are MD5 (default) and SHA.

You can edit this parameter from the CentraSite SNMP Configuration > Authorization Protocol field on the Administration > SNMP page of the Mediator Administration console.

pg.cs.snmpTarget.base64EncodedThis is an internal parameter. Do not modify.

pg.cs.snmpTarget.connTimeoutSpecifies the number milliseconds before an inactive connection to the SNMP target server is closed. If set to 0, the socket remains open indefinitely.

pg.cs.snmpTarget.ipAddressSets the IP address of the CentraSite SNMPv3 server. You can edit this parameter from the CentraSite SNMP Configuration > Host Name/IP Address field on the Administration > SNMP page of the Mediator Administration console.

You must configure a server running CentraSite for this property to synchronize with the default CentraSite installation values. You cannot set this parameter to localhost.

Important! If you do not set this parameter properly, the traps might not reach the SNMP server. Mediator will still send events as SNMP traps, but because there is no mechanism for acknowledging traps that are configured incorrectly, the SNMP server will not return errors when settings are incorrect.

pg.cs.snmpTarget.maxRequestSizeSpecifies the maximum size (in bytes) for SNMP traps. The default is 10485760.

pg.cs.snmpTarget.portSets the SNMP trap receiver port on theCentraSite server that is listening for SNMP requests and packets. The default is 8181.

You can edit this parameter from the CentraSite SNMP Configuration > Port field on the Administration > SNMP page of the Mediator Administration console.


pg.cs.snmpTarget.

pg.cs.snmpTarget.privProtocolSets the privacy protocol to use for SNMPv3 messages. Valid values are DES (default), AES128, AES192, and AES256.

You can edit this parameter from the CentraSite SNMP Configuration > Privacy Protocol field on the Administration > SNMP page of the Mediator Administration console.

pg.cs.snmpTarget.retriesSpecifies the number of times to resend SNMP traps upon failure. The default is 1.

This parameter works with pg.cs.snmpTarget.sendTimeOut to determine the delay in resending SNMP traps to malfunctioning SNMP servers (retries*sendTimeOut). This means that if the retries parameter is set to 3, and the sendTimeOut parameter is set to 500 milliseconds, there will be a 1.5 second delay before the Mediator thread sending the alert is available to send another event. Malfunctioning event destinations could delay the amount of time it takes Mediator to report events or lead to discarded events when the queue reaches its maximum level.

pg.cs.snmpTarget.sendTimeOutSpecifies the amount of time (in milliseconds) to wait before the SNMP trap times out because the server destination is not responding. This value schedules a timer that will resend an SNMP event that has not yet completed when it expires. You should set a time-out value that ensures that the trap is sent to the SNMP server within the time frame. This parameter does not abort an event that is in progress. Set this parameter higher than the default when sending traps with large payloads. The default is 500.

This parameter works with pg.cs.snmpTarget.retries to determine the delay in resending SNMP traps to malfunctioning SNMP servers (retries*sendTimeOut). This means that if the retries parameter is set to 3, and the sendTimeOut parameter is set to 500 milliseconds, there will be a 1.5 second delay before the Mediator thread sending the alert is available to send another event. Malfunctioning event destinations could delay the amount of time it takes Mediator to report events or lead to discarded events when the queue reaches its maximum level.

pg.cs.snmpTarget.sendTrapsSpecifies whether to send traps to the CentraSite SNMPv3 server. The default is false.

You can edit this parameter from the CentraSite SNMP Configuration > Send TRAPs to CentraSite check box on the Administration > SNMP page of the Mediator Administration console.

pg.cs.snmpTarget.transportProtocolSets the protocol used by SNMPv3 to send traps. Valid values are TCP (default) and UDP.

You can edit this parameter from the CentraSite SNMP Configuration > Transport field on the Administration > SNMP page of the Mediator Administration console.

pg.cs.snmpTarget.useAuthSpecifies whether an authorization key is required. The default is false.

You can edit this parameter from the CentraSite SNMP Configuration > Use Authorization check box on the Administration > SNMP page of the Mediator Administration console.


Advanced Settings

pg.cs.snmpTarget.usePrivacySpecifies whether a privacy (encryption) key is required. The default is false.

You can edit this parameter from the CentraSite SNMP Configuration > Use Privacy check box on the Administration > SNMP page of the Mediator Administration console.

pg.cs.snmpTarget.userNameSets the SNMPv3 user name to use when connecting to the receiver. You can edit this parameter from the CentraSite SNMP Configuration > User Name field on the Administration > SNMP page of the Mediator Administration console.

pg.csSnmpSender.

pg.csSnmpSender.sendDelayThis is an internal parameter. Do not modify.

pg.debug.

pg.debug.eventLoggerActiveThis is an internal parameter. Do not modify.

pg.delayedRefresher.

Mediator cannot query CentraSite for updates or receive deployed services until Integration Server is running. If Integration Server is not yet fully operational when Mediator starts, a delayed refresh helper is used to wait for Integration Server. This helper will periodically check on Integration Server’s status.

pg.delayedRefresher.napMillisSpecifies the amount of time (in milliseconds) the delayed refresher helper waits before checking to see whether Integration Server is running. The default is 500.

pg.email.

pg.email.charsetSpecifies the character set to use for the subject line, e-mail addresses, and message body of the e-mails when sending events. The default is US-ASCII.

pg.email.debugThis is an internal parameter. Do not modify.


pg.email.

pg.email.fromSpecifies the e-mail address used when sending events by e-mail. The default is targetName@IS-hostname.

You can edit this parameter from the From field on the Administration > Email page of the Mediator Administration console.

pg.email.resourceMimeTypeSpecifies the MIME type Mediator uses to send the request and response payload attachments for transaction events that are sent by e-mail. Mediator supports the following values:

application/gzip (.gz)

application/zip (.zip)

text/xml (.xml)

The default is application/zip.

pg.email.SenderActiveSpecifies whether there is an e-mail server configured for Mediator. The default is false.

Note: If a value is provided for the SMTP Host Name/IP Address field in the Administration > Email screen from the Mediator Administrator console, this flag is set to true.

pg.email.smtpHostSpecifies the host name of the e-mail server. If you define a value for this parameter, the pg.email.SenderActive parameter is set to true.

You can edit this parameter from the SMTP Host Name/IP Address check box on the Administration > Email page of the Mediator Administration console.

pg.email.smtpPortSpecifies the e-mail port for the SMTP or SMTPS protocol. The default is 25.

You can edit this parameter from the Port field on the Administration > Email page of the Mediator Administration console.

pg.email.timeOutSpecifies the time out period (in milliseconds) when connecting to an e-mail server and sending e-mails. The default is 1000.

pg.email.TLSEnabledSpecifies whether to use one-way transport-layer security. If set to true, the truststore configured for Mediator must include a certificate in the e-mail server's certificate chain. The default is false.

You can edit this parameter from the TLS Enabled check box on the Administration > Email page of the Mediator Administration console.


Advanced Settings

pg.email.userNameSpecifies the user name of the e-mail account used to log into the SMTP server. You can edit this parameter from the User field on the Administration > Email page of the Mediator Administration console.

pg.IntervalPool.

The interval pool is used to schedule the processing of recurring tasks.

pg.IntervalPool.minThreadsSpecifies the minimum thread count for this interval pool. The default is 1.

pg.IntervalPool.maxThreadsSpecifies the maximum thread count for this interval pool. The default is 1.

pg.IntervalPool.forcefulShutdownSpecifies whether the interval thread pool should wait for queued tasks to complete during Mediator shutdown. Setting this parameter to true will cause Mediator to shut down immediately, without waiting for the tasks to finish. The default is false.

pg.IntervalPool.poolNameSpecifies the name of the interval processor pool. The default is IntervalPool.

pg.jaxbFileStore.

pg.jaxbFileStore.consumerFileStoreSpecifies the location of the locally persisted consumer applications that Mediator received from CentraSite. This is updated periodically as long as communication with CentraSite is working. The default is resources\consumers\consumers.xml.

pg.keystore.

pg.keystore.keyStoreHandleThis is an internal parameter. Do not modify.

pg.keystore.trustStoreHandleThis is an internal parameter. Do not modify.

pg.lb.

pg.lb.http.urlSpecify the primary HTTP load balancer URL and port number to use in http://hostname:portnumber format. You can edit this parameter from the Load Balancer URL (HTTP) field on the Administration > General page of the Mediator Administration console.


pg.passman.

pg.lb.https.urlSpecify the primary HTTPS load balancer URL and port number to use in https://hostname:portnumber format. You can edit this parameter from the Load Balancer URL (HTTPS) field on the Administration > General page of the Mediator Administration console.

pg.passman.

pg.passman.configFileThis is an internal parameter. Do not modify.

pg.PgMenConfiguration.

pg.PgMenConfiguration.perfDataEnabledSpecifies whether Mediator collects and reports performance data to CentraSite. The default is true.

Note: If this parameter is disabled, Mediator removes all policy actions and will not trigger metrics reports.

You can edit this parameter from the Report Performance Data check box on the Administration > CentraSite Communication page of the Mediator Administration console.

pg.PgMenConfiguration.publishErrorEventsSpecifies whether to publish Error events to CentraSite. The default is false.

You can edit this parameter from the Error check box on the Administration > SNMP page of the Mediator Administration console.

pg.PgMenConfiguration.publishLifeCycleEventsSpecifies whether to publish Life Cycle events to CentraSite. The default is false.

You can edit this parameter from the Lifecycle check box on the Administration > SNMP page of the Mediator Administration console.

pg.PgMenConfiguration.publishPolicyViolationEventsSpecifies whether to publish Policy Violation events to CentraSite. The default is false.

You can edit this parameter from the Policy Violation check box on the Administration > SNMP page of the Mediator Administration console.

pg.PgMenConfiguration.reportIntervalSpecifies the how often (in minutes) Mediator publishes performance data to CentraSite. The default is 10.

You can edit this parameter from the Publish Interval field on the Administration > CentraSite Communication page of the Mediator Administration console.


Advanced Settings

pg.PgMenConfiguration.sieFlushIntervalSpecifies the number of seconds before the accumulated invoked service events are pushed into the shared cache. The default is 10.

pg.PgMenConfiguration.tickIntervalSpecifies the amount of time (in seconds) between each interval processor iteration. This must be an evenly divisible fraction of the smallest policy interval, which is one minute. The default is 15.

pg.PgMenSharedCacheManager.

pg.PgMenSharedCacheManager.lockRetrySpecifies the number of times Mediator attempts to obtain a lock on metrics data in the shared cache. The default is 1.

pg.PgMenSharedCacheManager.lockTimeOutSpecifies the amount of time (in seconds) the shared cache waits to obtain a lock before timing out. The default is 5.

pg.PgMetricsFormatter.

pg.PgMetricsFormatter.includeFaultsSpecifies whether service faults are included in the performance data aggregated metric counts. If set to true, the average, minimum, and maximum response times will include failed requests in the calculations. The default is false.

pg.policygateway.

pg.policygateway.targetNameSets the name of the Mediator configured as a target in CentraSite. It is used by CentraSite to identify this instance of Mediator. The default is your-target-name-here.

You can edit this parameter from the Target Name field on the Administration > CentraSite Communication page of the Mediator Administration console.

pg.policygateway.disableCsCommSpecifies whether Mediator will attempt to establish communication with CentraSite. If set to false, Mediator can send SNMP events to CentraSite, but will not send consumer applications, VSD synchronization, or metrics reporting. The default is true.

Note: If this parameter is set to true, it means that the Synchronize with CentraSite check box on the Administration > CentraSite Communication screen of the Mediator Administration console is not selected.

You can edit this parameter from the Synchronize with CentraSite check box on the Administration > CentraSite Communication page of the Mediator Administration console.


pg.proxyLoader

pg.policygateway.repositoryLocationThis is an internal parameter. Do not modify.

pg.proxyLoader

pg.proxyLoader.proxyLocationThis is an internal parameter. Do not modify.

pg.rampartdeploymenthandler.

pg.rampartdeploymenthandler.signingCertAliasSpecifies the signing alias used to sign the outgoing response from Mediator to the original request service consumer.

You can edit this parameter from the Alias (Signing) field on the Administration > General page of the Mediator Administration console.

pg.rampartdeploymenthandler.usernameTokenUserThis is an internal parameter. Do not modify.

pg.ReportingPool.

Reporting pool options affect outbound event publishing. The pool includes all events, including performance data, SNMP, and SMTP.

pg.ReportingPool.minThreadsSpecifies the minimum thread count for this reporting pool. Enabling more threads means that Mediator can send more events to the event destination faster. The default is 2.

pg.ReportingPool.maxThreadsSpecifies the maximum thread count for this reporting pool. Enabling more threads means that Mediator can send more events to the event destination faster. The default is 4.

pg.ReportingPool.forcefulShutdownSpecifies whether the reporting pool should wait for queued tasks to complete during Mediator shutdown. Setting this parameter to true will cause Mediator to shut down immediately, without waiting for the tasks to finish. The default is false.

pg.ReportingPool.poolNameSpecifies the name of the reporting pool. The default is ReportingPool.


Advanced Settings

pg.ReportingWorkQueue.

pg.ReportingWorkQueue.queueCapacitySets the capacity available for data collection tasks stored in the reporting work queue. Smaller in-memory collection and reporting queues reduce memory load on Integration Server, but can result in some messages being discarded. If you configure more memory for Integration Server it can support more events in the queues. The default is 5000.

pg.serviceReader.

pg.serviceReader.intervalThis is an internal parameter. Do not modify.

pg.snmp.communityTarget.

These parameters are used only when you have set pg.snmp.customTarget to community.


pg.snmp.communityTarget.base64EncodedSpecifies whether to use a third-party SNMPv1 community-based connection. If set to true, the community name entered in the Community Name field in the Administration > SNMP screen of the Mediator Administration console should be the Base64 value. The default is false.

pg.snmp.communityTarget.communityNameSpecifies the name used to interact with the SNMP receiver. You must specify a community name that can accept alert traps. The default is public.

You can edit this parameter from the 3rd Party SNMP Configuration > Community Name field in the Administration > SNMP screen of the Mediator Administration console.

pg.snmp.communityTarget.transportProtocolSpecifies the protocol used by SNMP to send traps. Valid values are tcp (default) and udp.

If you select udp, you must ensure that the SNMP server is in the same subnet or configure the routers to get packets across subnet boundaries. The maximum PDU size when running in UDP mode is 64Kb, which might be restrictive when sending large request and response payloads for Transaction Events.

You can edit this parameter from the 3rd Party SNMP Configuration > Transport field in the Administration > SNMP screen of the Mediator Administration console.


pg.snmp.communityTarget.

pg.snmp.communityTarget.ipAddressSpecifies the IP address of the host running the SNMP server. You cannot set this parameter to localhost.


You can edit this parameter from the 3rd Party SNMP Configuration > Host Name/IP Address field in the Administration > SNMP screen of the Mediator Administration console.

pg.snmp.communityTarget.portSpecifies the port accepting requests for the SNMP server. The default is 2162.

You can edit this parameter from the 3rd Party SNMP Configuration > Port field in the Administration > SNMP screen of the Mediator Administration console.

pg.snmp.communityTarget.retriesSpecifies the number of times to resend SNMP traps upon failure. The default is 1.

This parameter works with pg.snmp.communityTarget.sendTimeOut to determine the delay in resending SNMP traps to malfunctioning SNMP servers (retries*sendTimeOut). This means that if the retries parameter is set to 3, and the sendTimeOut parameter is set to 500 milliseconds, there will be a 1.5 second delay before the Mediator thread sending the alert is available to send another event. Malfunctioning event destinations could delay the amount of time it takes Mediator to report events or lead to discarded events when the queue reaches its maximum level.

pg.snmp.communityTarget.sendTimeOutSpecifies the amount of time (in milliseconds) to wait before the SNMP trap times out because the server destination is not responding. This value schedules a timer that will resend an SNMP event that has not yet completed when it expires. You should set a time-out value that ensures that the trap is sent to the SNMP server within the time frame. This parameter does not abort an event that is in progress. Set this parameter higher than the default when sending traps with large payloads. The default is 500.

This parameter works with pg.snmp.communityTarget.retries to determine the delay in resending SNMP traps to non-responsive SNMP servers (retries*sendTimeOut). This means that if the retries parameter is set to 3, and the sendTimeOut parameter is set to 500 milliseconds, there will be a 1.5 second delay before the Mediator thread sending the alert is available to send another event. Malfunctioning event destinations could delay the amount of time it takes Mediator to report events or lead to discarded events when the queue reaches its maximum level.

pg.snmp.communityTarget.maxRequestSizeSpecifies the maximum size (in bytes) for SNMP traps. The default is 65535.


Advanced Settings

pg.snmp.customTarget.

All SNMP settings must match those of the SNMP server. The settings must match what the server is set to receive.

pg.snmp.customTargetSpecifies which third-party SNMP security model Mediator should use. Valid values are:

communityTarget (default)—For SNMPv1 community-based security. For community-based parameters, see pg.snmp.communityTarget.

userTarget—For SNMPv3 user-based security. For user-based parameters, see pg.snmp.userTarget.

You can edit this parameter from the SNMP Target Type option on the Administration > SNMP page of the Mediator Administration console.

pg.snmp.customTarget.connTimeoutSpecifies the number milliseconds before an inactive connection to the SNMP target server is closed. If set to 0, the socket remains open indefinitely.

pg.snmp.customTarget.sendTrapsSpecifies whether to send traps to the selected third-party SNMP server. If set to true, the alerts will be sent to the configured third-party SNMP receiver (either community or user). The default is false.

pg.snmp.userTarget.

The pg.snmp.userTarget. parameters are used only when you have set pg.snmp.customTarget to user.


pg.snmp.userTarget.authProtocolSpecifies the authorization protocol to use. This parameter is valid only when pg.snmp.userTarget.useAuth is set to true. Valid values are MD5 (default) or SHA.

You can edit this parameter from the 3rd Party SNMP Configuration > Authorization Protocol field in the Administration > SNMP screen of the Mediator Administration console.


pg.snmp.userTarget.

pg.snmp.userTarget.ipAddressSpecifies the IP address of the SNMP server. You cannot set this parameter to localhost.


You can edit this parameter from the 3rd Party SNMP Configuration > Host Name/IP Address field in the Administration > SNMP screen of the Mediator Administration console.

pg.snmp.userTarget.maxRequestSizeSpecifies the maximum size (in bytes) for SNMP traps. The default is 65535.

pg.snmp.userTarget.portSpecify the SNMP trap receiver port that is listening for SNMP requests and packets. The default is 2161.

You can edit this parameter from the 3rd Party SNMP Configuration > Port field in the Administration > SNMP screen of the Mediator Administration console.

pg.snmp.userTarget.privProtocolSpecifies the privacy protocol to use. This parameter is valid only when pg.snmp.userTarget.usePrivacy is set to true. The default is DES.

DES (default)

AES128

AES192

AES256

You can edit this parameter from the 3rd Party SNMP Configuration > Privacy Protocol field in the Administration > SNMP screen of the Mediator Administration console.

pg.snmp.userTarget.retriesSpecifies the number of times to resend SNMP traps upon failure. The default is 1.

This parameter works with pg.snmp.userTarget.sendTimeOut to determine the delay in resending SNMP traps to malfunctioning SNMP servers (retries_param*sendTimeOut). This means that if the retries parameter is set to 3, and the sendTimeOut parameter is set to 500 milliseconds, there will be a 1.5 second delay before the Mediator thread sending the alert is available to send another event. Malfunctioning event destinations could delay the amount of time it takes Mediator to report events or lead to discarded events when the queue reaches its maximum level.

pg.snmp.userTarget.sendTimeOutSpecifies the amount of time (in milliseconds) to wait before the SNMP trap times out because the server destination is not responding. This value schedules a timer that will resend an SNMP event that has not yet completed when it expires. You should set a time-out value that ensures that the trap is sent to the SNMP server within the time frame. This parameter does not abort an event that is in progress. Set this parameter higher than the default when sending traps with large payloads. The default is 500.


Advanced Settings

This parameter works with pg.snmp.userTarget.retries to determine the delay in resending SNMP traps to malfunctioning SNMP servers (retries*sendTimeOut). This means that if the retries parameter is set to 3, and the sendTimeOut parameter is set to 500 milliseconds, there will be a 1.5 second delay before the Mediator thread sending the alert is available to send another event. Malfunctioning event destinations could delay the amount of time it takes Mediator to report events or lead to discarded events when the queue reaches its maximum level.

pg.snmp.userTarget.transportProtocolSpecifies the protocol used by SNMP to send traps. Valid values are tcp (default) and udp.

You can edit this parameter from the 3rd Party SNMP Configuration > Transport field in the Administration > SNMP screen of the Mediator Administration console.

pg.snmp.userTarget.useAuthSpecifies whether SNMP should support authenticated messages. Authenticated messages have a timestamp which ensures that if a user intercepts the request and then tries to send it repeatedly, the request is ignored.

If set to true, then the event is hashed to ensure that the contents are not modified by a third party while in transit. The default is false.

You can edit this parameter from the 3rd Party SNMP Configuration > Use Authorization check box in the Administration > SNMP screen of the Mediator Administration console.

pg.snmp.userTarget.usePrivacySpecifies whether to use privacy. If set to true, the content is encrypted. The default is false.

You can edit this parameter from the 3rd Party SNMP Configuration > Use Privacy check box in the Administration > SNMP screen of the Mediator Administration console.

pg.snmp.userTarget.userNameSpecifies the user name for the SNMP server. Also known as the security name.

You can edit this parameter from the 3rd Party SNMP Configuration > User Name field in the Administration > SNMP screen of the Mediator Administration console.

pg.vsdTransformer.

pg.vsdTransformer.xslFilePathThis is an internal parameter. Do not modify.


pg.wrapperFactory.

pg.wrapperFactory.

pg.wrapperFactory.hostNameSpecifies the name or IP address of the machine on which CentraSite is running. The default is your-CS-host-name.

You can edit this parameter from the Host Name field on the Administration > CentraSite Communication page of the Mediator Administration console.

pg.wrapperFactory.registryPortSpecifies the port used to access the CentraSite registry. The default is 53305.

You can edit this parameter from the Registry Port field on the Administration > CentraSite Communication page of the Mediator Administration console.

pg.wrapperFactory.uddiPortSpecifies the port used for UDDI access to CentraSite. The default is 53307.

You can edit this parameter from the UDDI Port field on the Administration > CentraSite Communication page of the Mediator Administration console.

pg.wrapperFactory.userNameSpecifies the user name Mediator must use to access CentraSite. The default is your-CS-host-name\\your-CS-user-name.

You can edit this parameter from the User Name field on the Administration > CentraSite Communication page of the Mediator Administration console.


B Server Configuration Parameters

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

watt.debug. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

watt.net. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

watt.server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122


Introduction

Introduction

This appendix contains a description of the Mediator-specific parameters you can specify in the server configuration file (server.cnf), which is located in the IntegrationServer_directory\config directory. Typically you will use the Settings > Extended screen from the Integration Server Administrator to update this file, but there might be times when you need to edit the file directly using a text editor. If you edit the file directly, you should first shut down the Integration Server before updating the file. After you make your changes, restart the server.

watt.debug.

watt.debug.layoutSpecifies the format of messages written to the server’s log file and to the Logs > Server screen. For Mediator, you should set this parameter to new, which will cause the Integration Server journal logging component to print a stack trace when an Error-level message is logged from the calling code sent in the exception. For more information about watt.debug.layout, see Administering webMethods Integration Server.

watt.net.

watt.net.maxClientKeepaliveConnsSetting this parameter may improve Mediator’s performance when multiple threads are invoking a native service and all virtual service invocations are routing to the same endpoint. For more information about watt.net.maxClientKeepaliveConns, see Administering webMethods Integration Server.

watt.server.

watt.server.enablePGEnables Mediator to run on the Integration Server. This is set to true when Mediator is installed.

Important! You must ensure that this is set to true in order to run Mediator.


Index

Aaudit log

as an event destination 45in Transaction events 39

authorize against registered consumers 71authorize users 71

CCentraSite

communication with Mediator 24clustering

about communication 48about nodes 48load balancer URLs 50load balancers 49subscription endpoints 49

clusterscreating 51deploying virtual services 52deployment communication 55deployment state 53initialization 54leaving members 56load balancing 48metric and event notifications 57prerequisites 51processing interval 58reporting non-aggregated events 58role of the shared cache 53, 57senior node 57service requests 57synchronizing nodes 53synchronizing virtual services 52

communicationMediator and CentraSite 24

configuration settingsdescriptions 122

configuringdescription of all settings 122SAML 69

consumer applicationsmanual synchronization 31synchronization process 29

synchronizing 28–31synchronizing manually 88viewing deployed 88

consumer provisioning 18conventions used in this document 9

Ddeploying

virtual services 24design time

deploying 24disabling

SOAP-JMS triggers 101documentation

conventions used 9using effectively 9

Ee-mail notification. See SMTPenabling

SOAP-JMS triggers 101Error events

SNMP 37error events 37event destinations

audit log 45local log 45SMTP 45SNMP 44types 44

event notifications. See run-time eventsevent types

Error 37life cycle 37monitoring 40policy violation 38service level agreements 41transaction 39


Index

Iidentify consumer

and the require encryption policy action 73as a security policy action 72as an SLA action 42

is_jaas.cnf 69

Kkeystores

configuring 86

LLife Cycle events

SNMP 37life cycle events 37load balancer URLs 50load balancers 49load balancing

service providers 61through clustering 48without clustering 61

local logas an event destination 45

local log journalmonitoring events 40

log invocation policies 39log journal

transaction events 39

Mmediation 14Mediator. See webMethods Mediatormetrics

definition 34MIB

importing for a third-party server 81location 45

Monitoring eventsSMTP 40SNMP 40

monitoring eventsabout 40local log journal 40

Pperformance data reporting

about 34

data collected 35definition 34intervals 35losing data 36

policy enforcement 14about 17

policy violation events 38SNMP 38

prerequisitessecurity 65

program code conventions in this document 9

Rrequire encryption 73require HTTP basic token 68require signing 72require SSL 74require timestamps 74require WSS SAML token 69require WSS username token 68require WSS X.509 token 68run-time event notifications

error events 37life cycle events 37monitoring events 40policy violation events 38service level agreements 41transaction events 39

run-time event notifications. See run-time eventsrun-time events

event typessetting notifications 83SNMP destination 78

run-time policiestypes 34


Index

SSAML 69SamlAsserLoginModule 69screens

CentraSite configuration 77configuring e-mail 83configuring keystores 86configuring load balancer URLs 85configuring truststores 86Consumers 88Email 83General 85, 86HTTP protocols 85HTTPS protocols 85List of Mediator Consumer 88List of Mediator Services 87Mediator Configuration 85, 86Services 87SNMP configuration 78

securityprerequisites 65

security policy actionsauthorize against registered consumers 71authorize users 71identify consumer 72, 73require encryption 73require HTTP basic token 68require signing 72require SSL 74require timestamps 74require WSS SAML token 69require WSS username token 68require WSS X.509 token 68validate schema 74

senior node 57server configuration file. See server.cnfserver.cnf

description of settings 122location 122

service level agreementsabout 41alert destinations 44enforcing aggregated metrics 42enforcing non-aggregated metrics 43

service providersload balancing 61

shared cachedeploying virtual services 53

metric and event notifications 57synchronizing virtual services 53

SLAs. See service level agreementsSMTP

as an event destination 45configuring 83Monitoring events 40Transaction events 39

SNMPas an event destination 44configuring 78configuring Community type 82configuring User type 81Error events 37Life Cycle events 37MIB 45Monitoring events 40policy violation events 38run-time events 78setting a CentraSite destination 79setting a third-party destination 81transaction events 39

SOAP-JMS triggersadjusting thread usage 100disabling 101enabling 101state 101suspending 101thread usage 99

subscription endpointsin clusters 49

Subscription update processrecovery 26–28

subscription update processabout 26startup 26

suspendingSOAP-JMS triggers 101

synchronization processconsumer applications 29

synchronizingconsumer applications 28–31consumer applications manually 88virtual services 26virtual services manually 87


Index

Tthreads

for SOAP-JMS triggers 99, 100Transaction events

audit log 39SMTP 39

transaction events 39log invocation policies 39log journal 39SNMP 39

transport protocols 64truststores

configuring 86typographical conventions in this document 9

Vvalidate schema 74viewing

deployed consumer applications 88deployed virtual services 87

virtual service definitionsabout 20

virtual servicesabout 16benefits 20deploying 24deploying to clusters 52synchronization 21synchronizing 26synchronizing in clusters 52synchronizing manually 87undeploying 31viewing deployed 87virtual service definintions 20

VSDs. See virtual service definitions

Wwatt properties

watt.debug.layout 122watt.server.enablePG 122

watt.debug.layout 122watt.server.enablePG 122webMethods Integration Server

configuration settings 122webMethods Mediator

about 14communication with CentraSite 24

mediation 14policy enforcement 14

webMethodsESB.MIB. See MIB


8-0 administering mediator

Documents

dirwebmethods8integrationserverpackageswmmediatorconfigresources

decreasing

controlling

online discussion

root installation

main installation

software ag

time stamp