aslom 2002/12/10 10:37:26
Modified: java/doc RELEASE_TASKS.txt build.htm changes.html index.html
wsif.css
Added: java/doc cvs.html requirements.html
java/doc/wsdl_extensions ejb_extension.html
java_extension.html
Log:
updated doc/ with factored out info about cvs and requirements and improved build
instructions
Revision Changes Path
1.6 +4 -2 xml-axis-wsif/java/doc/RELEASE_TASKS.txt
Index: RELEASE_TASKS.txt
===================================================================
RCS file: /home/cvs/xml-axis-wsif/java/doc/RELEASE_TASKS.txt,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- RELEASE_TASKS.txt 6 Dec 2002 12:07:41 -0000 1.5
+++ RELEASE_TASKS.txt 10 Dec 2002 18:37:26 -0000 1.6
@@ -14,8 +14,9 @@
* [Jeremy Sat 11a GMT (6am EST)] fixing problem with text files marked by Eclipse
as binary in CVS
* [owen] investigate using Forrest for creating separate pages for WSIF outside Axis
* [nirmal + alek] samples and modularization
-* [alek] split README.html into smaller pices and make it addressing two
communities: WSIF users and WSIF developers; README.html right now is kind of mixed up
-* [alek] simplify wsif.css
+* DONE but will need mroe work [alek] split README.html into smaller pices and make
it addressing two communities:
+ WSIF users and WSIF developers; README.html right now is kind of mixed up
+* DONE [alek] simplify wsif.css
* [alek] check in JAR files that we know WSIF works OK with LICENSE and README(and
can be checked in)
* [jeremy] automatic generation of javadoc API
* get the link to the API javadoc off the home page working
@@ -47,3 +48,4 @@
* [nirmal, alek, Jeremy ???] for sampels it would be good to have something
pernament for EJB/JMS
using Open Source EJBs/JMS (such as JBoss), etc. can we do that? is that
feasible?
* [alek ...] LATER: modularisation
+* allow compiling with only AXIS jars on CLASSPATH (generate only Apapche Axis SOAP
provider)
1.3 +32 -4 xml-axis-wsif/java/doc/build.htm
Index: build.htm
===================================================================
RCS file: /home/cvs/xml-axis-wsif/java/doc/build.htm,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- build.htm 25 Nov 2002 06:32:56 -0000 1.2
+++ build.htm 10 Dec 2002 18:37:26 -0000 1.3
@@ -17,7 +17,8 @@
Xerces2). For detailed list of required and optional JAR files and how to obtain
them please take a look in lib/ subdirectories. Each subdirectory has short
README file that explains how to get needed JAR file if you do not have them
-already on your CLASSPATH.</p>
+already on your CLASSPATH. Check detailed <a href="requirements.html">list of
+requirements</a>.</p>
<h2>How to build?</h2>
@@ -27,11 +28,38 @@
and <b>all</b> will clean, compile and generate JAR file for WSIF.</p>
<p>There is also available set of scripts to make building easier if you copy
-required JAR files (including your preferred version of ANT) into lib/
-subdirectories and set JAVA_HOME. Then <b>build.bat</b> on Windows or <b>
+required JAR files (including your preferred version of ANT) into
+<a href="../lib">lib/
+subdirectories</a> and set JAVA_HOME. Then <b>build.bat</b> on Windows or <b>
build.sh</b> on UNIX will automatically pick up all jar files from lib/
subdirectories and call ANT to build WSIF. You can pass parameter to build
scripts and they will passed to ANT when building.</p>
+
+<h2>Building WSIF directly using ANT</h2>
+<ul>
+ <li>Obtain all the necessary jar files as listed in the prerequisites.
+ </li><li>Set required environment variables, including,
+ JAVA_HOME, ANT_HOME.
+ </li><li>From the root directory of wsif (where build.xml is located), run
+ <pre>ant -Dwsif.build.classpath=<classpath> <target></pre>
+ <p>where <classpath> contains the location of the preequisite JAR files<br>
+ <br>
+ and, where <target> is one of the following:
+ <ul>
+ <li><b>compile</b>: Compiles the API
+ </li><li><b>samples</b>: Compiles the samples
+ </li><li><b>javadocs</b>: Builds the javadoc
+ </li><li><b>srcdist</b>: Creates the source distribution
+ zip file.
+ </li><li><b>dist</b>: Creates the binary distribution zip
+ file.
+ </li><li><b>clean</b>: Removes built files.
+ </li><li><b>all</b>: Cleans, creates source and binary distribution
+ zip files.
+ </li></ul>
+</li></ul>
+
+<p> </p>
<h2>Building tests?</h2>
1.2 +1 -1 xml-axis-wsif/java/doc/changes.html
Index: changes.html
===================================================================
RCS file: /home/cvs/xml-axis-wsif/java/doc/changes.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- changes.html 5 Dec 2002 16:54:33 -0000 1.1
+++ changes.html 10 Dec 2002 18:37:26 -0000 1.2
@@ -14,7 +14,7 @@
Add only <b>significant</b> changes such as changing API, modifying
implementation behavior, major bug fixes (hyperlink to bugzilla), new
functionality. Do not give <b>too detailed</b> descriptions as they belong to
-CVS commint logs :-)<a name="WSIF_"><h3>2001-12- </h3></a>
+CVS commit logs :-)<a name="WSIF_"><h3>2001-12- </h3></a>
<ul>
<li>preparing first official release: added <a href="RELEASE_TASKS.txt">
RELEASE_TASKS.txt</a><li>work on first alpha release
1.2 +30 -29 xml-axis-wsif/java/doc/index.html
Index: index.html
===================================================================
RCS file: /home/cvs/xml-axis-wsif/java/doc/index.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- index.html 9 Dec 2002 22:51:42 -0000 1.1
+++ index.html 10 Dec 2002 18:37:26 -0000 1.2
@@ -4,9 +4,10 @@
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Author" content="Ant Elder">
<meta name="Author" content="Nirmal Mukhi">
- <meta http-equiv="Content-Style-Type" content="text/css"><title>Web Services
Invocation Framework for Java API - Overview</title>
+ <meta http-equiv="Content-Style-Type" content="text/css">
+ <title>Web Services Invocation Framework for Java API - Overview</title>
- <link rel="stylesheet" href="../README_files/wsif.txt" type="text/css">
+ <link rel="stylesheet" href="wsif.css" type="text/css">
</head>
<body alink="#0000ff" bgcolor="#ffffff" leftmargin="2" topmargin="2"
marginwidth="2" marginheight="2">
@@ -23,8 +24,8 @@
<li><a href="#Refs">References</a></li>
</ul>
<hr width="100%">
- <a name="WhatIsIt"/><h2>What is WSIF?</h2>
- <p>WSIF stands for the Web Services Invocation Framework. It supports a simple
Java
+ <a name="WhatIsIt"></a><h2>What is WSIF?</h2>
+ <p>WSIF stands for the Web Services Invocation Framework. It supports a simple
Java
API for invoking Web services, no matter how or where the
services are provided. The framework allows maximum
flexibility for the invocation of any WSDL-described service.</p>
@@ -39,7 +40,7 @@
natural client programming model.</p>
<p>The WSIF API allows clients to invoke services focusing on the
- abstract service description - the
+ abstract service description - the
portion of WSDL that covers the port types, operations and
message exchanges without referring to real protocols. The
<em>abstract invocations</em> work because they are backed up by
@@ -105,7 +106,7 @@
<hr width="100%">
<a name="CustomisingIt"/><h2>How can I customise my WSIF
- installation?</h2>
+ installation?</h2>
<p>There are many points within the WSIF API that allow for
customisation. <a href="samples.html">An advanced WSIF sample</a>
demonstrates how to write your own WSIF service factory so that
@@ -140,7 +141,7 @@
<P>A J2SE v1.3 SDK (eg from <A href="http://java.sun.com/j2se";>Java J2SE
site</A>) and the Apache Jakarta Ant tool to build wsif. Ant is available at the <A
href="http://jakarta.apache.org/ant";>Apache ANT website</A>.
To build WSIF the jars from the following packages are
required:</P><BLOCKQUOTE><TABLE width="90%">
<TBODY>
-
+
<TR>
<TD width="573">JAXP compliant XML parser, such as <A
href="http://xml.apache.org/xerces2-j/index.html";>Apache Xerces</A>.</TD>
<TD width="367">xercesImpl.jar xmlParserAPIs.jar</TD>
@@ -162,17 +163,17 @@
<TD width="573">J2EE 1.3 from the <A
href="http://java.sun.com/j2ee/";>Java J2EE site</A></TD>
<TD width="367">j2ee.jar</TD>
</TR>
-
+
</TBODY>
</TABLE>
</BLOCKQUOTE>
- <P>Currently, in order to successfully build WSIF, all the above prerequisites
+ <P>Currently, in order to successfully build WSIF, all the above prerequisites
are required no matter which providers are going to be used.</P>
<h3><a name="sourcecode">Accessing Builds and Source Code</a></h3>
- <p>The source code for this package is available on the Apache web site.
Individual
- files can be accessed using the web-based
- <a href="http://cvs.apache.org/viewcvs.cgi/xml-axis-wsif/";
target="_blank">CVS interface</a>.
+ <p>The source code for this package is available on the Apache web site.
Individual
+ files can be accessed using the web-based
+ <a href="http://cvs.apache.org/viewcvs.cgi/xml-axis-wsif/";
target="_blank">CVS interface</a>.
The entire package can be downloaded using the following instructions.</p>
<h3><b><font size="+1">Accessing the Nightly Builds</font></b></h3>
@@ -181,17 +182,17 @@
complete build image, which includes wsif.jar and the API Javadoc. The second
file contains a copy of the source code, which could
be built using Ant. Both of these files can be accessed at the same location
as the <a href="http://cvs.apache.org/dist/axis/nightly/";
target="_blank">Axis nightly builds</a>.</p>
-
+
<H3><B><FONT size="+1">Accessing the Source Tree (AnonCVS)</FONT></B></H3>
<p>So, you've decided that you need access to the source tree to see the latest
and greatest code. There's two different forms of CVS access. The first
is anonymous and anybody can use it. The second is not and you must have
a login to the development server. If you don't know what this means, join
the <a href="http://xml.apache.org/axis/mail.html";>mailing list</a> and find
out.</p>
- <p>Anyone can checkout source code from our anonymous CVS server. To do so,
- simply use the following commands (if you are using a GUI CVS client,
configure
- it appropriatly):
-
+ <p>Anyone can checkout source code from our anonymous CVS server. To do so,
+ simply use the following commands (if you are using a GUI CVS client,
configure
+ it appropriatly):
+
</p><blockquote>
<table width="90%">
<tbody>
@@ -207,17 +208,17 @@
</table>
</blockquote>
<h3><b><font size="+1">Full Remote CVS Access</font></b> </h3>
- <p>If you are a <i>Committer</i> and have a login on the
- Apache development server, this section is for you. If you are not a
Committer,
- but you want to submit patches or even request commit privelages, please see
the
- <a href="http://jakarta.apache.org/site/guidelines.html";
target="newone">Jakarta
- GuideLines </a>page (we follow the same rules) for more information.
+ <p>If you are a <i>Committer</i> and have a login on the
+ Apache development server, this section is for you. If you are not a
Committer,
+ but you want to submit patches or even request commit privelages, please see
the
+ <a href="http://jakarta.apache.org/site/guidelines.html";
target="newone">Jakarta
+ GuideLines </a>page (we follow the same rules) for more information.
</p>
- <p>To have full access to the CVS server, you need to follow the links
depending
- on the operating system you are using:
-
+ <p>To have full access to the CVS server, you need to follow the links depending
+ on the operating system you are using:
+
</p><ul>
- <li><a href="http://jakarta.apache.org/site/cvsonunix.html";
target="new">Unix</a>
+ <li><a href="http://jakarta.apache.org/site/cvsonunix.html";
target="new">Unix</a>
</li><li><a href="http://jakarta.apache.org/site/cvsonwin32.html";
target="new">Windows</a> </li>
</ul>
<h3>Building wsif</h3>
@@ -248,9 +249,9 @@
<h2>Reference</h2>
<ul>
<li><a
href="http://www.research.ibm.com/people/b/bth/OOWS2001/duftler.pdf";>WSIF Framework
proposal</a>
- </li><LI><A href="http://www.alphaworks.ibm.com/tech/wsif";>IBM's original
alphaWorks WSIF site</A></LI>
- <LI>The W3C <A href="http://www.w3.org/TR/wsdl";>Web Services Description
Language (WSDL) specification</A>,
- <A href="http://www.jcp.org/jsr/detail/110.jsp";>JSR110</A> describing the Java
APIs for WSDL, and the
+ </li><LI><A href="http://www.alphaworks.ibm.com/tech/wsif";>IBM's original
alphaWorks WSIF site</A></LI>
+ <LI>The W3C <A href="http://www.w3.org/TR/wsdl";>Web Services Description
Language (WSDL) specification</A>,
+ <A href="http://www.jcp.org/jsr/detail/110.jsp";>JSR110</A> describing the Java
APIs for WSDL, and the
<A
href="http://oss.software.ibm.com/developerworks/projects/wsdl4j";>WSDL4J</A>
opensource site.</LI>
<LI>IBM developerWorks articles <A
href="http://www-106.ibm.com/developerworks/webservices/library/ws-wsif.html";>Web
service invocation sans SOAP</A>
and <A
href="http://www-106.ibm.com/developerworks/webservices/library/ws-appwsif.html?loc=dwmain";>Applying
the Web services invocation framework</A></LI>
1.2 +5 -10 xml-axis-wsif/java/doc/wsif.css
Index: wsif.css
===================================================================
RCS file: /home/cvs/xml-axis-wsif/java/doc/wsif.css,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- wsif.css 14 Oct 2002 16:47:53 -0000 1.1
+++ wsif.css 10 Dec 2002 18:37:26 -0000 1.2
@@ -3,7 +3,7 @@
border-left-style : none;
border-right-style : none;
border-bottom-style : none;
- font-size : 12px;
+ font-size : 14px;
font-family : Arial,sans-serif;
}
A:hover {
@@ -15,7 +15,6 @@
;
}
H3 {
- background-color : #3cbfff;
padding-left : 6px;
padding-right : 6px;
padding-top : 2px;
@@ -24,19 +23,15 @@
font-family : Arial,sans-serif;
}
H2 {
- background-color : #004e9b;
PADDING-BOTTOM: 1px;
PADDING-LEFT: 4px;
PADDING-RIGHT: 4px;
PADDING-TOP: 1px;
- FONT-FAMILY: Arial
-;
- color : white;
+ FONT-FAMILY: Arial;
}
H1 {
text-align : left;
- FONT-FAMILY: Arial
-;
+ FONT-FAMILY: Arial;
padding-top : 1px;
padding-left : 1px;
padding-right : 1px;
@@ -56,8 +51,8 @@
;
}
.NOTESID {
- COLOR: #004400;
FONT-FAMILY: Arial
+ background-color : silver;
;
}
H4{
@@ -69,6 +64,6 @@
padding-bottom : 1px;
}
TABLE{
- font-size : 12px;
+ font-size : 14px;
font-family : Arial,sans-serif;
}
1.1 xml-axis-wsif/java/doc/cvs.html
Index: cvs.html
===================================================================
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Author" content="Ant Elder">
<meta name="Author" content="Nirmal Mukhi">
<meta name="Author" content="Aleksander Slominski">
<meta http-equiv="Content-Style-Type" content="text/css">
<title>Web Services Invocation Framework for Java API - Overview</title>
<link rel="stylesheet" href="wsif.css" type="text/css">
</head>
<body alink="#0000ff" bgcolor="#ffffff" leftmargin="2" topmargin="2"
marginwidth="2" marginheight="2">
<h1><a name="CVS">WSIF: <br>
CVS</a></h1>
<p>Read this if you want to work with latest version of source code (some
people call it 'bleeding edge' :-))</p>
<h2><a name="sourcecode">Accessing Builds and Source Code</a></h2>
<p>The source code for this package is available on the Apache web site. Individual
files can be accessed using the web-based
<a href="http://cvs.apache.org/viewcvs.cgi/xml-axis-wsif/"; target="_blank">CVS
interface</a>.
The entire package can be downloaded using the following instructions.</p>
<h3><b><font size="+1">Accessing the Nightly Builds</font></b></h3>
<p>This package is built nightly along with Axis. The build will create two
zip files: wsif-bin-1.2.zip and xml-axis.wsif-src.zip. The first file contains a
complete build image, which includes wsif.jar and the API Javadoc. The second file
contains a copy of the source code, which could
be built using Ant. Both of these files can be accessed at the same location
as the <a href="http://cvs.apache.org/dist/axis/nightly/"; target="_blank">Axis
nightly builds</a>.</p>
<H3><B><FONT size="+1">Accessing the Source Tree (AnonCVS)</FONT></B></H3>
<p>So, you've decided that you need access to the source tree to see the latest
and greatest code. There's two different forms of CVS access. The first
is anonymous and anybody can use it. The second is not and you must have
a login to the development server. If you don't know what this means, join
the <a href="http://xml.apache.org/axis/mail.html";>mailing list</a> and find out.</p>
<p>Anyone can checkout source code from our anonymous CVS server. To do so,
simply use the following commands (if you are using a GUI CVS client, configure
it appropriatly):
</p><blockquote>
<table width="90%">
<tbody>
<tr bgcolor="silver">
<td>
<pre>cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic login
password: anoncvs
cvs -d :pserver:[EMAIL PROTECTED]:/home/cvspublic checkout xml-axis-wsif</pre>
</td>
</tr>
</tbody>
</table>
</blockquote>
<h3><b><font size="+1">Full Remote CVS Access</font></b> </h3>
<p>If you are a <i>Committer</i> and have a login on the
Apache development server, this section is for you. If you are not a Committer,
but you want to submit patches or even request commit privelages, please see the
<a href="http://jakarta.apache.org/site/guidelines.html"; target="newone">Jakarta
GuideLines </a>page (we follow the same rules) for more information.
</p>
<p>To have full access to the CVS server, you need to follow the links depending
on the operating system you are using:
</p><ul>
<li><a href="http://jakarta.apache.org/site/cvsonunix.html"; target="new">Unix</a>
</li><li><a href="http://jakarta.apache.org/site/cvsonwin32.html";
target="new">Windows</a> </li>
</ul>
<p> </p>
<hr>
$Id: cvs.html,v 1.1 2002/12/10 18:37:26 aslom Exp $
</body></html>
1.1 xml-axis-wsif/java/doc/requirements.html
Index: requirements.html
===================================================================
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Author" content="Ant Elder">
<meta name="Author" content="Nirmal Mukhi">
<meta name="Author" content="Aleksander Slominski">
<meta http-equiv="Content-Style-Type" content="text/css">
<title>Web Services Invocation Framework for Java API - Overview</title>
<link rel="stylesheet" href="wsif.css" type="text/css">
</head>
<body alink="#0000ff" bgcolor="#ffffff" leftmargin="2" topmargin="2"
marginwidth="2" marginheight="2">
<h1><a name="Requirements">WSIF: <br>
Requirements</a></h1>
<p> </p>
<h3>Prerequisites</h3>
<P>A J2SE v1.3 SDK (eg from <A href="http://java.sun.com/j2se";>Java J2SE site</A>)
and the Apache Jakarta Ant tool to build wsif. Ant is available at the <A
href="http://jakarta.apache.org/ant";>Apache ANT website</A>.
To build WSIF the jars from the following packages are
required:</P><BLOCKQUOTE><TABLE width="90%">
<TBODY>
<TR>
<TD width="573">JAXP compliant XML parser, such as <A
href="http://xml.apache.org/xerces2-j/index.html";>Apache Xerces</A>.</TD>
<TD width="367">xercesImpl.jar xmlParserAPIs.jar</TD>
</TR>
<TR>
<TD width="573">WSDL for Java API (WSDL4J), from the <A
href="http://www-124.ibm.com/developerworks/projects/wsdl4j/";>IBM developerWorks
site</A>.
</TD>
<TD width="367">wsdl4j.jar qname.jar</TD>
</TR>
<TR>
<TD width="573">Apache SOAP, from the <A
href="http://xml.apache.org/soap";>Apache SOAP site</A></TD>
<TD width="367">soap.jar</TD>
</TR>
<TR>
<TD width="573">Apache Axis, from the <A
href="http://xml.apache.org/axis";>Apache Axis site</A></TD>
<TD width="367">axis.jar saaj.jar jaxrpc.jar
commons-logging.jar</TD>
</TR>
<TR>
<TD width="573">J2EE 1.3 from the <A
href="http://java.sun.com/j2ee/";>Java J2EE site</A></TD>
<TD width="367">j2ee.jar</TD>
</TR>
</TBODY>
</TABLE>
</BLOCKQUOTE>
<P>Currently, in order to successfully build WSIF, all the above prerequisites
are required no matter which providers are going to be used.</P>
<p> </p>
<hr>
$Id: requirements.html,v 1.1 2002/12/10 18:37:26 aslom Exp $
</body></html>
1.1 xml-axis-wsif/java/doc/wsdl_extensions/ejb_extension.html
Index: ejb_extension.html
===================================================================
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>EJB binding</title>
</head>
<body>
<h2>EJB binding</h2>
<hr>
<p>The EJB 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 an enterprise java bean directly. This means that an EJB can
be described using WSDL, and can be accessed as a WSDL-described service through
WSIF.</p>
<p>The EJB binding extends WSDL with the following extensibility elements:</p>
<p><tt><pre>
<definitions .... >
<!-- EJB binding -->
<binding ... >
<ejb:binding/>
<format:typeMapping style="uri" encoding="..."/>?
<format:typeMap typeName="qname"|elementName="qname"
formatType="nmtoken"/>*
</format:typeMapping>
<operation>*
<ejb:operation
methodName="nmtoken"
parameterOrder="nmtoken"?
returnPart="nmtoken"?
interface="home|remote"? />?
<input name="nmtoken"? />?
<output name="nmtoken"? />?
<fault name="nmtoken"? />?
</operation>
</binding>
<service ... >
<port>*
<ejb:address
className="nmtoken"
jndiName="nmtoken"?
initialContextFactory="nmtoken"?
jndiProviderURL="url"?
archive="nmtoken"? />
</port>
</service>
</definitions>
</pre></tt></p>
<p>Each element is described in detail below.</p>
<ul>
<li><b><tt>ejb:binding</tt></b>
<p>This indicates that the binding is an EJB 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>
<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>
<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 EJB 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>
<li><b><tt>ejb:operation</tt></b>
<p>This element maps an abstract WSDL operation to a method offered by an EJB
interface. The <em>methodName</em> attribute specifies the name of the java method
corresponding to the abstract operation. The <em>parameterOrder</em> attribute is
similar to and overrides the <em>parameterOrder</em> specification in the abstract
operation. It specifies the ordering of the input message parts for the invocation; in
the EJB binding case it identifies the method signature. Having a
<em>parameterOrder</em> attribute here allows us to map an abstract operation to an
EJB method even if their signatures aren't compatible in the ordering of parts. The
<em>returnPart</em> is that part of the abstract output message which corresponds to
the return value of the java method. The <em>ejbInterface</em> attribute specifies
whether the method is offered through the home interface or the remote interface of
the EJB; by default the client will assume that it is a method on the remote
interface.</p></li>
<li><b><tt>ejb:address</tt></b>
<p>This element is an extension under the WSDL <em>port</em> element that allows
specification of an EJB object as an endpoint for a service available via the EJB
binding. The port whose address is specified this way must be associated with an EJB
binding only.</p>
<p>The <emclassName</em> attribute specifies the fully qualified name of the java
class to be used for service invocation. The optional <em>jndiName</em> attribute
specifies the name under which this EJB can be looked up in a JNDI context. The
<em>initialContextFactory</em> and <em>jndiProviderURL</em> attributes complete the
set if information required to perform a JNDI lookup for the EJB. The optional
<em>classLoader</em> attribute specifies the class loader to be used for loading the
service class, and the optional <em>archive</em> attribute is the location of a jar
file that the client would need. It is upto the service provider to insure that all
java methods used for mapping abstract operations must be publicly available through
the specified interface in the EJB.</p>
</ul>
<h4>Example:</h4>
<p><tt><pre>
<?xml version="1.0" ?>
<definitions targetNamespace="http://wsifservice.addressbook/";
xmlns:tns="http://wsifservice.addressbook/";
xmlns:typens="http://wsiftypes.addressbook/";
xmlns:xsd="http://www.w3.org/2000/10/XMLSchema";
xmlns:format="http://schemas.xmlsoap.org/wsdl/formatbinding/";
xmlns:java="http://schemas.xmlsoap.org/wsdl/java/";
xmlns="http://schemas.xmlsoap.org/wsdl/">
<!-- type defs -->
<types>
<xsd:schema
targetNamespace="http://wsiftypes.addressbook/";
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<xsd:complexType name="phone">
<xsd:element name="areaCode" type="xsd:int"/>
<xsd:element name="exchange" type="xsd:string"/>
<xsd:element name="number" type="xsd:string"/>
</xsd:complexType>
<xsd:complexType name="address">
<xsd:element name="streetNum" type="xsd:int"/>
<xsd:element name="streetName" type="xsd:string"/>
<xsd:element name="city" type="xsd:string"/>
<xsd:element name="state" type="xsd:string"/>
<xsd:element name="zip" type="xsd:int"/>
<xsd:element name="phoneNumber" type="typens:phone"/>
</xsd:complexType>
</xsd:schema>
</types>
<!-- message declns -->
<message name="AddEntryWholeNameRequestMessage">
<part name="name" type="xsd:string"/>
<part name="address" type="typens:address"/>
</message>
<message name="AddEntryFirstAndLastNamesRequestMessage">
<part name="firstName" type="xsd:string"/>
<part name="lastName" type="xsd:string"/>
<part name="address" type="typens:address"/>
</message>
<message name="GetAddressFromNameRequestMessage">
<part name="name" type="xsd:string"/>
</message>
<message name="GetAddressFromNameResponseMessage">
<part name="address" type="typens:address"/>
</message>
<!-- port type declns -->
<portType name="AddressBook">
<operation name="addEntry">
<input name="AddEntryWholeNameRequest"
message="tns:AddEntryWholeNameRequestMessage"/>
</operation>
<operation name="addEntry">
<input name="AddEntryFirstAndLastNamesRequest"
message="tns:AddEntryFirstAndLastNamesRequestMessage"/>
</operation>
<operation name="getAddressFromName">
<input name="GetAddressFromNameRequest"
message="tns:GetAddressFromNameRequestMessage"/>
<output name="GetAddressFromNameResponse"
message="tns:GetAddressFromNameResponseMessage"/>
</operation>
</portType>
<!-- binding declns -->
<binding name="EJBBinding" type="tns:AddressBook">
<ejb:binding/>
<format:typeMapping encoding="Java" style="Java">
<format:typeMap typeName="typens:address"
formatType="addressbook.wsiftypes.Address" />
<format:typeMap typeName="xsd:string" formatType="java.lang.String" />
</format:typeMapping>
<operation name="addEntry">
<ejb:operation
methodName="addEntry"
parameterOrder="name address"
interface="remote" />
<input name="AddEntryWholeNameRequest"/>
</operation>
<operation name="addEntry">
<ejb:operation
methodName="addEntry"
parameterOrder="firstName lastName address"
interface="remote" />
<input name="AddEntryFirstAndLastNamesRequest"/>
</operation>
<operation name="getAddressFromName">
<ejb:operation
methodName="getAddressFromName"
parameterOrder="name"
interface="remote"
returnPart="address" />
<input name="GetAddressFromNameRequest"/>
<output name="GetAddressFromNameResponse"/>
</operation>
</binding>
<!-- service decln -->
<service name="AddressBookService">
<port name="EJBPort" binding="tns:EJBBinding">
<java:address className="addressbook.wsiftypes.AddressBook"
jndiName="/services/addressbook"
initialContextFactory="com.mycompany.server.MyappInitialContext"
jndiProviderURL="ormi://myserver.mycompany.com/ejbsample"/>
</port>
</service>
</definitions></pre></tt></p>
<p>In the above example, an address book service is offered through an EJB. The EJB
object is looked up through the specified context factory using the provider URL and
lookup name. 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. All of these
methods are offered through the remote interface of the EJB. 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>
</body></html>
1.1 xml-axis-wsif/java/doc/wsdl_extensions/java_extension.html
Index: java_extension.html
===================================================================
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<title>Java binding</title>
</head>
<body>
<h2>Java binding</h2>
<hr>
<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><tt><pre>
<definitions .... >
<!-- Java binding -->
<binding ... >
<java:binding/>
<format:typeMapping style="uri" encoding="..."/>?
<format:typeMap typeName="qname"|elementName="qname"
formatType="nmtoken"/>*
</format:typeMapping>
<operation>*
<java:operation
methodName="nmtoken"
parameterOrder="nmtoken"?
returnPart="nmtoken"?
methodType="instance|static|constructor"? />?
<input name="nmtoken"? />?
<output name="nmtoken"? />?
<fault name="nmtoken"? />?
</operation>
</binding>
<service ... >
<port>*
<java:address
className="nmtoken"
classPath="nmtoken"?
classLoader="nmtoken"? />
</port>
</service>
</definitions>
</pre></tt></p>
<p>Each element is described in detail below.</p>
<ul>
<li><b><tt>java:binding</tt></b>
<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". 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 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.
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 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 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>
<p><tt><pre>
<?xml version="1.0" ?>
<definitions targetNamespace="http://wsifservice.addressbook/";
xmlns:tns="http://wsifservice.addressbook/";
xmlns:typens="http://wsiftypes.addressbook/";
xmlns:xsd="http://www.w3.org/2000/10/XMLSchema";
xmlns:format="http://schemas.xmlsoap.org/wsdl/formatbinding/";
xmlns:java="http://schemas.xmlsoap.org/wsdl/java/";
xmlns="http://schemas.xmlsoap.org/wsdl/">
<!-- type defs -->
<types>
<xsd:schema
targetNamespace="http://wsiftypes.addressbook/";
xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<xsd:complexType name="phone">
<xsd:element name="areaCode" type="xsd:int"/>
<xsd:element name="exchange" type="xsd:string"/>
<xsd:element name="number" type="xsd:string"/>
</xsd:complexType>
<xsd:complexType name="address">
<xsd:element name="streetNum" type="xsd:int"/>
<xsd:element name="streetName" type="xsd:string"/>
<xsd:element name="city" type="xsd:string"/>
<xsd:element name="state" type="xsd:string"/>
<xsd:element name="zip" type="xsd:int"/>
<xsd:element name="phoneNumber" type="typens:phone"/>
</xsd:complexType>
</xsd:schema>
</types>
<!-- message declns -->
<message name="AddEntryWholeNameRequestMessage">
<part name="name" type="xsd:string"/>
<part name="address" type="typens:address"/>
</message>
<message name="AddEntryFirstAndLastNamesRequestMessage">
<part name="firstName" type="xsd:string"/>
<part name="lastName" type="xsd:string"/>
<part name="address" type="typens:address"/>
</message>
<message name="GetAddressFromNameRequestMessage">
<part name="name" type="xsd:string"/>
</message>
<message name="GetAddressFromNameResponseMessage">
<part name="address" type="typens:address"/>
</message>
<!-- port type declns -->
<portType name="AddressBook">
<operation name="addEntry">
<input name="AddEntryWholeNameRequest"
message="tns:AddEntryWholeNameRequestMessage"/>
</operation>
<operation name="addEntry">
<input name="AddEntryFirstAndLastNamesRequest"
message="tns:AddEntryFirstAndLastNamesRequestMessage"/>
</operation>
<operation name="getAddressFromName">
<input name="GetAddressFromNameRequest"
message="tns:GetAddressFromNameRequestMessage"/>
<output name="GetAddressFromNameResponse"
message="tns:GetAddressFromNameResponseMessage"/>
</operation>
</portType>
<!-- binding declns -->
<binding name="JavaBinding" type="tns:AddressBook">
<java:binding/>
<format:typeMapping encoding="Java" style="Java">
<format:typeMap typeName="typens:address"
formatType="addressbook.wsiftypes.Address" />
<format:typeMap typeName="xsd:string" formatType="java.lang.String" />
</format:typeMapping>
<operation name="addEntry">
<java:operation
methodName="addEntry"
parameterOrder="name address"
methodType="instance" />
<input name="AddEntryWholeNameRequest"/>
</operation>
<operation name="addEntry">
<java:operation
methodName="addEntry"
parameterOrder="firstName lastName address"
methodType="instance" />
<input name="AddEntryFirstAndLastNamesRequest"/>
</operation>
<operation name="getAddressFromName">
<java:operation
methodName="getAddressFromName"
parameterOrder="name"
methodType="instance"
returnPart="address" />
<input name="GetAddressFromNameRequest"/>
<output name="GetAddressFromNameResponse"/>
</operation>
</binding>
<!-- service decln -->
<service name="AddressBookService">
<port name="JavaPort" binding="tns:JavaBinding">
<java:address className="addressbook.wsiftypes.AddressBook"/>
</port>
</service>
</definitions></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
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>
