Today every enterprise application that encompasses fairly large number of users and provides services or solutions to the users are ultra large in nature - as it involves many systems, many services, many users, many organizations and many management domains. We define ultra large systems as a system having span into different ownership domains, sizable numbers of processing unit types, large number of users and which provides services to the users or involved parties where the service is constituted in collaboration of different capabilities coming from different ownership domains.
Now question is what this framework, framework for ultra large systems, would do? Well, there are some common technical "capabilities" required for these systems. Base of every system is the infrastructure of these capabilities. For each solution we build we either create this infrastructure of technical capabilities from ground up, but mostly in an ad-hoc way, or we rely on some proprietary technology stack that controls the entire systems backbone in very closed and intrusive manner. Both are not good in most of the situations. When such infrastructure is built ground up and in ad-hoc basis, we can not envision the technical capabilities distinctly upfront and hence the infrastructure of technical capabilities become unmanageable making the systems unstable in turn. The solution team also spends a lot of time on technology decisions and making all those capabilities working together. Our intention is to take the pain out from solution team and provide them a solid base on which they can start building business focused offerings straight-on. While the focus of a solution team should be on building business focused offerings, they too have constraint of using base systems, or runtime systems, that the organization, for which the system is being built, invested already. Challenge is in two folds here, protecting the investment on base runtime systems and focusing on business focused offerings. Answer to these problem is to build a base that is more or less runtime system independent, and combines the common technical capabilities so that the capabilities can collaboratively work together as and when needed. The target system may also use these capabilities in a-la-carte fashion. But the chosen capabilities are never discrete but always in a harness that makes them integrated and collaborative. We are calling this answer, the base we are discussing about, the framework. Let see the precise definition of the framework.
The Framework: An extensible harness of common technical capabilities found in modern large systems with the following special mentions and constraints.
- No runtime binding - e.g. it should run on any JEE compliant application server irrespective of its vendor.
- A-la-carte model of technical capabilities. Use what you want and discount others.
- Standard based technical capability binding, making those technical capabilities interchangeable
- Pluggable functional capabilities
Let me now propose what are technologies are going to be used in this framework and then I will explain why my choice is so.
The technologies.
- OSGi - Blueprint Services
- EIP - Spring Integration and Apache Camel
- Spring Batch
- Spring Security
- Java, Scala and Groovy
I will hold back for some times the explanation of the technology choices. Lets look at now how the common technical capabilities constitutes the harness, the infrastructure of set of common technical capabilities, the framework. Lets see the picture.
=================Picture: The Framework===================