Protocol Implementation Details 

Processing Message Content

It is a very simple procedure to process message content, but these messages determine which binding you want to process. Each binding works with its own messages, so there are two solutions. If you are interested in SOAP binding only, for example, then you can extend the SoapProtocolImpl or MimeProtocolImpl found in the binding directory, and implement the methods described in the SOAPProtocol or MimeProtocol interfaces. This approach causes highly-optimized, binding-specific messages to flow through the framework, which have all the specific binding fields required. It is relatively easy to write a protocol that can handle all the binding-specific messages it wants, since only one generic handler methods type check must be performed and typecast to a binding-specific message.

Processing Message Content

It is a very simple procedure to process the message content, but the messages determine which binding you want to process. Each binding works with its own messages. How many binding-specific messages the protocol supports depends on the protocol implementers. All binding-specific messages extend the AbstractMessage class. You can check the type of the message that is passed with the instanceof expression. It you are interested in SOAP binding only, for example, then you can extend the SoapProtocolImpl or the MimeProtocolImpl found in the binding directory, and implement the methods described in the SOAPProtocol or MimeProtocol interfaces. These are both implementations of AbstractProtocol and they provide the instance check and the typecast of the AbstractMessage to the binding-specific message. This approach causes highly-optimized, binding-specific messages to flow through the framework, which have all the specific binding fields required. If you want to process messages produced by more than one binding, use the AbstractProtocol interface and do the message typecast yourself.

The check on the type of the messages passed to the protocol by the binding must always be performed, since some binding (unknown to the developer) may try to call the protocol without delivering a proper message.

Adding Protocols to Standalone Proxies

Create a property file called protocols.txt in the directory where you have placed your generated stubs. The keys are the names of the protocols, obtained through FeatureProviderInterface.getName(). The values are the fully qualified names of the implementation classes. For example:

<ProtocolName>=<Protocol Implementation Class name>

When the standalone service class is instantiated, it reads protocols.txt and creates protocol instances

Retrieving Protocols and Feature Configurations During Client Runtime

This is an easy task, but is slightly incompatible with JAX-RPC (JSR 109). You have to cast your proxy client stub to:

com.sap.engine.services.webservices.jaxrpc.wsdl2java.BaseGeneratedStub.

This is the base class for all client stubs. This typecast will expose the following methods to the developer:

·        ProtocolList _getGlobalProtocols() - returns the global protocol list

·        ProtocolList _getOperationProtocols(String operationName) – returns the operation protocols

·        PropertyContext _getGlobalFeatureConfig() - returns the operation protocols

·        PropertyContext _getOperationFeatureConfig(String operationName) – returns the operation protocol configuration.

The ProtocolList class implements the List interface and is used for encapsulation purposes only.

Client Stub Configuration

The Stub is a class that implements the standard JAX-RPC stub interface javax.xml.rpc.Stub. There are two methods that enable you to set the user properties for the stub:

public void _setProperty(String key, Object value);

public Object _getProperty(String key);

The key names for these properties are shown below. The values are of type String and they are provided by the javax.xml.rpc.Stub interface:

SECURITY_USERNAME = "javax.xml.rpc.security.auth.username"; // Default not set

SECURITY_USERPASS = "javax.xml.rpc.security.auth.password"; // Default not set

PORT_ENDPOINT = "javax.xml.rpc.service.endpoint.address"; // Default set

HTTPPROXYPORT = "javax.xml.rpc.http.proxyport"; // HTTP proxy port

HTTPPROXYHOST = "javax.xml.rpc.http.proxyhost"; // HTTP proxy host

When you set the runtime of these properties they overwrite the feature values set in logical port configuration. An example is provided below.

// For deployable Web service clients InitialContext ctx = new InitialContext(); FooServiceInterface fsi = (FooServiceInterface)ctx.lookup(“FooService”); // For standalone Web service clients FooServiceInterface fsi = new FooServiceInterfaceImpl(); FooPort pf = (FooPort)fsi.getLogicalPort(FooPort.class); pf._setProperty(FooPort.HTTPPROXYPORT, “8080”); pf._setProperty(FooPort.HTTPPROXYHOST, “proxy”);