Processing Web Services Which use Soap 1.2 Extensions

 

The framework uses the namespace in the binding stanza of the specified wsdl document to determine the soap extension namespace for the service.

 

You must do two things to invoke Soap 1.2 web services.

 

You must use a serialization manager which can process Soap 1.2 messages:

 

| aContainer aServiceCollection |

 

aContainer := SstWSContainer

createContainerUsingDocLiteralWrappedNamed: (SciSocketManager default getHostName).

wsdlContainer startUp.

 

aContainer serializationManager: (SstWSSoap12SerializationManager for: aContainer

 

Note: This manager can also process Soap 1.1 messages. Use it for containers which will be processing both Soap 1.1 and Soap 1.2 web services.

 

You must explicitly specify the namespace of the Soap envelope for the service, as in the example below:

 

aServiceCollection := aContainer deploy: 'a valid wsdl path or url').

 

aServiceCollection first sstSoapEnvelopeNamespace: SstSoapConstants::SstSoap12EnvelopeNamespace.

 

New schemas and mapping specifications were necessary to process the Soap 1.2 extensions:

•	sstoenv12.xsd

•	sstoenc12.xsd

•	sstwsdlsoap12.xsd

•	sstwsdlsoap12.map

•

xml.xsd,

These files are shipped with 8.6.1. You will find them in the xml folder of the installation.

 

Extending/ Customizing the Web service platform

The VA Smalltalk Web services framework allows for pluggability and extensibility in virtually every aspect of the framework.

Customizing SstWSService

SstWSService is a proxy object which is a subclass of the SstObject and SstForwarder proxy hierarchy. This inheritance limits methods which can safely be sent by the class. Be cautious when extending SstWSService.

For instance, SstForwarder forwards the method “class”, which means that sending self class from a method in SstWSService can lead to unexpected results.

Customizing the Container

Application developers can introduce custom implementations for key system behaviors through the use of configuration classes. To override Web services behaviors you must introduce user-defined class names into the SstWSContainerConfiguration, which is used to start the container.

The following is a customization example:

" Specify a custom deployment manager and start

a new container that uses it "

| containerConfig |

containerConfig := SstWSContainerConfiguration defaultConfiguration.

containerConfig

deploymentManager: MyDeploymentManager.

SstWSContainer createContainerNamed: 'MyContainer'

using: containerConfig

Extending the container

If you want to add a desired behavior to a Web services container, create a custom manager class for the new behavior. The new class is then added to the container before the container is deployed. The custom managers can then be utilized by Web service handlers at runtime. An example of this would be to create a manager to control access to a service via security information passed in the SOAP message header. The following code demonstrates how a new manager is added to the container

SstWSContainer containerNamed: 'MyContainer')

addManager: MyLoginManager new

named: 'LoginManager'

The container can also be customized by supplying custom settings in a container configuration file.

Extending the deployment manager

Service deployment, by default, is accomplished automatically by supplying a WSDL file or VA Smalltalk deployment descriptor file (.XML). The appropriate deployment strategy is chosen based on the suffix of the URL/filename supplied. The following suffixes are currently supported: wsd, wsdl, xml (Files with the .xml suffix are assumed to be VAST deployment descriptors). The deployment manager can also be extended to support new strategies, for organizations that may wish to deploy services via some other mechanism. An example of how to add a new strategy to the deployment manager is shown below.

SstWSDeploymentManager register: MyCustomDeploymentStrategy new

as: http://myservice.xml

Custom service handlers

The handler framework for VA Smalltalk Web services provides a versatile service invocation mechanism, which can be customized through the service deployment descriptor. Content passed into SOAP headers use the same algorithm as messages passed into the SOAP message body.

The algorithm used by VA Smalltalk Web services for processing service requests is as follows:

•	Use the operationName/namespace combination to determine whether a custom handler has been defined to process the passed request.

•	If a handler was found, invoke the handler passing the message context

Otherwise (jukebox technique)

•	Use the operationName/namespace combination to determine a Smalltalk message to handle the incoming request

•	Construct a Smalltalk directed message based upon the receiver and selector name found in the deployment descriptor

•	Send the message using the arguments from the SOAP message

Customizing serialization

The default message serialization step automatically builds a SOAP string by associating an interface definition from a WSDL document with a collection of arguments provided by a service request or response. Serialization behavior is customized by supplying custom serialization configurations in the container serialization manager. See the XML section of the VA Smalltalk User's Guide for additional information.

Customizing deserialization (parsing)

The default process for message deserialization uses the AbtXmlMappingParser to construct domain objects from an incoming XML stream. Parsing is then accomplished by applying rules, which are defined in a deserialization configuration (AbtXmlDeserializationConfiguration). The Deserialization configurations are stored in the serializationManager of a container. The configurations are then resolved in the serializationManager using the namespace of the incoming XML tag. Default configurations can be replaced or modified. See the XML section of the VA Smalltalk User's Guide for additional information about deserialization configurations.

Customizing encoding strategy

Various styles can be used to represent web service operations as SOAP strings. The VA Smalltalk Web Services support uses WSDL to determine which encoding strategy should be used to encode or decode a SOAP message. The proper encoding strategy is determined using the style from the WSDL SOAP operation extension (ie: soap:operation) and use from the WSDL SOAP message extension (ie: soap:body, soap:header, soap:fault).

Example:

SstWSEncodingStrategy register: MyDocLitStrategy new

as: 'documentliteral'