DataPower Service Types
There are three major service types available in the DataPower appliance.
- Multi-Protocol Gateway (MPGW)
- Web Service Proxy (WSP)
- XML Firewall (XMLFW)
Each type of Data-Power service has built-in features and functionality to handle different types of transactions and protocols for the type of traffic that is to be expected, as well as the type of backend being proxied. It is important to understand these different service types and what they have to offer when planning for the creation of a new service.
A general rule to guide for the service type selection is this: If the service is proxying a Web service with an available WSDL, use a Web Service Proxy service. If there is no WSDL provided by the backend application or service, an MPGW is the next best choice.
Web Service Proxy
- A Web Service Proxy (WSP) is a DataPower service type used to provide security and abstraction for backend Web services. It is a powerful proxy for the backend Web service.
- The WS-Proxy service can establish a service that is described by a WSDL and is used to receive SOAP-based Web service traffic over multiple transports and forward the traffic to Web service applications over HTTP or MQ.
- The Web Service Proxy service provides an XML threat-reduction and security-enforcement layer for XML messages and Web services transactions, including encryption, filtering, digital signatures, schema validation, WS-Security, XML access control, XPath, and detailed logging.
- The Web Service Proxy reads and parses a WSDL file to establish an automatic configuration. The WSDL file used for configuration could be obtained through subscriptions to a UDDI or WSRR registry.
- WSP automatically performs SOAP schema validation from WSDL types definition and decryption of encrypted request messages.
- By simply uploading a WSDL document and adding a Front Side Handler to the service, it is created and ready to start receiving requests.
- XML well-formedness checking, SOAP schema validation, payload schema validation, hooks for monitoring service executions, and a platform for building operation-level rules. All these features are automatically provided as DataPower uses the information provided within the WSDL such as endpoints, schema(s) and operations to configure the service. These few simple steps provide a full-featured service to act as a base for additional configuration required to meet your usecase requirements such as AAA, document transformations, message encryption, and so on.
- A WSDL file provides critical information about a Web service, including endpoint locations, instructions on binding to those endpoints, and expected message schemas.
- In addition to the WSP being capable of uploading or fetching a WSDL, it can also be configured to subscribe to a UDDI registry or a WSRR server to provide automatic updates of the WSDL or dynamically look up the endpoints for the service. As you might imagine, this flexibility can be useful for managing WSDLs and receiving updates in your service.
- Data Power’s introspection of the service’s WSDL file provides a powerful opportunity to implement rules and actions that are tied closely to that service’s natural structure. For example, any of the actions available can be used in a rule and applied to a particular service operation or to every operation in the service.
- To demonstrate the power and flexibility of this feature, let’s take an example Web service that is used for processing online shopping requests. Suppose there is one operation in the Web service for checking out, called checkout, and another for retrieving catalog information, called browse Catalog. It may not be required to authenticate and authorize requests for the browse Catalog operation; however, the checkout operation requires authentication and authorization. Because it is possible to implement a processing rule at the operation level of the WSDL, it is easy to implement this requirement. A processing rule would simply be created to authenticate and authorize the request and applied only to the checkout operation.
- The Web Service Proxy also has some powerful monitoring and logging capabilities. Web service traffic flowing through a WSP can be monitored and logged at the service level or down to the WSDL operation level, providing great flexibility and granularity in the monitoring and logging capabilities.
- In summary, a WSP service can be used to proxy Web services by simply importing, referencing, or subscribing to the backend WSDL file.
- The WSP automatically uses the endpoints contained within the WSDL to expose new, virtualized endpoints. It enforces schema validation based on the contents of the WSDL, providing an extremely powerful and valuable service with minimal configuration. The WSP can also implement all the multistep capabilities that a Data-Power service has to offer, while providing many additional Web services features.
- When configuring a service based on a pre-existing WSDL, we should almost always use a Web Service Proxy, as its automatic schema validation and port/binding/operation-level enforcement of policies and service level agreements is unmatched by any of the other service types. In an SOA infrastructure, this service type provides the deepest integration with registry, management, monitoring, and other governance tools.
WSDL = WSP
When configuring a service based on a pre-existing WSDL, we should almost always use a Web Service Proxy as it acquires many of the configuration details from the WSDL itself.
When to use Web Service Proxy
Use a Web Service Proxy when you need to perform one or more of the following tasks:
- Implement Web services Policy enforcement points, including security policies and reliable messaging policies.
- Implement Web Services Addressing protocol enforcement.
- Accept and send SOAP, raw XML, or unprocessed (binary) documents.
- Filter, validate, transform, encrypt, or decrypt XML documents.
- Route XML documents to the appropriate back-end service.
- Sign documents or verify signatures.
- Implement document-level security or service-level security.
- Communicate with clients, servers, and peers with SSL encryption.
- Monitor and control data traffic based on request sources and requested resources to the WSDL operation level.