Apache SOAP Project To-Do List
Updated: November 8, 2002

All of the things listed in intro.html as not supported:
========================================================

- multiple encoding styles in the encodingStyle attribute
  (see section 4.1.1 of the spec)

- actor attribute and SOAP intermediaries (4.2.2)

- complete mustUnderstand attribute behavior - only supports checking
  for and rejecting requests that require mustUnderstand
  checking (4.2.3)

- element typing by having the name of the element bear a definite
  relation to the type, that type then determinable from a schema,
  except for elements named SOAP-ENC:Array (5.1 rule 2c)

- deserialization of null values for XML schema types
  that are mapped to primitive Java types (5.1 rule 9)

- the complete set of XML schema simple types (5.2)

- multi-dimensional arrays (5.4.2), arrays of arrays (5.4.2),
  partially transmitted arrays (5.4.2.1), sparse arrays (5.4.2.2)

- root attribute (5.6)

- input/output and output parameters

General Wish List:
==================

- allow config files to be resources so they can be packed in the war in a
  portable manner
  
- enhance the messaging sample by actually accessing elements from the
  SOAP envelope within the service method
 
- create a sample using envelope editors, an interesting possibility being the
  use of XML digital signature
  
- one-way messaging Microsoft style, in which the server responds with an
  HTTP "202 Accepted" status upon receipt of the request *before* actually
  invoking the method to handle it; this would be a deployment descriptor
  option on the server

- better isolate servlet container dependencies so that server code could
  be used in non-servlet environments
  
- support DIME and WS-Attachments

- mirror Axis XML <--> Java mappings more closely

- optional logging of requests and/or maintenance of request statistics

- schema validation option with a way to specify schemas to possibly
  validate against
  
- change the server side router to a regular class with a small servlet
  to servlet-enable it. The idea is to enable the code to be used to 
  implement server-side support using other transports as well, such as
  a pure SMTP "application" server or a JMS server. The current code is
  almost totally useable, except that we put too much stuff into the
  rpcrouter.jsp JSP - most of that needs to be moved to a regular class.

  The server directory needs to be reorganized a bit too in the process -
  the base server dir should have stuff common to all server-sides, 
  irrespective of deployment platform (http app server or smtp or jms or 
  whatever). 
	[Sanjiva is signed up for this; in-progress]
	[Sanjiva did first cut of this on 6/22/00]

- add a setHeader(s) method to SOAPTransport to allow a client to set 
  transport headers. Currently we allow getting at response headers, but
  not to set outgoing headers. Ouch. Note that SOAPHTTPConnection allows
  headers to be specified in the send method.

- change the APIs to enable one to use this code to do just one directional
  messaging instead of only RPCs. The code already does support one
  directional messaging (the RPC layer is on top of that), but I think
  we can improve the APIs a bit to make that clearer. 

- change the service manager to perist registered services into some
  real store; such as a JDBC store. Currently the stuff is written out
  to a file via serialization. An abstraction layer needs to be put on
  to allow easy integration with hosting app server's persistency 
  mechanism.  This work appears to have at least started, as there is
  also a configuration manager that reads/writes XML.

- consider and understand the role of servlet scopes in lifecycle mgmt of
  objects. We currently allow the deployer of a service to indicate the
  lifecycle of the object providing the service to be one of request,
  page, session or application. There's some unintuitive overlap with
  these scopes and static classes that are used to provide a service.
  Also, need to develop a transport-layer independent way to manage these
  lifecycle roles.

- change the smtp bridge to use JavaMail.

- implement a JMS SOAP transport

- write a JMS <-> HTTP bridge

- write a GUI for the service manager client (one in Java, one in DHTML?).
  If the DHTML client also uses SOAP to talk to the service manager
  service, then the HTML webapp can go away completely. This is a nice
  motivation for SOAP too - we can take a Java class and expose its
  methods via SOAP and write a Java client and a DHTML client that talk
  to it via HTTP and the server side wouldn't care which is which.

- sort out the issue with target object URI vs. method namespace URI. The
  SOAP spec talks about a target object URI, but not about where it goes.
  This needs to be agreed upon for interoperability across different SOAP
  implementations.

- add memory to the calculator demo where the memory is saved on the server
  side. The purpose is to use a session scoped service and to see how to
  implement the cookies stuff so that the right thing happens.