SourceForge.net Logo

Home | SF Project | Download | Forum | Bugs | History | For Coders | HowTo | Commentary | TODO | Support This Project

DonsProxy Code

The GUI

Well, you may have noticed that there isn't one. And probably people are gonna want that. Everything in DonsProxy is built in such a way that creating a GUI view over all the pieces should not be difficult. The delay here is that the GUI framework with which I am currently most familiar (RCP) creates big honkin' executables even for the most minimal GUI. So, I have not decided what way to go. I'm planning to investigate IntelliJ's GUI building stuff and see if that helps any.

GUI UPDATE
Okay, now there's a GUI. That means my friend Mike can use it now. ;) The tool I chose after a little looking around is Jigloo. It saved me a great deal of time in creating a Swing GUI. It does sometimes get confused about its own generated code. There was once or twice where it inserted new lines of code between parts of a long split line of code, resulting in code that had to be tweaked to be compiled. Once I knew what to look for, it was no big deal.

I considered using IntelliJ. They kindly gave me a license to use version 7.0 for this opensource project, but I ended up not using it because it wouldn't create a GUI application framework as a basis. It would be nice if it had a number of options in this regard.

I also considered NetBeans. At the time, the 6.1 beta was available. It has the GUI features I wanted, but I don't care for how it interacts with Subversion, which is what I use as a repository. I much prefer the power Eclipse brings with its Subversive plugin. I delayed using Subversion for some time, waiting for a decent plugin for it. Now that I've been using Subversive, I don't want to give it up. So, I chose to use the Jigloo plugin for Eclipse to generate GUI code.

Once I had some basic stuff working, I decided to refactor the code so that it better followed the MVP Pattern. There is a variety of points of view of what constitutes MVP. I picked one and followed that. You might be using the MVP pattern and doing something quiet different.

You'll see in the code that there are essentially four components for each view. First, the view itself, which is as thin as possible, since it's harder to GUI code. Next, there's an interface that the view will implement. The next component, the Presenter, will always use the interface to communicate with the view. Among other things, this allows use to swap in a mock view for testing, which is what you'll find in the unit tests. Finally, there's a Model. In the case of DonsProxy, the model is the components that make up the existing proxy functionality.

Having refactored to MVP, I find that Jigloo has some trouble presenting the GUI editor. <sigh>

SSLEngine

One of the most difficult parts of writing DonsProxy so far has been the use of SSLEngine. It's hard to find good examples out there that show the use of SSLEngine along with NIO networking code. Hopefully, if you're looking for such an example, you'll find it here. it took a lot of work to get it where it is today, and it's still not perfect. There are a couple sites I know where it doesn't work perfectly, so that'll have to be fixed.

The move to SSLEngine makes the new DonsProxy faster than the original, by far. First, there's no more need for the Shim that the original used to terminate the client-side SSL connection. It was needed because there was no easy way to convert an existing clear-text connection to secure on the fly. Now, with SSLEngine, a connection can start off as clear-text, then switch to SSL as needed.

NIO

The new DonsProxy is almost all NIO-based. The only thing that is not is the communication with the subscribers. This means faster transport than the old DonsProxy, since the NIO system is faster than the old pipe-based system. It means fewer threads, since there's no longer a need to have a thread for each connection. The SocketSelectHandler manages connections, and fewer threads are needed. All the threads created in DonsProxy are prefixed with "DP-" so that they're easy to filter for in JConsole. The new DonsProxy is very minimally intrusive, so the performance hit on your client sessions should minimal.

Channel Decorators

The Channel behavior modifiers are designed following the Decorator pattern. You'll see them in the package com.moneybender.proxy.channels.decorators. The Decorator pattern was part of making new Decorators easy to write. The longest one is about sixty lines of code, inclduing the Apache License header and imports. Plus, since the modifiers are Decorators, you can use them in combinations simply by specifying options on the command line. You can configure DonsProxy to simulate a high-latency connection, or a high-latency connection with low bandwidth, and so forth. I encourage you to write your own and contribute them to the project.

Dependency Injection

Dependency injection is used a great deal, and a byproduct of this is that options that control the behavior of DonsProxy is created at the highest level, and passed to where it's needed. This helps make the Proxy class more easily re-used. If you have an application that needs an embedded proxy, you can instantiate and run the Proxy from your code, and have full control over how it's configured.

Subscribers

There are currently a few basic subscribers - PrintSubscriber, HttpHeadSubscriber, and HttpXmlSubscriber. More could be written. You can write your own, and contribute them to the project.

There could also be other subscriber types, such as ones that target LDAP or other protocols.

Another whole potential category is for Subscribers that collect metrics about a session, such as average response time. I haven't even begun to work on these yet.

Unit Tests

Everything was built generally following TDD principles, although I believe there's some flexibility (gasp!) in that some tests are better written just after implementation rather than just before.