On Wed, Nov 12, 2008 at 16:37, Asankha C. Perera <[EMAIL PROTECTED]> 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
