WSIF system management and administration

WSIF is provided as a stand-alone JAR file called wsif.jar. The JAR file contains the core WSIF classes, and the Java, EJB, SOAP over HTTP and SOAP over JMS providers. Additional providers are packaged as separate JAR files.

When you install WAS, wsif.jar is put on the WebSphere or JVM class path.

WSIF requires no further configuration. WSIF is a thin abstraction layer between application code and the relevant invocation infrastructure.

Maintaining the WSIF properties file

WSIF properties are stored in a properties file (in wsif.jar) called wsif.properties. This file is kept on the class path, so that WSIF can find it, and the client administrator can use it to configure WSIF.

Here are the initial contents of wsif.properties. All the possible properties are listed and described.

# Two properties are used to override which WSIFProvider is selected when there
# exists multiple providers supporting the same namespace URI. These properties are: 
#
#    wsif.provider.default.CLASSNAME=N
#    wsif.provider.uri.M.CLASSNAME=URI
#
# CLASSNAME is the WSIFProvider class name
# N is the number of following default wsif.provider.uri.M.CLASSNAME properties 
# M is a number from 1 to N to uniquely identify each wsif.provider.uri.M.CLASSNAME
#   property key.
# For example the following two properties would override the default SOAP provider 
# to be the Apache SOAP provider:
#
# wsif.provider.default.org.apache.wsif.providers.soap.ApacheSOAP.WSIFDynamicProvider_ApacheSOAP=1 
# wsif.provider.uri.1.org.apache.wsif.providers.soap.ApacheSOAP.WSIFDynamicProvider_ApacheSOAP=\
# http://schemas.xmlsoap.org/wsdl/soap/
#

# maximum number of milliseconds to wait for a response to a synchronous request. 
# Default value if not defined is to wait forever.
wsif.syncrequest.timeout=10000

# maximum number of seconds to wait for a response to an async request. 
# if not defined on invalid defaults to no timeout  
wsif.asyncrequest.timeout=60

Enabling security for WSIF

This is how WSIF interacts with a security manager:

• WSIF runs in the current J2EE security context without modifying it.
• When WSIF is run under a J2EE container, Port implementations can utilize security context to pass on security tokens or credentials as necessary.
• WSIF implementations can automatically convert J2EE security context into appropriate context for onward services.

For WSIF to interact effectively with the WAS's security manager, these permissions must be set in the server.policy file:

• FilePermission to load the WSDL (this is only required when a WSDL file is referred to using the file:/// protocol)
• RuntimePermission "getClassLoader" for the current thread's context class loader (this is not required by the EJB portion).
• RuntimePermission "accessDeclaredMembers" (this is required by both portions for handling enterprise beans)
• PropertyPermission for system properties (this is required by SOAP and many others; read and write access is required for the SOAP and Java portion, only write access is required for the EJB portion)
• NetPermission "specifyStreamHandler" (this must be in either the SOAP and Java portion, or the EJB portion, but it need not be in both).
• SocketPermission "host_name", "resolve" (this is not required by the SOAP and Java portion)
• SocketPermission "host_name:port_no", "connect" (this is required by both portions)

where host_name is your host name (for example localhost), and port_no is your port number (for example 9080).