Vikas Gupta: Software architect

Archive for November, 2009

Organizing Domain Logic

Posted by Vikas Gupta on November 24, 2009


Most enterprise applications use Layering as the primary technique to break the complexity of the software projects. Layering involves breaking down the applications in various layers where each layer lie above the other and provide services to the higher layer. Layering provides following benefits

  • You can understand about a layer without knowing about other layers. For example, if you know how TCP works you can create your own FTP service without actually knowing about the internals of the ethernet.
  • It is easy to substitute the layers with alternative implementation. For example, if DAO layer is designed properly, if should be easy to change the ORM solution from Hibernate to iBatis easily.
  • Layering also helps in standardization and extensibility.

But the downsides of layering applications include cascading changes, performance overhead of converting data from one representation into another and it is not often easy to decide the later of a particular component. Considering the benefits of layering and it’s applicability to almost any sort of computer application, it is used widely and successfully.

Three primary layers of an enterprise application can broadly be categorized into

  1. Presentation Layer: Information display, HTTP requests, command line invocations, batch API, etc.
  2. Domain Layer: Here lies the “Heart of the software”
  3. Datasource Layer: Provides access to external resources like databases, messaging, mail server, etc.

In this blog, we will discuss various patterns of organizing domain logic and specific pros and cons of each. We will also discuss how these approaches compare with each other.
Read the rest of this entry »


Posted in DDD, Design Patterns, EA Patterns | Tagged: , , , , | Leave a Comment »

Captcha usage pattern to prevent bot attack

Posted by Vikas Gupta on November 21, 2009

In one of the projects, we had a requirement of preventing bot attacks without captcha. After hitting the wall on freely available solutions, I thought of staying with captcha, but in a different way.

To devise a solution, I thought that most users would not register account on the same website again at least with in a day, may be a year also. So, using this fact, the proposed solution was to display the captcha only when the user is registering again on the website. In this way, we could avoid irritating the user by showing the captcha, but if needed, we can again activate captcha for second or subsequent captcha.

The proposed solution brought an interesting challenge. How would we determine whether the request is coming from the same machine? HttpServletRequest.getRemoteAddr() gives you the client local IP. But, if you are behind NAT, you might not get different IPs for different machine.

In order to resolve the above mentioned issue, we can use X-FORWARDED-FOR, which is a HTTP header that is inserted by proxies to identify the IP address of the client. It can also be added to requests if application servers are proxied by proxy servers. In this case, the request IP address is always a local address and the client IP address must be extracted from the request. Since proxies can be chained – for example if the client’s request is already made through a proxy – the X-FORWARDED-FOR header can contain more than one IP address, separated by commas. In this case, the first one should be used.

The solution is still not full proof, because headers can be tampered easily. To rescue comes a module of Apache http server, which is mod_remoteip,
Thanks to this, request.getRemoteAddr(), request.getRemoteHost(), request.isSecure(), request.getScheme() and request.getServerPort() will expose the values transmitted by X-Forwarded-For and X-Forwarded-Proto rather than the values of the preceding proxy / load balancer.

The above mentioned Apache module works on an open source project, RemoteIpValve, and, XForwardedFilter. The RemoteIpValve and the XForwardedFilter have been integrated in the Tomcat Project. The RemoteIpValve will be available in the forthcoming Tomcat 6.0.21 version, whereas, XForwardedFilter has been renamed RemoteIpFilter and will be integrated in Tomcat 7.

Thanks to all those who worked on RemoteIpValve and RemoteIpFilter.

Posted in Site Improvement, Usability | Tagged: , , | Leave a Comment »