axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject cvs commit: xml-axis/java/docs requirements.txt
Date Tue, 30 Jan 2001 22:06:52 GMT
sgg         01/01/30 14:06:51

  Added:       java/docs requirements.txt
  Obtained from: Jacek's web site
  Submitted by:	sgg
  Revision  Changes    Path
  1.1                  xml-axis/java/docs/requirements.txt
  Index: requirements.txt
  1 General
  1.1	It works 
  1.1.1	Minikernel is OK, *micro*kernel is not.  -- The Mysterious Stranger
  1.2	It is fully SOAP 1.1 compliant. 
  1.2.1	Fully support the SOAP concept of mustUnderstand headers
  1.2.2	Fully support the SOAP actor header attributes
  1.2.3	Fully support obtaining type data from an external source, such as a service description
  	(calling these three out because 2.0 doesn't support this stuff yet...)
  1.3	Synchronous request/response is the highest priority
  1.3.1	MUST support one-way and asynchronous scenarios as well
  1.4	Must not preclude any particular dispatch / object-location system
  1.5	A simple and extensible error-handling system 
  1.5.1	Needs to specify Java Exception mapping into SOAP - exception propagation
  1.6	We will diligently track the XP protocol as it evolves, and support it when it's ready.
  2 Performance
  2.1	It is fast 
  	TBD:	define exactly what this means?
  		Large vs. small documents?
  		Fast under load?
  		Compared to what?
  		NOTE : talk to the IU guys who did the performance stats
  3 Ease of use
  3.1	Intermediaries (hosts) should be integrated in an elegant way 
  3.2	"Don't forget the hooks" - make sure stub/skeleton/service-description tools can be
integrated easily
  3.3	APIs are kept simple
  3.4	Installation and deployment of both the engine and services should be simple
  3.5	Administration/monitoring should be easy (hooks)
  4 Message processing
  4.1	Support a flexible extension mechanism within a single installation
  4.1.1	Pluggable providers - support a provider API	Java provider	BSF provider	EJB provider	COM	etc...
  4.1.2	Pluggable protocol support (SOAP, XP)	must not name general classes as SOAPWhateverDoer	Simultaneous support for multiple message protocols
  4.2	Support a flexible and extensible system allowing message handlers (extensions, applications)
to build up orthogonal pieces of a message
  4.2.1	Same for Response message
  4.2.2	Handler invocation order is always deterministic for a given server configuration
and message bits
  4.3	the handlers involved should be configurable depending on the message bits (ActionURI,
NS URI, ...) and configuration
  4.4	some information should be shared between all the handlers in the "chain" on one host
- MessageContext
  4.4.1	have the ability to specify application specific parameters (like username or other
thing) in the context 
  4.4.2	some encapsulation of the idea of a session that's transport-independent (cookies
in the HTTPRequest/HTTPResponse for http)	Client code needs to change here as well - need to pass session back across if necessary...
  ??4.5	Handlers need to be allowed to reach raw request data
  5 Configuration
  5.1	the configuration should be accessible/modifiable in run time via an administration
  5.2	Defaults must be sane, ready to go
  6 Transport
  6.1	Support an abstract messaging model which allows mapping to different wire prototols
(HTTP, HTTPS, SMTP, compression of message, MIME encoding, JMS, MQ, ....)
  6.1.1	support for HTTP MIME attachments	Using "SOAP messages with attachments" W3C note style
  6.2	the transport can insert arbitrary transport-specific stuff into the Context
  6.3	the transport specific stuff should be encapsulated, most of the engine should work
on a canonical form of the message 
  7 Security
  7.1	Support transport-level and SOAP level security - both of which may map to a canonical
form of security
  7.2	Administration controls/APIs for security 
  7.3	Default admin setting for engine is "secure" (deployment, etc. not accessible via SOAP)
  8 Client-side
  8.1	We will provide separate client and server configurations
  8.1.1	We will attempt to make a client distribution/configuration that is SUPER TINY
  8.2	Must provide support for client forming requests and receiving responses, as well as
server side 
  8.3	Where possible, we will reuse the server-side classes to do client stuff too
  9 Service Description
  9.1	The service description should not be required (for instance, WSDL)
  9.2	Different service description languages should be allowed 
  9.2.1	Should abstract the SD layer, and have an included WSDL implementation	Use a model of a service description to "understand" the request, should not be
tied to WSDL's assumptions 
  10 Platforms
  10.1	Java and C++ implementations should have as much in common as possible 
  10.2	C++ impl core should be cross platform with platform specific extensions (like COM
as discussed on the list by James) 
  10.3	Should be parser-independent (and probably independent on other components, too)
  11 Data Encoding
  11.1	Support pluggable encoding models
  11.2	Implement SOAP encoding
  11.3	Support literal XML encoding
  11.4	It should be relatively easy to write a "Serializer"
  11.4.1	Should include some general serializers (that handle multiple types), so that there
needn't exist a serializer for every type that could possibly travel over the wire (needs
further discussion - isomorphism (roundtrip) issues)
  11.4.2	Serialization should occur in a Handler, like RPCPayloadHandler
  99 Other (99 so it stays at the end)
  99.1	Transparency should be provided when we place intermediaries (hosts) between requester
and provider 
  99.2	Should be able to handle arbitrarily large requests - streaming, PDOM
  Message Bits => The entire contents of a protocol message, including the transport package,
any MIME extensions, etc.

View raw message