cvs commit: xml-soap TODO

[sa...@locus.apache.org]

sanjiva     00/06/19 04:13:16

  Added:       .        TODO
  Log:
  first-cut at a to-do list
  
  Revision  Changes    Path
  1.1                  xml-soap/TODO
  
  Index: TODO
  ===================================================================
  Apache SOAP Project To-Do List:
  
  - 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]
  
  - 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.
  
  - 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
  	[Under development in IBM; to be committed soon]
  
  - write a JMS bridge
  	[Under development in IBM; to be committed soon]
  
  - write a GUI for the service manager client (one in Java, one in DHTML?)
  
  - 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.