Cisco ACE XML Gateway User Guide (Software Version 6.0) - Editing and Maintaining Virtual Services [Cisco ACE XML Gateways]

Table Of Contents

Editing and Maintaining Virtual Services

Overview

Incorporating Changes by WSDL Update

Disabling a Virtual Service

Removing a WSDL

Editing and Maintaining Virtual Services

This chapter describes how to use the ACE XML Manager's tools to edit existing service settings. It covers these topics:

•Overview

•Incorporating Changes by WSDL Update

•Disabling a Virtual Service

•Removing a WSDL

Overview

Many of the settings in a virtual service configuration are specified when the object is first created. You can modify the original settings or configure options not available in the new object wizard from the service settings page, which you open as follows:

Step 1 While logged in to the web console as an Administrator user or a Privileged user with the Routing role or Access Control role, set the active subpolicy to the one that includes the service object, if not already active.

Step 2 Click the Virtual Services link in the navigation menu.

Step 3 In the Virtual Services browser, click on the name of the basic virtual service, handler, or service descriptor to edit.

Step 4 Use the controls on the information page to change the settings as desired. For example, to change the name of the object, click the Edit link in the General heading.

Note For more information on specific settings, see the online help for that settings page by clicking the help link ().

Step 5 Save your changes to commit your changes to the active policy and deploy the policy to have your changes take effect at the ACE XML Gateway.

Incorporating Changes by WSDL Update

When you import a WSDL file, the ACE XML Manager generates policy objects that represent the services described in the WSDL. If there are subsequent changes to the external WSDL, you can re-import it to update the WSDL in the policy. Updating the WSDL causes its changes to be reflected in the policy objects that were generated from the original WSDL.

To apply WSDL changes to service settings in the policy, the ACE XML Manager must be able to match the changed service description in the WSDL to the virtual service. The Manager matches operations between the changed WSDL and the policy based on these features:

•Operation name

•SOAP version

•SOAP style

•Backend service path (if the previous three properties cannot be used to unambiguously match services in the ACE XML Gateway policy)

If these properties are matched in a virtual service from the ACE XML Gateway policy by a service definition in the WSDL, the virtual service in the policy inherits the settings in the WSDL.

For properties that are definable by WSDL, the values in the updating WSDL supersede those in the policy. Non-WSDL properties in the policy (that is, settings that are specific to the ACE XML Gateway policy) are retained, such as the local path or encryption settings. Virtual services that are no longer in the updating WSDL are removed from the policy.

Note Since the update process matches operations to be updated by operation name, it is important that the name of the virtual service or handler is unchanged in the policy as generated by WSDL import. If the name of the virtual service object is changed, automated updates will not work.

WSDL update does not remove any new handlers or routes that you have created by hand, but if any handlers are attached to services that no longer exist in the new WSDL file then the previously configured routes are lost. If the import removes existing routes then the ACE XML Manager displays a warning.

Because the new WSDL can overwrite working handlers, routes, and service descriptors, it's important to always review the new policy after importing a WSDL file. You may find that you need to change or add handlers and routes to restore services to consumers.

Similar considerations apply when deleting an imported WSDL file. The ACE XML Manager does not remove any new handlers or routes that you created by hand, but if a handler routes to a service that no longer exists after the WSDL is deleted, the route is lost.

Note The Manager can subscribe to changes to source WSDL in some cases. For a WSDL imported by service discovery from a Systinet Registry 6.5 running UDDI version 3, you can choose to enable subscriptions. If enabled, the Manager displays a notice on the Imported WSDL Files page when there are changes to the source WSDL.

To update a WSDL file:

Step 1 While logged in to the console as an Administrator user or a Privileged user with the Access Control or Routing role, set the active subpolicy to the one that provides the WSDL to update.

Step 2 Click the Imported WSDL Files link in the Navigation menu.

Step 3 In the Imported WSDL Files page, click the update link that appears to the right of the WSDL to update.

Step 4 Use the file or URL fields to identify the updating WSDL file.

Step 5 Click the Update WSDL button to have the ACE XML Manager update policy objects based on the specified WSDL file.

The policy objects generated by the import of the original WSDL are modified based on any new settings in the updating WSDL. The update procedure changes the working policy in the ACE XML Manager. Deploy the policy to have the changes take effect at the ACE XML Gateway.

Disabling a Virtual Service

A virtual service may need to be disabled temporarily for a variety of reasons, such as:

•The backend service is unavailable or you have developed the virtual service before the backend service is available, and you need to disable access to the service until that date.

•You suspect that a particular virtual service is the source of a problem, and you want to test the possibility by disabling it.

•A particular handler or small group of handlers is the target of an attack. You may decide to disable them until the attack subsides.

Disabling a virtual service in effect turns it off—it stops processing network traffic until re-enabled. HTTP requests sent to a disabled virtual service get a "500 no service found" error. Once enabled, the virtual service resumes processing traffic.

To disable a handler, basic virtual service, or operation:

Step 1 As an Administrator user or Privileged user with the Access Control role in the console, click the Virtual Services link in the navigation menu.

Step 2 Click the name of the virtual service or handler to disable.

The ACE XML Manager displays the information page for the object.

Step 3 If it is not visible in your browser window, scroll to the bottom of the page and click the Disable button.

If the virtual service contains multiple operations, click the Manage link and select the operation to be disabled in the operations list, and click the Disable button.

The virtual service is now disabled, so that the ACE XML Gateway rejects requests sent to it. For handlers that are disabled, a banner appears at the top of the information page in the console indicating that the handler is disabled. You can re-enable the virtual service by clicking the Enable button at the bottom of its information page or in the operations list.

Removing a WSDL

Removing a WSDL in the Imported WSDL page has the effect of undoing the effects of importing the WSDL. It removes the virtual services, port objects, HTTP Servers, and any other object that was created as a result of the WSDL import.

The ACE XML Manager retains objects generated from the WSDL-import if dependencies were added by hand later. For example, if you create a virtual service by hand that uses a server definition generated by WSDL import, when the WSDL is removed, the server object is retained since it is still in use by objects not deleted by removing the WSDL. If the server is used only by virtual services that were also created by WSDL import, the server definition is removed.

The Manager prevents you from removing a WSDL if a handler that was not generated from the WSDL import routes to a service descriptor that was generated by WSDL import. Also, WSDL removal is blocked if the schema generated from the import is used to validate content in virtual services not created by WSDL import.

To remove a WSDL:

Step 1 In the Imported WSDL Files page, click the remove link next to the WSDL.

Step 2 Review the changes that result from removing the WSDL, and click Save Changes.

When complete, the Imported WSDL Files page appears. The WSDL should not be listed and the policy objects originally created by the import are removed from the working policy.

	Cisco ACE XML Gateway User Guide (Software Version 6.0)
	Editing and Maintaining Virtual Services
Cisco ACE XML Gateway User Guide (Software Version 6.0) Preface Introducing the Cisco ACE XML Gateway Basic Concepts First Steps Working with Virtual Services Working with Handlers, Routes, and Service Descriptors Controlling Access to Services Authenticating Requests to Backend Systems Editing and Maintaining Virtual Services Using Variables in Paths Validating Messages Processing SOAP Messages XML Encryption and XML Signature Transforming Messages with XSLT Configuring Destination Server Settings Working with Ports and Hostnames Working With JMS Traffic Working with TIB/RV and MQ Services Working with ebXML Traffic Securing Traffic with SSL/TLS Configuring Reactor Processing Caching Service Responses Mapping HTTP Error Responses Setting Global Traffic Rules Securing Web Applications Working with Virtual Web Applications Working with Profiles Developing Rules and Signatures Managing Resource Files Deploying the Policy Managing the Policy Publishing Service Information Monitoring System Status Managing Web Console Users Managing Gateway Clusters Configuring the Manager Web Console Using the ACE XML Manager SOAP API Troubleshooting Log Messages	Download this chapter Editing and Maintaining Virtual Services Download the complete book Cisco ACE XML Gateway User Guide Book-Length PDF (PDF - 9 MB) Feedback Table Of Contents Editing and Maintaining Virtual Services Overview Incorporating Changes by WSDL Update Disabling a Virtual Service Removing a WSDL Editing and Maintaining Virtual Services This chapter describes how to use the ACE XML Manager's tools to edit existing service settings. It covers these topics: •Overview •Incorporating Changes by WSDL Update •Disabling a Virtual Service •Removing a WSDL Overview Many of the settings in a virtual service configuration are specified when the object is first created. You can modify the original settings or configure options not available in the new object wizard from the service settings page, which you open as follows: Step 1 While logged in to the web console as an Administrator user or a Privileged user with the Routing role or `Access Control` role, set the active subpolicy to the one that includes the service object, if not already active. Step 2 Click the Virtual Services link in the navigation menu. Step 3 In the Virtual Services browser, click on the name of the basic virtual service, handler, or service descriptor to edit. Step 4 Use the controls on the information page to change the settings as desired. For example, to change the name of the object, click the Edit link in the General heading. Note For more information on specific settings, see the online help for that settings page by clicking the help link (). Step 5 Save your changes to commit your changes to the active policy and deploy the policy to have your changes take effect at the ACE XML Gateway. Incorporating Changes by WSDL Update When you import a WSDL file, the ACE XML Manager generates policy objects that represent the services described in the WSDL. If there are subsequent changes to the external WSDL, you can re-import it to update the WSDL in the policy. Updating the WSDL causes its changes to be reflected in the policy objects that were generated from the original WSDL. To apply WSDL changes to service settings in the policy, the ACE XML Manager must be able to match the changed service description in the WSDL to the virtual service. The Manager matches operations between the changed WSDL and the policy based on these features: •Operation name •SOAP version •SOAP style •Backend service path (if the previous three properties cannot be used to unambiguously match services in the ACE XML Gateway policy) If these properties are matched in a virtual service from the ACE XML Gateway policy by a service definition in the WSDL, the virtual service in the policy inherits the settings in the WSDL. For properties that are definable by WSDL, the values in the updating WSDL supersede those in the policy. Non-WSDL properties in the policy (that is, settings that are specific to the ACE XML Gateway policy) are retained, such as the local path or encryption settings. Virtual services that are no longer in the updating WSDL are removed from the policy. Note Since the update process matches operations to be updated by operation name, it is important that the name of the virtual service or handler is unchanged in the policy as generated by WSDL import. If the name of the virtual service object is changed, automated updates will not work. WSDL update does not remove any new handlers or routes that you have created by hand, but if any handlers are attached to services that no longer exist in the new WSDL file then the previously configured routes are lost. If the import removes existing routes then the ACE XML Manager displays a warning. Because the new WSDL can overwrite working handlers, routes, and service descriptors, it's important to always review the new policy after importing a WSDL file. You may find that you need to change or add handlers and routes to restore services to consumers. Similar considerations apply when deleting an imported WSDL file. The ACE XML Manager does not remove any new handlers or routes that you created by hand, but if a handler routes to a service that no longer exists after the WSDL is deleted, the route is lost. Note The Manager can subscribe to changes to source WSDL in some cases. For a WSDL imported by service discovery from a Systinet Registry 6.5 running UDDI version 3, you can choose to enable subscriptions. If enabled, the Manager displays a notice on the Imported WSDL Files page when there are changes to the source WSDL. To update a WSDL file: Step 1 While logged in to the console as an `Administrator` user or a `Privileged` user with the `Access Control` or `Routing` role, set the active subpolicy to the one that provides the WSDL to update. Step 2 Click the Imported WSDL Files link in the Navigation menu. Step 3 In the Imported WSDL Files page, click the update link that appears to the right of the WSDL to update. Step 4 Use the file or URL fields to identify the updating WSDL file. Step 5 Click the Update WSDL button to have the ACE XML Manager update policy objects based on the specified WSDL file. The policy objects generated by the import of the original WSDL are modified based on any new settings in the updating WSDL. The update procedure changes the working policy in the ACE XML Manager. Deploy the policy to have the changes take effect at the ACE XML Gateway. Disabling a Virtual Service A virtual service may need to be disabled temporarily for a variety of reasons, such as: •The backend service is unavailable or you have developed the virtual service before the backend service is available, and you need to disable access to the service until that date. •You suspect that a particular virtual service is the source of a problem, and you want to test the possibility by disabling it. •A particular handler or small group of handlers is the target of an attack. You may decide to disable them until the attack subsides. Disabling a virtual service in effect turns it off—it stops processing network traffic until re-enabled. HTTP requests sent to a disabled virtual service get a "`500 no service found`" error. Once enabled, the virtual service resumes processing traffic. To disable a handler, basic virtual service, or operation: Step 1 As an `Administrator` user or `Privileged` user with the `Access Control` role in the console, click the Virtual Services link in the navigation menu. Step 2 Click the name of the virtual service or handler to disable. The ACE XML Manager displays the information page for the object. Step 3 If it is not visible in your browser window, scroll to the bottom of the page and click the Disable button. If the virtual service contains multiple operations, click the Manage link and select the operation to be disabled in the operations list, and click the Disable button. The virtual service is now disabled, so that the ACE XML Gateway rejects requests sent to it. For handlers that are disabled, a banner appears at the top of the information page in the console indicating that the handler is disabled. You can re-enable the virtual service by clicking the Enable button at the bottom of its information page or in the operations list. Removing a WSDL Removing a WSDL in the Imported WSDL page has the effect of undoing the effects of importing the WSDL. It removes the virtual services, port objects, HTTP Servers, and any other object that was created as a result of the WSDL import. The ACE XML Manager retains objects generated from the WSDL-import if dependencies were added by hand later. For example, if you create a virtual service by hand that uses a server definition generated by WSDL import, when the WSDL is removed, the server object is retained since it is still in use by objects not deleted by removing the WSDL. If the server is used only by virtual services that were also created by WSDL import, the server definition is removed. The Manager prevents you from removing a WSDL if a handler that was not generated from the WSDL import routes to a service descriptor that was generated by WSDL import. Also, WSDL removal is blocked if the schema generated from the import is used to validate content in virtual services not created by WSDL import. To remove a WSDL: Step 1 In the Imported WSDL Files page, click the remove link next to the WSDL. Step 2 Review the changes that result from removing the WSDL, and click Save Changes. When complete, the Imported WSDL Files page appears. The WSDL should not be listed and the policy objects originally created by the import are removed from the working policy.
	Terms & Conditions \| Privacy Statement \| Cookie Policy \| Trademarks