| 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 | ||