requirements - 2000/11/29

[Jacek Kopecky <ja...@idoox.com>]

 Hello. 8-)
 The next iteration has undergone some deleting (mostly redundant
requirements) and a few additions.
 If I forgot anything please write me ASAP. AFAICS I'll be off-line
from Saturday until the F2F meeting (unless I find some access in D.C.
- I won't be staying at a hotel where one would expect net access).
 Attached is the full version, following is the diff.
 I'll go now through the thread "Re: Today's IRC log" and others.

                            Jacek Kopecky
                               Idoox


@@ -1,6 +1,8 @@
 1: General
 
 1.1 It works 
+1.1.1 APIs are kept simple
+1.1.2 It is fast
 1.2 It is fully SOAP 1.1 compliant. 
 1.3 Synchronous request/response is the highest priority 
 1.4 Fully support the SOAP concept of mustUnderstand and actor header attributes
@@ -18,7 +20,7 @@
 3.1 Support a flexible extension mechanism within a single installation
 3.1.1 Pluggable providers
 3.1.1.1 possible providers should be: Java, JavaScript?, EJB, executable, COM
-3.1.2 Pluggable protocol support (SOAP, XP) (questionable)
+3.1.2 Pluggable protocol support (SOAP, XP)
 3.1.2.1 must not name classes as SOAPWhateverDoer
 3.2 Support a flexible and extensible system allowing message handlers (extensions, applications) to build up orthogonal pieces of a response message
 3.2.1 Allow for explicit ordering of the handlers
@@ -28,20 +30,13 @@
 3.5 some information should be shared between all the handlers in the "pipeline" on one host - MessageContext 
 3.5.1 have the ability to specify application specific parameters (like username or other thing) in the context 
 3.5.2 some encapsulation of the idea of a session that's transport-independent (cookies in the HTTPRequest/HTTPResponse for http) 
-3.6 Any handler should be able to add arbitrary information to a response message 
 3.7 must provide a way for the server to pass the request to another server - some kind of router 
-3.7.1 provide a way of transferring the context among hosts (questionable)
 
 4: Transport
 
-4.1 Support an abstract messaging model which allows mapping to different wire prototols 
-4.2 the transport should be flexible (HTTP, HTTPS, SMTP, compression of CMD, MIME encoding, JMS, MQ, ....) 
-4.2.1 support for HTTP MIME attachments
-4.3 client side and server side implementation classes should get access to some type of context assocated with the request and the response (independently, one for each) to gain access to transport-level headers, session data etc 
+4.1 Support an abstract messaging model which allows mapping to different wire prototols (HTTP, HTTPS, SMTP, compression of CMD, MIME encoding, JMS, MQ, ....)
+4.1.1 support for HTTP MIME attachments
 4.4 the context should include a "transportSpecific" object as one of its members 
-4.5 have the ability to specify transport-dependent parameters 
-4.6 preferably in a transport-independent fashion 
-4.7 several "listeners" should be possible (HTTP, mail, JMS, ...) 
 4.8 the transport specific stuff should be encapsulated, most of the engine should work on a cannonical form of the message 
 4.9 Transport-level and SOAP level security
 
@@ -63,13 +58,12 @@
 7.1 Java and C++ implementations should have as much in common as possible 
 7.2 C++ impl core should be cross platform with platform specific extensions (like COM as discussed on the list by James) 
 7.2.1 COM and .NET would be another type of provider 
+7.3 Should be parser-independent (and probably independent on other components, too)
 
 9: Other
 
-9.1 Transparency should be provided when we place intermediaries between requester and provider 
-9.2 Response should not be required (in case of async messaging) 
-9.3 request should not be required in case of event driven messaging 
-9.3.1 might be implemented with oneway messaging
+9.1 Transparency should be provided when we place intermediaries (hosts) between requester and provider 
+9.2 Response should not be required (in case of one-way messaging) 
 9.4 It should relatively easy to write a "Serializer"
 9.4.1 Should include some general serializers, so that there needn't exist a serializer for every type that could possibly traver over the wire
 9.4.2 Serialization should occur in a Handler, like RPCPayloadHandler