XML serialization is performed by objects called 'serializers'. Developers can supply custom serializers that replace the default serialization logic.

Alternatively, the serialization configuration itself can be replaced.

By default, SOAP encoded messages are constructed using the serialized named SstSoapOutputSerializer. This serializer causes all complex SOAP messages to be encoded as SOAP multi-refs. Notice that the serialization configuration is referenced using the SOAP encoding namespace.

Mapping parsed XML into Smalltalk model objects is performed by objects called 'deserializers'. Developers can supply custom deserializers to enhance default mapping behavior. Custom deserializers can be created and set in deserialization configurations.

The message handler chain can be modified to add code that dumps the contents of the SOAP message and response.

To disable the tracing code, execute the snippet below:

To disable the tracing code, execute the snippet below:

The script below shuts down all active HTTP servers, and terminates all active sockets.

The algorithm for processing 'anyType' and for processing 'subtypes' is very similar.

A new mapping spec is introduced (contained in 'abtvast.map') to represent the Smalltalk namespace. The new mapping spec is intended to describe how Smalltalk objects should map to XML schema types. For typical mapping specs, it is possible to have multiple types map to the same object; therefore, determination of a schema type from an object instance is ambiguous. The Smalltalk namespace mappings remove ambiguity because each object maps to a single schema type.

For many cases, it is not necessary to refer to the Smalltalk mapping spec in order to determine a proper type mapping. The Smalltalk namespace exists strictly to remove ambiguity when the same class can map to multiple types.

When trying to determine the 'actual' type for an object, VAST does the following:

For types other than anyType, if no specialized type is found, the baseType is assumed to be the serialization type.

For an anyType, if no specialized type is found, a type definition is constructed based on the class shape. The type is created in the "VA Smalltalk" namespace. The "Smalltalk" namespace is settable in the serialization configuration. The default value is urn:Vast and is globally settable in the pool variable AbtXmlConstants::AbtXmlSmalltalkNamespace.

-------------------------------

Execute the following Smalltalk expression:

Add an 'XmlDefaultEncoding' entry to the [Xml] stanza of your application's .ini file and set decodingEnabled to false in the AbtXmlConfiguration used by AbtXmlMappingParser.

The value for this entry should be the target encoding for the serialized SOAP message. The VAST Web services support will always attempt to serialize SOAP messages using the specified encoding.

For less common encodings, it may be necessary to add a code page mapping using API in AbtXmlStreamConverter to map the specified encoding value to a valid code page supported by the platform. AbtXmlStreamConverter mapEncoding: 'UTF-8' toCodePage: 65001

-------------------------------

The deployment descriptor contains a <schemaUrls> block for this purpose. Schemas that are imported by deployed WSDL documents are automatically deployed to the container and do not need to be included in the <schemaUrls> block of the deployment descriptor.

Use the <schemaUrls> block to: - Specify XML schemas required to provide supplemental functionality (ie. SOAP 1.2, WS-Security ) - Override schemas that are already deployed to the global XML object cache (ie. WSDL, SOAP)

-------------------------------

VAST Web services containers can be configured to enable processing of SOAP 1.2 messages. This is accomplished by deploying SOAP 1.2 schemas and mapping specifications to the server container. See the sample directory /samples/sstws/soap12/Readme.txt for additional information about configuring a Web services container for SOAP 1.2.

The same Web services container can be used to process SOAP 1.1 and SOAP 1.2 messages.

-------------------------------

VAST Web services client containers can be configured to enable processing of SOAP 1.2 messages. This is accomplished by deploying SOAP 1.2 schemas and mapping specifications to the client container. In addition, SstWSService instances contain accessors to allow the SOAP 1.2 namespace to be specified for outgoing SOAP messages.

See the sample directory /samples/sstws/soap12/Readme.txt for additional information about configuring a Web services container for SOAP 1.2.

-------------------------------

The schema (http://schemas.xmlsoap.org/ws/2002/07/secext/) must be managed by the serializationManager of the Web services container. This is accomplished by modifying the client deployment descriptor to include the required schema.

Authorization credentials can be specified in the SstWSService that is being invoked causing those credentials to be passed automatically as part of the message. The SstWSService contains accessors for getting and setting HTTP authorization credentials (#sstAuthCredential:) as well as WS-Security username tokens (#sstUsernameToken:). See the sample directory /samples/sstws/ws_security/Readme.txt for additional information and examples.

-------------------------------

The default servlet for processing incoming Web services messages is SstWSServlet. Developers may provide their own custom servlet if more sophisticated rocessing is required. To enable an alternative servlet using the default http transport strategy, execute code like that shown below:

The container configuration supports transport mappings that are used to map url schemes to the registered SST transport schemes used for invocation.

The #urlScheme setting can specify a full URL name to enable special processing for a specific resource location, or the value can be a scheme prefix (ie. 'http' or https') for general cases.

The #transportScheme is the identifier for an SstTransport configuration that describes the details of the underlying communications protocol.

The code below accomplishes the same task:

SST transport schemes must be registered in class SstTransport prior to usage. See the class methods #serverTransportConfiguration and registerPluginConfigurations in SstHttpCommunications for an example of how transport configurations are created and registered.

-------------------------------

The resource files 'sstaxis.map' and 'sstaxis.xsd' contain the rules required for mapping Smalltalk Dictionary objects to/from XML. Dictionaries are represented in XML as 'Map' elements in the namespace 'http://xml.apache.org/xml-soap'

-------------------------------

Execute SstWSContainer’s class side method resetWebServicesDevelopmentEnvironment. The method can be useful in several scenarios such as a failed deployment, or a failed deserialization attempt.

In both these cases, schemas can be left in several caches which should be removed so that any modifications made to them will take effect during the next test. Schemas are cached in lookup tables with the namespace as a key. If you update a schema and its namespace exists in these caches as a key, the schema will not be updated or re-imported.

The method also clears all containers from SstWSContainer's cache and resets the secure socket registry.