Web services and Bindings in Siebel 7.8

Siebel Systems is the world's leading provider of customer relationship management software and a leading provider of software applications for business intelligence and business integration. Siebel Systems began supporting Web Services standards with the release of Siebel 2000. Since that time, it has introduced several key infrastructure enhancements that allow Siebel customers to publish and consume XML documents over a variety of transports, including HTTP and Message Queuing. Siebel 7.7/7.8 provides support for two of the core Web Services standards (SOAP version 1.1 and WSDL version 1.1) by building upon the XML and HTTP support previously introduced in Siebel 2000.


Web Services Infrastructure

The Web Services infrastructure has been enhanced in Siebel 7.7/7.8 to provide:

• Document-Literal and RPC-Literal binding support—By providing the ability to
publish a Siebel Web Service as a Document-Literal or RPC-Literal bound Web Service,
Siebel is adhering to the specification as defined by the Web Services Interoperability
Organization’s (WS-I) Basic Profile Version 1.0 specification.5 Adherence to this
specification reduces the total cost of integration by ensuring that Siebel can successfully
interoperate with external Web Service providers.

RPC allows the use of transports other than HTTP (for example, MQ and
MSMQ), because you do not have to use the SOAPAction header to specify
the operation.
The following specifications are required for using RPC-literal:
• An RPC-literal binding in a description must have the namespace attribute
specified, the value of which must be an absolute uniformed resource instant
(URI), on contained soapbind:body elements.

• A message described with an RPC-literal binding that is a response message
must have a wrapper element whose name is the corresponding
wsdl:operation name suffixed with the string Response.

• A message described with an RPC-literal binding must place the part
accessory elements for parameters and return value in no namespace.

• A wsdl:message in a description may contain wsdl:parts that use the elements
attribute provided that those wsdl:parts are not referred to by a soapbind:body
in an rpc-literal binding.





Document/literal (wrapped)
• Messaging with plain XML instance documents (rather than invoking operations with parameters serialized into XML - RPC).
• For multiple XML docs, nest them within a single wrapper element (which can be simply added to the section of the WSDL file). The has only one nested sub-element (WS-I compliant).
• Doc style SOAP messages are very similar to RPC/literal messages as both produce a single nested element with the . The main difference is that each element is fully qualified with a Schema defined ns (enables validation of complex data).




Advantages and Disadvantages of Each WSDL Binding Style and SOAP Encoding
Style
Advantages
Disadvantages
RPC
Encoded


• Simple WSDL

• Operation name wraps parameters



• Complex types are sent as multipart references meaning can have multiple children

• Not WS-I compliant

• Not interoperable

• Type encoding information generated in soap message

• Messages can’t be validated

• Child elements are not fully qualified

RPC
Literal


• Simple WSDL

• Operation name wraps parameters

• has only one element

• No type encoding information

• WS-I compliant



• Difficult to validate message

• Sub elements of complex types are not fully qualified.

Doc
Literal


• No type encoding information

• Messages can be validated

• WS-I compliant but with restrictions

• Data can be modelled in separate schema



• WSDL file is more complicated

• Operation name is missing in soap request which can create interoperability problems

• can have multiple children

• WS-I recommends only one child in


Document/literal wrapped style is best, especially if you need to describe, model and validate complex data.


• Custom SOAP header support—Headers represent SOAP’s extensibility mechanism
and provide a flexible and standards-based mechanism of adding additional context
to a request or response. Providing custom SOAP header support provides Siebel
customers and partners a flexible extensibility mechanism when integrating with
external Web Services, and a means of providing additional context as required by
the Web Service implementation.
By customizing the SOAP headers sent through with the SOAP envelope, you can provide
the authentication credentials with the data, or even supply additional authentication tokens
that can be used to verify the source of the SOAP envelope.
Using custom SOAP headers separates authentication data from application data. Having
this distinction between application data and authentication data is a good design principle
to follow and can be helpful when troubleshooting a Web service, as it helps to identify whether
a particular problem has been caused by incorrect credentials or invalid data.
Further, this logical separation enables the developer to concentrate on providing the real power
behind the Web service: the business logic

• Handling custom headers using filters—SOAP headers provide customers with the
option of providing optional or mandatory processing information. To process optional
custom headers that are provided by external applications, a special business service
known as a filter may be defined. Filters can process both request and response headers.

• One-Way operation support—One-Way operations provide a means of sending a
request to a Web Service with the expectation that a SOAP response will not be returned.
Siebel 7.7 provides the ability to publish and consume Web Services that implement
One-Way operations.


Siebel Application Service Interfaces (ASIs)
An Application Services Interface (ASI) is a release independent interface published by Siebel Systems, in a standard metadata
format - XML DTD, WSDL/XSD and can be exposed as Web Services, XML or Java for external apps and support HTTP and MQ
transports.
ASIs use the standard metadata format, which makes ASIs language-independent, so they return the same value type regardless of language setting Siebel ASIs are prebuilt and can be used immediately.
ASIs provide a release-independent integration interface to the Siebel application, which remains unchanged with each upgrade to a new release