You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@ws.apache.org by Andreas Veithen <an...@gmail.com> on 2008/11/17 01:17:45 UTC
Transport test kit: future directions [Was: Re: Enhancements to the JMS transport]
On Wed, Nov 12, 2008 at 16:37, Asankha C. Perera <as...@apache.org> wrote:
> I must say
> that I am really impressed with the Transport TestKit that Andreas
> developed.. it was initially a black box for me, but soon it started to show
> me many bugs in the code and other issues, and was a really pleasant test
> bench to work with.. I think Andreas has started some Wiki documentation
> that will help others write new tests for other/new transports as well this
> way..
Asankha,
I didn't take the time yet to comment on this part of your mail, I'm
just catching up.
First of all, I would like to thank you for the recognition of my work.
I indeed started a Wiki page [1], but it is still quite rudimentary.
For the moment, the most useful information is contained in the
Javadoc.
I would also like to take the opportunity to explain a bit how I see
the future evolution of this piece of code and where the opportunities
are (and maybe get some more people involved :-). I think that there
are three dimensions where the usage of the test kit could be
expanded:
1. Provide regression testing for other existing or new transports, as
you have suggested. I believe that the first candidate for this should
be the FIX transport. There three reasons for this:
* The FIX transport belongs to the category of transports that are
based on AbstractTransport(Listener|Sender). Since there is no
regression test suite for the FIX transport (and not everybody has the
required knowledge to manually test the transport), this makes changes
in AbstractTransport(Listener|Sender) quite hazardous, because there
is always a risk of accidentally breaking the FIX transport in some
subtle way.
* Given the nature of the FIX protocol, I guess that the quality
requirements are a bit higher than for other transports and a test
suite would certainly help to guarantee that quality.
* I'm not familiar with FIX, but AFAIK all the necessary
infrastructure to run this protocol is available as Java components so
that the tests could be completely self-contained.
2. Test more message exchange patterns and validate that the
transports can be used with various WS-* protocols. Example:
Asynchronous responses with WS-Addressing.
3. Interoperability with (transport implementations of) other Web
Service stacks. The test kit naturally evolved into a design where the
core is (almost) completely independent of Axis2. The reason is that
one of the goals was to test the transports with simple non Axis2
clients (such as java.net.URLConnection for HTTP) and non Axis2
endpoints (e.g. an embedded Jetty engine). This architecture makes it
quite easy to extend the test kit with test clients and endpoints
based on other Web Service stacks, so that we can check
interoperability between the Axis2 transports and their counterparts
in the other frameworks. For example, some time ago Ant Elder
suggested [2] to make the JMS transport compatible with Tuscany's JMS
binding, so Tuscany would be one of the candidates.
Andreas
[1] http://wiki.apache.org/ws/FrontPage/Transport/TestkitHowto
[2] http://markmail.org/message/25ippyjdnhhq4qpi
Re: Transport test kit: future directions [Was: Re: Enhancements
to the JMS transport]
Posted by Asanka Abeysinghe <as...@wso2.com>.
Hi Andreas,
Please see my comments inline.
- Asanka A.
Andreas Veithen wrote:
> 1. Provide regression testing for other existing or new transports, as
> you have suggested. I believe that the first candidate for this should
> be the FIX transport. There three reasons for this:
>
I will do the regression test suite for the FIX protocol, but can only
commit something after December.
> * The FIX transport belongs to the category of transports that are
> based on AbstractTransport(Listener|Sender). Since there is no
> regression test suite for the FIX transport (and not everybody has the
> required knowledge to manually test the transport), this makes changes
> in AbstractTransport(Listener|Sender) quite hazardous, because there
> is always a risk of accidentally breaking the FIX transport in some
> subtle way.
> * Given the nature of the FIX protocol, I guess that the quality
> requirements are a bit higher than for other transports and a test
> suite would certainly help to guarantee that quality.
>
+1
> * I'm not familiar with FIX, but AFAIK all the necessary
> infrastructure to run this protocol is available as Java components so
> that the tests could be completely self-contained.
>
Yes, all FIX components come as Java components (we are using QFJ) so
the test can run as a self-contained test suite.
Re: Transport test kit: future directions [Was: Re: Enhancements to the JMS transport]
Posted by Senaka Fernando <se...@gmail.com>.
On Mon, Nov 17, 2008 at 8:53 AM, Asankha C. Perera <as...@apache.org>wrote:
> Hi Andreas
>
> I fully agree with all of you comments, which are excellent! I myself am
> not familiar with FIX, but know that both Asanka A. and Hiranya (who wrote
> the FIX transport) will be able to handle the immediate suggestion of
> incorporating FIX into the test suite. If you can add some documentation on
> how one could add 1) a new transport, 2) a new test case, I think that will
> be very useful for others to start adding expanding the tests
>
+1, That would really help.
Regards,
Senaka
>
>
> asankha
>
> On Wed, Nov 12, 2008 at 16:37, Asankha C. Perera <as...@apache.org> <as...@apache.org> wrote:
>
>
> I must say
> that I am really impressed with the Transport TestKit that Andreas
> developed.. it was initially a black box for me, but soon it started to show
> me many bugs in the code and other issues, and was a really pleasant test
> bench to work with.. I think Andreas has started some Wiki documentation
> that will help others write new tests for other/new transports as well this
> way..
>
>
> Asankha,
>
> I didn't take the time yet to comment on this part of your mail, I'm
> just catching up.
>
> First of all, I would like to thank you for the recognition of my work.
>
> I indeed started a Wiki page [1], but it is still quite rudimentary.
> For the moment, the most useful information is contained in the
> Javadoc.
>
> I would also like to take the opportunity to explain a bit how I see
> the future evolution of this piece of code and where the opportunities
> are (and maybe get some more people involved :-). I think that there
> are three dimensions where the usage of the test kit could be
> expanded:
>
> 1. Provide regression testing for other existing or new transports, as
> you have suggested. I believe that the first candidate for this should
> be the FIX transport. There three reasons for this:
>
> * The FIX transport belongs to the category of transports that are
> based on AbstractTransport(Listener|Sender). Since there is no
> regression test suite for the FIX transport (and not everybody has the
> required knowledge to manually test the transport), this makes changes
> in AbstractTransport(Listener|Sender) quite hazardous, because there
> is always a risk of accidentally breaking the FIX transport in some
> subtle way.
> * Given the nature of the FIX protocol, I guess that the quality
> requirements are a bit higher than for other transports and a test
> suite would certainly help to guarantee that quality.
> * I'm not familiar with FIX, but AFAIK all the necessary
> infrastructure to run this protocol is available as Java components so
> that the tests could be completely self-contained.
>
> 2. Test more message exchange patterns and validate that the
> transports can be used with various WS-* protocols. Example:
> Asynchronous responses with WS-Addressing.
>
> 3. Interoperability with (transport implementations of) other Web
> Service stacks. The test kit naturally evolved into a design where the
> core is (almost) completely independent of Axis2. The reason is that
> one of the goals was to test the transports with simple non Axis2
> clients (such as java.net.URLConnection for HTTP) and non Axis2
> endpoints (e.g. an embedded Jetty engine). This architecture makes it
> quite easy to extend the test kit with test clients and endpoints
> based on other Web Service stacks, so that we can check
> interoperability between the Axis2 transports and their counterparts
> in the other frameworks. For example, some time ago Ant Elder
> suggested [2] to make the JMS transport compatible with Tuscany's JMS
> binding, so Tuscany would be one of the candidates.
>
> Andreas
>
> [1] http://wiki.apache.org/ws/FrontPage/Transport/TestkitHowto
> [2] http://markmail.org/message/25ippyjdnhhq4qpi
>
> --
> Asankha C. Pererahttp://adroitlogic.org
> http://esbmagic.blogspot.com
>
>
Re: Transport test kit: future directions [Was: Re: Enhancements
to the JMS transport]
Posted by "Asankha C. Perera" <as...@apache.org>.
Hi Andreas
I fully agree with all of you comments, which are excellent! I myself am
not familiar with FIX, but know that both Asanka A. and Hiranya (who
wrote the FIX transport) will be able to handle the immediate suggestion
of incorporating FIX into the test suite. If you can add some
documentation on how one could add 1) a new transport, 2) a new test
case, I think that will be very useful for others to start adding
expanding the tests
asankha
> On Wed, Nov 12, 2008 at 16:37, Asankha C. Perera <as...@apache.org> wrote:
>
>> I must say
>> that I am really impressed with the Transport TestKit that Andreas
>> developed.. it was initially a black box for me, but soon it started to show
>> me many bugs in the code and other issues, and was a really pleasant test
>> bench to work with.. I think Andreas has started some Wiki documentation
>> that will help others write new tests for other/new transports as well this
>> way..
>>
> Asankha,
>
> I didn't take the time yet to comment on this part of your mail, I'm
> just catching up.
>
> First of all, I would like to thank you for the recognition of my work.
>
> I indeed started a Wiki page [1], but it is still quite rudimentary.
> For the moment, the most useful information is contained in the
> Javadoc.
>
> I would also like to take the opportunity to explain a bit how I see
> the future evolution of this piece of code and where the opportunities
> are (and maybe get some more people involved :-). I think that there
> are three dimensions where the usage of the test kit could be
> expanded:
>
> 1. Provide regression testing for other existing or new transports, as
> you have suggested. I believe that the first candidate for this should
> be the FIX transport. There three reasons for this:
>
> * The FIX transport belongs to the category of transports that are
> based on AbstractTransport(Listener|Sender). Since there is no
> regression test suite for the FIX transport (and not everybody has the
> required knowledge to manually test the transport), this makes changes
> in AbstractTransport(Listener|Sender) quite hazardous, because there
> is always a risk of accidentally breaking the FIX transport in some
> subtle way.
> * Given the nature of the FIX protocol, I guess that the quality
> requirements are a bit higher than for other transports and a test
> suite would certainly help to guarantee that quality.
> * I'm not familiar with FIX, but AFAIK all the necessary
> infrastructure to run this protocol is available as Java components so
> that the tests could be completely self-contained.
>
> 2. Test more message exchange patterns and validate that the
> transports can be used with various WS-* protocols. Example:
> Asynchronous responses with WS-Addressing.
>
> 3. Interoperability with (transport implementations of) other Web
> Service stacks. The test kit naturally evolved into a design where the
> core is (almost) completely independent of Axis2. The reason is that
> one of the goals was to test the transports with simple non Axis2
> clients (such as java.net.URLConnection for HTTP) and non Axis2
> endpoints (e.g. an embedded Jetty engine). This architecture makes it
> quite easy to extend the test kit with test clients and endpoints
> based on other Web Service stacks, so that we can check
> interoperability between the Axis2 transports and their counterparts
> in the other frameworks. For example, some time ago Ant Elder
> suggested [2] to make the JMS transport compatible with Tuscany's JMS
> binding, so Tuscany would be one of the candidates.
>
> Andreas
>
> [1] http://wiki.apache.org/ws/FrontPage/Transport/TestkitHowto
> [2] http://markmail.org/message/25ippyjdnhhq4qpi
>
>
--
Asankha C. Perera
http://adroitlogic.org
http://esbmagic.blogspot.com
Re: Transport test kit: future directions [Was: Re: Enhancements
to the JMS transport]
Posted by Asanka Abeysinghe <as...@wso2.com>.
Hi Andreas,
Please see my comments inline.
- Asanka A.
Andreas Veithen wrote:
> 1. Provide regression testing for other existing or new transports, as
> you have suggested. I believe that the first candidate for this should
> be the FIX transport. There three reasons for this:
>
I will do the regression test suite for the FIX protocol, but can only
commit something after December.
> * The FIX transport belongs to the category of transports that are
> based on AbstractTransport(Listener|Sender). Since there is no
> regression test suite for the FIX transport (and not everybody has the
> required knowledge to manually test the transport), this makes changes
> in AbstractTransport(Listener|Sender) quite hazardous, because there
> is always a risk of accidentally breaking the FIX transport in some
> subtle way.
> * Given the nature of the FIX protocol, I guess that the quality
> requirements are a bit higher than for other transports and a test
> suite would certainly help to guarantee that quality.
>
+1
> * I'm not familiar with FIX, but AFAIK all the necessary
> infrastructure to run this protocol is available as Java components so
> that the tests could be completely self-contained.
>
Yes, all FIX components come as Java components (we are using QFJ) so
the test can run as a self-contained test suite.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org