The Housing Office is an organization in Australia supporting low income families to find suitable government subsided housing and managing payment. In order to assess an applicant’s eligibility and determine the rate, the applicant is required to obtain relevant document from Centrelink (www.humanservices.gov.au/individuals/centrelink) Now both the Housing Office
and Centerlink want to reduce the amount of time and money spent on hiring staff handling applicant inquiries and claims. By allowing applicants to view their own information and work out their eligibility and entitlements, and to request changes and make payments online, they will be able to cut back significantly on resource use by staff in local branches, and more importantly help applicants make better informed decisions. The objective is to allow policyholders to make decisions based on the housing support policy information stored in the databases in the Housing Office, as well as applicant information stored in the databases in the Centerlink offices.
Suppose an applicant wants to check her housing subsidy eligibility, the types of housing support one can apply for, the available housing in a desired area as well as rental availability. This request would actually need data from multiple disparate back-end systems from the Housing Office and Centerlink. In this case, there is a need to decompose a request into multiple requests to be sent to different back-end databases applications, then gather the information sent back and assemble this information into the form of a single uniform response (recompose). Therefore you need to:
- design simple schemas for the housing policies and customer databases and explain what kind of integration technique you will be using. Assume the back-end databases are relational.
- design and draw a tiered EAI system that can handle this situation and how users can gain direct access to business applications and data.
- explain how queries will be decomposed and replies recomposed. You can make necessary assumptions.