You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-dev@xml.apache.org by Ryo Neyama <ne...@trl.ibm.co.jp> on 2000/11/02 14:03:25 UTC
Transport hook extension
Any comment or objection to this proposal?
I'm going to commit the extension to the CVS repository on the next
Monday in Japan time (+9 ahead to GMT). I hope to have any comment
within this weekend.
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: Transport hook extension
Posted by Vahe Amirbekyan <av...@techone.com>.
Hello Ryo et al.,
Ryo Neyama wrote:
>
> Any comment or objection to this proposal?
Your proposal looks very good, and I agree that this kind of
functionality is extremely useful, especially when we "talk" to systems
which use non-SOAP XML formats. Actually, we implemented a similar
framework (transformers) and plugged it into our customized ApacheSOAP
some time ago. As your EnvelopeEditors, the transformers can be regarded
as filters are in CORBA. As with your solution, transformers process
XML->XML on both sides using various tools (in particular, we used
XSLTs, but it is generally open to any other tool/technology). There are
several differences between your and our approaches though:
- Transformers can be linked in chains, the output of one transformer is
input for the following transformer
- Transformers can be applied to selected SOAP messages based on the
following criteria:
- whether it is IN or OUT message (for both client and server)
- target object(s)
- target method(s)
- specific document type
- Transformers framework itself is separate and does not depend on the
SOAP. It is incorporated into SOAP via subclasing the Envelope, Call and
Response classes (we didn't want to change the original code at that
time). We had to also enhance the DeploymentDescriptor class and tweak
the ServiceManager.
Just in case you weren't participating in the mailing list at that time
- please, look at my email sent on September 6th with the attached code
of our transformers in the archives
(http://archive.covalent.net/xml/soap-dev/2000/09/0085.xml). We would be
happy to cooperate with you, to share our experience/design/code in
order to come up with some really powerful solution.
With the best regards, Vahe
> I'm going to commit the extension to the CVS repository on the next
> Monday in Japan time (+9 ahead to GMT). I hope to have any comment
> within this weekend.
>
> Regards,
> Ryo Neyama @ IBM Research, Tokyo Research Laboratory
> Internet Technology
> neyama@trl.ibm.co.jp
>
> > 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.
> >
--
(\______________________________________________________/)
__|_| Vahe AMIRBEKYAN, Senior Consultant |_|__
(___o) tel: (510) 729 6750 ext.375 (o___)
(__o) mailto:avahe@techone.com (o__)
(__o) http://www.techone.com (o__)
(_o)____________________________________________________(o_)
Re: Transport hook extension
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
+1
----- Original Message -----
From: "Ryo Neyama" <ne...@trl.ibm.co.jp>
To: <so...@xml.apache.org>
Sent: Thursday, November 02, 2000 8:03 AM
Subject: Transport hook extension
> Any comment or objection to this proposal?
>
> I'm going to commit the extension to the CVS repository on the next
> Monday in Japan time (+9 ahead to GMT). I hope to have any comment
> within this weekend.
>
> 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: Transport hook extension
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
+1
----- Original Message -----
From: "Ryo Neyama" <ne...@trl.ibm.co.jp>
To: <so...@xml.apache.org>
Sent: Thursday, November 02, 2000 8:03 AM
Subject: Transport hook extension
> Any comment or objection to this proposal?
>
> I'm going to commit the extension to the CVS repository on the next
> Monday in Japan time (+9 ahead to GMT). I hope to have any comment
> within this weekend.
>
> 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: Transport hook extension
Posted by Vahe Amirbekyan <av...@techone.com>.
Hello Ryo et al.,
Ryo Neyama wrote:
>
> Any comment or objection to this proposal?
Your proposal looks very good, and I agree that this kind of
functionality is extremely useful, especially when we "talk" to systems
which use non-SOAP XML formats. Actually, we implemented a similar
framework (transformers) and plugged it into our customized ApacheSOAP
some time ago. As your EnvelopeEditors, the transformers can be regarded
as filters are in CORBA. As with your solution, transformers process
XML->XML on both sides using various tools (in particular, we used
XSLTs, but it is generally open to any other tool/technology). There are
several differences between your and our approaches though:
- Transformers can be linked in chains, the output of one transformer is
input for the following transformer
- Transformers can be applied to selected SOAP messages based on the
following criteria:
- whether it is IN or OUT message (for both client and server)
- target object(s)
- target method(s)
- specific document type
- Transformers framework itself is separate and does not depend on the
SOAP. It is incorporated into SOAP via subclasing the Envelope, Call and
Response classes (we didn't want to change the original code at that
time). We had to also enhance the DeploymentDescriptor class and tweak
the ServiceManager.
Just in case you weren't participating in the mailing list at that time
- please, look at my email sent on September 6th with the attached code
of our transformers in the archives
(http://archive.covalent.net/xml/soap-dev/2000/09/0085.xml). We would be
happy to cooperate with you, to share our experience/design/code in
order to come up with some really powerful solution.
With the best regards, Vahe
> I'm going to commit the extension to the CVS repository on the next
> Monday in Japan time (+9 ahead to GMT). I hope to have any comment
> within this weekend.
>
> Regards,
> Ryo Neyama @ IBM Research, Tokyo Research Laboratory
> Internet Technology
> neyama@trl.ibm.co.jp
>
> > 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.
> >
--
(\______________________________________________________/)
__|_| Vahe AMIRBEKYAN, Senior Consultant |_|__
(___o) tel: (510) 729 6750 ext.375 (o___)
(__o) mailto:avahe@techone.com (o__)
(__o) http://www.techone.com (o__)
(_o)____________________________________________________(o_)