8-0 Administering Mediator

Title Page
Administering webMethods Mediator
Version 8.0
December 2009
Copyright & Document 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 AGs 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
Table of Contents
About This Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Documentation Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Online Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . What Is Mediator? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mediation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Policy Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mediator in the SOA Landscape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mediator Key Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service Virtualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Virtual Service Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Monitoring and Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Message Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Policy Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service Level Agreement Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security Policy Enforcement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Consumer Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Seamless Integration with CentraSite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Clustering Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mediator Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service Providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service Consumers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CentraSite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Virtual Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Virtual Service Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Virtual Service Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2. Deploying and Synchronizing Virtual Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Communication Between Mediator and CentraSite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deploying and Redeploying Virtual Services to Mediator . . . . . . . . . . . . . . . . . . . . . . . . . . Design-Time Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deployment Time Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9 9 10 13 14 14 14 14 15 16 16 17 17 17 17 17 17 18 18 18 19 19 19 19 20 20 21 23 24 24 24 24
Administering webMethods Mediator Version 8.0
Table of Contents
Synchronizing Virtual Service Subscription Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Subscription Update Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Updating Mediator at Start Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Subscription Notification Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Virtual Service Deployment Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Confirmation Deployment Message Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mediator Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Synchronizing Consumer Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Synchronization Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Synchronizing All Consumer Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Manual Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Undeploying Virtual Services in Mediator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Metrics and Events Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Metrics Reported by Mediator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Events Reported by Mediator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performance Data Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intervals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performance Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Losing Performance Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Run-Time Event Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Event Types Set on Mediator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Policy Violation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service Level Agreement Alerting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Identify Consumer Policy Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enforcing Policies Against Aggregated Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Alert Destinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Event Destinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SNMP Destinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SMTP (E-mail) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Local Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Audit Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. Clustering and Load Balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Nodes and Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Load Balancers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Subscription Endpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26 26 26 26 27 28 28 28 28 29 31 31 31 33 34 34 34 34 35 35 36 37 37 37 37 38 39 40 41 42 42 44 44 44 45 45 45 47 48 48 48 49 49
Table of Contents
Load Balancer URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a Mediated Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Integration Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring the Third-Party Load Balancer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Mediator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring CentraSite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deployment and Synchronization in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Role of the Shared Cache in Deployment and Synchronization . . . . . . . . . . . . . . . . . . Synchronizing Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deployment State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Communication During Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Communication During Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Communication When a Node Leaves a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Processing Service Requests in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Metric and Event Notification in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Role of the Shared Cache in Metrics and Events Notification . . . . . . . . . . . . . . . . . . . Senior Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Processing Interval . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reporting Non-Aggregated Run-Time Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reporting Performance Data and Aggregated Events in a Cluster . . . . . . . . . . . . . . . Load Balancing Service Providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Round-Robin Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Inactive Endpoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5. Enforcing Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Actions Mediator Enforces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transport Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CentraSite Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Integration Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mediator Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mediator Security Processesing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Selecting a Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multiple Security Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enforcing Authentication Policy Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Require HTTP Basic Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Require WSS Username Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Require WSS X.509 Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Require WSS SAML Token . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Run-Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50 51 51 52 52 52 52 53 53 53 54 55 56 57 57 57 57 58 58 59 61 62 62 63 64 64 64 65 65 65 65 66 66 66 68 68 68 68 69 69 69
Table of Contents
Enforcing Authorization Policy Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Authorize Users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Authorize Against Registered Consumers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Identify Consumer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enforcing XML Security Policy Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Require Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Require Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Responses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Identify Consumer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Require SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Require Timestamps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enforcing the Validate Schema Policy Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . When Security Policy Actions Are Violated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6. Configuring Mediator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Before Configuring Mediator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Communication with CentraSite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SNMP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting a CentraSite SNMP Destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting a Third-Party SNMP Destination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting Event Notification Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-mail Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HTTP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Keystore Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing and Synchronizing Services Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Synchronizing Consumer Applications Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7. Configuring SOAP Over JMS Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring SOAP-JMS Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a SOAP-JMS Web Service Endpoint Alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a SOAP-JMS Provider Web Service Endpoint Alias . . . . . . . . . . . . . . . . . . . Creating a SOAP-JMS Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a SOAP-JMS Consumer Web Service Endpoint Alias . . . . . . . . . . . . . . . . . . About Managing SOAP-JMS Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Controlling Thread Usage for SOAP-JMS Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing Thread Usage for SOAP-JMS Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Increasing or Decreasing Thread Usage for All Triggers . . . . . . . . . . . . . . . . . . . . . . . Enabling, Disabling, and Suspending SOAP-JMS Triggers . . . . . . . . . . . . . . . . . . . . . . . . . Built-In Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71 71 71 72 72 72 73 73 73 73 74 74 74 74 75 76 76 77 78 79 81 83 83 85 86 87 88 91 92 92 93 94 94 96 99 99 99 100 101 103
A. Advanced Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 pg.3pSnmpSender. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Table of Contents
pg.CollectionPool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.CollectionWorkQueue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.cs.snmpTarget. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.csSnmpSender. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.debug. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.delayedRefresher. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.email. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.IntervalPool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.jaxbFileStore. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.keystore. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.lb. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.passman. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.PgMenConfiguration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.PgMenSharedCacheManager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.PgMetricsFormatter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.policygateway. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.proxyLoader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.rampartdeploymenthandler. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.ReportingPool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.ReportingWorkQueue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.serviceReader. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.snmp.communityTarget. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.snmp.customTarget. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.snmp.userTarget. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.vsdTransformer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.wrapperFactory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B. Server Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . watt.debug. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . watt.net. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . watt.server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
106 106 107 109 109 109 109 111 111 111 111 112 112 113 113 113 114 114 114 115 115 115 117 117 119 120 121 122 122 122 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
Convention Bold Narrow font UPPERCASE Italic Description Identifies elements on a user interface. Identifies storage locations for services on webMethods Integration Server, using the convention folder.subfolder:service. Identifies keyboard keys. Keys you must press simultaneously are joined with a plus sign (+). 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. 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 (...).
Monospace font
{} | [] ...
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. For webMethods... 6.x The documentation is downloaded to... The installation directory of each product.
About This Guide
For webMethods... 7.x 8.x
The documentation is downloaded to... A central directory named _documentation in the main installation directory (webMethods by default). A central directory named _documentation in the main installation directory (Software AG by default).
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. If you want to... Access the latest version of product documentation. 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. Go to... Software AG Documentation Web site http://documentation.softwareag.com Empower Product Support Web site https://empower.softwareag.com
10
About This Guide
If you want to... 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.
Go to... Software AG Developer Community for webMethods http://communities.softwareag.com/ webmethods
11
About This Guide
12
Introduction
14 15 16 19
What Is Mediator? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mediator in the SOA Landscape . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mediator Key Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mediator Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
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 AGs 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 WSAddressing) 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
14
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.
15
Mediator Key Capabilities
Mediator in the system
Step 1 2 3 4 5 6
Description A service consumer makes a call to a Web service running on a service provider. The virtual service running on Mediator receives and processes the message. The message is sent to the service provider. The service provider retrieves the required data or performs the proper task. The service provider, through the native service, sends the requested data back through Mediator to the consumer application. Throughout the process, Mediator sends monitoring data through SNMP traps, e-mail, and other means, to CentraSite.

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.
16
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.
17
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.
18
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 CentraSites communication with Mediator, see Communication Between Mediator and CentraSite on page 24.
19
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.
20
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 services 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.
21
Mediator Components
22
Deploying and Synchronizing Virtual Services

24 24 26 28 31
Communication Between Mediator and CentraSite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deploying and Redeploying Virtual Services to Mediator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Synchronizing Virtual Service Subscription Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Synchronizing Consumer Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Undeploying Virtual Services in Mediator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
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 2 You create a virtual service and run-time policy. The service and the policy are stored in the CentraSite repository as assets. 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 services deployment state.
24
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 1 2 3 4
Description When a user deploys or reploys a virtual service, CentraSite uses a notification message to notify Mediator. Mediator retrieves the VSD. Mediator checks the VSD and deploys or redeploys the virtual service. 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.
25
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 services 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
26
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
27
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.
28
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.
29
Consumer Application Synchronization
Step 1
Description 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 3
Mediator queries CentraSite for any changes to consumer applications that occurred during the coverage period of the notification. 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. CentraSite sends the updated consumer application information back to Mediator. Mediator updates the consumer applications accordingly.
4 5
30
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.
31
Undeploying Virtual Services in Mediator
Undeployment Interactions Between CentraSite and Mediator
Step 1 2 3
Description CentraSite sends an undeploying request to Mediator. Mediator undeploys the virtual service and removes the VSD. Mediator responds to CentraSite with a message to confirm that the service is undeployed.
32
Metrics and Events Notification

34 34 37 41 44
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performance Data Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Run-Time Event Notifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Service Level Agreement Alerting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Event Destinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
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.
34
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 Total Request Count Success Count Fault Count Minimum Response Time Reports... The total number of requests for each service running in Mediator for the current interval. The number of successful service invocations for the current interval. The number of failed invocations for the current interval. 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.
35
Performance Data Reporting
Metric Maximum Response Time
Reports... 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. 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.
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. 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.
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.
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.
36
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: Parameter Mediator name Transaction date Status Alert description Indicates... The name of the Mediator instance reporting the event. The date the error occurred. Whether Mediator started or shut down. A description of the event.
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.
37
Error events report the following data: Parameter Run-time session Target name Contract name Consumer Reports... The SOAP invocation session in which the event occurred. The name of the Mediator instance reporting the event. The service against which the event was logged. 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 Transaction date Run-time error source Run-time error description The IP address of the consumer. The time stamp showing the date and time the event occurred. The source of the error. A description of the error.
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 Run-time session Target name Contract name Reports... The SOAP invocation session in which the event occurred. The name of the Mediator instance reporting the event. The service against which the event was logged.
38
Parameter Consumer
Reports... 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 Transaction date Run-time alert source Run-time alert type Run-time alert description
The IP address of the consumer. The time stamp showing the date and time the event occurred. The source of the error. The policy violation event type. The policy violation message.
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: Parameter Run-time session Contract name Target name Reports... The SOAP invocation session in which the event occurred. The name of the service against which the event was logged. The name of the Mediator instance reporting the event.
39
Parameter Transaction date Consumer
Reports... The time stamp showing the date and time the event occurred. The service consumer. 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 Request status Response payload (optional) Request payload (optional) Provider round trip time
The IP address of the service consumer. Whether the transaction resulted in success or failure. The SOAP envelope and contents of the response payload.
The SOAP envelope and contents of the request payload.
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. 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.
Total round trip time
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.
40
Mediator sends the following parameters as part of a monitoring event: Parameter Run-time session Target name Contract name Consumer Reports... The SOAP invocation session in which the event occurred. The name of the Mediator instance reporting the event. The name of the service against which the event was logged. The service consumer. 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 Transaction date Monitored attribute The IP address of the service consumer. The time stamp showing the date and time the event occurred. 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. The name of the policy action from which it originated. The monitoring event type. This can be either monitor or sla. The message describing the event.
Run-time alert source Run-time alert type Run-time alert description
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 services 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.
41
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 Minimum Response Time Reports... 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. Note: This parameter does not include metrics for failed invocations.
42
Metric Average Response Time
Reports... 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. Note: This parameter does not include metrics for failed invocations.
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.
Enforcing Policies Against Non-Aggregated Metrics

For 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: Metric Total Request Count Success Count Fault Count Reports... The total number of requests for each service running in Mediator for the current interval. The number of successful service invocations for the current interval. The number of failed invocations for the current interval.
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
43
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.
44
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.
45
Event Destinations
46
Clustering and Load Balancing

48 48 48 49 51 52 57 57 61
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Nodes and Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Load Balancers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a Mediated Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deployment and Synchronization in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Processing Service Requests in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Metric and Event Notification in a Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Load Balancing Service Providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
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 Mediators 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.
48
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.
49
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.
50
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

Mediators cluster implementation is built upon the Integration Servers cluster support. You must configure the Integration Servers in the cluster as described in the webMethods Integration Server Clustering Guide.
51
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.
52
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.
53
Clusters use the following deployment states: A deployment state of... Initializing Indicates that... 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 Resynching The cluster is in synch and is not performing any in-process deployment. 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.
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 nonsynchronizing nodes can then refresh from the shared cache.
54
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
55
Step 1 2
Description The synchronizing node receives the VSD or consumer application information from CentraSite. The synchronizing node: a b c d Locks the deployment state. Changes the deployment state from running to either initializing or resynching to reflect the current operation. Performs the deployment operation. Changes the deployment state to Running and releases the deployment state lock.
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.
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: If the deployment state is... Initializing Resynching Running 2 The node... Makes itself the running node and performs a full synchronization with CentraSite. Updates the deployment state to Running, which stops the current synchronization. Does nothing.
The lock on the deploy state is released.
56
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 runtime 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.
57
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.
58
Non-aggregated events processed in this way are: Error Policy violation Life Cycle Reporting Non-Aggregated Events in a Cluster
Step 1 2
Description The node produces an event. The node reports the event to CentraSite.
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.
59
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 nodes 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 1 2 3
Description The aggregated events or metrics are produced by nodes in the cluster. Each node that collected the events and metrics publishes them to the shared cache. 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. The first node to respond to the senior nodes notification processes the event or metrics and reports them to CentraSite.
60
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
61
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 roundrobin 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.
62
Enforcing Security Policies

64 65 66 68 71 72 74 74
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mediator Security Processesing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enforcing Authentication Policy Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enforcing Authorization Policy Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enforcing XML Security Policy Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enforcing the Validate Schema Policy Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . When Security Policy Actions Are Violated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
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 transportlevel 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
64
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.
65
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 2 If a signing certificate was included in the message, Mediator uses the same certificate to sign the response/request. 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 5 6 The WSS-Username token in the security header. Mediator will use this to look up a certificate with that alias. 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. 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.
66
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: If... the mustUnderstand attribute of the first security element is set to 1 (true) Mediator... 1 2 Ignores all other security elements in the request. 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.
Removes the security element from the request or response before sending it to the service provider or consumer. Sends an event if configured to do so and the policy is violated. Ignores all other security elements in the request. Performs one of the following.
4 the mustUnderstand attribute of the first security element is set to 0 (false) 1 2
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.
Removes the security element from the request or response before sending it to the service provider or consumer. Sends an event if configured to do so and the policy is violated.
Note: Mediator ignores all but the first security element.
67
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.
68
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 2 Open the following file: install-dir\conf\is_jaas.cnf 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"
69
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... issuers Specify... 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. You must list the clock differences in the same order as the corresponding issuer listed in the issuers option.
issuers_clock_skew
A comma-separated list of the clock differences between you and each of your SAML issuers. You must list the clock differences in the same order as the corresponding issuer listed in the issuers option.
70
This option... verifySignature
Specify... 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.
4 5
Save the file. 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.
71
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.
72
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 2 3 4 A signing certificate Consumer name WSS username, SAML token, or X.509 certificate HTTP authorized user
73
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.
74
76 76 77 78 83 85 86 87 88
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Before Configuring Mediator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Communication with CentraSite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SNMP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . E-mail Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HTTP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Keystore Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing and Synchronizing Services Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Synchronizing Consumer Applications Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
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. Ensure that you have webMethods administrator privileges so that you can access Mediators administrative screens. For information about setting user privileges, see Administering webMethods Integration Server. 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. Verify that the Mediator user has the following permissions:

Read/write permissions on the virtual services and consumer applications Permission to store performance data
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.
76
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 2 3 4 5 6 Open the Integration Server Administrator if it is not already open. In the Navigation panel, select Solutions > Mediator. In Mediator, select Administration > CentraSite Communication. On the CentraSite Configuration screen, click Edit. In the CentraSite Configuration area, select the Synchronize with CentraSite check box. Set the CentraSite Configuration parameters as follows: For this parameter... Host Name Registry Port UDDI Port Target Name User Name Specify... The name or IP address of the machine on which CentraSite is running. The port used to access the CentraSite registry. The port used for UDDI access to CentraSite. The name of the Mediator configured as a target in CentraSite. This name must match the target name defined in CentraSite. The user name Mediator must use to access CentraSite. Use the following format:
CS-hostname\user-name
Password Retype Password
The password Mediator must use to access CentraSite. The same password you entered in the Password field to verify that you entered it correctly.
77
SNMP Configuration
For this parameter... Report Performance Data
Specify... 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.
Click Test Connection. If the parameters you entered are... Correct Then... 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. 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
78
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 1 2 3 4 5 6 Open the Integration Server Administrator if it is not already open. In the Navigation panel, select Solutions > Mediator. In Mediator, select Administration > SNMP. On the SNMP Configuration screen, click Edit. Under CentraSite SNMP Configuration, select the Send TRAPs to CentraSite check box. Set the CentraSite SNMP Configuration parameters as follows: For this parameter... Host Name/IP Address Specify... 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. The SNMP trap receiver port on theCentraSite server that is listening for SNMP requests and packets. The protocol used by SNMP to send traps. This can be either TCP or UDP. The default is TCP.
Port Transport
79
SNMP Configuration
For this parameter... User Name
Specify... 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) Authorization Password Retype Authorization Password Authorization Protocol
Whether an authorization key is required. The default is off. The password to be used for authorization. This must also be configured on the SNMP server. The same password you entered in the Authorization Password field to verify that you entered the password correctly. The authorization protocol to use. Mediator supports the following values: MD5 (default) SHA
Use Privacy (optional) Privacy Password Retype Privacy Password Privacy Protocol
Whether a privacy (encryption) key is required. The default is off. The key to be used for privacy. The same privacy password you entered in the Privacy Password field to verify that you entered the password correctly. The privacy protocol to use. Mediator supports the following values: DES (default) AES128 AES192 AES256
Click Save. Your changes take effect immediately.
80
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 Mediators 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 Mediators 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 1 2 3 4 5 6 7 Open the Integration Server Administrator if it is not already open. In the Navigation panel, select Solutions > Mediator. In Mediator, select Administration > SNMP. On the SNMP Configuration screen, click Edit to make the values available for editing. Under 3rd Party SNMP Configuration, select the Send TRAPs to 3rd party SNMP Server check box. For SNMP Target Type, click User. Set the 3rd Party SNMP Configuration parameters as follows: For this parameter... Host Name/IP Address Port Transport Specify... The name or IP address of the third-party SNMP server. The SNMP trap receiver port that is listening for SNMP requests and packets. The protocol used by SNMP to send traps. This can be either TCP or UDP. The default is TCP.
81
SNMP Configuration
For this parameter... User Name Use Authorization (optional) Authorization Password Retype Authorization Password Use Privacy (optional) Privacy Password Retype Privacy Password 8 Click Save.
Specify... The SNMPv3 user name to use when connecting to the receiver. Whether an authorization key is required. It is set to off by default. The key to be used for authorization. This must also be configured on the SNMP server. The same password you entered in the Authorization Password field to verify that you entered it correctly. This flag indicates whether a privacy (encryption) key is required. It is set to off by default. The key to be used for privacy. The same password you entered in the Privacy Password field to verify that you entered it correctly.
Your changes take effect immediately. To configure third-party SNMP server using the Community target type 1 2 3 4 5 6 7 Open the Integration Server Administrator if it is not already open. In the Navigation panel, select Solutions > Mediator. In Mediator, select Administration > SNMP. On the SNMP Configuration screen, click Edit to make the values available for editing. Under 3rd Party SNMP Configuration, select the Send TRAPs to 3rd party SNMP Server check box. For SNMP Target Type, click Community. Provide the following information: For this parameter... Host Name/IP Address Port Specify... The name or IP address of the third-party SNMP server. The SNMP trap receiver port that is listening for SNMP requests and packets.
82
For this parameter... Transport Community Name
Specify... The protocol used by SNMP to send traps. This can be either TCP or UDP. The default is TCP. 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.
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 1 2 3 Open the Integration Server Administrator if it is not already open. In the Navigation panel, select Solutions > Mediator. Under Publish Events on the SNMP Configuration screen, select one or more of the following parameters to define which events to publish: Select... Lifecycle Error Policy Violation 4 Click Save. Your changes take effect immediately. To report... Life cycle events such as Mediator startup and shutdown. Run-time error events that occur during a virtual service invocation. Run-time policy assertion violations that occur during a virtual service invocation.
E-mail Configuration
You can configure Mediator to send events to an SMTP mail server as e-mail messages.
83
E-mail Configuration
To configure event notification through e-mail 1 2 3 4 5 Open the Integration Server Administrator if it is not already open. In the Navigation panel, select Solutions > Mediator. In Mediator, select Administration > Email. On the Email Configuration screen, click Edit. Under Email Configuration, set the parameters as follows: For this parameter... SMTP Host Name/IP Address Port User Password Retype Password From Specify... The address of the SMTP server to be used by Mediator for sending e-mail alerts. The port on which the SMTP server is listening. The user name of the e-mail account used to log into your SMTP server. The password of the e-mail account used to log into your SMTP server. The same password you entered in the Password field to verify that you entered it correctly. 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 email 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 email.
84
To test your connection, enter an e-mail address in the Test Recipient field and click Test. If the configuration is... Successful Then... 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.
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 1 2 3 4 Open the Integration Server Administrator if it is not already open. In the Navigation panel, select Solutions > Mediator. In Mediator, select Administration > General. On the Mediator Configuration screen, click Edit.
85
Keystore Configuration
Under HTTP Config, set the parameters as follows: For this parameter... Load Balancer URL (HTTP) Specify... 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 http://hostname:portnumber
or
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 https://hostname:portnumber
or
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. 6 Click Save. Your changes take effect immediately.
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.
86
To configure keystore information 1 2 3 4 5 Open the Integration Server Administrator if it is not already open. In the Navigation panel, select Solutions > Mediator. In Mediator, select Administration > General. On the Mediator Configuration screen, click Edit to make the values available for editing. Under Keystore Config, set the parameters as follows: For this parameter... IS Keystore Name Specify... 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. 6 Click Save. Your changes take effect immediately.
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.
87
Synchronizing Consumer Applications Manually
To view and synchronize services 1 2 3 4 5 Open the Integration Server Administrator if it is not already open. In the Navigation panel, select Solutions > Mediator. In Mediator, click Services. For any service in the list, click VSD to view the virtual service definition or WSDL to view the WSDL file for the service. Manually synchronize the virtual services with CentraSite by performing one of the following actions: Click... Sync All To manually synchronize... 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

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 1 2 3 Open the Integration Server Administrator if it is not already open. In the Navigation panel, select Solutions > Mediator. In Mediator, click Consumers.
88
View the details of consumer applications synchronized with CentraSite by performing one of the following actions: Click... All or Expand To view the details of... All of the consumer applications synchronized to Mediator. An individual consumer application synchronized to Mediator. Note: To hide all consumer application details, click Collapse All. To hide the details for an individual consumer application, click .
To synchronize consumer applications 1 2 3 4 Open the Integration Server Administrator if it is not already open. In the Navigation panel, select Solutions > Mediator. In Mediator, click Consumers. Click Sync All Consumer Apps.
89
90
Configuring SOAP Over JMS Protocols

92 92 93 99 99 101 103
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring SOAP-JMS Messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a SOAP-JMS Web Service Endpoint Alias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . About Managing SOAP-JMS Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Controlling Thread Usage for SOAP-JMS Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enabling, Disabling, and Suspending SOAP-JMS Triggers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Built-In Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
Overview
Overview
Mediator supports sending SOAP over JMS (SOAP-JMS) messages between Web services. Mediators 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. Use the JMS service provider to create request and response queues. For more information, see the documentation for your JMS service provider. Specify the JMS client libraries in the Integration Server classpath so that Mediator is able to communicate with the JMS service provider.
2 3
92
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. 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.
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 8
If necessary, edit the SOAP-JMS trigger to better suit your environment. For more information, see About Managing SOAP-JMS Triggers on page 99. 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.
93
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 services 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 2 3 4 Open Integration Server Administrator if it is not already open. In the Navigation panel, select Settings > Web Services. Click Create Web Service Endpoint Alias. Under Web Service Endpoint Alias Properties, provide the following information: In this field... Alias Specify... 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 Type Transport Type 5 A description for the endpoint alias. Provider JMS
Under JMS Transport Properties, provide the following information: In this field... SOAP-JMS trigger Name Delivery Mode (optional) Specify... WS Endpoint Trigger. Integration Server populates this field automatically with all valid SOAP-JMS trigger names. Whether the JMS transport should be Persistent or Non_Persistent.
94
In this field... Time to Live (optional) Priority (optional) Reply To Name (optional) Reply To Type (optional)
Specify... The amount of time (in milliseconds) before a message expires. If set to zero, the message does not expire. The messages priority in the queue. You can specify a number from 0 to 9, where 0 is the lowest priority and 9 is the highest. The name or lookup name of the JMS destination where a reply to the message should be sent. 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.
Under JMS WSDL Options, provide the following information: In this field... Include Connection Factory Name in JMS URI Include JNDI Parameters in JMS URI Specify... Whether to include the connection factory name in the generated WSDL. Whether to include the JNDI parameters in the generated WSDL.
Under WS Security Properties, if the inbound SOAP request must be decrypted and/or the outbound SOAP request must be signed, do the following: In this field... Keystore Alias Specify... 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.
95
Under WS Security Properties, if the signing certificate chain of an inbound signed SOAP message has to be validated, specify the following: In this field... Truststore Alias Specify... The alias for the truststore that contains the list of CA certificates that Integration Server uses to validate the trust relationship.
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 1 2 3 Open Integration Server Administrator if it is not already open. In the Navigation panel, select Settings > Web Services. Click Create Web Service Endpoint Alias.
96
Under Web Service Endpoint Alias Properties, provide the following information: In this field... Alias Specify... A name for the provider Web service endpoint alias. The alias name cannot include the following illegal characters: # \ & @ ^ ! % * : $ . / \ \ ` ; , ~ + = ) ( | } { ] [ > < " Description Type Transport Type A description for the endpoint alias. Consumer JMS
Under JMS Transport Properties, provide the following information: In this field... Connect Using JNDI Provider Alias Connection Factory Name Specify... JNDI Properties The name of the JNDI provider alias. The connection factory JNDI lookup name.
Under WS Security Properties, provide the following information: In this field... User Name Password Retype Password Partners Certificate Keystore Alias Key Alias Specify... User name used to authenticate the consumer at the JMS transport level on the host server. The password used to authenticate the consumer on the host server. Re-enter the above password. The path and file name of the providers certificate, which contains its public key. The alias of the keystore that contains the private key used to connect to the Web service host securely. 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. The alias for the truststore that contains the list of CA certificates that Integration Server uses to validate the trust relationship.
Truststore Alias 7
Click Save Changes.
97
To create a JMS consumer Web service endpoint alias that includes a JMS connection alias 1 2 3 4 Open Integration Server Administrator if it is not already open. In the Navigation panel, select Settings > Web Services. Click Create Web Service Endpoint Alias. Under Web Service Endpoint Alias Properties, provide the following information: In this field... Alias Specify... A name for the provider Web service endpoint alias. The alias name cannot include the following illegal characters: # \ & @ ^ ! % * : $ . / \ \ ` ; , ~ + = ) ( | } { ] [ > < " Description Type Transport Type 5 A description for the endpoint alias. Consumer JMS
Under JMS Transport Properties, provide the following information: In this field... Connect Using JMS Connection Alias Specify... JMS Connection Alias The name of the JMS connection alias.
Under WS Security Properties, provide the following information: In this field... User Name Password Retype Password Partners Certificate Keystore Alias Specify... User name used to authenticate the consumer at the JMS transport level on the host server. The password used to authenticate the consumer on the host server. Re-enter the above password. The path and file name of the providers certificate, which contains its public key. The alias of the keystore that contains the private key used to connect to the Web service host securely.
98
In this field... Key Alias
Specify... 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. The alias for the truststore that contains the list of CA certificates that Integration Server uses to validate the trust relationship.
Truststore Alias 7
Click Save Changes.
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 1 2 3 Open the Integration Server Administrator if it is not already open. In the Settings menu of the Navigation panel, click Messaging. Click JMS Trigger Management.
99
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 1 2 3 4 5 Open the Integration Server Administrator if it is not already open. In the Settings menu of the Navigation panel, click Messaging. Click JMS Trigger Management. Click Edit JMS Global Trigger Controls. 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. 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. 7 Click Save Changes. 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 SOAPJMS triggers.
100
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: Trigger State Enabled Description The SOAP-JMS trigger is running and connected to the JMS provider. Integration Server retrieves and processes messages for the SOAP-JMS trigger. The SOAP-JMS trigger is stopped. Integration Server neither retrieves nor processes messages for the SOAP-JMS trigger. 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.
Disabled Suspended
Using the Integration Server Administrator, you can: Enable, disable, or suspend all SOAP-JMS triggers. Enable, disable, or suspend specific SOAP-JMS triggers.
101
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 1 2 3 4 Open the Integration Server Administrator if it is not already open. In the Settings menu of the Navigation panel, click Messaging. Click JMS Trigger Management. If you want to change the state of all SOAP-JMS triggers, do the following: a b 5 Under Individual SOAP JMS Trigger Controls, in the Enabled column, click edit all. 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. 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 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.
If you want to change the state of a specific SOAP-JMS trigger, do the following: a b
Click Save Changes.
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.
102
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 SOAPJMS 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 SOAPJMS 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.
103
Built-In Services
104
Advanced Settings
106 106 106 106 107 109 109 109 109 111 111 111 111 112 112 113 113 113 114 114 114 115 115 115 117 117 119 120
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.3pSnmpSender. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.CollectionPool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.CollectionWorkQueue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.cs.snmpTarget. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.csSnmpSender. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.debug. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.delayedRefresher. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.email. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.IntervalPool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.jaxbFileStore. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.keystore. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.lb. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.passman. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.PgMenConfiguration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.PgMenSharedCacheManager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.PgMetricsFormatter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.policygateway. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.proxyLoader . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.rampartdeploymenthandler. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.ReportingPool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.ReportingWorkQueue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.serviceReader. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.snmp.communityTarget. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.snmp.customTarget. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.snmp.userTarget. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.vsdTransformer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . pg.wrapperFactory. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
105
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.sendDelay This is an internal parameter. Do not modify.
pg.CollectionPool.
pg.CollectionPool.minThreads Sets the minimum number of threads Mediator Event Engine data collection work queue minimum thread count. The default is 1. pg.CollectionPool.maxThreads Sets the maximum number of threads used for the data collection work queue. The default is 8. pg.CollectionPool.forcefulShutdown Specifies 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.poolName Sets the name for the data collection thread pool. The default is CollectionPool.
pg.CollectionWorkQueue.
pg.CollectionWorkQueue.queueCapacity Sets the capacity available for data collection tasks stored in the memory work queue. The default is 10000.
106
Advanced Settings
pg.cs.snmpTarget.
These properties specify the settings for Mediator to use the CentraSite SNMPv3 userbased 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.authProtocol Sets 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.base64Encoded This is an internal parameter. Do not modify. pg.cs.snmpTarget.connTimeout Specifies 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.ipAddress Sets 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.maxRequestSize Specifies the maximum size (in bytes) for SNMP traps. The default is 10485760. pg.cs.snmpTarget.port Sets 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.
107
pg.cs.snmpTarget.
pg.cs.snmpTarget.privProtocol Sets 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.retries Specifies 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.sendTimeOut Specifies 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 timeout 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.sendTraps Specifies 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.transportProtocol Sets 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.useAuth Specifies 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.
108
Advanced Settings
pg.cs.snmpTarget.usePrivacy Specifies 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.userName Sets 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.sendDelay This is an internal parameter. Do not modify.
pg.debug.
pg.debug.eventLoggerActive This 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 Servers status. pg.delayedRefresher.napMillis Specifies 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.charset Specifies 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.debug This is an internal parameter. Do not modify.
109
pg.email.
pg.email.from Specifies 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.resourceMimeType Specifies 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.SenderActive Specifies 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.smtpHost Specifies 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.smtpPort Specifies 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.timeOut Specifies the time out period (in milliseconds) when connecting to an e-mail server and sending e-mails. The default is 1000. pg.email.TLSEnabled Specifies 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.
110
Advanced Settings
pg.email.userName Specifies 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.minThreads Specifies the minimum thread count for this interval pool. The default is 1. pg.IntervalPool.maxThreads Specifies the maximum thread count for this interval pool. The default is 1. pg.IntervalPool.forcefulShutdown Specifies 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.poolName Specifies the name of the interval processor pool. The default is IntervalPool.
pg.jaxbFileStore.
pg.jaxbFileStore.consumerFileStore Specifies 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.keyStoreHandle This is an internal parameter. Do not modify. pg.keystore.trustStoreHandle This is an internal parameter. Do not modify.
pg.lb.
pg.lb.http.url Specify 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.
111
pg.passman.
pg.lb.https.url Specify 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.configFile This is an internal parameter. Do not modify.
pg.PgMenConfiguration.
pg.PgMenConfiguration.perfDataEnabled Specifies 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.publishErrorEvents Specifies 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.publishLifeCycleEvents Specifies 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.publishPolicyViolationEvents Specifies 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.reportInterval Specifies 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.
112
Advanced Settings
pg.PgMenConfiguration.sieFlushInterval Specifies the number of seconds before the accumulated invoked service events are pushed into the shared cache. The default is 10. pg.PgMenConfiguration.tickInterval Specifies 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.lockRetry Specifies the number of times Mediator attempts to obtain a lock on metrics data in the shared cache. The default is 1. pg.PgMenSharedCacheManager.lockTimeOut Specifies 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.includeFaults Specifies 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.targetName Sets 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.disableCsComm Specifies 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.
113
pg.proxyLoader
pg.policygateway.repositoryLocation This is an internal parameter. Do not modify.
pg.proxyLoader
pg.proxyLoader.proxyLocation This is an internal parameter. Do not modify.
pg.rampartdeploymenthandler.
pg.rampartdeploymenthandler.signingCertAlias Specifies 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.usernameTokenUser This 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.minThreads Specifies 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.maxThreads Specifies 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.forcefulShutdown Specifies 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.poolName Specifies the name of the reporting pool. The default is ReportingPool.
114
Advanced Settings
pg.ReportingWorkQueue.
pg.ReportingWorkQueue.queueCapacity Sets 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.interval This is an internal parameter. Do not modify.
pg.snmp.communityTarget.
These parameters are used only when you have set pg.snmp.customTarget to community. Note: All SNMP settings must match those of the SNMP server. The settings must match what the server is set to receive. pg.snmp.communityTarget.base64Encoded Specifies 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.communityName Specifies 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.transportProtocol Specifies 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.
115
pg.snmp.communityTarget.
pg.snmp.communityTarget.ipAddress Specifies the IP address of the host running the SNMP server. 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. 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.port Specifies 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.retries Specifies 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.sendTimeOut Specifies 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 timeout 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.maxRequestSize Specifies the maximum size (in bytes) for SNMP traps. The default is 65535.
116
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.customTarget Specifies which third-party SNMP security model Mediator should use. Valid values are: communityTarget (default)For SNMPv1 community-based security. For communitybased parameters, see pg.snmp.communityTarget. userTargetFor 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.connTimeout Specifies 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.sendTraps Specifies 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. Note: All SNMP settings must match those of the SNMP server. The settings must match what the server is set to receive. pg.snmp.userTarget.authProtocol Specifies 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.
117
pg.snmp.userTarget.
pg.snmp.userTarget.ipAddress Specifies the IP address of the SNMP server. 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. 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.maxRequestSize Specifies the maximum size (in bytes) for SNMP traps. The default is 65535. pg.snmp.userTarget.port Specify 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.privProtocol Specifies 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.retries Specifies 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.sendTimeOut Specifies 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 timeout 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.
118
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.transportProtocol Specifies 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.useAuth Specifies 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.usePrivacy Specifies 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.userName Specifies 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.xslFilePath This is an internal parameter. Do not modify.
119
pg.wrapperFactory.
pg.wrapperFactory.
pg.wrapperFactory.hostName Specifies 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.registryPort Specifies 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.uddiPort Specifies 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.userName Specifies the user name Mediator must use to access CentraSite. The default is your-CShost-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.
120
Server Configuration Parameters

122 122 122 122
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . watt.debug. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . watt.net. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . watt.server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
121
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.layout Specifies the format of messages written to the servers 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.maxClientKeepaliveConns Setting this parameter may improve Mediators 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.enablePG Enables 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.
122
Index
A
audit log as an event destination 45 in Transaction events 39 authorize against registered consumers 71 authorize users 71 synchronizing 2831 synchronizing manually 88 viewing deployed 88 consumer provisioning 18 conventions used in this document 9
D
deploying virtual services 24 design time deploying 24 disabling SOAP-JMS triggers 101 documentation conventions used 9 using effectively 9
C
CentraSite communication with Mediator 24 clustering about communication 48 about nodes 48 load balancer URLs 50 load balancers 49 subscription endpoints 49 clusters creating 51 deploying virtual services 52 deployment communication 55 deployment state 53 initialization 54 leaving members 56 load balancing 48 metric and event notifications 57 prerequisites 51 processing interval 58 reporting non-aggregated events 58 role of the shared cache 53, 57 senior node 57 service requests 57 synchronizing nodes 53 synchronizing virtual services 52 communication Mediator and CentraSite 24 configuration settings descriptions 122 configuring description of all settings 122 SAML 69 consumer applications manual synchronization 31 synchronization process 29
E
e-mail notification. See SMTP enabling SOAP-JMS triggers 101 Error events SNMP 37 error events 37 event destinations audit log 45 local log 45 SMTP 45 SNMP 44 types 44 event notifications. See run-time events event types Error 37 life cycle 37 monitoring 40 policy violation 38 service level agreements 41 transaction 39
123
Index
I
identify consumer and the require encryption policy action 73 as a security policy action 72 as an SLA action 42 is_jaas.cnf 69
K
keystores configuring 86
data collected 35 definition 34 intervals 35 losing data 36 policy enforcement 14 about 17 policy violation events 38 SNMP 38 prerequisites security 65 program code conventions in this document 9
L
Life Cycle events SNMP 37 life cycle events 37 load balancer URLs 50 load balancers 49 load balancing service providers 61 through clustering 48 without clustering 61 local log as an event destination 45 local log journal monitoring events 40 log invocation policies 39 log journal transaction events 39
R
require encryption 73 require HTTP basic token 68 require signing 72 require SSL 74 require timestamps 74 require WSS SAML token 69 require WSS username token 68 require WSS X.509 token 68 run-time event notifications error events 37 life cycle events 37 monitoring events 40 policy violation events 38 service level agreements 41 transaction events 39 run-time event notifications. See run-time events run-time events event types setting notifications 83 SNMP destination 78 run-time policies types 34
M
mediation 14 Mediator. See webMethods Mediator metrics definition 34 MIB importing for a third-party server 81 location 45 Monitoring events SMTP 40 SNMP 40 monitoring events about 40 local log journal 40
P
performance data reporting about 34
124
Index
S
SAML 69 SamlAsserLoginModule 69 screens CentraSite configuration 77 configuring e-mail 83 configuring keystores 86 configuring load balancer URLs 85 configuring truststores 86 Consumers 88 Email 83 General 85, 86 HTTP protocols 85 HTTPS protocols 85 List of Mediator Consumer 88 List of Mediator Services 87 Mediator Configuration 85, 86 Services 87 SNMP configuration 78 security prerequisites 65 security policy actions authorize against registered consumers 71 authorize users 71 identify consumer 72, 73 require encryption 73 require HTTP basic token 68 require signing 72 require SSL 74 require timestamps 74 require WSS SAML token 69 require WSS username token 68 require WSS X.509 token 68 validate schema 74 senior node 57 server configuration file. See server.cnf server.cnf description of settings 122 location 122 service level agreements about 41 alert destinations 44 enforcing aggregated metrics 42 enforcing non-aggregated metrics 43 service providers load balancing 61 shared cache deploying virtual services 53
metric and event notifications 57 synchronizing virtual services 53 SLAs. See service level agreements SMTP as an event destination 45 configuring 83 Monitoring events 40 Transaction events 39 SNMP as an event destination 44 configuring 78 configuring Community type 82 configuring User type 81 Error events 37 Life Cycle events 37 MIB 45 Monitoring events 40 policy violation events 38 run-time events 78 setting a CentraSite destination 79 setting a third-party destination 81 transaction events 39 SOAP-JMS triggers adjusting thread usage 100 disabling 101 enabling 101 state 101 suspending 101 thread usage 99 subscription endpoints in clusters 49 Subscription update process recovery 2628 subscription update process about 26 startup 26 suspending SOAP-JMS triggers 101 synchronization process consumer applications 29 synchronizing consumer applications 2831 consumer applications manually 88 virtual services 26 virtual services manually 87
125
Index
T
threads for SOAP-JMS triggers 99, 100 Transaction events audit log 39 SMTP 39 transaction events 39 log invocation policies 39 log journal 39 SNMP 39 transport protocols 64 truststores configuring 86 typographical conventions in this document 9
mediation 14 policy enforcement 14 webMethodsESB.MIB. See MIB
V
validate schema 74 viewing deployed consumer applications 88 deployed virtual services 87 virtual service definitions about 20 virtual services about 16 benefits 20 deploying 24 deploying to clusters 52 synchronization 21 synchronizing 26 synchronizing in clusters 52 synchronizing manually 87 undeploying 31 viewing deployed 87 virtual service definintions 20 VSDs. See virtual service definitions
W
watt properties watt.debug.layout 122 watt.server.enablePG 122 watt.debug.layout 122 watt.server.enablePG 122 webMethods Integration Server configuration settings 122 webMethods Mediator about 14 communication with CentraSite 24
126

8-0 Administering Mediator

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

8-0 Administering Mediator

Hochgeladen von

Copyright:

Verfügbare Formate

Title Page

Administering webMethods Mediator

Copyright & Document ID

Document ID: SMG-AG-80-20091204

Administering webMethods Mediator Version 8.0

Administering webMethods Mediator Version 8.0

Administering webMethods Mediator Version 8.0

71 71 71 72 72 72 73 73 73 73 74 74 74 74 75 76 76 77 78 79 81 83 83 85 86 87 88 91 92 92 93 94 94 96 99 99 99 100 101 103

Administering webMethods Mediator Version 8.0

Administering webMethods Mediator Version 8.0

Administering webMethods Mediator Version 8.0

About This Guide

Administering webMethods Mediator Version 8.0

About This Guide

For webMethods... 7.x 8.x

Administering webMethods Mediator Version 8.0

About This Guide

Go to... Software AG Developer Community for webMethods http://communities.softwareag.com/ webmethods

Administering webMethods Mediator Version 8.0

About This Guide

Administering webMethods Mediator Version 8.0

Administering webMethods Mediator Version 8.0

Administering webMethods Mediator Version 8.0

Mediator in the SOA Landscape

Administering webMethods Mediator Version 8.0

Mediator Key Capabilities

Mediator in the system

Mediator Key Capabilities

Administering webMethods Mediator Version 8.0

Virtual Service Updates

Monitoring and Statistics

Service Level Agreement Enforcement

Security Policy Enforcement

Administering webMethods Mediator Version 8.0

Mediator Key Capabilities

Seamless Integration with CentraSite

Administering webMethods Mediator Version 8.0

Administering webMethods Mediator Version 8.0

Virtual Service Definitions

Administering webMethods Mediator Version 8.0

Virtual Service Synchronization

Administering webMethods Mediator Version 8.0

Administering webMethods Mediator Version 8.0

Deploying and Synchronizing Virtual Services

Administering webMethods Mediator Version 8.0

Communication Between Mediator and CentraSite

Communication Between Mediator and CentraSite

Deploying and Redeploying Virtual Services to Mediator

Deployment Time Process

Administering webMethods Mediator Version 8.0

Deploying and Synchronizing Virtual Services

Administering webMethods Mediator Version 8.0

Synchronizing Virtual Service Subscription Updates

Synchronizing Virtual Service Subscription Updates

Subscription Update Process

Updating Mediator at Start Up

Administering webMethods Mediator Version 8.0

Deploying and Synchronizing Virtual Services

Subscription Notification Failure

Administering webMethods Mediator Version 8.0

Synchronizing Consumer Applications

Virtual Service Deployment Failure

Confirmation Deployment Message Failure