The VisualAge Web services framework allows for pluggability and extensibility in virtually every aspect of the framework.
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
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.
Service deployment, by default, is accomplished automatically by supplying a WSDL file or VisualAge 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
The handler framework for VisualAge 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 VisualAge Smalltalk Web services for processing service requests is as follows:
Otherwise (jukebox technique)
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 VisualAge User's Guide for additional information.
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 VisualAge User's Guide for additional information about deserialization configurations.
Various styles can be used to represent web service operations as SOAP strings. The VisualAge 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'