8.7 Quality of service capabilities
|
| < Day Day Up > |
|
8.7 Quality of service capabilities
In this section we discuss Quality of Service capabilities and considerations specific to the Web Services Gateway.
8.7.1 Performance and availability
In this section we discuss considerations regarding performance and availability.
SOAP Caching
SOAP caching can significantly improve the performance of Web services. The SOAPAction HTTP header in the request is defined in the SOAP specification and is used by HTTP proxy servers to dispatch requests to particular HTTP servers. WebSphere Application Server dynamic cache can use this header in its cache policies to build IDs without having to parse the SOAP message.
Application server clustering
The Web Services Gateway is a J2EE enterprise application that runs on WebSphere Application Server. This means that in a Network Deployment environment, clustering of application servers can be used to improve performance and availability.
For information on WebSphere Application server clustering, see IBM WebSphere V5.0 Performance, Scalability, and High Availability, SG24-6198.
8.7.2 Security
Security is one of the crucial QoS aspects which needs to be addressed when an enterprise plans to expose their internal applications to partner organizations. The following topics address Web Services Gateway security features.
Invocation of services using SSL
As a request passes from one component to another, the opportunities for the interception and exposure of information increase and ultimately the overall security of a system directly relates to the weakest, or least secure, point. SSL can be used to secure connections between two endpoints.
WebSphere Application Server, and the Web Services Gateway support SSL connections.
Basic authentication and authorization facilities
Web Services Gateway provides a basic authentication and authorization mechanism based upon the broader security features of WebSphere Application Server.
Basic authentication can be applied at two levels:
-
Gateway-level authentication
-
Web service operation-level authorization
For gateway-level authentication, you set up a role and realm for the gateway on WebSphere Application Server's Web server and servlet container, and define the user ID and password that is used by the gateway to access the role and realm. You also modify the gateway's channel applications so that they only give access to the gateway to service requesters that supply the correct user ID and password for that role and realm.
| Note | This means that gateway-level authentication must be enabled before you install any channels |
For operation-level authorization, you apply security to individual methods in a Web service. To do this, you create an enterprise bean with methods matching the Web service operations. These EJB methods perform no operation and are just entities for applying security. Existing WebSphere Application Server authentication mechanisms can be applied to the enterprise bean. Before any Web service operation is invoked, a call is made to the EJB method. If authorization is granted, the Web service is invoked. Your target Web service is protected by wrapping it in an EAR file, and applying role-based authorization to the EAR file.
| Notes |
|
WS-Security
Because the Web Services Gateway deals with SOAP messages at the application level, you are introducing the potential for a security risk. Securing the message at the transport protocol level is not sufficient. WS-Security describes how to secure messages using XML encryption and XML digital signature and how to integrate these specifications into a SOAP message.
Web Services Gateway can be configured for the secure transmission of SOAP messages using tokens, keys, signatures and encryption in accordance with the Web Services Security (WS-Security) draft recommendation.
In a normal (non-gateway) WS-Security scenario, the flow is as shown in the following figure:
Figure 8-43: WS-Security flow in a non-gateway environment
The client generates a request which is then handled by the client Web services engine. It reads the client security configuration and applies the security defined in the ibm-webservicesclient-ext.xmi file to the SOAP message. It gets additional binding information from the ibm-webservicesclient-bnd.xmi file (for instance, the location of a keystore on the file system).
On receipt of a SOAP message, the Web services engine on the server refers to the *.xmi files for the called Web service. In this case, the ibm-webservices-ext.xmi file tells the engine what security the incoming message must have (for example, that the body of the message must be signed). If the message does not comply, then it is rejected. The Web services engine verifies any security information, then passes the message on to the Web service being called.
On the response leg from server to client, the process is reversed. The Web service *.xmi files tell the Web services engine what security to apply to the response message, and the client *.xmi files tell the client engine what security to require in the response message.
When the gateway is introduced, the scenario is more complex. Essentially it can be thought of as two separate request/response invocations. Client to gateway and gateway to target service, as shown in the following figure:
Figure 8-44: WS-Security flow in a gateway environment
In this scenario, the client and the Web service are unchanged, and still have the same security settings in their *.xmi files. However, the gateway is unsecured. Secure SOAP messages cannot travel through the gateway unchanged, and must be processed on receipt. So the gateway needs to act as the target service from the point of view of the client, and as the client from the point of view of the target service.
This scenario means that the security settings for the Web service need to be configured for the view of the service that the gateway presents to the client, and the security settings for the associated gateway target services (remember that there may be multiple target services deployed for a single gateway service) need to be configured with the security settings for the client.
WS-Security settings for the gateway are configured manually using the gateway administrative user interface.
Proxy authentication for the gateway
The gateway requires access to the Internet for invoking Web services and for retrieval of WSDL files. Many enterprise installations use a proxy server in support of Internet routing, and many proxy servers require authentication before they grant access to the Internet. This requirement is supported in HTTP messaging by a "Proxy-Authorization" message header that contains encoded username and password credentials.
For messages passing through the gateway, you can enable and disable proxy authentication, and specify whether the authentication credentials are supplied by the service requester or by the gateway. If you specify requester-supplied credentials, the credentials in the HTTP message that the gateway receives are re-instantiated by the gateway in the equivalent message that it sends on to the proxy. If you specify gateway-supplied credentials, the gateway ignores any credentials in the incoming HTTP message and supplies its own credentials in the equivalent message that it sends on to the proxy.
| Note | In certain circumstances, the gateway also creates and sends its own messages (for example for WSDL retrieval). In these cases, the gateway always supplies its own credentials to the authenticating proxy. So even if you enable proxy authentication and specify requester-supplied credentials, you must still supply credentials for the gateway. |
8.7.3 Standards compliance
By utilizing open standards, Web services can, in theory, enable any two software components to communicate regardless of what technologies or platforms are used to create or deploy them. Interoperability across heterogeneous platforms is one of the key value propositions of Web services.
WS-I Profile
The Web Services Interoperability Organization is an open industry effort chartered to promote Web services interoperability across platforms, applications, and programming languages. Web services for J2EE intends to conform to the WS-I Basic Profile 1.0, and should interoperate with any other vendor conforming to this specification.
WS-Security
You can configure the gateway for secure transmission of SOAP messages using tokens, keys, signatures and encryption in accordance with the Web Services Security (WS-Security) draft recommendation.
Interoperability through firewalls
The Web Services Gateway is entirely based on Web services, which when implemented using HTTP as SOAP transport protocol, are totally firewall friendly.
8.7.4 Autonomic
Log and trace facilities are important for fault monitoring and isolation. WebSphere Application Server provides a number of log files. JVM logs are located in the <WAS_HOME>/logs/<applicationServerName> directory, and by default are named SystemOut.log and SystemErr.log.
The Diagnostic Trace Service can be used to enable tracing of application server components. The following trace specification can be used when diagnosing Web Services Gateway problems:
com.ibm.wsgw.*=all=enabled: org.apache.wsif.*=all=enabled: com.ibm.ws.webservices.*=all=enabled
The following tools can also be helpful when analyzing problems:
-
TCPMon:
The TCPMon tool allows you to view the contents of the SOAP messages being generated by the interaction between the source application, gateway, and target application.
-
Tivoli® Performance Viewer:
The Tivoli Performance Viewer packaged with IBM WebSphere Application Server V5.0 can monitor Web Services Gateway requests and responses. When the gateway is installed in WebSphere V5.0, counters are added automatically to the Performance Monitoring Service. Gateway monitoring can be enabled by simply starting performance monitoring. See the redbook for details on specific procedures for enabling monitoring:
-
IBM WebSphere Application Server V5.0 System Management and Configuration: WebSphere Handbook Series, SG24-6195
Once monitoring is enabled on the WebSphere Application Server, open the Tivoli Performance Monitor and navigate to the Web Services Gateway. The Viewer monitors both synchronous and asynchronous requests and responses. The output can be viewed in either table or graph format. It can also be logged and played back when needed. Figure 8-45 shows the Tivoli Performance Viewer monitoring gateway requests and responses.
Figure 8-45: Tivoli Performance Viewer -
-
Microsoft Network Monitor:
Microsoft Network Monitor captures network traffic on local area networks for real-time or post-capture analysis. The Network Monitor captures frames from the network that can be filtered to present only relevant material. It can also be configured to detect specific network conditions and generate events as needed. Figure 8-46 shows the Microsoft Network Monitor. Details concerning the configuration and use of the monitor can be found from Windows Help.
Figure 8-46: Microsoft Network MonitorOf particular interest to the gateway is the Network Monitor's ability to monitor TCP/IP packets from a particular target and source. In this manner, traffic to and from the gateway can be traced from its origin to its destination.
|
| < Day Day Up > |
|
EAN: N/A
Pages: 102