Should I use a single platform for common services or modularize them?

Question

I am designing a suite of web applications that have the same base functionality. That is, they all will know how to create and operate on widgets. The differences will be in their target audience and how a user will interact with a widget. Essentially, if these applications were developed independently, there would be a lot of duplicated effort.

To simplify this I have thought of two solutions. I would like all of your feedback on the pros and cons for each solution, and which you would prefer.

1. "Platform" -- The idea is that there is an independent service layer, a la web services. It wouldn't be a web service, but simply a back-end for all the applications. The platform would talk to the applications via messaging or object serialization.

   I would want to write the platform with Java, but the intention would be that the applications could be written with any web framework such as Rails, Django, Flex, or just something in Java.

   The platform would abstract the database, so all interaction with the back-end would be done via the platform. One potential problem with this is that updating the platform will entail taking down all the applications. But at least all the applications will be consistent in regards with the back-end.

   I like how this is cut horizontally, and that the application really only has to focus on the front-end, rather then worrying about how to organize the back-end.

2. "Modules" -- The idea is that I just write everything with Java and develop modules which would live in their own jars. Each module would represent a Guice module and each application would just include the modules they want, and create their own Injectors.

   This approach would make each application completely independent from each other, aside of sharing a common database. So, theoretically, it would be much easier to deploy an application in a different environment with out worrying about the platform. I would be stuck in one language environment, Java. Although, JRuby and Jython would be available. So maybe that isn't much of a concern.

   Also, I foresee it being easier to customize an application with out effecting the platform. The one con is that if I update a module, I would want to redeploy each application using that module. This would be easy with continuous integration, though.

Thank you for your time.

---

In regards to Gary's answer, I've decided to take a hybrid approach.

I'm going to develop a platform, which will be the access point for the web applications to data and services. I will then modularize the platform, but all the modules will remain under a single repository with a parent POM. While I could just keep them all in a single JAR, I would like the classpath separation for development purposes, to make me/others think before requiring a module to depend on another.

Answer 1

Platform

I like the idea of the platform approach, but there are a couple of points you mention that give me cause for concern.

Why not make the back-end entirely stateless and RESTful? You know, have a bunch of web services that provide the necessary JSON or XML to drive the front end clients. These clients could be written in any language you like, so long as they can consume/produce the necessary intermediate representation. Implementing RESTful web services these days is trivial with JAX-RS implementations like RESTEasy just a Maven dependency away.

Having the platform abstract the database away is good practice simply because you want your client and your services to be as independent of each other as possible.

You mention that updates to the platform would mean taking down the whole system. Why? If you're serious about it, you'll have your live and fail-over clusters running in parallel. You upgrade your fail-over cluster and run your verification test suite on it to ensure it's up to scratch. Then you switch your load balancer to use the fail-over cluster instead of the live one (the live becoming fail-over). If your platform is truly stateless your clients operations will be uninterrupted since the DNS of your services remains the same.

I'd caution against using Java object serialization (e.g. RMI) just because of the binary API restrictions you may encounter if you decide to update the objects.

Modules

Sharing common code between modules is trivial with a build system like Maven (or Ivy if you can't leave Ant). Having a common back-end language will also reduce the learning curve for new developers. Also you'd doubtless have a large collection of template base classes to support common functions in the different back-end layers (DAOs, DTOs, BOs etc). (This is also true of the platform approach).

Given that each module is separate and independent of each other you may find that if developers don't communicate effectively, code duplication will likely occur within modules. Also, bugs will be fixed in one module, but missed in another. This is especially true if you're creating multiple variations of a module to look after different clients.

Obviously, dependency injection and good design will go a long way to mitigate this, but you may find the solution more complex than if you go the platform route.