Return-Path: Delivered-To: apmail-xml-axis-dev-archive@xml.apache.org Received: (qmail 72909 invoked by uid 500); 31 May 2001 23:00:14 -0000 Mailing-List: contact axis-dev-help@xml.apache.org; run by ezmlm Precedence: bulk Reply-To: axis-dev@xml.apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list axis-dev@xml.apache.org Received: (qmail 72899 invoked by uid 500); 31 May 2001 23:00:13 -0000 Delivered-To: apmail-xml-axis-cvs@apache.org Received: (qmail 72893 invoked by uid 1323); 31 May 2001 23:00:11 -0000 Date: 31 May 2001 23:00:11 -0000 Message-ID: <20010531230011.72891.qmail@apache.org> From: robj@apache.org To: xml-axis-cvs@apache.org Subject: cvs commit: xml-axis/java/docs requirements.html robj 01/05/31 16:00:11 Modified: java/docs requirements.html Log: Added "status" column. Please correct any mistakes and sign up for whatever you think you're working on! Revision Changes Path 1.2 +1721 -403 xml-axis/java/docs/requirements.html Index: requirements.html =================================================================== RCS file: /home/cvs/xml-axis/java/docs/requirements.html,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- requirements.html 2001/03/05 15:03:04 1.1 +++ requirements.html 2001/05/31 23:00:09 1.2 @@ -1,413 +1,1731 @@ + - - + Axis requirements & status + - - - +

Requirements

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

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

+ Providers
90 Pluggable provider API
+ NYI
+ 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
+ done
+ X X X
+
101 XML Protocol
+
+ NYI but theoretically OK in the architecture?
+
+
+ ? ?
102 Must not name general classes as SOAPWhateverDoer
+
+ done
+ X X X
+
103 Simultaneous support for multiple message protocols
+
+ done?
+
+
+
+ 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)
+
+ NYI - RobJ
+
+
+ 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
+ NYI - Glen / RobJ
+ 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 - Lance & HP 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
+ ?
+
+ 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
+ ?
+
+
+ ? ?
163 Support for multidimensional arrays
+ ?
+
+
+
+ X
164 Support literal XML encoding
+ ?
+
+
+ X
+
165 It should be relatively easy to write a "Serializer"
+ ?
+
+ 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)
+
+ ?
+
+
+ ? ?
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. -
-
RPC calls in SOAP headers -
Multiple RPC calls in a single SOAP message -
- - -
- +
+We find the SOAP spec. to be unclear on these issues so we decided not +to support them. +
+
RPC calls in SOAP headers
+
Multiple RPC calls in a single SOAP message
+
+

Releases and test cycles
-We're planning on releasing .5, .8, .9 and 1.0.
-.5 is a preview.
-.8, .9 are to show the growing set of features and docs and test cases and all that.
-We're not functionally complete before 1.0.
-1.0 will have a beta cycle. - -
- - + We're planning on releasing .5, .8, .9 and 1.0.
+ .5 is a preview.
+ .8, .9 are to show the growing set of features and docs and test cases + and all that.
+ We're not functionally complete before 1.0.
+ 1.0 will have a beta cycle. + +