On Mon, Nov 17, 2008 at 8:53 AM, Asankha C. Perera <[EMAIL PROTECTED]>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 <[EMAIL PROTECTED]> <[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 > > -- > Asankha C. Pererahttp://adroitlogic.org > http://esbmagic.blogspot.com > >
