# Requirements

There is a non-requirements section below.
Release cycles are explained below.

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] |  | NY I - 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 |

# Non-requirements (won't be supported)

We find the SOAP spec. to be unclear on these issues so we decided not to support them.

1. RPC calls in SOAP headers
2. Multiple RPC calls in a single SOAP message

# Releases and test cycles

We're planning on releasing alpha1 (a1), alpha2 (a2), beta, and 3.0.
alpha is a preview.
subsequent alphas are to show the growing set of features and docs and test cases and all that.
Beta is functionally complete.