Re: [Visionaries] Vision of debugging webservices : Interceptors

[James Michael DuPont]

 --- Norbert Bollow <address@hidden> schrieb: > > > I doubt that the
above suggestion is a good solution.
> 
> James Michael DuPont <address@hidden> relied:
> 
> > It is a very good solution.
> 
> Well, I disagree.  The "interceptor" idea requires adding complexity
> to the VMs in an area where things should be kept as simple as
> possible so that we can optimise for speed.  

No, it does not, I disagree. 

An interceptor can be implemented as a store and forward webservice. A
man in the middle attack if you wish.


>Also, from a security
> perspective, it's bad news if you can't rely on method calls doing
> exactly what the code says they should do.  A complicated security
> model is a bad security model.

With webservices, you can hardly be sure that the person you are
talking to is the person they say they are, unless you use some ssl
like authentication, even then, the interceptor can work, unless the
packages are encrypted. Then it could work on the client side, acting
as an intellgent agent.

> 
> > > I'd rather suggest that there is a "data recording mode"
> > > in which the webservice server logs all data that is necessary
> > > for replaying exactly whatever the webservice program is doing.
> > 
> > That is only one function of many. We need way to filter out single
> > calls and be able to display them graphically.
> 
> If you can replay exactly what the VM in the webservice server did,
> you can do this on a "debugging VM" which does whatever you want.
> 
> My objection is not against providing the functionality that you
> desire; rather I'm saying that the VMs in the webservice server are
> not the right place for providing this functionality.

I agree, it does not require any change in the vm to implement.
Given a set of dgmx and the reflection, I think that an interceptor
framework could be easily implemented, and then executed outside the
vm.

> 
> > > (This includes both data that is received via the network and
> also
> > > copies of all database records that are retrieved by the
> webservice
> > > program.)
> > 
> > That is easy to do, but the data is hard to use. You need ways to
> pick
> > out and process individual records.
> 
> I don't agree with the statement "the data is hard to use".
> 
> Think of this as downloading a copy of the server's database (as it
> was before the webservice ran) from which those records which are
> known to be irrelevant have been removed.
> 
> Then you replay whatever the webservice did in your "debugging VM".
> 
> > I have worked with some xml rpcs stuff before, and they are hard to
> > debug.  We need to have a framework for finding and intercepting
> single
> > packages. We need way to send the packets to a gui on the client.
> 
> Yes, whatever "webservice debugger app" we build around the
> "debugging
> VM" should provide this functionality.

A debugging vm? hmm, i dont know anything about that.
> 
> (Note that until we have a mature webservices debugging system, this
> webservice debugger app will be much easier to debug if it is *not*
> a webservice app.)

I think that this idea of an interceptor is easy to implement and run
as a web service. It can be used to get between the client and the
server and will help people debug.

Of course I am open to other ideas.
Mike

=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________________________________________

Gesendet von Yahoo! Mail - http://mail.yahoo.de
Bis zu 100 MB Speicher bei http://premiummail.yahoo.de