No. |
Description [Priority] |
|
status - worker(s) |
a1 |
a2 |
beta/ 3.0 |
later |
|
XML Protocol compliance |
10 |
We will diligently track the XP protocol as it evolves, and support it when it's ready. |
|
n/a |
|
|
? |
? |
|
Error and fault handling |
20 |
Specify an extensible Java Exception mapping into SOAP faults |
|
? |
|
X |
X |
|
21 |
Specify an extensible SOAP fault mapping into Java exceptions |
|
? |
|
X |
X |
|
|
Service and Operation Identification |
30 |
Dispatch by transport URL |
|
done |
|
X |
X |
|
31 |
Dispatch by SOAPAction |
|
done |
|
X |
X |
|
32 |
Dispatch by QName of the first body entry |
|
done |
|
|
X |
|
33 |
Dispatch by a custom handler (to use any information available) |
|
done (can do it already) |
|
X |
X |
|
|
Message exchange patterns supported at the client API level |
|
Motivation: we believe the following message exchange patterns are in common use and important to implement (e.g. WSDL uses them) |
40 |
Synchronous request/response |
|
done |
X |
X |
X |
|
41 |
One-way messaging |
|
NYI - ? |
X |
X |
X |
|
42 |
[??] Asynchronous request/response (non-blocking) (the question marks mean we don't know whether to provide this) |
|
NYI - ? |
|
|
|
|
|
SOAP 1.1 compliance |
50 |
All aspects of SOAP 1.1 supported by Apache SOAP 2.x |
|
what is missing? (actor, full sec-5) |
|
|
X |
|
51 |
Support intermediaries |
|
NYI - RobJ |
|
|
? |
? |
52 |
Transparency should be provided when we place intermediaries (hosts) between requestor and provider (creating a proxy server) |
|
NYI - RobJ |
|
|
? |
? |
53 |
Support the SOAP concept of mustUnderstand headers |
|
done |
|
X |
X |
|
54 |
Support the SOAP actor header attributes |
|
NYI - Glen |
|
X |
X |
|
|
Performance |
60 |
The architecture must not require the whole message to be in memory at the same time |
|
not for 1.0 - no incremental 1.0 parse; architecture still allows this, later |
X |
X |
X |
|
61 |
Scalable |
|
? - Sam |
|
|
X |
|
62 |
Faster than Apache SOAP 2.x |
|
done! |
|
|
X |
|
63 |
Must not be significantly slower than comparable alternative implementations |
|
done? |
|
|
X |
|
|
Administration and monitoring |
70 |
Logging API |
|
NYI (all) |
X |
X |
X |
|
71 |
Metrics API |
|
NYI - ? |
|
|
X |
|
72 |
Management (JMX) API |
|
n/a? |
|
|
? |
? |
73 |
Run-time (un)deployment API |
|
NYI - ? |
|
|
X |
|
|
Deployment |
80 |
Installation and deployment of both the engine, components, and services should be simple |
|
done! (what more?) |
|
|
X |
|
81 |
Support a WebServiceArchive format which associates the executable and the description files |
|
NYI (does JWS count?) - ? |
|
|
X |
|
82 |
Support .asmx-like drop-in service deployment |
|
done - this is JWS |
|
|
? |
? |
83 |
A single SUPER TINY .jar file must be enough for a client to communicate via SOAP |
|
NYI - what is best way to build it? |
X |
X |
X |
|
84 |
Defaults packaged with both client and server must be sane, secure and ready to go |
|
NYI but getting there! |
|
|
X |
|
85 |
Intermediaries (hosts) should be easy to configure |
|
NYI - RobJ |
|
|
? |
? |
86 |
WSDD implementation |
|
NYI - Carl W / Glen |
|
|
? |
|
|
Providers |
90 |
Pluggable provider API |
|
done? (handler API) |
X |
X |
X |
|
91 |
Java provider |
|
done? |
X |
X |
X |
|
92 |
BSF provider |
|
NYI -? |
|
|
X |
|
93 |
EJB provider |
|
NYI - ? |
|
|
? |
? |
94 |
COM provider |
|
NYI - ? |
|
|
? |
? |
95new |
App server provider / connectivity layer [High] |
|
NYI - Glen? |
|
|
X |
|
|
Pluggable XML protocol support |
100 |
SOAP 1.1 |
|
done |
X |
X |
X |
|
101 |
SOAP 1.2 |
|
Partial - doesn't yet do envelope versioning or namespaces |
|
|
? |
? |
102 |
Must not name general classes as SOAPWhateverDoer |
|
done |
X |
X |
X |
|
103 |
Simultaneous support for multiple message protocols |
|
NYI |
|
|
|
X |
|
Message processing |
110 |
Support a flexible and extensible system allowing message handlers (extensions, applications) to build up orthogonal pieces of a message |
|
done |
X |
X |
X |
|
111 |
Handler invocation order is always deterministic for a given server configuration and message |
|
done |
X |
X |
X |
|
112 |
Some information should be shared between all the handlers in the "chain" on one host - MessageContext |
|
done |
X |
X |
X |
|
112a |
Have the ability to specify application-specific parameters (like username or other thing) in the context |
|
done |
X |
X |
X |
|
112b |
Some encapsulation of the idea of a session that's transport-independent (cookies in the HTTPRequest/HTTPResponse for http) |
|
done |
|
|
X |
|
112b.1 |
An example/sample for a SOAP session header/handler/supplier |
|
NYI - RobJ |
|
|
? |
? |
112b.2 |
Client code needs to support this as well - need to pass session back across if necessary... |
|
NYI - RobJ |
|
|
X |
|
113 |
Handlers need to be allowed to reach raw message data |
|
done |
X |
X |
X |
|
|
Transport |
120 |
Pluggable transport API |
|
done - needs doc! |
X |
X |
X |
|
121 |
HTTP listener and sender |
|
done |
X |
X |
X |
|
122 |
HTTPS listener and sender |
|
NYI - ? |
|
|
X |
|
123 |
SMTP sender |
|
NYI - ? |
|
|
X |
|
124 |
POP3 poller |
|
NYI - ? |
|
|
X |
|
125 |
JMS listener and sender |
|
NYI - ? |
|
|
? |
? |
126 |
Support for "SOAP messages with attachments"[High] |
|
NYI - Glen / RobJ |
|
X |
X |
|
127 |
The transport can insert arbitrary transport-specific stuff into the Context |
|
done |
X |
X |
X |
|
128 |
The transport-specific stuff should be encapsulated, most of the engine should work on a canonical form of the message |
|
done |
X |
X |
X |
|
|
Security |
130 |
Support transport-level security [High] |
|
NYI - per-transport issue? |
|
|
X |
|
130b |
Support SOAP-level security [High] |
|
what, specifically? - Yuhichi? |
|
|
|
|
131 |
HTTP Basic auth |
|
done? |
|
|
X |
|
132 |
Support for existing security SOAP-level standards |
|
what, specifically? |
|
|
? |
? |
133 |
An example/sample for a SOAP Basic Authentication header/handler |
|
done? |
|
|
? |
? |
|
Service Description and Discovery (for instance, WSDL, DISCO) |
140 |
Support the ability to query a service's description at runtime (e.g. GET ...?wsdl) |
|
NYI - Jim's contribution? or is this something simpler? |
|
X |
X |
|
140a |
If deployment params have altered the service description, the updated version must be returned |
|
NYI? |
|
|
X |
|
141 |
Support a basic html page describing the service (via an HTTP GET) |
|
NYI - James? Doug? |
|
X |
X |
|
142 |
Support a pretty html page describing the service (via an HTTP GET) |
|
NYI - James? Doug? |
|
|
|
X |
143 |
Services can be deployed and used without service descriptions |
|
done |
X |
X |
X |
|
144 |
Should abstract the SD layer, at least by keeping the interfaces clean [High] |
|
? |
|
|
X |
|
144a |
The abstract SD layer must support run-time determination of xsi:types of parts of the message |
|
NYI? - Sam? |
|
X |
X |
|
144b |
Include a WSDL implementation of the SD layer [High] |
|
NYI - Lance & HP contribution? |
|
X |
X |
|
144c |
Extend WSDL with information on where to get components for stuff |
|
NYI - James? |
|
|
|
X |
144d |
Tools and/or run-time support for proxy generation from WSDL and/or WSDD |
|
NYI - Lance & HP? |
|
|
|
X |
145 |
HTTP GET on the Axis node returns an appropriate DISCO document |
|
NYI - ? |
|
|
|
X |
|
Platforms |
150 |
Java implementation |
|
underway :-) |
X |
X |
X |
|
151 |
C++ implementation |
|
n/a for 1.0 |
|
|
|
X |
151a |
C++ impl core should be cross platform with platform-specific extensions (like COM) |
|
n/a for 1.0 |
|
|
|
X |
152 |
All implementations should have as much in common as possible |
|
n/a for 1.0 |
X |
X |
X |
|
153 |
Use standard APIs wherever possible |
|
done |
X |
X |
X |
|
|
Data Encoding |
160 |
Extensible support for encodings |
|
NYI |
|
X |
X |
|
161 |
Implement basic SOAP encoding (the level of current Apache SOAP 2.x) |
|
done |
X |
X |
X |
|
162 |
Support for sparse and partially-transmitted arrays |
|
NYI |
|
X |
X |
|
163 |
Support for multidimensional arrays |
|
NYI |
|
|
|
X |
164 |
Support literal XML encoding |
|
NYI |
|
X |
X |
|
165 |
It should be relatively easy to write a "Serializer" |
|
done (depending on feedback from users) |
|
X |
X |
|
166 |
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) |
|
Is this the beanserializer / basicDeserializer, or something else? |
|
|
? |
? |
167 |
(De)serialization may occur at any time on demand |
|
done |
X |
X |
X |
|
168 |
(De)serialization should be available to the application |
|
done |
|
|
X |
|
|
Release |
|
Although these are a 1.0 requirements, significant progress must be made on these items during interim releases. |
170 |
Product-level code |
|
getting there.... |
|
|
X |
|
171 |
Product-level docs [High] |
|
NYI - ? |
|
|
X |
|
172 |
Product-level examples |
|
NYI but getting there - everyone |
|
|
X |
|
173 |
Product-level performance |
|
NYI - Sam? |
|
|
X |
|
174 |
Product-level testing |
|
getting there, with functional & unit tests |
|
|
X |
|
|
Migration from Apache SOAP 2.x |
180 |
Documentation |
|
NYI - ? |
|
X |
X |
|
181 |
The legacy Call object |
|
NYI - ? |
|
|
X |
|
182 |
Serialization, custom serializers - maybe wrappers |
|
NYI - ? |
|
|
? |
? |
183 |
Support for legacy messaging services |
|
NYI - which?
|
|
|
X |
|
184 |
Support for legacy providers [Medium] |
|
NYI - ? |
|
|
|
X |
185new |
Support for legacy deployment |
|
NYI - James? |
|
|
X
|
|
|
Coding |
190 |
Follow the Java Coding Style with no tab characters. |
|
done |
X |
X |
X |
|
191 |
Use javadoc style to document all non-private methods in commits. |
|
could be more... |
X |
X |
X |
|
192 |
Document packages. |
|
could be MUCH more... |
|
|
X |
|
193 |
Committing a new package, at least place in a placeholder for the package doc that says "this is to be done". |
|
NYI - everyone!!! |
X |
X |
X |
|