Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 66936 invoked from network); 28 Mar 2009 16:18:39 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 28 Mar 2009 16:18:39 -0000 Received: (qmail 96913 invoked by uid 500); 28 Mar 2009 16:18:38 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 96814 invoked by uid 500); 28 Mar 2009 16:18:38 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 96806 invoked by uid 99); 28 Mar 2009 16:18:38 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 28 Mar 2009 16:18:38 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of rahul.soa@googlemail.com designates 209.85.220.168 as permitted sender) Received: from [209.85.220.168] (HELO mail-fx0-f168.google.com) (209.85.220.168) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 28 Mar 2009 16:18:30 +0000 Received: by fxm12 with SMTP id 12so1385556fxm.25 for ; Sat, 28 Mar 2009 09:18:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=JKGXU+tvsHkeSh7U1bYrO/jIQqLxwTLtfr9EZT3CBCk=; b=LhCqVbCUVYW/lZJo2mGIrJPTYnMi2QJ+gMtqZiir8cpcMRhmSMkerfOC3vDZVbF2pY uOYNRCp4q1s4he/Oh3kD93F9U/+pgoFaiztowvdF0oP9uF+6jmHudnxyhyDzfkvL/UgJ 1R6H/hVd2PXDqDXYUDiGiKAQrgf88DdHFVtcE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=IT62szvrKt61CAQUvhzxq22W6B5xC/CQf7bF/v//CaEY8DhjFt7ZSxU97bGy4gUb8r 2ysPvHEpgldAS0LjDZKXeA/j0CK+f9FROF5vylxFaf4iSdIzSY9boOTJfqfu0Zz2u6wW dnw0E6XeyZvag1OOGet4BCvpE4/KcDGfCj9Dg= MIME-Version: 1.0 Received: by 10.204.55.200 with SMTP id v8mr1168419bkg.54.1238257088041; Sat, 28 Mar 2009 09:18:08 -0700 (PDT) In-Reply-To: <5A2110DC1CD00B45A0832E5BF98ECB0602C859A213@ex2> References: <5A2110DC1CD00B45A0832E5BF98ECB0602C859A213@ex2> Date: Sat, 28 Mar 2009 17:18:08 +0100 Message-ID: Subject: Re: Initial Draft for gsoc proxy plugin project From: "rahul.soa" To: Apache Directory Developers List Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org Hello Martin, Thanks for your immediate suggestions. On Thu, Mar 26, 2009 at 1:00 PM, Martin Alderson wrote: > Hi Rahul, > > I know that personally I would like to see a standalone service (non-gui)= to start with that would act as an intermediate LDAP server, passing all r= equests on to a target LDAP server. =A0This could be configured to do vario= us tasks like dump the requests and responses to an LDIF file, load balance= .. etc. Yes, I agree with you and what you suggested above is convincing for me as well. As all the requests/responses pass through the proxy where we can keep them in LDIF file for analysis (I guess). In addition, proxy can think about the load balancing before forwarding the requests to LDAP servers. =A0I don't know if the proxy you describe would work at that level. What I described in the draft was more or less a =93debugger tool=94 as an eclipse plugin (GUI) just to analyze the request/response to and from server. > > Thinking about it further perhaps this would just involve writing a new p= ass-through partition (backend) for ApacheDS (I think this has been talked = about in the past). =A0This partition would send a request on to another ta= rget LDAP server instead of using it against a local database. > Yes. honestly, I need to understand the internals to see how we can implement this and can implement a new intermediary pass through partition for this. I am reading developers documentation. > Once we have that a Studio plug-in could be written to show the output of= the journal or changelog interceptors that I think Emmanuel's been working= on. =A0In addition or instead of that we could write an extra "debug" Apac= heDS interceptor to allow Studio to intercept a request and decide what to = do with it in real time (i.e. cancel or continue with an optional modificat= ion). > Yes right. > This seems to me to be a more flexible and useful direction to take rathe= r than just writing another standalone tool. =A0I think it also helps to ha= ve the project broken into mostly independent chunks like this. > > How does that sound? It sounds appealing to me and giving me both functionality (proxy and debugger) separately. And with this discussion I am familiar with two terms partition and interce= ptor. > > Martin > > Best Regards, Rahul > > > -----Original Message----- > From: rahul.soa [mailto:rahul.soa@googlemail.com] > Sent: Wednesday 25 March 2009 23:26 > To: Apache Directory Developers List > Subject: Initial Draft for gsoc proxy plugin project > > Hello Devs, > > I have written an initial draft for gsoc "LDAP proxy plugin" project. > Can you please suggest about the modifications (what should be added or s= hould be removed from it)? > > > > // quote > > Title/Summary: LDAP Proxy Plug-in > -------------- > > Abstract: > --------- > > To develop an eclipse plug-in for exposing and storing the exchanged mess= ages between the LDAP server and client for debugging/diagnosing purpose. T= his plug-in will be encapsulated in Apache Studio. > > > Detailed Description: > --------------------- > > In order to expose message exchange (request/response - such as bind, sea= rch, add entry, delete entry, modify entry etc.) =A0between the Directory S= erver (LDAP Server) and client (Apache Studio), there is a need of proxy to= ol (initially a debugger tool) which will allow us to analyze the exchanged= decoded messages. Furthermore, this proxy should allow us to store the mes= sages in xml format to generate tests based on those recorded requests/resp= onses messages. > > This proxy will be integrated in the Apache Studio as an eclipse plug-in = and will provide the debugging facility "on demand". This proxy plug-in wil= l be able to work with any kind of LDAP server. The basic idea is to extrac= t the exchanged PDU (Protocol Data Unit) and to present them with their dec= oded values. This will enable us to explore the system to understand how it= works by tracing down the request and response and to see what messages we= send to and receive from the LDAP server. > > The future work could be to extend this debugging/diagnostic tool to a re= al proxy by implementing some additional new features like integrating a LD= AP smart load balancer or switch (smartly distribute the connection and sea= rch requests based on the namingContext across replica and by taking advant= age of already populated cache respectively), failover mechanism (to improv= e the availability) and security features (filtering mechanism and logging = utilities etc). > > > Deliverables: > > 1. To develop proxy plug-in for Apache Directory Studio with the followin= g features: > > =A0 -> To expose the decoded exchanged messages in UI > =A0 -> To store the messages in the xml file > =A0 -> To generate the tests based on the stored messages > > 2. Testing with LDAP Server and Apache Studio 3. Documentation 4. Future = work indication > > > //Unquote > > Any suggestion will be appreciable. > > Many Thanks. > > Best Regards, > Rahul >