You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-dev@ws.apache.org by Sanjiva Weerawarana <sa...@watson.ibm.com> on 2000/06/14 15:48:34 UTC
to-do list
Here's a list of items that I have in mind as to-do items for the xml-soap
codebase:
- 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.
Unless anyone objects I'd like to do this. 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).
- 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.
- 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.
- change the smtp bridge to use JavaMail.
That's all I can think of for now .. so, who's willing to do what? :-)
I think Matt also has a detailed list of items on his whiteboard .. we'll
send that too (those were lower granularity items as far as I remember).
Sanjiva.
Re: to-do list
Posted by Eric Anderson <er...@ultracode.com>.
Sanjiva Weerawarana wrote:
> Here's a list of items that I have in mind as to-do items for the xml-soap
> codebase:
>
> - 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.
>
>> That's all I can think of for now .. so, who's willing to do what? :-)
>>
>
>> Sanjiva.
>
I've already hacked rpcrouter.jsp into an HttpServlet class to use for my own
purposes. I'd be willing to submit a direct port (w/o my proprietary
additions)
if there's any demand.
-Eric
Re: to-do list
Posted by Eric Anderson <er...@ultracode.com>.
Sanjiva Weerawarana wrote:
> Here's a list of items that I have in mind as to-do items for the xml-soap
> codebase:
>
> - 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.
>
>> That's all I can think of for now .. so, who's willing to do what? :-)
>>
>
>> Sanjiva.
>
I've already hacked rpcrouter.jsp into an HttpServlet class to use for my own
purposes. I'd be willing to submit a direct port (w/o my proprietary
additions)
if there's any demand.
-Eric
Re: to-do list
Posted by Eric Anderson <er...@ultracode.com>.
Ara Kassabian wrote:
> I am pretty new to this list so I hope I am not breaking any protocols.
> However, if I may suggest some additional to-dos:
>
> 3. Implement a more general object location scheme (that supports the
> location of EJBs, for example).
Yes! I've plugged in my own ad-hoc object location scheme, which uses a
homegrown naming service. It would be nice if the location/instantiation
scheme was pluggable by design.
Here's a trivial request for the to-do list: In ServiceManager.java, the
deployment descriptor filename needs to be passed as a parameter on a new
constructor.
public ServiceManager(String ddFile)
{
filename = ddFile;
ServiceManager();
}
...or the equivalent.
-Eric
Re: to-do list
Posted by Eric Anderson <er...@ultracode.com>.
Ara Kassabian wrote:
> I am pretty new to this list so I hope I am not breaking any protocols.
> However, if I may suggest some additional to-dos:
>
> 3. Implement a more general object location scheme (that supports the
> location of EJBs, for example).
Yes! I've plugged in my own ad-hoc object location scheme, which uses a
homegrown naming service. It would be nice if the location/instantiation
scheme was pluggable by design.
Here's a trivial request for the to-do list: In ServiceManager.java, the
deployment descriptor filename needs to be passed as a parameter on a new
constructor.
public ServiceManager(String ddFile)
{
filename = ddFile;
ServiceManager();
}
...or the equivalent.
-Eric
RE: to-do list
Posted by Ara Kassabian <ar...@techone.com>.
I am pretty new to this list so I hope I am not breaking any protocols.
However, if I may suggest some additional to-dos:
1. Implement a SOAP transport that is based on Java Message Service.
2. Change some of the APIs to more closely conform to the factory pattern
used in most of the JDK APIs.
3. Implement a more general object location scheme (that supports the
location of EJBs, for example).
4. Create a SOAP compiler to automatically generate client-side stubs and
skeletons, like a CORBA IDL compiler would.
----------------------------------------------
Ara Kassabian
Manager, TechOne, Inc.
7677 Oakport Street, Suite 1030
Oakland, CA 94621
http://www.techone.com
ara@techone.com
(510) 729-6750 Ext. 396 (Oakland)
(818) 548-4135 (Los Angeles)
-----Original Message-----
From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
Sent: Wednesday, June 14, 2000 6:49 AM
To: Apache SOAP
Subject: to-do list
Here's a list of items that I have in mind as to-do items for the xml-soap
codebase:
- 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.
Unless anyone objects I'd like to do this. 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).
- 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.
- 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.
- change the smtp bridge to use JavaMail.
That's all I can think of for now .. so, who's willing to do what? :-)
I think Matt also has a detailed list of items on his whiteboard .. we'll
send that too (those were lower granularity items as far as I remember).
Sanjiva.
Re: to-do list
Posted by James Duncan Davidson <ja...@eng.sun.com>.
on 6/14/00 6:48 AM, Sanjiva Weerawarana at sanjiva@watson.ibm.com wrote:
> Here's a list of items that I have in mind as to-do items for the xml-soap
Can you check it into the repository as a TODO file?
.duncan
Re: to-do list
Posted by James Duncan Davidson <ja...@eng.sun.com>.
on 6/14/00 6:48 AM, Sanjiva Weerawarana at sanjiva@watson.ibm.com wrote:
> Here's a list of items that I have in mind as to-do items for the xml-soap
Can you check it into the repository as a TODO file?
.duncan
RE: to-do list
Posted by Ara Kassabian <ar...@techone.com>.
I am pretty new to this list so I hope I am not breaking any protocols.
However, if I may suggest some additional to-dos:
1. Implement a SOAP transport that is based on Java Message Service.
2. Change some of the APIs to more closely conform to the factory pattern
used in most of the JDK APIs.
3. Implement a more general object location scheme (that supports the
location of EJBs, for example).
4. Create a SOAP compiler to automatically generate client-side stubs and
skeletons, like a CORBA IDL compiler would.
----------------------------------------------
Ara Kassabian
Manager, TechOne, Inc.
7677 Oakport Street, Suite 1030
Oakland, CA 94621
http://www.techone.com
ara@techone.com
(510) 729-6750 Ext. 396 (Oakland)
(818) 548-4135 (Los Angeles)
-----Original Message-----
From: Sanjiva Weerawarana [mailto:sanjiva@watson.ibm.com]
Sent: Wednesday, June 14, 2000 6:49 AM
To: Apache SOAP
Subject: to-do list
Here's a list of items that I have in mind as to-do items for the xml-soap
codebase:
- 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.
Unless anyone objects I'd like to do this. 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).
- 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.
- 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.
- change the smtp bridge to use JavaMail.
That's all I can think of for now .. so, who's willing to do what? :-)
I think Matt also has a detailed list of items on his whiteboard .. we'll
send that too (those were lower granularity items as far as I remember).
Sanjiva.