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 "Nelson, Christopher" <cn...@synchrony.net> on 2000/10/31 15:57:51 UTC
RE: Commit of the fixes and extensions (WAS Re: Request for two n
ew locus IDs)
Can you send the attachments again? I would like to see the code. It
sounds like your needs would be having a preprocessing handler. Is this
true? There are many proposals floating around to do this, and we should
probably try to merge these and get something in the code ASAP. I think it
would be a very good idea to have it driven by the Deployment Descriptor.
I've looked at this code and it shouldn't be too bad to do this, I think.
Are you able to attend the IRC chat today? We could hash things out
there...
-----Original Message-----
From: Ryo Neyama [mailto:neyama@trl.ibm.co.jp]
Sent: Tuesday, October 31, 2000 2:44 AM
To: soap-dev@xml.apache.org
Cc: brian@collab.net
Subject: Commit of the fixes and extensions (WAS Re: Request for two new
locus IDs)
> Accounts created, temp. passwords sent, cvs avail will be set up as soon
> as I finish this batch of account additions and make the commit of the new
> avail file. Sorry about the delay.
>
> Brian
Thank you for creating the account.
I will commit the two bug fixes I sent some days ago, that is:
fix for NullPointerException in QName
fix for NullPointerException in MessageRouterServlet
Also, I'll commit the transport hooking extension after making sure
there is no objection against the proposal. I attached the proposal I
sent before (see below). The attached files are omitted here so as
not to waste the network resources.
Regards,
Ryo Neyama @ IBM Research, Tokyo Research Laboratory
Internet Technology
neyama@trl.ibm.co.jp
-----------------
Subject: Proposal: add hooks in the Apache SOAP 2.0
From: Ryo Neyama <ne...@trl.ibm.co.jp>
To: soap-dev@xml.apache.org
Cc: neyama@trl.ibm.co.jp
Date: Thu, 19 Oct 2000 17:37:55 +0900
Reply-To: soap-dev@xml.apache.org
X-Mailer: Mew version 1.94.2 on Emacs 20.4 / Mule 4.0 (HANANOEN)
Mailing-List: contact soap-dev-help@xml.apache.org; run by ezmlm
list-help: <ma...@xml.apache.org>
list-unsubscribe: <ma...@xml.apache.org>
list-post: <ma...@xml.apache.org>
Hi,
I propose some modifications to Apache SOAP to increase extensibility
and flexibility. We needed such extension in order to sign request
and response envelopes using header entries, i.e. "Signature" tag is
added to embed signature information in the header part. However,
the current Apache SOAP does not provide developers with any elegant
way to process envelopes. Our approach is to hook envelopes immediate
before the transport at client side, and immediate after the transport
at server side. With this extension, you can set envelope processing
components such as the signer component to SOAP engine, minimizing
the impact on Apache SOAP in the sense that existing applications
should work.
------
Proposal: add hooks in the Apache SOAP 2.0:
The Fig.1 illustrates the current message flow between SOAP client
and server in the Apache SOAP 2.0 and the Fig.2 shows our proposal.
Vertical lines are timelines of functions and horizontal lines are
message flows between functions.
The proposed change in the Fig.2 is to add XML-in/XML-out hooks
(EnvelopeEditors in the chart below) between a network transport and
SOAP message handlers where a string format of XML message flows. The
advantage of this hook is flexibility that a programmer can add any
functions that modify raw SOAP messages in any sense, such as sign a
message, transcode a format with XSLT processor, and so on. One of
the disadvantage of this approach is performance because there is a
possibility of calling a XML parser multiple times in each added
function. At this time, we would like to take the flexibility.
There is another change proposed in the Fig.2 The current SOAP 2.0
implementation invokes a hard-coded XML parser. We would like to
propose to make is replaceable with any other XML parsers. This gives
programmers a freedom of parser choice. Another advantage is that
this may be able to improve perfomance by eliminating multiple parser
calls because this is regarded as another kind of XML-in/DOM-out hook
and extension can be implemented as a part of parser (liaison)
functions.
Manifest of ZIP file:
xml-soap/fig1.gif ---> Fig.1
xml-soap/fig2.gif ---> Fig.2
(mod)
xml-soap/java/src/org/apache/soap/server/http/MessageRouterServlet.java
(mod) xml-soap/java/src/org/apache/soap/server/http/RPCRouterServlet.java
(mod) xml-soap/java/src/org/apache/soap/server/http/ServerHTTPUtils.java
(mod) xml-soap/java/samples/messaging/SendMessage.java
(add) xml-soap/java/src/org/apache/soap/transport/FilterTransport.java
(add) xml-soap/java/samples/messaging/SampleXMLParserLiaison.java
(add) xml-soap/java/src/org/apache/soap/transport/EnvelopeEditorAdapter.java
(add) xml-soap/java/src/org/apache/soap/transport/EnvelopeEditorFactory.java
(add) xml-soap/java/src/org/apache/soap/transport/EnvelopeEditor.java
Note that (mod) and (add) means the source code was modified or added
respectevely.
For more detail, please take a look at comments in the modified or
added source codes.
I hope any comments or questions for this proposal.
RE: Commit of the fixes and extensions (WAS Re: Request for two n
ew locus IDs)
Posted by Ryo Neyama <ne...@trl.ibm.co.jp>.
Nelson,
From: "Nelson, Christopher" <cn...@synchrony.net>
Subject: RE: Commit of the fixes and extensions (WAS Re: Request for two n ew locus IDs)
Date: Tue, 31 Oct 2000 09:57:51 -0500
> Can you send the attachments again? I would like to see the code.
I'll send you the attachments as a private mail later.
> It
> sounds like your needs would be having a preprocessing handler. Is this
> true?
Yes. That's right.
> There are many proposals floating around to do this, and we should
> probably try to merge these and get something in the code ASAP. I think it
> would be a very good idea to have it driven by the Deployment Descriptor.
> I've looked at this code and it shouldn't be too bad to do this, I think.
Yes. I agree with you. In my understanding the work is driven in the
context of Apache SOAP V3, right? My needs is to insert preprocessors
of SOAP headers in V2, too. Although the transport hook extension
seems to be a "rushed" job, I think it is reasonable in the sense of
compatibility (there is no need to change applications for conformity
to the extension) and flexibility (Developers can insert any hook in
hook, for example XSLT stylesheet, SAX event handler, Base-64
encoder/decoder, and so on).
> Are you able to attend the IRC chat today? We could hash things out
> there...
I'm sorry I couldn't attend the chat. I haven't read your e-mail
yesterday.
Regards,
Ryo Neyama @ IBM Research, Tokyo Research Laboratory
Internet Technology
neyama@trl.ibm.co.jp
RE: Commit of the fixes and extensions (WAS Re: Request for two n
ew locus IDs)
Posted by Ryo Neyama <ne...@trl.ibm.co.jp>.
Nelson,
From: "Nelson, Christopher" <cn...@synchrony.net>
Subject: RE: Commit of the fixes and extensions (WAS Re: Request for two n ew locus IDs)
Date: Tue, 31 Oct 2000 09:57:51 -0500
> Can you send the attachments again? I would like to see the code.
I'll send you the attachments as a private mail later.
> It
> sounds like your needs would be having a preprocessing handler. Is this
> true?
Yes. That's right.
> There are many proposals floating around to do this, and we should
> probably try to merge these and get something in the code ASAP. I think it
> would be a very good idea to have it driven by the Deployment Descriptor.
> I've looked at this code and it shouldn't be too bad to do this, I think.
Yes. I agree with you. In my understanding the work is driven in the
context of Apache SOAP V3, right? My needs is to insert preprocessors
of SOAP headers in V2, too. Although the transport hook extension
seems to be a "rushed" job, I think it is reasonable in the sense of
compatibility (there is no need to change applications for conformity
to the extension) and flexibility (Developers can insert any hook in
hook, for example XSLT stylesheet, SAX event handler, Base-64
encoder/decoder, and so on).
> Are you able to attend the IRC chat today? We could hash things out
> there...
I'm sorry I couldn't attend the chat. I haven't read your e-mail
yesterday.
Regards,
Ryo Neyama @ IBM Research, Tokyo Research Laboratory
Internet Technology
neyama@trl.ibm.co.jp