Comments
Faults
A service implementation is responsible for processing header and body
parts accoring to its application's need.
Where appropriate it should implement the necessary processing in order to comply
with SOAP specifications.
For example, if ti encounters an inconsistent message part, like a mustUnderstand header
which is not understood, it should generate and return the appropriate SOAP fault.
Intermediary Service
If a service is acting as an intermediary it may, after performing its function,
relay the message to another service using the SOAP client service.
A service implementation is responsible for knowing which actor/role it is currently playing.
WSDL Generation
the wsdlGenerator can be used to dynamically generate a WSDL description
for a SOAP service endpoint.
If uses information from the SOAPServiceMap configuration resource to generate
the WSDL document.
The HTTPBridge will direct SOAP mode requests for URLs with a ?WSDL
query to the wsdlGenerator
service.
wsDocumentation
WSDL is a machine readable formal description of a SOAP service.
Whilst this is concise it is frequently useful to provide a human readable description
of a service.
The HTTP Bridge will direct SOAP mode requests for URLs with a
?DOC query to the
wsDocumentation service.
This implements the mapper pattern and uses the SOAP
service map configuration file and endpoint URI to locate and issue a request to the
internal URI which provides the documentation for the service.
The ws_test module provides examples of a service with static HTML documentation and
a services which uses the NetKernel docxter engine to dynamically generate HTML documentation.
SOAP with Attachments
SOAP with attachments is currently an unstandardized extension to SOAP and a likely cause of incompatibility between
different SOAP servers
(see Steve Loughran's Fear of Attachments
).
Until there is more stability we have chosen not to support proprietary SOAP attachments.
For now there are two choices for a future-proof and compatible way to exchange
binary data. The first is to Base-64 encode your binary content and add it as the text of an element in the body part of the SOAP message - a base-64 encoding/decoding utility
is provided in the ext_layer1 module, org.ten60.netkernel.layer1.util.Base64. The second is to use a pass by reference
pattern by sending the URI to a servable client-side resource in the SOAP message which can be retrieved by the server-side's implementing process.
References
Preface
Cron
SOAP
