Wednesday, March 12, 2008

Mixed Language Architectures

I've recently switched jobs. I won't get too much into that. I hate interviewing and recruiters even more. More importantly, my new home is full of smart people and a snazzy set of problems to solve.

The CTO at this company was dealt a bad hand. Before either of us were hired, a functional, but severely damaged PHP application was built by contractors for the main web site. Put away your flame throwers; that's a comment about the situation and has zero to do with the language. Because we're not far into the life of this company or the application, there's an opportunity to fix what doesn't work, and the underlying (lack of) architecture doesn't work.

In an effort not to drastically upset time lines and ongoing projects, our CTO had to come up with an approach that would increase capacity, scale, and inject design principals and best practices into what already existed. The current application did not allow for the features the business folks wanted down the road. It needed love and attention.

The plan was to leave PHP for the presentation logic, templating, and rendering, but to gut major pieces of business functionality and implement them as services that exist in a middle tier. These services are written in Java and served up as web services for easy consumption by the PHP front end layer as well as by third party applications for integration. The PHP layer retains some ability to cache results from the service layer, where necessary, but ultimately, the real heavy lifting in business logic takes place within the services, themselves.

The advantages to this approach are:

  • Existing functionality can be tackled and replaced piecemeal; a much less taxing proposal.
  • A very clear separation of responsibility must exist.
  • Rapid prototyping can still occur in PHP which is generally better at fast turn around and testing.
  • The majority of very complex configuration and scaffolding that needs to happen with Java is in the web tier and its associated frameworks. Using Java as a back end service layer lets you get strongly typed, well defined, and proven technology in a place where it's easy to work with. Frameworks and components like Spring, Quartz, Hibernate, JMS, Lucene, and solid transaction management can be exploited without having to incur the long development times that are expected at the web layer.

Surely this isn't magic, nor is it rocket science. I do find it interesting that the downside - a strained architecture - can be turned into something positive by clearly defining lines and using standards as a means of self-integration.

If you work in an environment similar to this, I'm interested in hearing your experiences, both good and bad.

1 comment:

Anonymous said...

hey there, this new architecture was a good choice ?? what other challenges did you have to face in the process, I'm kind of interested in this situation since I'm facing somthing very similar today , ... you can send me your thoughts: dmassonar@gmail.com , ...