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 VAST 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 VAST 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 VAST 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 VAST 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 Visual Programming User 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 Visual Programming User Guide for additional information about deserialization configurations.
Customizing encoding strategy
Various styles can be used to represent web service operations as SOAP strings. The VAST 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'