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).
**Added record / playback icon on the screen to turn on feature.
*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.   

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).

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.   

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/
>


Reply via email to