re: requirements - 2000/11/29

[Darrel Drake <EB...@jp.ibm.com>]

From: Jacek Kopecky <ja...@idoox.com> on 2000-11-30 03:15

Please respond to soap-dev@xml.apache.org

To:   soap-dev@xml.apache.org
cc:
Subject:  requirements - 2000/11/29

<snip>

 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

</snip>

I love the overall architecture; it seems very similar to the V3
architecture that has been discussed. My only concern is that you placed
security concerns (SOAP and transport-level) inside the section on
transport. I suggest that there be an independent security requirements
section which breaks down into independent subsections on the SOAP level
and transport level. Like this:

8:  Security

8.1 Transport level
8.1.1 Transports must remain modular and pluggable, independent of each
other (or SOAP level)
8.1.1.1 Must never modify (should never have access to) SOAP Envelopes
8.1.1.2 Each security model should work completely within its specific
transport module of SOAP
8.1.1.3 Configuration information should be as external as possible
8.1.1.3.1 Different transports can share config files, but SOAP platform
must not modify config
8.1.2 SOAP Application programmers should pay little or no attention to
this level of security
8.1.2.1 Connection setup within SOAP Client App should be effortless
(passing parameters at most)
8.1.2.2 No changes to the SOAP Servlet App should be mandatory
8.1.2.2.1 Standard, transport-agnostic API for Servlet to retrieve
transport-layer security information should be provided
8.1.3 SOAP should offer transports with varying strengths of security
8.1.3.1 Strength of security vs. performance trade-off should be settled by
user

8.2 SOAP level
8.2.1 Should be modular and pluggable, independent of any transport layer
8.2.1.1 Should modify only SOAP Envelopes, not connections or system
environment
8.2.2 Standard APIs to create security-related elements on the client side
and decode them into objects on the server side should be provided
8.2.3 Should be capable of ensuring authentication, authorization and data
integrity with or without a secure transport layer

Darrell Drake*
IBM Japan, TRL
+81-46-215-4175
EB92401@jp.ibm.com
* - Notes ID has a misspelling of my name