Nick, Please see my questions/comments inline.
Thanks, Andreas On Sat, Jul 11, 2009 at 06:49, Neuberger, Nicholas (EHQ)<npneuber...@express-scripts.com> wrote: > I'll give everyone a quick status of our progress on extending TcpMon with a > record / playback functionality. > > Here's what we have now, but there are a few flaws. > > New Feature: > *Added record / playback feature that is SOAP centric (this was our primary > need). What kind of SOAP processing framework does it use? > **Added record / playback icon on the screen to turn on feature. Did you integrate that into the Swing UI or the Eclipse plugin? > *When R/P feature is on the following occurs: > > The incoming request is analyzed and parsed. All SOAP header information and > XML soap request is parsed into a pojo/domain object. The object is then > checked to determine if it is stored in the database. We are currently using > hashCode for object identity, which appears to be a short term solution. > The parsing to POJO and the use of hashCode sounds like it's very specific to your use case, or do I miss something? > We compare the identity on the XML soap message only, and store other parts > as additional fields like the following: > --If it isn't then a request to the backend remote host is forwarded and the > response is returned back to TcpMon and stored in the database. Final the > response is returned back to the original request on the listening port. > > --If it is in the database, then the response from the db is returned back to > the original request on the listening port. > > > Currently we are using Spring / Hibernate for the persistence layer and MySQL > for the local database. Now current implementation with these api's > probably won't mesh well with a patch to an Apache project and GPL / Apache > licensing. Also, we are going looking at building into the application an > In-Memory database possibly (h2, hsqldb, or derby). > We already depend on Spring in other Apache projects. Not sure about Hibernate though. For the database, Derby should be fine. > The current implementation we have is SOAP centric but could possibly be > enhanced for other things as well. And there are issues with using hashCode > on the soap envelope. If any request comes in with any different value, > then the remote server is called, which in some development cases, you > wouldn't want that. In one scenario, a developer would want to always > return the same response no matter what. Basically, an override table that > if a request with a soap action of: findMyWidgets then always return a > default down response. > > Thoughts? I'm open to any suggestions, criticism, ideas. > Some other questions that come to my mind: - Is the feature completely optional, i.e. can TCPMon still be used as before (in particular without the need to configure the database connection) if the user doesn't need the R/P feature? - What is the amount of change to the existing code base? > Nick > > -----Original Message----- > From: Andreas Veithen [mailto:andreas.veit...@gmail.com] > Sent: Saturday, June 20, 2009 6:47 AM > To: commons-dev@ws.apache.org > Subject: Re: [TCPMON] request / response > > I agree. The feature is interesting in itself, and will also allow us > to improve the architecture of TCPMon. > > Andreas > > On Fri, Jun 19, 2009 at 04:32, Sanjiva Weerawarana<sanj...@opensource.lk> > wrote: >> 2009/6/18 Neuberger, Nicholas (EHQ) <npneuber...@express-scripts.com> >> >>> Thanks a ton for the complete explanation of the core API. This will help >>> a great deal for me to get started. I'll let you know my progress in the >>> next day or two. >>> >>> I may ask your input on if you see this possible record/playback feature as >>> a nice feature to TCPMon. If you find it valuable to contribute to the >>> community let me know. >> >> >> Its a great feature - I'd love to see it contributed! >> >> Sanjiva. >> -- >> Sanjiva Weerawarana, Ph.D. >> Founder, Director & Chief Scientist; Lanka Software Foundation; >> http://www.opensource.lk/ >> Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/ >> Member; Apache Software Foundation; http://www.apache.org/ >> Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/ >> >> Blog: http://sanjiva.weerawarana.org/ >> > > >