Skip to content

HMIS Detailed Design Notes

Jump to bottom
Eric Jahn edited this page Oct 15, 2015 · 4 revisions

You can view the detailed design here. HMIS Detailed Design

Highlights of the design
  • Each micro service is built to serve set of related business operations.
  • Some micro services include a copy of all the modules below , for the purpose of achieving "dual mode" (intra and inter) communication between services.
    • Core service module (a jar file that contains the all business components)
    • Core persistence module (a jar file that contains all the DAO components)
    • Core client module (a jar file that facilitates RESTful communication among micro services)
    • Core model module (a jar file that contains all the java representation of API requests)
      • intra - direct call between business components
      • inter - REST call through client module
If the micro service is totally independent (it has its own service module, own persistence module) as in Notification service, the call will always be using Client module (REST call). However, if the micro services share the same service module (as in enrollment service and authorization service), the call can either be direct - in which case Enrollment Business component just invokes the method on Authorization business component OR the call can be via Client module - Enrollment Business component makes a call to Authorization service RESTfully.
Please refer to the legend in the design diagram
1. HTTP(s) Request posted by clients / trusted apps to HMIS APIs. Both XML/JSON requests are supported
2. Controller - REST Endpoints that are exposed by Micro service. Each Micro service can have one or more controllers, each controller exposing one or more end points. For instance Enrollment Micro service , can have Account Controller - with end points create Account, delete Account , and a Password Reset controller - with end points for forgot password and reset password
3. Unmarshalled Request data objects -Each JSON/ XML request is unmarshalled following Spring MVC configuration. For XML, JAXB framework is used and for JSON , Jackson framework (?) is used.
4. Factory (Service Factory and Persistence Factory) - configured as a Spring bean in the application. A layer of abstraction that facilitates communication between layers and among the components with in the layer.

Service Factory abstracts how the service component is handed over to the caller. Also, service factory abstracts the communication protocol among services. For instance, when "Enrollment Service" need to make a call to "Authorization Service", it would ask factory to give a reference of Authorization service, and factory either can hands over a "Authorization Business Component" (an internal call) or "Authorization Client Component" (REST call), both essentially performing the same operation. What reference needs to be sent back is driven by configuration.

Persistence Factory abstracts how DAO components are handed over to the caller (business layer components).

5. Business component - configured as a spring bean in the application. Each business component extends a Parent Business service that contains Service Factory and Persistence Factory.
6. Client component - configured as a spring bean in the application. Each Micro service has a associated Client component and configuration to be able to call the end points via REST.
7. DAO component - configured as a spring bean in the application. Each DAO component extends a Parent DAO which is has several utility methods to perform various operations on DB, in a consistent way (execute NativeSQL queries, execute Criteria queries, execute Stored Procedures etc.).
8. Hibernate Pojo - A java representation of an entity in the DB.
9. RDBMS (PostgreSQL)
Clone this wiki locally