Technology Plan 2010
Backgroundsectnum::
In March, 2010, the Mifos development team participated in a BootCamp led by Jim McCarthy. One of the goals of the BootCamp was to create a 5-year technology plan for Mifos. The architectural plan described here is a 50,000 foot view of an architecture that could satisfy many desired attributes of Mifos.
Major features
Open, extensible architecture
Mifos will continue to be offered as free-libre, open-source software (FLOSS). Mifos will apply the FLOSS philosophy at the architectural level, for example by allowing an MFI to add new services that can be integrated with Mifos services.
Service-oriented
Mifos offers a suite of business services that are accessed via a well-defined interface from client technologies such as a web page or an external application. It will be straightforward to program a client to access the services and not require any heavyweight technology. Moreover, services can access other services to coordinate some function requiring multiple services. For example, creating a loan requires collaborating with client services (the loan owner) organizational services (the loan officer).
The 50,000-foot view
The following diagram illustrates, at a very high level, the technical direction proposed for Mifos. In fact, several initiatives have begun to move in this direction, for example, to refactor the domain layer into separate logical services as illustrated here, and to separate the presentation layer from the services layer using a bus based on RESTful interface.
Architectural Layers and Components
Presentation
The top layer interfaces directly with clients, either via web pages in a browser, or using external applications that are either headless (run unattended) or themselves have web or application interfaces. For example, a periodically scheduled batch job pulls reports from Mifos's reporting service.
Client-side applications or interfaces communicate with domain services through the bus.
Current Mifos Implementation
Mifos provides JSP pages for view in a browser. Pages minimally use CSS, and enforce consistent look and feel with manual HTML coding.
Planned Implementation
Mifos will provide Grails Server Pages (GSP), and use CSS to enforce consistent look and feel. There are no immediate plans to provide external applications.
The Bus
The concept of a software "bus" has been around for nearly 2 decades. Quoting from a 16-year-old article: "An abstract decoupling agent, called the software bus, is introduced between the system components. Heterogeneity in language and architecture is accommodated since program units are prepared to interface directly to the bus and not to other program units."
More recently the software industry has evolved and specialized a bus abstraction as an enterprise service bus: "a software architecture construct which provides fundamental services for complex architectures via an event-driven and standards-based messaging-engine (the bus)."
In Mifos's context, the bus enables web pages and external applications to communicate with domain services in a uniform, technology-independent way. It also decouples services from each other as long as those services communicate with each other through the bus.
Current Implementation
Mifos does not implement a bus architecture. JSP pages communicate directly with domain components using Java method calls within a single JVM.
Planned Implementation
Mifos will not implement an enterprise service bus as defined above, but will migrate communication to a lightweight http-based communication using REST. Mifos will supply REST-based service facades front-ending each domain service. Thus any external client or web page that can request services via HTTP can access Mifos services.
By convention, services will communicate with each other using REST.
Service Layer
Functions of the application are partitioned into logical business services accessed via a service API. Although at the bottom-most level the API is technology dependent (in Mifos's case, interfaces are implemented as Java object methods), services can be decorated with facades that adapt virtually any communication protocol to the service's internal API. When a higher-level function requires the collaboration of more than one component, these components will communicate with each other using API's provided by the facade.
When a bus is implemented using a particular protocol, services with communicate via the bus.
Current Implementation
Some of Mifos's business functions are fronted by service classes. However, most communication occurs as direct, complexly constructed method calls between domain objects. Although the characterization is not entirely fair, developers immersed in the guts of Mifos's code envision a tightly coupled "ball of mud".
Planned Implementation
Domain logic will be refactored as a collection of separate services as shown in the figure above. Services will be decorated with a facade that implements a RESTful interface. Services will communicate with other services via this RESTful interface.
Data Layer
Current Implementation
Planned Implementation
Will the data layer also implement a RESTful interface? For example, so a reporting service, or external reporting application, can access the database directly?
How this plan supports desired features
Open
Mifos will add no proprietary software or communication protocols.
Extensible
Users of Mifos are free to plug in new services to "the bus". If these services are wrapped in RESTful facades, they can be accessed in a manner consistent with other services.
For example, if a client wished to add insurance services for their clients, the client could build or buy an insurance package, wrap it in a RESTful facade, add or modify web pages to access the service using REST. The client is free to either store insurance data in a separate database or integrate with existing Mifos databases (although doing so will add possibly undesirable dependencies on existing Mifos data schema). Existing client demographic data can be accessed using Mifos's client service via the REST interface.