As of version 5.9.0, WebSphere® Portlet Factory uses AXIS for both its inbound and outbound SOAP request handling. This file provides a summary to explain its impact on inbound request processing.
AXIS uses a deployment descriptor called "server-config.wsdd" to define the services available on a server. The deployment descriptor defines the service namespace, implementing class, methods, arguments, type mappings, and so on. It resides in the project's WEB-INF directory.
An inbound SOAP envelope has as its first child element in the SOAP:Body a namespace, which is either the method namespace URI (if RPC) or the element namespace (if Document style). AXIS matches that namespace against the deployment descriptor entries, finds a match (using a FileProvider extension provided with WebSphere Portlet Factory), and then it invokes the WebSphere Portlet Factory implementation to invoke the appropriate method in the appropriate model. There are some key points of note:
The server-config.wsdd does not need to exist. WebSphere Portlet Factory will supply the descriptor information to AXIS dynamically at runtime and AXIS holds that data in memory.AXIS Examine Descriptor Property
If the server-config.wsdd does exist, there is a property (in WEB-INF/config/bowstreet.properties) that governs whether WebSphere Portlet Factory will allow AXIS to examine the descriptor first, or to call WebSphere Portlet Factory to find a model with a method that implements the namespace (and then allow AXIS to examine the descriptor file). Allowing AXIS to look at its descriptors first (and specifying them in server-config.wsdd) allows you to preempt processing of particular namespaces.Descriptor Deployment Property
There is a second property that dictates whether, having found a model and built a descriptor, WebSphere Portlet Factory deploys that to the AXIS descriptors. WebSphere Portlet Factory returns the definition to AXIS to use, but it is just a "throw away" unless WebSphere Portlet Factory deploys it. By default the property is set to true which means that when WebSphere Portlet Factory finds a model implementing a desired namespace and creates a descriptor for it is then deploy it to AXIS (in memory), so that next time AXIS needs that namespace it will already have the information and not call WebSphere Portlet Factory to find a model for that namespace.
So having this "true" and having the other property set to allow AXIS to examine its descriptors first is the most efficient processing model. But in development when models are changing it is probably preferable to specify that WebSphere Portlet Factory does not deploy the descriptors it builds that way the changing models are always being examined for matching web services.
AXIS has various hooks for introducing request and response handlers for any inbound requests. See the AXIS site for information on this. Those handlers can be defined in the server-config.wsdd and used in the normal manner. The only difference in the mechanisms described above and the normal AXIS processing is that WebSphere Portlet Factory provides the definitions dynamically at runtime.
If bowstreet.system.request or bowstreet.system.webservice.incomingSOAPRequest log4j properties are set to debug, the descriptors generated and fed to AXIS will dumped out to the SystemOut log. This allows you to capture the descriptor for a particular model/namespace and copy it into the server-config.wsdd and override or modify values as needed. For this to work you will of course need to make sure the property that allows AXIS to look at its descriptors before calling for a model search is set.
Parent topic: Web Service Enable builder: wpf7