There is a close relationship between the metadata-based
Web Services Invocation Framework (WSIF) and the evolving semantics
of Web Services Description Language (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 Web Services Invocation Framework (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 you 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.