Smart eDA was a system developed for Enterprise Software Architecture, were I was given a made-up scenario in which land developers could lodge applications to build. This project was completed entirely by myself and I received 90% for the assessment item. The following information below discusses the details of the project.
Description of the System
This system manages new land development applications. It accepts applications, manages the business process (interacts with Cadastre and the City Council) and notifies the applicant if their land development is approved or rejected.
Due to limitations of only having a one-man-band and limited time, some of the extra functionality, such as the DNR, NRW and EPA were stripped from the scope of the project. Given more time I would also have expanded the functionality to generate a quote to send the client and request an accept or reject message from the client.
Logical Layered Architecture Diagram
Interaction Diagram (Level 0) and Choreography
The Client lodges a development application with the Assessment Manager (AM) . The AM retrieves geographical information about the lot from Cadastre. The AM then sends this information to the City Council which processes the information and either approves or rejects the application.
Logical Layered Architecture
At the basic layer the system uses two services. The Cadastre service wraps the geographical information database. The City Council service provides logic for validating development applications.
At the process layer the Assessment Manager utilise both of the basic layer services to provide new functionality needed to carry the business model from start to finish.
At the enterprise layer exists the Application Portal, enabling the clients the ability to submit development applications into the assessment manager’s process.
SOA Design
The design was developed using a top-down approach, looking at what serviced needed to be developed, rather than the bottom-up, since the scenario did not have existing proven business models. This process broke the system down into service packages. These services were designed with the idea of being re-usable with loose coupling. The basic services are more re-useable than the higher level services.
The system allows users to submit a development application via a website. This development application is sent to the assessment manager for retrieves information about the lot being developed from the Cadastre. This new information is sent with the development application to the City Council for validation. The result of the validation process is emailed to the applicant.
In an alternative design, I considered adding an additional data-centric service to store the Development Applications. I could then use this data to extend the functionality of the client’s web application. The reason for not doing this originally was due to the limitations of only having one person.
One assumption was that every application submitted to the City Council could be automated and required no human input. Another assumption was that every applicant had an email address handy for contact purposes.
Aspects of Service Orientation
- 1 Logic-Centric Service – provides reusability for other systems.
- 1 Data-Centric Service (Data Encapsulation) – able to abstract data.
- 1 Process-Centric Service/Asynchronous – Matches business model flow.
- 1 Web Application – Easy access, available on all operating systems.
- Loose-coupling – Elements of the system can change if required, it’s a fluid system made up of services.
- Reusable – Can be used again by other systems
- Abstraction – Data and details are hidden from view.
Physical Deployment Diagram
The system is spread across BPEL, LINUX and WINDOWS servers and a client pc.
Services technologies Table
Process-Oriented Service Internal Behaviour
