1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
|
Apache SOAP Project To-Do List:
V2.1 ToDo List:
===============
Owner(s) Item
-------- ---------------------------------------------------------------
V2.1 Wish List:
===============
(items can move to ToDo List if there's an owner):
Owner Item
-------- ---------------------------------------------------------------
? Support HTTP Basic Authentication
? Support HTTP Sessions
General Wish List:
==================
- Add an interface such that if the service class implements that interface
the SOAP engine will call a method (ie. setContext() ) with context
information. Similar to the SOAPContext 'bag' thing we have but pass
it to the service not just the provider.
- 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.
- 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
- 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.
|
