Server-Side General Architecture 
Purpose
As stated before, the Web services framework is a modular framework, offering several extension points. Later in this document we will also refer to these points as pluggable components. This component provides only a high-level overview of the main architectural elements.
 |
This graphic is an overview of the process of invoking a Web service implementation.
At the beginning, a client initiates a call to a Web service, to a port hosted by the dedicated transport implementation. The transport forwards this call to the Web Services Runtime. After some processing to find which is the Web service implementation or configuration being invoked, the framework calls the particular configuration for this configuration protocol. Each protocol is invoked in turn. It possesses its own logic, which may include (but is not limited to) the processing of the actual message being transferred.
Next, the transport binding takes care to create the Java objects that will be used to invoke the Web service implementation. At the end, the implementation container receives the Java objects, and invokes the Web service implementation.
Afterwards, the implementation container returns a response object to the transport binding. It serializes the object in the fixed wire format. The response message is passed through the protocols, and, finally, the transport sends it back to the client.
Note that, in this short overview, neither HTTP, SMTP, SOAP nor any other fixed methods were mentioned. Indeed, theoretically, it should be possible to use any transport, wire format, protocol or Web service implementation.
Note that some techniques require a lot of knowledge and advanced skills to implement.
A more detailed overview of each of the main components of the Web services framework follows.
Features
Transport
The transport is an entity that acquires data, encapsulates it inside a transport object, and gives it to the Web services runtime. A transport must be capable of uniquely identifying a request. This functionality is used by the Web services runtime to find the correct Web service implementation.
Protocol
Once the Web service implementation and configuration have been identified, the list of runtime features required for this service is loaded. Each feature is mapped to a protocol implementation. This mapping is part of the Web service configuration. The Web services runtime starts invoking the protocols. As the protocols are implemented as Java services, they have access to all of the features provided by the SAP J2EE Engine (for example, they may query the Security Service for active user roles, use the Configuration Service to store persistent data, and so on). In addition, the protocol has access to the whole message, and the transport specific properties (such as HTTP headers for the HTTP transport). The protocol may read or write the message and the transport-specific properties in a way that is required for its proper execution.
A protocol can have a different configuration for each different Web service configuration or even operation. The configuration of a protocol is done in the SAP NetWeaver Developer Studio, and is property-based. It is invoked to handle the request, the response or the fault if there is one.
Transport Binding
As all other components, this element is also implemented as a Java service. But unlike the protocol and transport components, this one has a lot of responsibilities. Its main task is, given a wire stream message, to process it and create appropriate Java objects. These objects are handled by the implementation container, which does the invocation of the Web service implementation. Since the wire message can have any format, one of the subtasks of the transport binding is to generate the binding part of the WSDL. In this way, the client knows what to send and the transport binding knows how to handle it when it receives it. The transport binding does not have to handle any schema and port-type details. This stuff is handled in the core parts of the framework. Since there are several official port-type and schema formats, the binding needs to tell to the runtime, which format it needs – document/literal, rpc/encoded, or rpc/literal. In the final WSDL the framework will take care to set a reference from this binding to the proper port-type.
Typically, a binding may need to add schema types to the types section in the WSDL, messages and parts to existing messages. At least this functionality should be present if we want to provide the transport binding with full control. But actually this breaks the WSDL interface/implementation paradigm, which is required for many scenarios involving UDDI. In short, the binding of a service should implement a port-type that is not dependant of any binding.
Implementation Container (IC)
The task of the Implementation Container is to find and invoke the Web service implementations. For each Web service configuration there is a set of properties enabling the Implementation Container to find and load the proper implementation.
For EJBeanImplementationContainer, these properties are BeanName, JarName, and Application Name. The IC takes the objects, invokes the proper implementation, and then it returns either the response or the fault to the runtime.
Due to the classloading requirements in Java, before the invocation process, the Transport Binding has to ask the IC for a Classloader, which is used to load the instances of the deserialized objects.
Probably, it is not required for all Transport Bindings and ICs, especially if the hosted Web Service Implementations have only methods with simple Java types.
The IC also exposes some methods that allow a statefull protocol to manage sessions with implementations. In case of no active session, the Web Services Runtime makes use of these methods, allows reusal of stateless implementation, as turning them into performance benefits.
See also: