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