[prev in list] [next in list] [prev in thread] [next in thread] 

List:       axis-dev
Subject:    cvs commit: xml-axis/java/docs requirements.txt
From:       sgg () apache ! org
Date:       2001-01-30 22:06:52
[Download RAW message or body]

sgg         01/01/30 14:06:51

  Added:       java/docs requirements.txt
  Log:
  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
  4.1.1.1	Java provider
  4.1.1.2	BSF provider
  4.1.1.3	EJB provider
  4.1.1.4	COM
  4.1.1.5	etc...
  4.1.2	Pluggable protocol support (SOAP, XP)
  4.1.2.1	must not name general classes as SOAPWhateverDoer
  4.1.2.2	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)   4.4.2.1	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 API  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  6.1.1.1	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 
  9.2.1.1	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  
  
  GLOSSARY
  
  Message Bits => The entire contents of a protocol message, including the transport \
package, any MIME extensions, etc.  
  
  
  


[prev in list] [next in list] [prev in thread] [next in thread]