xml-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Noel Gadreau <jngadr...@activcard.com>
Subject Evolutions on XML-SOAP
Date Fri, 04 Aug 2000 15:55:23 GMT
First of all, I would like to say that I was really impressed when I first
tried XML-SOAP recently to have a package that allows so powerful things. 

My company (ActivCard, http://www.activcard.com ) wants to use the XML-SOAP
toolkit for the SOAP related tools that we want to have. Basically, we want
to be able to:

	1) put some information in the envelope header in order to keep some
session information
	2) provide other services on top of SOAP, not just RPC. For
instance, we want to be able to:
		- have a component that will be able to look at the envelope
and route it to the actual server performing the request
		- have a component that will perform some access control on
the SOAP services
		- rewrite or modify an envelope before passing along to
another part
	3) when performing a call, have a way to provide additionnal
information about the call (who is performing the call, what are the
permissions, ...)

I have downloaded the XML-SOAP source code from CVS and started playing with
it. In order to be able to implement the above features, we are going to
need to extend the existing implementation. My company has agreed to give
back all the changes to the XML-SOAP project. Therefore, I thought that I
would share with you what I changes I have in mind, so that everybody can
provide feedback, ideas, improvement, ... BEFORE I start the implementation.
This would allow to have our modifications go in the "right direction" from
the XML-SOAP point of view. 

The proposition below is my first view of the modifications I would like to
perform. I am still quite new to SOAP and XML-SOAP, so I will probably
missed things, so I apologize in advance if I mention something stupid, or
already implemented in the code... :-)

We have already implemented in Java a system using XML commands that
provides the above services, but we want to use the SOAP formalism for the
XML commands, instead of our own XML format. Some on the concepts that I
will mention below are extracted from the system we have already, just
adapted to the SOAP environment/language.

Here are the proposals (I numbered them so that we can refer to them more
easily)


P1) SOAP Envelope Parser / SOAP Envelope Reader
===============================================

One first comment is on how the SOAP Envelope is created. Right now, it is
through the static method "Envelope.unmarshall".

For instance, in the rpcrouter.jsp, you have:
		...
	      payloadEl = callDoc.getDocumentElement ();
	      Envelope callEnv = Envelope.unmarshall (payloadEl);
		...

The problem with the static method here is that what you will be creating is
necessarly an Envelope, and there is no way to create a sub-class.

In our current system, we have what would be a "SOAP Envelope Parser" which
is going to parse the input and create you an "Envelope" object. The
advantage is that if you want to create a different kind of Envelope, all
you need is a different SOAPEnvelopeParser.

Right now, we use this to support a JAXP XML parser or Xerces as XML parser,
so we just have 2 subclasses of the EnvelopeParser, one for JAXP and one for
Xerces (I know about the ...ParserLiaison, but this is more as an example).


In a recent C++ implementation thread, James Snell kinda mentioned something
equivalent as a "SOAPEnvelopeReader". I don't know if we should have a
"SOAPEnvelopeReader" being a "java.io.Reader" and/or a "SOAPEnvelopeParser"
parser ?


P2) "EnvelopeProcessors"
========================

Given what we want to do (see beginning of the e-mail), we need to be able
to process the envelope, without necessarly creating a "Call" object out of
it. For instance, if I just want to create a router that is going to
dispatch the SOAP envelope to the appropriate server, based on the service,
I don't need to unmarshall everything.

The idea here is to define a "EnvelopeProcessor" interface:

	Envelope processEnvelope(Envelope cmd); // probably throws an
Exception => which one ?

which would mean: take the "cmd" envelope, process it and (possibly) return
the response envelope (or null if none).

Then, you can define EnvelopeProcessors for all the tasks you want to do
(like RoutingProcessor, RPCCallProcessor, LoggingProcessor,
AccessControlProcessor, ...). 

For those familiar with Tomcat / Catalina, I would say this is similar to
the "Valves" in Catalina. 

In the C++ implementation thread, "message handlers" and "transport
handlers" were also mentionned. I think this is a similar idea. I am
wondering if there should be some handlers for specific steps of the process
(processHeader, processBody, ... ) or just a "processEnvelop" function. If
it is decomposed in several entry point, that would make it closer to the
"Interceptors" used in Tomcat, whereas the one function approach is closer
to the "Valves" in Catalina. Your feedback would be welcome on this point...
:-)


P4) HeaderHandlers
==================

I have seen on the SOAP@discuss.develop.com mailing list some mentions of
"Header Handlers" which would be called to handle the different "header
entries". I think this is something really interesting and I would like to
know what would be needed to have this features. This way, it would be
possible to register HeaderHandlers in the "SOAP Engine" and then the engine
would invoke them automatically. Has anybody already 


P5) EnvelopeContext / CallContext
=================================

The above interface for the EnvelopeProcessor is a bit simplified. In fact,
I am more thinking to something like:

	Envelope processEnvelope(Envelope cmd, EnvelopeContext ctxt) throws
SomeException; 

This EnvelopeContext would contain some information used by the server to
perform the processing. I see this as a mix between a "ServletRequest" and a
"ServletContext". In the EnvelopeContext, you would have attributes that can
be stored (similar to the attributes you can put in a ServletRequest, or in
a HttpSession). This would allow EnvelopeProcessors to attach information to
the "context" as they process the envelope.

For instance, you could have the servlet put some information about the HTTP
request:

"soap.transport.http.clientIP" => "123.45.67.89"
"soap.transport.http.secure" => true
"soap.transport.http.clientCert" => someX509Cert

Another processor performing access control could put the rights on the user
in the attributes, so that the following processor have this information
available if needed. This context could also be where the unmarshalled
parameters are stored, before the actual call, making them available to the
processors.

For the methods available, I was thinking to map the Servlet API equivalent:

	void setAttribute(String name, Object value);
	Object getAttribute(String name);
	void removeAttribute(String name);
	java.util.Enumeration getAttributeNames(); //I am not sure about
this one...

I think this EnvelopeContext could also provide some higher level services,
like the ServletContext. For instance, there could be a "log" function
defined in the EnvelopeContext that can be used by any of the processors. I
don't know exactly what services should be exposed at this level.

To be honest, I don't really like the "EnvelopeContext" name, and I am
wondering if something would be more appropriate (like CallContext ? ).



P5) Have a new kind of call
===========================

We would also like to have another "Call" class that can take advantage of
the EnvelopeContext. I think it is possible to have both "Calls" exist in
the same environment. You could have two "EnvelopeProcessor", one that
handles "Call" and another that handles "ExtendedCall" (or whatever name),
and let's say that passes as a first parameter the "EnvelopeContext" so that
it can be used when implementing the function. 

For instance, let's take the StockQuoteService example, where you have the
function:

	float getQuote(String symbol)

, you could imagine the ExtendedStockQuoteService that would be defined as:

	float getQuote(EnvelopeContext ctxt, String symbol)

and that could use the information in the context to compute the result
(like look whether the client is considered a member and therefore should
get real-time quotes, compared to an anonymous user that would get 20
minutes delayed quotes).


P6) SOAPEngine
==============

I am wondering if having a separate class "SOAPEngine" could be useful. It
could the place where you register HeaderHandler, as well as all the
SOAPMappings. 


P7) SOAP Servlet
================

As I am writing this e-mail, I have seen that there is a servlet
implementation going on. It would be nice to integrate the above stuff in
this servlet.



I am sorry for the length of this e-mail but I though it was better to group
in one e-mail all the proposals since they are all related to each other.
This proposal is how I see things right now, I would encourage feedback so
that we can get to a better overall result. If you think that this does not
really belong to XML-SOAP, let me know. It may sound that we want to add
extensions to the actual SOAP, but what I am really interested in is to do
the necessary changes so that extensions can be written using the XML-SOAP
codebase. If interesting, those extensions could be included separately of
XML-SOAP.


Thanks a lot for your time.

Best regards,
Jean-Noel GADREAU


=============
Jean-Noel GADREAU
Software Engineer, ActivCard Inc.(http://www.activcard.com )
E-mail: jngadreau@activcard.com
Tel (main): 510-574-0100
Tel (direct): 510-574-1736




Mime
View raw message