SOAP Framework and Connection 
SOAP is a lightweight protocol for exchanging information in a decentralized, distributed environment. It is an XML based protocol that consists of:
· A package that defines a framework for describing what is in a message and how to process it
· A set of encoding rules for expressing instances of data types defined by an application
· A convention for representing remote procedure calls and responses
SOAP also can be used in combination with a variety of other protocols. However, the only bindings defined in this document describe how to use SOAP in combination with HTTP and HTTP Extension Framework. The portal Web services supports the SOAP 1.1 specification. A Web service is an interface that describes a collection of operations that are network accessible through standardized XML Messaging.
WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. Portal Web services supports the WSDL 1.1 specification.
Common Connection Architecture for Web Services
The portal Web services give a common architecture to connect external Web services. In this case, the portal runtime will also provide its own implementation to generate proxy for Web services connection. If you need to contact external Web services, you should also use the portal Web services implementation to address them.
The open tool can generate a portal service from a WSDL file.
The PRT provides:
· An interpreter for the WSDL language, which enables you to:
¡ Make portal services
¡ Address external Web services
· Serializers/deserializers generator. It enables you to manage the custom types
· Complex Object wrapper
· Central configuration storage for the Web services configuration
SOAP Connection
The SOAP connection registers itself to the Portal Connection Framework to receive a request call, extract SOAP messages from it and to pass them to the SOAP Consumer.
The SOAPConnection class can receive an HttpRequest. It implements IServletConnection. It gets from the request the MimeHeaders and the ServletInputstream, to recreate the incoming SOAP message. The difference is that this approach enables the PRT to include the SOAP listening to the connection layer.
SOAP Consumer
The SOAP consumer is in charge of processing the SOAP message. That means that it must verify whether the SOAP message is PRT-compliant. If the XML SOAP message description is well formatted and if the called service exists on the Portal Runtime environment, then the SOAP consumer can work correctly. The SOAP consumer is also in charge of the answer construction. It calls the service manager to access the called service.
SOAPConsumer class can read the SOAP message and its possible attachments together with the ServiceManager to retrieve, load the portal runtime services dynamically and address the call to them.
To process a SOAP message, you need to unmarshal it first. The SOAP message is deserialized to transform it into a Java method call. The XML content is converted to Java code. When a SOAP message is constructed, however, the Java object is serialized to an XML content (marshal of the SOAP message). An XML tag represents a method, another a type, another one the value and so on. This process works also on interfaces and copes with inheritance (if a class has no deserializer, the parent class is asked for it – and so on for as many levels as required).
Processor
The processor insures the method invocation. A list of processors is maintained by the portal. Now, the only processor provided is a portal service.
SOAP Logger
There are two different types of logs in the PRT SOAP framework. All exceptions raised by the SOAP framework and the portal Web services are logged in the SOAP logger in the log folder of the PRT under the name soap.log.
The second type of information contained in the log is the SOAP debug information. In this mode, all SOAP messages in the XML format are logged.
By default the debug logger is disabled. To enable the SOAP logger to store the SOAP message and debug information you must select the “Log” property in the configuration menu of the SOAP Admin component.
Registries
Supported types (serialization and deserialization) are maintained by registries. A global one, the mapping registry, contains all SOAP types and some common Java types. Other registries are linked to services. Each service refers to its specialized registry to deals with custom types. These serializers and deserializers are included into the deployed PAR files.
The specialized registries are loaded in the class loader of the corresponding service.
Security Support
SOAP messages from a SAP Enterprise Portal to SOAP processors may not be encrypted. Other messages (that is, outgoing SOAP messages) need to be encrypted. Incoming SOAP messages are protected and verified to services being executed via SOAP attacks. There are two ways to do this:
· SOAP messages are included in an HttpRequest. The normal process of authentication included in the Portal Runtime environment can perform the authentication process. It means the use of HTTPs protocol and Single Sign-On (SSO) identification (in the SOAP header). The header also contains a way of checking the SOAP message integrity.
· Block the method call for users without permission to use them. It provides efficient security for the portal Web services.
See also: