33 lines
2.8 KiB
HTML
33 lines
2.8 KiB
HTML
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||
|
|
<html>
|
||
|
|
<head>
|
||
|
|
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
|
||
|
|
<LINK rel="stylesheet" type="text/css" href="../../../rzahg/ic.css">
|
||
|
|
|
||
|
|
<title>WSIF and WSDL</title>
|
||
|
|
</head>
|
||
|
|
|
||
|
|
<BODY>
|
||
|
|
<!-- Java sync-link -->
|
||
|
|
<SCRIPT LANGUAGE="Javascript" SRC="../../../rzahg/synch.js" TYPE="text/javascript"></SCRIPT>
|
||
|
|
|
||
|
|
<h5><a name="wswsifwsdl">WSIF and WSDL</A></h5>
|
||
|
|
|
||
|
|
<p>In Web Services Description Language (WSDL), a service is defined in three distinct parts:</p>
|
||
|
|
|
||
|
|
<ul><li><strong>The PortType</strong> The PortType 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 output messages. A message is defined as a set of parts, and each part has a schema-defined type. </li>
|
||
|
|
<li><strong>The Binding</strong> A binding defines how to map between the abstract PortType and a real service format and protocol. For example, the Simple Object Access Protocol (SOAP) binding defines the encoding style, the SOAPAction header, and the namespace of the body (the targetURI). </li>
|
||
|
|
<li><strong>The Port.</strong> This defines the actual location (endpoint) of the available service. For example, the HTTP URL on which a SOAP service is available.</li> </ul>
|
||
|
|
<p>Currently in WSDL, each Port has one and only one binding, and each binding has a single PortType. But each Service (PortType) can have multiple Ports, each of which represents an alternative location and binding for accessing that service.</p>
|
||
|
|
|
||
|
|
<p>Web Services Invocation Framework (WSIF) follows the semantics of WSDL as much as possible:</p>
|
||
|
|
<ul>
|
||
|
|
<li>The WSIF dynamic call API directly exposes run time equivalents of the model from WSDL. For example, calling an operation involves executing an operation with an Input Message. </li>
|
||
|
|
<li>WSDL has extension points that allow new ports and bindings to be added so that WSDL can describe new systems. The equivalent concept in WSIF is a provider, that allows WSIF to understand a class of extensions, and therefore support new service implementation types. </li>
|
||
|
|
</ul>
|
||
|
|
<p>As a metadata-based call framework, WSIF follows the design of the metadata. As WSDL is extended, WSIF is updated accordingly.</p>
|
||
|
|
<p><strong>Note:</strong> The implicit and primary type system of WSIF is XML Schema, not Java. WSIF supports calls using dynamic proxies, which support Java type systems, but when you use the WSIFMessage interface it is your responsibility to populate WSIFMessage objects with data based on the XML Schema types as defined in the WSDL document. You should define types of objects by a canonical and fixed mapping from schema types into the run time.</p>
|
||
|
|
|
||
|
|
</body>
|
||
|
|
</html>
|