axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From antel...@apache.org
Subject cvs commit: xml-axis-wsif/java/README_files/wsdl_extensions java_extension.html
Date Fri, 20 Sep 2002 08:42:56 GMT
antelder    2002/09/20 01:42:56

  Modified:    java/README_files/wsdl_extensions java_extension.html
  Log:
  Correct some minor spelling and gramatical errors
  
  Revision  Changes    Path
  1.2       +12 -12    xml-axis-wsif/java/README_files/wsdl_extensions/java_extension.html
  
  Index: java_extension.html
  ===================================================================
  RCS file: /home/cvs/xml-axis-wsif/java/README_files/wsdl_extensions/java_extension.html,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- java_extension.html	17 Sep 2002 15:56:40 -0000	1.1
  +++ java_extension.html	20 Sep 2002 08:42:56 -0000	1.2
  @@ -7,9 +7,9 @@
     <body>
       <h2>Java binding</h2>
       <hr>
  -<p>The java binding is a WSDL binding that allows abstract functionality in the abstract
service description (messages, operastions and port types) to be mapped to functionality offered
by a java class directly. This means that a java class can be described using WSDL, and can
be accessed as a WSDL-described service through WSIF.</p>
  +<p>The Java binding is a WSDL binding that allows abstract functionality in the abstract
service description (messages, operations and port types) to be mapped to functionality offered
by a Java class directly. This means that a Java class can be described using WSDL, and can
be accessed as a WSDL-described service through WSIF.</p>
   
  -<p>The java binding extends WSDL with the following extensibility elements:</p>
  +<p>The Java binding extends WSDL with the following extensibility elements:</p>
   
   <p><tt><pre>
   &lt;definitions .... &gt; 
  @@ -47,24 +47,24 @@
   
   <ul>
   <li><b><tt>java:binding</tt></b>
  -<p>This indicates that the binding is a java binding.</p></li>
  +<p>This indicates that the binding is a Java binding.</p></li>
   
  -<li><b><tt>format:typemapping</tt></b>
  -<p>This element allows the specification of a mapping from abstract types used in
WSDL message parts (within the abstract service description) to java types that can represent
the same information. The style attribute is used to say something about the target type system
(i.e. the native type system being used to represent the abstract information); in the case
of the java type system the value here must be "Java". This use of this attribute allows this
extension to be reused for other kinds of bindings. The encoding attribute must be a URI which
is used to denote the specific way in which the native type corresponds to the abstract type.
We define a special encoding, the "Java" encoding, with the rules that tell us how to create
a java class corresponding to an abstract schema type that can be used through the WSDL java
binding. Details on the "Java" encoding follow. Having the encoding attribute allows us to
map abstract types to java types in other convenient ways by using a customized encoding.</p></li>
  +<li><b><tt>format:typeMapping</tt></b>
  +<p>This element allows the specification of a mapping from abstract types used in
WSDL message parts (within the abstract service description) to Java types that can represent
the same information. The style attribute is used to say something about the target type system
(i.e. the native type system being used to represent the abstract information); in the case
of the Java type system the value here must be "Java". The use of this attribute allows this
extension to be reused for other kinds of bindings. The encoding attribute must be a URI which
is used to denote the specific way in which the native type corresponds to the abstract type.
We define a special encoding, the "Java" encoding, with the rules that tell us how to create
a Java class corresponding to an abstract schema type that can be used through the WSDL Java
binding. Details on the "Java" encoding follow. Having the encoding attribute allows us to
map abstract types to Java types in other convenient ways by using a customized encoding.</p></li>
   
   <p><b>Java encoding</b><br>
  -The java encoding used by WSIF is unspecified. The reason it does not need to be specified
is that encoding information is useful only when the information contained within the java
object is transformed in some way - serialized to a SOAP message, or converted to a representation
in another type system for example. If all we do with a WSIF message containing parts belonging
to the java type system is invoke the corresponding java service, we don't need to do anything
more than verify that each message part is is represented using a java object of the correct
type (as specified by the typemapping element in the java binding).<br>
  -Of course, we envisage the need for transforming messages from one representation to another,
but we leave the complete specification of the java encoding for a later release.</p>
  +The Java encoding used by WSIF is unspecified. The reason it does not need to be specified
is that encoding information is useful only when the information contained within the Java
object is transformed in some way - serialized to a SOAP message, or converted to a representation
in another type system for example. If all we do with a WSIF message containing parts belonging
to the Java type system is invoke the corresponding Java service, we don't need to do anything
more than verify that each message part is represented using a Java object of the correct
type (as specified by the typemapping element in the Java binding).<br>
  +Of course, we envisage the need for transforming messages from one representation to another,
but we leave the complete specification of the Java encoding for a later release.</p>
   
   <li><b><tt>format:typemap</tt></b>
  -<p>Each typemap element maps an abstract type to a type in some more convenient type
system; in the case of the java binding this is the java type system. The typeName attribute
is a qualified name for the abstract type being mapped (this must be one of the predefined
schema types recognised in WSDL, or a type defined under the <types> section in the
WSDL). The elementName attribute may be used to specify an element instead of a type (since
WSDL message parts can be described either way). The formatType attribute is the java type
corresponding to that abstract type or element. It values must be one of the primitive java
types (char, byte, short, int, long, float, double) or the fully qualified name of a java
class.</p></li>
  +<p>Each typemap element maps an abstract type to a type in some more convenient type
system; in the case of the Java binding this is the Java type system. The typeName attribute
is a qualified name for the abstract type being mapped (this must be one of the predefined
schema types recognised in WSDL, or a type defined under the <types> section in the
WSDL). The elementName attribute may be used to specify an element instead of a type (since
WSDL message parts can be described either way). The formatType attribute is the Java type
corresponding to that abstract type or element. Its value must be one of the primitive Java
types (char, byte, short, int, long, float, double) or the fully qualified name of a Java
class.</p></li>
   
   <li><b><tt>java:operation</tt></b>
  -<p>This element maps an abstract WSDL operation to a java method. The methodName
attribute specifies the name of the java method corresponding to the abstract operation. The
parameterOrder attribute is similar to and overrides the paramterOrder specification in the
abstract operation. It specifies the ordering of the input message parts for the invocation;
in the java binding case it identifies the method signature. Having a parameterOrder attribute
here allows us to map an abstract operation to a java method even if their signatures aren't
compatible in the ordering of parts. The returnPart is that part of the abstract output message
which corresponds to the return value of the java method. The methodType attribute specifies
whether the java method is a contructor, a static method or an instance method.</p></li>
  +<p>This element maps an abstract WSDL operation to a Java method. The methodName
attribute specifies the name of the Java method corresponding to the abstract operation. The
parameterOrder attribute is similar to and overrides the paramterOrder specification in the
abstract operation. It specifies the ordering of the input message parts for the invocation;
in the Java binding case it identifies the method signature. Having a parameterOrder attribute
here allows us to map an abstract operation to a Java method even if their signatures aren't
compatible in the ordering of parts. The returnPart is that part of the abstract output message
which corresponds to the return value of the Java method. The methodType attribute specifies
whether the Java method is a constructor, a static method or an instance method.</p></li>
   
   <li><b><tt>java:address</tt></b>
  -<p>This element is an extension under the WSDL port element that allows specification
of a java object as an endpoint for a service available via the java binding. The port whose
address is specified this way must be associated with a java binding only.</p>
  -<p>The className attribute specifies the fully qualified name of the java class to
be used for service invocation. The optional classPath attribute specifies the classpath to
be set prior to invocation, and the optional classLoader attribute specifies the class loader
to be used for loading the service class. If invoking an instance method, the service user
can load and instantiate the service class; it is upto the service provider to insure that
a public no-argument constructor is available. All other java methods/constructors used for
mapping abstract operations must also be publicly available in the service class.</p>
  +<p>This element is an extension under the WSDL port element that allows specification
of a Java object as an endpoint for a service available via the Java binding. The port whose
address is specified this way must be associated with a Java binding only.</p>
  +<p>The className attribute specifies the fully qualified name of the Java class to
be used for service invocation. The optional classPath attribute specifies the classpath to
be set prior to invocation, and the optional classLoader attribute specifies the class loader
to be used for loading the service class. If invoking an instance method, the service user
can load and instantiate the service class; it is up to the service provider to insure that
a public no-argument constructor is available. All other Java methods/constructors used for
mapping abstract operations must also be publicly available in the service class.</p>
   </ul>
   
   <h4>Example:</h4>
  @@ -176,6 +176,6 @@
     &lt;/service&gt;
   
   &lt;/definitions&gt;</pre></tt></p>
  -<p>In the above example, an address book service is offered through the java class
<tt>addressbook.wsiftypes.AddressBook</tt>. The service offers two variants of
the <tt>addEntry</tt> operation. One takes an input message consisting of a full
name and address and the other accepts an input message with a first name and last name (as
separate message parts) and an address. Both of these operations are mapped to a java method
called <tt>addEntry</tt>, but there are different parameter lists (this is an
overloaded method in the implementing class). Finally, the abstract operation <tt>getAddressFromName</tt>
is mapped to a java method of the same name. The types <tt>typesns:address</tt>
and <tt>xsd:string</tt> used during method invocations are mapped to java types
<tt>addressbook.wsiftypes.Address</tt> and <tt>java.lang.String</tt>
respectively. Note that the type <tt>typesns:phone</tt> does not need to be mapped
to a java type since it is contained within the address type which is represented by a known
java class. WSIF does not need to know how this class represents the information described
in the schema type if that is being done is service invocation. If we needed to inspect the
information in the WSIF message and transform it in some way, we would need details on how
the java class represents the type information (see the above discussion on the java encoding).</p>
  +<p>In the above example, an address book service is offered through the Java class
<tt>addressbook.wsiftypes.AddressBook</tt>. The service offers two variants of
the <tt>addEntry</tt> operation. One takes an input message consisting of a full
name and an address and the other accepts an input message with a first name, a last name
(as separate message parts), and an address. Both of these operations are mapped to a Java
method called <tt>addEntry</tt>, but there are different parameter lists (this
is an overloaded method in the implementing class). Finally, the abstract operation <tt>getAddressFromName</tt>
is mapped to a Java method of the same name. The types <tt>typesns:address</tt>
and <tt>xsd:string</tt> used during method invocations are mapped to Java types
<tt>addressbook.wsiftypes.Address</tt> and <tt>Java.lang.String</tt>
respectively. Note that the type <tt>typesns:phone</tt> does not need to be mapped
to a Java type since it is contained within the address type which is represented by a known
Java class. WSIF does not need to know how this class represents the information described
in the schema type if all that is being done is service invocation. If we needed to inspect
the information in the WSIF message and transform it in some way, we would need details on
how the Java class represents the type information (see the above discussion on the Java encoding).</p>
   <p>All the methods needed for invocation are instance methods, so a client would
need to create an instance of the service class. Since no classpath or class loader is specified,
the client can assume that there are no special service requirements in this regard, and can
just load and instantiate the class and begin using the address book service it implements.</p>
   </body></html>
  
  
  

Mime
View raw message