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 RE: Evolutions on XML-SOAP
Date Fri, 04 Aug 2000 17:40:58 GMT
I guess I was not exactly clear so I will try to clarify. My main priority
here is to define with you guys changes that would be part of the core "SOAP
engine". I agree that is not a good idea at all to modify the existing SOAP
to support additional features that are not part of the spec. We really
don't want to embrace-and-extend the Apache-SOAP implementation.

What I want to achieve is to provide the appropriate "hooks" to the existing
Apache-SOAP so that 3rd parties (like us) can use the Apache-SOAP code,
rather than rewriting their own SOAP core implementation.

For instance, we have a need to provide authentication / authroization of
SOAP commands. I don't think this belongs to the Apache-SOAP which I
consider as an implementation of the SOAP spec. I see these extensions as a
set of "plugins" that could be added to the core.

We are going to change our existing server to move to SOAP (right now, we
are using our own XML notation). All we want to do is give back to the
community part of what we are doing to improve the SOAP implementation. This
seems fair, knowing that we will be using some of the code from the

The reason why I even proposed those changes beforehand, rather than giving
patches including those changes is that we want to work with the Apache-SOAP
community to go "in the right direction". If you think what we are proposing
does not fit with Apache-SOAP, that's ok with us too.

I hope this will clarify a bit our point of view. Feel free to contact me
for further information.

Best regards,

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

-----Original Message-----
From: Richard_Stanford@exe.com [mailto:Richard_Stanford@exe.com]
Sent: Friday, August 04, 2000 9:10 AM
To: soap-dev@xml.apache.org
Subject: Re: Evolutions on XML-SOAP

My personal reaction as an observer (rather than a current committer or
anything) is that some of these sound like embrace-and-extend tactics
(especially storing the extra information in the envelope header).
I feel that projects like this are most successful when they correctly
the standard as written.  Extentions are great for add-on products, but
shouldn't interoperability be the primary goal?  The same with security --
its a
good idea, but if implemented externally in a 3rd party product it would
for all complient SOAP servers, and all SOAP servers would work with all
security add-ons (well, good from a standards base rather than a
base I guess).


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.

View raw message