WAS v8.5 > WebSphere applications > Web services > WSIF > WSIF OverviewWSIF and WSDL
There is a close relationship between the metadata-based WSIF and the evolving semantics of WSDL.
In WSDL, a service is defined in three distinct sections:
- The portType. This section defines the abstract interface offered by the service. A portType defines a set of operations. Each operation can be In-Out (request-response), In-Only, Out-Only and Out-In (Solicit-Response). Each operation defines the input and/or output messages. A message is defined as a set of parts, and each part has a schema-defined type.
- The binding. This section defines how to map between the abstract portType and a real service format and protocol. For example the SOAP binding defines the encoding style, the SOAPAction header, the namespace of the body (the targetURI), and so on.
- The port. This section defines the location (endpoint) of the available service. For example, the HTTP web address at which a SOAP service is available.
Currently in WSDL, each port has one and only one binding, and each binding has a single portType. But (more importantly) each service (portType) can have multiple ports, each of which represents an alternative location and binding for accessing that service.
The WSIF follows the semantics of WSDL as much as possible:
- The WSIF dynamic invocation API directly exposes runtime equivalents of the model from WSDL. For example, invocation of an operation involves executing an operation with an input message.
- WSDL has extension points that support the addition of new ports and bindings. This enables WSDL to describe new systems. The equivalent concept in WSIF is a provider, which links the WSIF service to the underlying implementation of the service. This enables WSIF to understand a class of extensions and thereby to support a new service implementation type.
As a metadata-based invocation framework, WSIF follows the design of the metadata. As WSDL is extended, WSIF is updated to follow.
The primary type system of WSIF is XML schema. WSIF supports invocation using dynamic proxies, which in turn support Java type systems, but when we use the WSIFMessage interface to invoke a Web service through the WSIF API you must populate WSIFMessage objects with data based on the XML schema types as defined in the WSDL document. You should define your object types by a canonical and fixed mapping from schema types into the runtime environment.
Related concepts:
WSIF architecture
WSIF usage scenarios
Related
Linking a WSIF service to the underlying implementation of the service
Invoking a WSDL-based web service through the WSIF API
Reference:
Web services specifications and APIs