While writing Netty socket listeners for Flipkart Phantom project, we realized the need for a Unix Domain Sockets based transport. We wrote one and published more details here : https://github.com/Flipkart/phantom/wiki/Unix-domain-socket-transport-for-netty

It is a UDS transport implementation for Netty and is compliant with Netty version 3.3.x. This transport is a port of the Netty OIO transport implementation and uses UDS specific API. It may be used independently of Phantom and has dependencies only on Netty and junixsocket libraries.

Advertisements

2012 in review

December 31, 2012

The WordPress.com stats helper monkeys prepared a 2012 annual report for this blog.

Here’s an excerpt:

600 people reached the top of Mt. Everest in 2012. This blog got about 5,300 views in 2012. If every person who reached the top of Mt. Everest viewed this blog, it would have taken 9 years to get that many views.

Click here to see the complete report.

Code commits on Trooper (https://github.com/regunathb/Trooper/) have kept me busy the last few weeks. Trooper is an umbrella project for a number of things.

Trooper now has a RabbitMQ connector for Mule.

I wrote this article for CIOUpdate.com (http://www.cioupdate.com) a while back on SOA and its relation to the Cloud. The article tries to introduce the two concepts and compares them using different view perspectives.

You can find the original article here : http://www.cioupdate.com/reports/article.php/3853076/How-SOA-and-the-Cloud-Relate.htm

I would not be exaggerating if I said its a war out there between the supporters of stateful and stateless frameworks and solutions in Java. Add to this melee the number of frameworks that are built on either of these two premise. An application developer is therefore spoilt for choices and often confused. The easiest way out is to align with one of the camps and trust their solutions.  

Proponents of the various frameworks vouch for their solutions – a natural thing, but unfortunately it is biased due to their own business interests. I’ll take two solutions for illustration purposes – Spring and JBoss Seam. I am a big fan of Spring and am interested enough to dabble in Seam. FYI, one of my projects uses Seam extensively and I personally have designed complex systems on the JBoss platform in the past. So, there is no bias there. I’ll use an example to illustrate the comment on bias – I find the Spring Acegi framework to be a great solution for application security. I suspect the people behind Seam might think likewise but will never integrate the two. I read something about they having evaluated Acegi and decided to write their own. JBoss Seam security looks good but one is forced to write stuff for say RDBMS or LDAP based authentication while it is readily available in Spring Acegi. Other useful features are Transaction(compensation based) support for LDAP operations and the Spring AOP implementation. 

I do believe the need for evolution. Hibernate came along and changed the way we wrote JDBC access. But, I would hate to see somebody rubbish stuff that others have done before. For e.g. I dont subscribe to Gavin King’s (creator of Hibernate and Seam) thought that applications are by default stateful. Maintaining state comes with a price – we have all not forgotten the problems we had with earlier versions of Stateful EJBs, Entity beans and Http session replication. I dont think Seam has cracked this entirely yet despite claims that the JBoss clustering on JGroups does fine grained replication of changes. My team members complain of huge files on the JBoss server environment that is presumably used to passivate state. I would not convince myself to write all my applications as stateful ones even if the associated framework claims greater productivity (this is debatable and the answers are unique to situations).

The best solution for an application developer like me would be to use the best of both worlds. There definitely is a case for using both Spring and Seam in your application stack. Lets look at an architectural paradigm that has generated lot of interest these days – SOA. Web services over Http and JMS are common technologies used to implement services in a SOA. Both these technologies advocate a request-response model and are mostly stateless. Spring and its integration with a framework like Mule make a compelling choice to implement the services layer. However you need more than just services to build an end application – you need a presentation layer, a mechanism to maintain conversational state (between user and application) and ability to perform data access where the nature of the use case does not require you to write it as a service. Enter Seam and other productivity enhancing web frameworks like Grails. Presentation frameworks and component libraries (Facelets, JSF component libraries, jQuery) e.t.c integrate nicely and is rarely an issue. 

Such an approach allows one to leverage the scalability benefits of stateless frameworks (for the services layer) and the productivity benefits of the stateful frameworks. A combined reference architecture that demonstrates building stateful applications on a stateless service layer in the true spirit of SOA is useful. The MindTree Momentum platform achieve this – leverage the best of open source stateful and stateless frameworks.

One of the first few questions an architect would pose when designing an application would be: what are the availability needs of the system?

The answer would not only influence the overall architecture but would trickle all the way down to application design, choice of technologies and of course the physical deployment.

Clustering solutions help to address availability needs by aiding deployment of redundant servers that fail-over in real-time.

There is a cost to redundancy though, and often a high one. While at it, be prepared to spend a few hundred thousand dollars on software licenses if you use commercial J2EE app servers and RDBMS that are priced on per CPU basis. Now, as an architect you need to fight another battle – that of justifying deployment and ownership costs.

Sharing infrastructure between applications helps to ease this burden. Is it not nice if three applications can be “co-located/co-deployed” on the same set of boxes and thereby only incur one-third the cost that would have been the case otherwise?

The rest of this post is about recommendations, challenges and potential pitfalls in creating and using a shared infrastructure.

I have chosen the term shared “infrastructure” instead of shared hardware intentionally. It is because co-deploying applications often needs more than just computing boxes. It requires a holistic view of your applications – from development to final deployment.

Recommendations:

  • Firstly have a broad technology blueprint that applies to all your applications. Decisions here include technology stack – Operating System, RDBMS vendor & version, Application server, tiering of applications, hardware configuration – scale up vs. scale out.
  • Consider a common boiler-plate structure for your code repository. The structure is prescriptive on what goes where(Html,images, JSP, EJB, DAO, SQL Scripts, deployment descriptors) but does not dictate package hierarchy say.
  • Create a unified build and release process. This includes build scripts, final packaged binaries(exe, rpm, so files) and the supporting artifacts that enable the release & continuous integration.
  • Identify and build/buy/wrap common services & components across the applications. They may be across the various tiers – data access, security, scheduling, pagination, internationalization.
  • Establish clear guidelines on resource usage and communicate to all project teams. Indicative ones can be on : connection usage & release, JVM heap – stateful vs. stateless behavior, synchronous vs. asynchronous modes, Transaction demarcation in applications and with common components/services.
  • Design the tiers and common components/services in such a way that they may be remotely deployed. Can help to isolate heavy use components and move them to dedicated servers – batch jobs run by the scheduling component for e.g

Challenges:

The challenges arise largely around the recommendations themselves.

  • Governance – ensuring the guidelines are adhered to. Peer reviews work great here.
  • Uptime of the infrastructure – a downtime can affect not just one but all of the applications.
  • Monitoring and administration process, tools – Monitor the infrastructure for signs of distress – over use of CPU, memory, resource pools.
  • Personnel skills and training – The overall infrastructure in a shared setup is mostly more sophisticated than that of one dedicated to a single application, at least initially when setup. Specialized skills around clustering solutions – OS onwards, shared data storage(NAS, SAN), physical security would require good in-house skills or the services of consultants.
  • Smooth roll-out and compartmentalized releases that have minimum downtime of the shared infrastructure. For e.g, the ability to turn off individual silos, deploy the release and bring them back on.

Potential Pitfalls:

  • Rogue applications : All applications that reside and benefit from the shared MUST adhere to the established guidelines for development. Non compliance affects all.
  • Overloading : Every infrastructure has its limits. The application portfolio cannot simply grow. Application sizing must be done and the infrastructure augmented if required.
  • Trouble shooting : Application logs, databases, concurrency, tool mix e.t.c tends to grow with co-deployment. Issues arise out of sheer size. This can be suitably mitigated by : log analysis tools, partitioning, tool standardization and avoiding shared data between threads.

Of course it may appear less painful to have dedicated infrastructure. It is not true because you end up addressing most of the above anyway, though maybe on a smaller scale 🙂

The trail is born

January 30, 2007

Well I had to start with something to get my blog up….