You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by di...@apache.org on 2003/10/16 20:44:08 UTC
cvs commit: ws-axis/contrib/axisdocs/src/documentation/content/xdocs/java requirements.ihtml
dims 2003/10/16 11:44:08
Added: contrib/axisdocs/src/documentation/content/xdocs/java
requirements.ihtml
Log:
Doc contribution from "Tetsuya Kitahata" <te...@apache.org>:
Step #1: download Apache Forrest from http://xml.apache.org/forrest/ (version 0.5.1) and install.
Step #2: From unzipped directory ($AXIS), run "forrest site" and the html files will be created at
$AXIS/build/site/ directory.
Revision Changes Path
1.1 ws-axis/contrib/axisdocs/src/documentation/content/xdocs/java/requirements.ihtml
Index: requirements.ihtml
===================================================================
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<link href="axis.css" rel=stylesheet type=text/css>
<style type="text/css">
small.red { color: red }
</style>
<title>Axis requirements & status</title>
</head>
<body>
<h1>Requirements</h1>
There is a <A href="#nonreq">non-requirements</A> section below. <br>
<A href="#releases">Release cycles</A> are explained below.
<p>
<table border="3" cellspacing="0" cellpadding="3" width="700">
<tbody>
<tr valign="top">
<th>No.</th>
<th>Description [Priority]</th>
<th><br>
<br>
</th>
<td valign="top"><b>status</b> - worker(s)<br>
</td>
<th>a1</th>
<th>a2</th>
<th>
<P>beta/</P>
<P>3.0</P></th>
<th>later</th>
</tr>
<tr valign="top">
<th><br>
</th>
<th colspan="7"> XML Protocol compliance</th>
</tr>
<tr valign="top">
<td>10</td>
<td> We will diligently track the XP protocol as it evolves, and support
it when it's ready. </td>
<td><br>
<br>
</td>
<td valign="top">n/a<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>?</td>
<td>? </td>
</tr>
<tr valign="top">
<th><br>
</th>
<th colspan="7"> Error and fault handling</th>
</tr>
<tr valign="top">
<td>20</td>
<td> Specify an extensible Java Exception mapping into SOAP faults
</td>
<td><br>
<br>
</td>
<td valign="top">?<br>
</td>
<td><br>
</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>21</td>
<td> Specify an extensible SOAP fault mapping into Java exceptions
</td>
<td><br>
<br>
</td>
<td valign="top">?<br>
</td>
<td><br>
</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<th><br>
</th>
<th colspan="7"> Service and Operation Identification</th>
</tr>
<tr valign="top">
<td>30</td>
<td> Dispatch by transport URL </td>
<td><br>
</td>
<td valign="top">done<br>
</td>
<td><br>
</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>31</td>
<td> Dispatch by SOAPAction </td>
<td><br>
</td>
<td valign="top">done<br>
</td>
<td><br>
</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>32</td>
<td> Dispatch by QName of the first body entry </td>
<td><br>
</td>
<td valign="top">done<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>33</td>
<td> Dispatch by a custom handler <i>(to use any information
available)</i></td>
<td><br>
</td>
<td valign="top">done (can do it already)<br>
</td>
<td><br>
</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<th><br>
</th>
<th colspan="7"> Message exchange patterns supported at the client
API level</th>
</tr>
<tr valign="top">
<td><br>
</td>
<td colspan="7"><i>Motivation: we believe the following message exchange
patterns are in common use and important to implement (e.g. WSDL uses
them)</i></td>
</tr>
<tr valign="top">
<td>40</td>
<td> Synchronous request/response </td>
<td><br>
</td>
<td valign="top">done<br>
</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>41</td>
<td> One-way messaging </td>
<td><br>
</td>
<td valign="top"><b>NYI</b> - ?<br>
</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>42</td>
<td> [??] Asynchronous request/response (non-blocking) <i>(the question
marks mean we don't know whether to provide this)</i></td>
<td><br>
<br>
</td>
<td valign="top"><b>NYI - </b>?<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td><br>
</td>
<td><br>
</td>
</tr>
<tr valign="top">
<th><br>
</th>
<th colspan="7"> SOAP 1.1 compliance</th>
</tr>
<tr valign="top">
<td>50</td>
<td> All aspects of SOAP 1.1 supported by Apache SOAP 2.x </td>
<td><br>
<br>
</td>
<td valign="top">what is missing?<br>
(actor, full sec-5)
</td>
<td><br>
</td>
<td><br>
</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>51</td>
<td>Support intermediaries</td>
<td><br>
<br>
</td>
<td valign="top"><b>NYI</b> - RobJ<br>
<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>?</td>
<td>? </td>
</tr>
<tr valign="top">
<td>52</td>
<td> Transparency should be provided when we place intermediaries
(hosts) between requestor and provider (creating a proxy server)
</td>
<td><br>
<br>
</td>
<td valign="top"><b>NYI</b> - RobJ<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>?</td>
<td>? </td>
</tr>
<tr valign="top">
<td>53</td>
<td> Support the SOAP concept of mustUnderstand headers </td>
<td><br>
</td>
<td valign="top">done<br>
</td>
<td><br>
</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>54</td>
<td> Support the SOAP actor header attributes </td>
<td><br>
</td>
<td valign="top"><STRONG>NYI - Glen</STRONG><br>
</td>
<td><br>
</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<th><br>
</th>
<th colspan="7"> Performance</th>
</tr>
<tr valign="top">
<td>60</td>
<td> The architecture must not require the whole message to be in
memory at the same time </td>
<td><br>
<br>
</td>
<td valign="top">not for 1.0 - no incremental 1.0 parse; architecture
still allows this, later<br>
<br>
</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>61</td>
<td> Scalable </td>
<td><br>
</td>
<td valign="top">? - Sam<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>62</td>
<td> Faster than Apache SOAP 2.x </td>
<td><br>
</td>
<td valign="top">done!<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>63</td>
<td> Must not be significantly slower than comparable alternative
implementations </td>
<td><br>
<br>
</td>
<td valign="top">done?<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<th><br>
</th>
<th colspan="7"> Administration and monitoring</th>
</tr>
<tr valign="top">
<td>70</td>
<td> Logging API </td>
<td><br>
</td>
<td valign="top"><b>NYI
(all)</b>
</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>71</td>
<td> Metrics API </td>
<td><br>
</td>
<td valign="top"><b>NYI</b> - ?<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>72</td>
<td> Management (JMX) API </td>
<td><br>
</td>
<td valign="top"><b>n/a?</b>
</td>
<td><br>
</td>
<td><br>
</td>
<td>?</td>
<td>? </td>
</tr>
<tr valign="top">
<td>73</td>
<td> Run-time (un)deployment API </td>
<td><br>
</td>
<td valign="top"><b>NYI</b> - ?<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<th><br>
</th>
<th colspan="7"> Deployment</th>
</tr>
<tr valign="top">
<td>80</td>
<td> Installation and deployment of both the engine, components, and
services should be simple </td>
<td><br>
<br>
</td>
<td valign="top">done! (what more?)<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>81</td>
<td> Support a WebServiceArchive format which associates the
executable and the description files </td>
<td><br>
<br>
</td>
<td valign="top">NYI (does JWS count?) - ?<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>82</td>
<td> Support .asmx-like drop-in service deployment </td>
<td><br>
</td>
<td valign="top">done - this is JWS<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>?</td>
<td>? </td>
</tr>
<tr valign="top">
<td>83</td>
<td> A single SUPER TINY .jar file must be enough for a client to
communicate via SOAP </td>
<td><br>
<br>
</td>
<td valign="top"><b>NYI</b> - what is best way to build it?<br>
</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>84</td>
<td> Defaults packaged with both client and server must be sane,
secure and ready to go </td>
<td><br>
<br>
</td>
<td valign="top"><b>NYI</b> but getting there!<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>85</td>
<td> Intermediaries (hosts) should be easy to configure
</td>
<td><br>
<br>
</td>
<td valign="top"><b>NYI</b> - RobJ<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>?</td>
<td>? </td>
</tr>
<tr>
<td valign="top">86<br>
</td>
<td valign="top">WSDD implementation<br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><b>NYI</b> - Carl
W / Glen
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
<td valign="top">?<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr valign="top">
<th><br>
</th>
<th colspan="7"> Providers</th>
</tr>
<tr valign="top">
<td>90</td>
<td> Pluggable provider API </td>
<td><br>
</td>
<td valign="top"><b>done? (handler
API)</b>
</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>91</td>
<td> Java provider </td>
<td><br>
</td>
<td valign="top">done?<br>
</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>92</td>
<td> BSF provider </td>
<td><br>
</td>
<td valign="top"><b>NYI -</b>?<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>93</td>
<td> EJB provider </td>
<td><br>
</td>
<td valign="top"><b>NYI - </b>?<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>?</td>
<td>? </td>
</tr>
<tr valign="top">
<td>94</td>
<td> COM provider </td>
<td><br>
<br>
</td>
<td valign="top"><b>NYI</b> - ?<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>?</td>
<td>? </td>
</tr>
<tr>
<td valign="top">95new<br>
</td>
<td valign="top">App server provider / connectivity layer<b> [High]</b><br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><b>NYI</b> - Glen?<br>
</td>
<td valign="top"><br>
</td>
<td valign="top"><br>
</td>
<td valign="top">X<br>
</td>
<td valign="top"><br>
</td>
</tr>
<tr valign="top">
<th><br>
</th>
<th colspan="7"> Pluggable XML protocol support</th>
</tr>
<tr valign="top">
<td>100</td>
<td> SOAP 1.1 </td>
<td><br>
</td>
<td valign="top">done<br>
</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>101</td>
<td> SOAP 1.2 </td>
<td><br>
<br>
</td>
<td valign="top"><STRONG>Partial -</STRONG> doesn't yet
do envelope versioning or namespaces
</td>
<td><br>
</td>
<td><br>
</td>
<td>?</td>
<td>? </td>
</tr>
<tr valign="top">
<td>102</td>
<td> Must not name general classes as SOAPWhateverDoer </td>
<td><br>
<br>
</td>
<td valign="top">done<br>
</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>103</td>
<td> Simultaneous support for multiple message protocols </td>
<td><br>
<br>
</td>
<td valign="top">NYI<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X </td>
</tr>
<tr valign="top">
<th><br>
</th>
<th colspan="7"> Message processing</th>
</tr>
<tr valign="top">
<td>110</td>
<td> Support a flexible and extensible system allowing message handlers
(extensions, applications) to build up orthogonal pieces of a message
</td>
<td><br>
<br>
</td>
<td valign="top">done<br>
</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>111</td>
<td> Handler invocation order is always deterministic for a given
server configuration and message </td>
<td><br>
<br>
</td>
<td valign="top">done<br>
</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>112</td>
<td> Some information should be shared between all the handlers in
the "chain" on one host - MessageContext </td>
<td><br>
<br>
</td>
<td valign="top">done<br>
</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>112a</td>
<td> Have the ability to specify application-specific parameters (like
username or other thing) in the context </td>
<td><br>
<br>
</td>
<td valign="top">done<br>
</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>112b</td>
<td> Some encapsulation of the idea of a session that's transport-independent
(cookies in the HTTPRequest/HTTPResponse for http) </td>
<td><br>
<br>
</td>
<td valign="top"> done<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>112b.1</td>
<td> An example/sample for a SOAP session header/handler/supplier
</td>
<td><br>
<br>
</td>
<td valign="top"><b>NYI</b> - RobJ<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>?</td>
<td>? </td>
</tr>
<tr valign="top">
<td>112b.2</td>
<td> Client code needs to support this as well - need to
pass session back across if necessary... </td>
<td><br>
<br>
</td>
<td valign="top"><b>NYI</b> - RobJ<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>113</td>
<td> Handlers need to be allowed to reach raw message data </td>
<td><br>
<br>
</td>
<td valign="top">done<br>
</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<th><br>
</th>
<th colspan="7"> Transport</th>
</tr>
<tr valign="top">
<td>120</td>
<td> Pluggable transport API </td>
<td><br>
</td>
<td valign="top">done - needs doc!
</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>121</td>
<td> HTTP listener and sender </td>
<td><br>
</td>
<td valign="top">done<br>
</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>122</td>
<td> HTTPS listener and sender </td>
<td><br>
<br>
</td>
<td valign="top"><b>NYI</b> - ?<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>123</td>
<td> SMTP sender </td>
<td><br>
<br>
</td>
<td valign="top"><b>NYI</b> - ?<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>124</td>
<td> POP3 poller </td>
<td><br>
<br>
</td>
<td valign="top"><b>NYI</b> - ?<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>125</td>
<td> JMS listener and sender </td>
<td><br>
<br>
</td>
<td valign="top"><b>NYI</b> - ?<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>?</td>
<td>? </td>
</tr>
<tr valign="top">
<td>126</td>
<td>Support for "SOAP messages with attachments"<b>[High]</b>
</td>
<td><br>
<br>
</td>
<td valign="top"><b>NYI</b> - Glen / RobJ<br>
</td>
<td><br>
<br>
</td>
<td>X<br>
</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>127</td>
<td> The transport can insert arbitrary transport-specific stuff into
the Context </td>
<td><br>
<br>
</td>
<td valign="top">done<br>
</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>128</td>
<td> The transport-specific stuff should be encapsulated, most of
the engine should work on a canonical form of the message </td>
<td><br>
<br>
</td>
<td valign="top">done<br>
</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<th><br>
</th>
<th colspan="7"> Security</th>
</tr>
<tr valign="top">
<td>130</td>
<td> Support transport-level security<b> [High]</b></td>
<td><br>
</td>
<td valign="top"><b>NY</b><b>I</b> - per-transport issue?<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr>
<td valign="top">130b<br>
</td>
<td valign="top">Support SOAP-level security<b> [High]</b><br>
</td>
<td valign="top"><br>
<br>
</td>
<td valign="top">what, specifically? - Yuhichi?<br>
</td>
<td valign="top"><br>
<br>
</td>
<td valign="top"><br>
<br>
</td>
<td valign="top"><br>
<br>
</td>
<td valign="top"><br>
<br>
</td>
</tr>
<tr valign="top">
<td>131</td>
<td> HTTP Basic auth </td>
<td><br>
</td>
<td valign="top">done?<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>132</td>
<td> Support for existing security SOAP-level standards </td>
<td><br>
</td>
<td valign="top">what, specifically?<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>?</td>
<td>? </td>
</tr>
<tr valign="top">
<td>133</td>
<td> An example/sample for a SOAP Basic Authentication header/handler
</td>
<td><br>
</td>
<td valign="top">done?<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>?</td>
<td>? </td>
</tr>
<tr valign="top">
<th><br>
</th>
<th colspan="7"> Service Description and Discovery (for instance, WSDL,
DISCO)</th>
</tr>
<tr valign="top">
<td>140</td>
<td> Support the ability to query a service's description at runtime
(e.g. GET ...?wsdl) </td>
<td><br>
<br>
</td>
<td valign="top"><b>NYI</b> - Jim's contribution? or is this
something simpler?<br>
</td>
<td><br>
</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>140a</td>
<td> If deployment params have altered the service description,
the updated version must be returned </td>
<td><br>
<br>
</td>
<td valign="top"><b>NYI</b>?<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>141</td>
<td> Support a basic html page describing the service (via an HTTP
GET) </td>
<td><br>
<br>
</td>
<td valign="top"><b>NYI</b> - James? Doug?<br>
</td>
<td><br>
</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>142</td>
<td> Support a pretty html page describing the service (via an HTTP
GET) </td>
<td><br>
<br>
</td>
<td valign="top"><b>NYI - </b>James? Doug?</td>
<td><br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X </td>
</tr>
<tr valign="top">
<td>143</td>
<td> Services can be deployed and used without service descriptions
</td>
<td><br>
<br>
</td>
<td valign="top">done<br>
</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>144</td>
<td> Should abstract the SD layer, at least by keeping the interfaces
clean<b> [High]</b> </td>
<td><br>
<br>
</td>
<td valign="top">?<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>144a</td>
<td> The abstract SD layer must support run-time determination
of xsi:types of parts of the message </td>
<td><br>
<br>
</td>
<td valign="top"><b>NYI?</b> - Sam?<br>
</td>
<td><br>
</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>144b</td>
<td> Include a WSDL implementation of the SD layer<b> [High]</b>
</td>
<td><br>
<br>
</td>
<td valign="top"><b>NYI</b> - Lance & HP contribution?<br>
</td>
<td><br>
</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>144c</td>
<td> Extend WSDL with information on where to get components for stuff
</td>
<td><br>
<br>
</td>
<td valign="top"><b>NYI</b> - James?<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X </td>
</tr>
<tr valign="top">
<td>144d</td>
<td> Tools and/or run-time support for proxy generation from WSDL
and/or WSDD </td>
<td><br>
<br>
</td>
<td valign="top"><b>NYI</b> - Lance & HP?<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X </td>
</tr>
<tr valign="top">
<td>145</td>
<td> HTTP GET on the Axis node returns an appropriate DISCO document
</td>
<td><br>
<br>
</td>
<td valign="top"><b>NYI</b> - ?<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X </td>
</tr>
<tr valign="top">
<th><br>
</th>
<th colspan="7"> Platforms</th>
</tr>
<tr valign="top">
<td>150</td>
<td> Java implementation </td>
<td><br>
</td>
<td valign="top">underway :-)<br>
</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>151</td>
<td> C++ implementation </td>
<td><br>
</td>
<td valign="top">n/a for 1.0<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X </td>
</tr>
<tr valign="top">
<td>151a</td>
<td> C++ impl core should be cross platform with platform-specific
extensions (like COM) </td>
<td><br>
<br>
</td>
<td valign="top">n/a for 1.0<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X </td>
</tr>
<tr valign="top">
<td>152</td>
<td> All implementations should have as much in common as possible
</td>
<td><br>
<br>
</td>
<td valign="top">n/a for 1.0<br>
</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>153</td>
<td> Use standard APIs wherever possible </td>
<td><br>
</td>
<td valign="top">done<br>
</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<th><br>
</th>
<th colspan="7"> Data Encoding</th>
</tr>
<tr valign="top">
<td>160</td>
<td> Extensible support for encodings </td>
<td><br>
</td>
<td valign="top">NYI<br>
</td>
<td><br>
</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>161</td>
<td> Implement basic SOAP encoding (the level of current Apache SOAP
2.x) </td>
<td><br>
</td>
<td valign="top">done<br>
</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>162</td>
<td> Support for sparse and partially-transmitted arrays </td>
<td><br>
</td>
<td valign="top">NYI<br>
</td>
<td><br>
</td>
<td>X<br>
</td>
<td>X</td>
<td> </td>
</tr>
<tr valign="top">
<td>163</td>
<td> Support for multidimensional arrays </td>
<td><br>
</td>
<td valign="top">NYI<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X </td>
</tr>
<tr valign="top">
<td>164</td>
<td> Support literal XML encoding </td>
<td><br>
</td>
<td valign="top">NYI<br>
</td>
<td><br>
</td>
<td>X<br>
</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>165</td>
<td> It should be relatively easy to write a "Serializer" </td>
<td><br>
</td>
<td valign="top">done (depending on feedback from
users)<br>
</td>
<td><br>
</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>166</td>
<td> Include some general (de)serializers (that handle multiple
types), so that there needn't exist a (de)serializer for every type
that could possibly travel over the wire (needs further discussion
- isomorphism (roundtrip) issues) </td>
<td><br>
<br>
</td>
<td valign="top">Is this the beanserializer /
basicDeserializer, or something else?<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>?</td>
<td>? </td>
</tr>
<tr valign="top">
<td>167</td>
<td> (De)serialization may occur at any time on demand </td>
<td><br>
</td>
<td valign="top">done<br>
</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>168</td>
<td> (De)serialization should be available to the application
</td>
<td><br>
</td>
<td valign="top">done<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<th><br>
</th>
<th colspan="7"> Release</th>
</tr>
<tr valign="top">
<td><br>
</td>
<td colspan="7"><i>Although these are a 1.0 requirements, significant
progress must be made on these items during interim releases.</i></td>
</tr>
<tr valign="top">
<td>170</td>
<td> Product-level code </td>
<td><br>
</td>
<td valign="top">getting there....<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>171</td>
<td> Product-level docs<b> [High]</b> </td>
<td><br>
</td>
<td valign="top"><b>NYI</b> - ?<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>172</td>
<td> Product-level examples </td>
<td><br>
</td>
<td valign="top"><b>NYI</b> but getting there - everyone<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>173</td>
<td> Product-level performance </td>
<td><br>
</td>
<td valign="top"><b>NYI</b> - Sam? </td>
<td><br>
</td>
<td><br>
</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>174</td>
<td> Product-level testing </td>
<td><br>
</td>
<td valign="top">getting there, with functional & unit tests<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<th><br>
</th>
<th colspan="7"> Migration from Apache SOAP 2.x</th>
</tr>
<tr valign="top">
<td>180</td>
<td> Documentation </td>
<td><br>
</td>
<td valign="top"><b>NYI - </b>?<br>
</td>
<td><br>
</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>181</td>
<td> The legacy Call object </td>
<td><br>
</td>
<td valign="top"><b>NYI</b> - ?<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>182</td>
<td> Serialization, custom serializers - maybe wrappers </td>
<td><br>
</td>
<td valign="top"><b>NYI</b> - ?<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>?</td>
<td>? </td>
</tr>
<tr valign="top">
<td>183</td>
<td> Support for legacy messaging services </td>
<td><br>
</td>
<td valign="top"><b>NYI</b> - which?<br>
<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>184</td>
<td> Support for legacy providers <b>[Medium]</b> </td>
<td><br>
</td>
<td valign="top"><b>NYI</b> - ?<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X </td>
</tr>
<tr>
<td valign="top">185new<br>
</td>
<td valign="top">Support for legacy deployment<br>
</td>
<td valign="top"><br>
<br>
</td>
<td valign="top"><b>NYI</b> - James?<br>
</td>
<td valign="top"><br>
<br>
</td>
<td valign="top"><br>
<br>
</td>
<td valign="top">X<br>
<br>
</td>
<td valign="top"><br>
<br>
</td>
</tr>
<tr valign="top">
<th><br>
</th>
<th colspan="7"> Coding</th>
</tr>
<tr valign="top">
<td>190</td>
<td>Follow the <a href="http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html">
Java Coding Style</a> with <b>no</b> tab characters. </td>
<td><br>
</td>
<td valign="top">done<br>
</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>191</td>
<td>Use javadoc style to document all non-private methods in commits.
</td>
<td><br>
<br>
</td>
<td valign="top">could be more...<br>
</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>192</td>
<td> Document packages. </td>
<td><br>
<br>
</td>
<td valign="top">could be MUCH more...<br>
</td>
<td><br>
</td>
<td><br>
</td>
<td>X</td>
<td><br>
</td>
</tr>
<tr valign="top">
<td>193</td>
<td>Committing a new package, at least place in a placeholder for the
package doc that says "this is to be done". </td>
<td><br>
<br>
</td>
<td valign="top"><b>NYI</b> - everyone!!!<br>
</td>
<td>X</td>
<td>X</td>
<td>X</td>
<td><br>
</td>
</tr>
</tbody>
</table>
<a name="nonreq"></a></p>
<h1>Non-requirements (won't be supported)</h1>
<br>
<i>We find the SOAP spec. to be unclear on these issues so we decided not
to support them.</i>
<ol>
<li> RPC calls in SOAP headers
<li> Multiple RPC calls in a single SOAP message </li>
</ol>
<p><a name="releases"></a></p>
<h1>Releases and test cycles</h1>We're planning on
releasing alpha1 (a1), alpha2 (a2), beta, and 3.0.<br>
alpha is a preview.<br>
subsequent alphas are to show the growing set of features and docs and test cases
and all that.<br>
Beta is functionally complete.
</body>
</html>