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 |