Initial design thoughts on the IBP Middleware
- One of the roles of the Middleware is providing data acess to an ICIS database. The Middleware should have a data access API which can be used by developers to interact with the IBDB database. The ICIS DLLs are used as a starting point for the data access API.
- Middleware should have Hibernate POJOs, DAOs, and Data Access Managers.
- It is recommended to use Hibernate as it is the go-to open source ORM framework and has the needed features for the Middleware. It is also recommended to use Hibernate Annotations for mapping tables to POJOs. Annotations are easier to manage than POJOs + mapping file.
- Hibernate provides us the flexibility to have the data-access API work with having MySQL or MS Access as the database.
- From the base data-access API, we can make the Middleware easily expandable to provide other functionalities. But the important thing right now for the project is we have a good data-access layer interfacing with the IBDB database.
- REST Web Services can be written easily on top of the data-access API. We can write utility classes to convert JSON to objects and vice versa.
- No Direct JDBC Connection to the central databases - this is to avoid inherent problem in exposing the central db jdbc port to the public.
- Merging of query results from local and central databases are done in the middleware.
- Once the middleware is stable, we can encourage the developers of the legacy tools to use the middleware instead of connecting directly to the database. Once they used the middleware, all interactions with the resources in the cyberinfrastructure will also be available to them. It also could handle some operations like backup transparently for them.
Middleware Data Access Layers
Middleware on the Proposed IBP Architecture
- Hibernate Annotations
- Jersey (for REST web services implementation)
- Junit (for testing)
- Eclipse 3.6 (IDE)
- SVN repository on cropforge.irri.org