Requirements

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

The requirements, I hope I didn't miss anything important, if I did, go on and add. 8-)
There's no particular order other than rough resorting - feel free to reorder this if you think it will add on clarity (I'd appreciate it)

1: General

1.1 It works 
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 headers 
1.5 Must not preclude any particular dispatch / object-location system 
1.6 A simple and complete error-handling system 

2: Ease of use

2.1 Intermediaries (hosts) should be integrated in an elegant way 
2.2 Should include stub/skeleton generating tools

3: Message processing

3.1 Support a flexible extension mechanism within a single installation 
3.1.1 possible providers should be: Java, JavaScript?, EJB, executable, COM
3.2 Support a flexible and extensible system allowing message handlers (extensions, applications) to build up orthogonal pieces of a response message
3.3 the handlers involved should be configurable depending on information of the request (ActionURI, NS URI, ...) 
3.4 Handlers should be able to modify the incoming request and the outgoing response 
3.5 some information should be shared between all the handlers in the "chain" - 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 

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, ....) 
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.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 

5: Client-side

5.1 Must provide support for client forming requests and receiving responses, as well as server side 
5.2 the classes for the server implementation should be (partly) reusable to write the client side processing 
5.3 a stand-alone client should be able to receive and dispatch messages too (for transports types like MoM/JMS, mail) 

6: Service Description

6.1 The service description should not be required 
6.2 Different service description languages should be allowed 
6.2.1 Should abstract the SD layer, and have an included WSDL implementation 
6.2.1.1 Use a model of a service description to "understand" the request, should not be tied to WSDL's assumptions 

7: Platforms

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 would be another type of provider 

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.4 It should relatively easy to write a "Serializer"
9.5 Should be able to handle arbitrarily large requests - streaming, PDOM


Sorry for the lag confusion during the chat, I'll send clarifications
later.

And I will get back to this list tomorrow (it's 11:24 PM here and
now) and I might clean it.

Enjoy. 8-)




                            Jacek Kopecky
                               Idoox