Category Archives: Software Architecture

Getting SOA Right – Thinking Beyond ‘The Right Angles’

Cable Mess

Photo by dM.nyc

There was a time when Service Oriented Architecture was a buzzword. That time is now long gone, and SOA has become one of the essentials of enterprise software architecture. Due to the adaptation of SOA by many leading enterprises (such as Facebook, Amazon) and software systems, there is a trend of everyone wanting to be ‘service oriented’. Engineers talk about building web services, JSON services, RESTful APIs, but a significant number of them have been mislead by various misnomers (no pun intended) regarding SOA.

SOA is based on a concept which is inline with the basics of object orientation, and component based software engineering. What it advocates is to build services that focuses on a specific functionality (thus coherent), and to have a well defined API, backed by an encapsulated implementation. There’s more to it (and above sentence does no justice to SOA, I agree), but that’s the basic idea behind SOA. This might be one reason why Gregor Hohpe calls it ‘Same Old Architecture’ [1]. However, this simplicity is often mistaken, and solutions which are not at all SOA are labelled as SOA today.

One of the nicest descriptions of SOA is the one circulated by Jeff Bezos, CEO of Amazon within his organization. Steve Yegge, who was an ex-amazonian and currently works for Google, wrote and amazing article about how well Amazon developed their platform in a SOA way, and how Google should improve on the platforming and SOA front. Yes, you heard that right. Even Google, the tech-giant is yet to learn the right use of SOA. Steve’s post was supposed to be published in an internal blog of Google, but he mistakenly published it in his public blog (which was withdrawn later). If you are interested, you can still read it at http://news.ycombinator.com/item?id=3101876 (which is a very insightful article).

Coming back to the topic, Jeff Bezos circulated the following at Amazon around 2002, when he decided that Amazon should build a platform. He never said it’s SOA, and he didn’t care about technology. Yet it worked, and transformed Amazon to the massive services platform it is today. Bezos said,

  1. All teams will henceforth expose their data and functionality through service interfaces.
  2. Teams must communicate with each other through these interfaces.
  3. There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
  4. It doesn’t matter what technology they use. HTTP, Corba, Pub-Sub, custom protocols — doesn’t matter. Bezos doesn’t care.
  5. All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
  6. Anyone who doesn’t do this will be fired.

Above six points (or the first five) lays down the foundation for building a service oriented architecture. All communication happens through well-defined service interfaces, no exceptions. Each service is self-contained. Services are re-usable and externalizable. Another key point that should be highlighted is that ‘technology is not important’ for SOA. SOA is an architecture which can be applied for any technology.
Continue reading

A Thought about Java EE Applications

Most of the software houses in my country seem to have embraced the concept of EJB3 hardly, for new projects. They develop new projects (and ports) using EJB3 as the middle tier technology, for various reasons.  Majority of the companies also employ Spring Framework as a part of their solutions as well. With the additions of JEE support (XML Bean Definitions) in Spring, the two technologies complements each other, and can be used to promote good programming practices like coding to interfaces, through Spring’s Inversion of Control support. Also, companies are embracing JPA, due to the simple nature of the technology, through “convention over configuration”. Finally, because of the use of EJBs, the solution is deployed into a full blown application server such as JBoss, Websphere, WebLogic etc. 

However, most of these applications are just web applications. And the architecture of these solutions are not distributed. All components of the solution live in a single VM. This raises the question, why do we need EJB? Well, in my perspective, I think it’s basically due to the fact that most developers think EJB is a core part of J2EE stack, and it should be there no matter what. If the final solution is deployed into a clustered environment, if the app is going to be executed in a distributed manner on several VMs, then yes, EJB is the way to go; but why for a webapp which runs in a single VM? Majority of the projects out there are not multi-modular distributed applications. They are single module web applications. IMO, using a technology like EJB is overkill for this type of projects. 

Continue reading