Patterns: Broker Interactions for Intra- and Inter-enterprise

210 Broker Interactions for Intra- and Inter-enterprise

TCP/IP Monitor Server

The TCP/IP Monitor Server provided with WebSphere Studio Application

Developer (shown in Figure 8-42) also allows tracing of SOAP messages. It

works in a similar way to the WebSphere TCPMon tool. To use the TCP/IP

Monitor Server, create a new Server and Configuration and select Other

→

TCP/IP Monitor Server for the server type.

Figure 8-42 Tracing SOAP messages using WebSphere Studio TCP/IP Monitor Server

򐂰 Back up your configuration.

The Web Services Gateway offers a very easy way to make a backup of the

entire configuration of the gateway. This backup does not include the filter

implementation, which resides in a separated Enterprise Application.

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.

Chapter 8. Router solutions using Web Services Gateway 211

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

212 Broker Interactions for Intra- and Inter-enterprise

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.

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:

Notes:

򐂰 If you want to enable operation-level authorization, you must first enable

gateway-level authentication.

򐂰 If you want to change the default gateway-level authentication settings,

you must do so before you install any channels.

򐂰 After gateway-level authentication has been enabled, filters have access to

the requester's authentication information.