||1Z0-865: Java Enterprise Architect Certified Master Assignment
||Assignment Document :
1. Design Goal
The TeamDoctor system will be used by doctors/consultants. My main emphasis on this application is to meet the Non-Functional Requirements first then Functional Requirements by providing JEE based solution,
as "Risks are usually associated with the service-level requirements and can occasionally be associated with a business requirement". Early considerations for NFR will help to schedule the project and cost.
I also tried to use the already tested and proven desings using various JEE design patterns ( please refer to diagrams).
I tried to fulfil the following service level requirements:
- The Single Sign-On (SSO) approach is used to secure the rich infrastructure of network and system services.
- Firewalls and authentication mechanisms are also used to support internet security.
- Privacy, Integrity, Authenticity and Availability are considered.
- Risks based threats like Accidental, intentional, passive and active threats are considered in winder range.
- Unique identification and verification of TeamDoctor system users via certification servers and global authentication services ( Single Sign-On services).
- Front end access to each UI component for example JSP is controlled by taglib.
- Using of HTTPS connection to access the contents of TeamDoctor application.
- There will be two webserver cluster on each server in order to improve performance and balance load.
- Various logging point provided to monitor the performance.
- Using Value/transfer objects for communication across layers.
- Sending Asynchronous calls for Emails.
- Added database performance enhancement such as indices and caching to speed up lookups and update processing.
- Transaction performance could be increased by using “vertical scalability”. For this we can add capacity (memory and CPUs) to the existing servers.
- We can update the hardware platform. Our use of JEE servers is a solution that offers
platform independence and enables rapid deployment and easier integration of new technology.
- We add session management to improve communication among clients and servers through session pooling.
- Our use of clustering provides transparent access to multiple servers to increase throughput during peak loads.
The load balancing provided by clustering is necessary to support the unpredictable and uncontrollable demands of TeamDoctor system
- To improve the communication between the application component server and various data sources through the use of connection pooling management.
- Tried to keep very loose coupling between the components and tiers (only one bean method called between web tier and EJB tier),
Presentation and business logic are kept separate.
- The TeamDoctor system is designed with separation of concern: presentation tier, business tier, persistence tier and integration tier.
Each tier is loosely coupled with each other with good usage of design patters, interfaces and best practices of object-oriented design
such as encapsulation and inheritance.
- Due to modularity of the system it's Extensibility and Maintainability and Horizontal scalability is achieved.
But this can be revisited in order to achieve the Performance.
back to the top
- We have made use of object-oriented designs to be more flexible and adaptable than the older procedural designs,
thus reducing maintenance costs
- To make use of OO principles to reduce the maintenance costs we use object-oriented modelled business
entities and processes to address the “separation of concerns”.
- Due to the layered (loosely coupled) architecture, each layer addresses a particular need so that any enhancement
to the TeamDoctor application can be made easily. Also each layer is loosely coupled with best design practices,
which makes understand, analysing and debugging the TeamDoctor functionalities as well as making changes easier.
back to the top
- The doctor can act as an expert adviser(consultant) to provide advice on his specialisation.
- The X-rays, MRI scans, patient history, previous feedback and prescriptions are recorded through external system, TeamDoctor application will use these in read only mode.
- The patient history and prescription data will be available in textual form and rich contents will be available in binary form.
- Doctors requests and comments will be logged into TeamDoctor system to track the comments for each patient.
3. Brief Overview of the System
[Please refer diagrams for Pattern implementation]
The TeamDoctor system was designed as Java Enterprise application which will be used by end users, doctors/consultants through
Web based Java Enterprise technology was used to design the TeamDoctor system.
back to the top
- System was designed to be highly available across North America, Europe, Asia with data centres located on those three continents.
- Provided design allows it to work on 'commodity' computers, not needing any expensive infrastructure,
to meet one of the business goals to reduce cost of specialized resources.
- Data used in TeamDoctor system is stored in synchronous multi-master relational database cluster.
- Any rich content files attached to request going through the system will be stored in RDBS in form of metadata and the file content
will be replicated across data centres in secure, durable way using asynchronous messages with JMS technology and stored on local hard drives.
- All pages are available only for logged in users.
- Authorization and authentication will be provided by the container accompanied with JDBC realm.
back to the top
8. Risks and Mitigations
What if more hospitals will join the TeamDoctor system?.
The architecture allows both vertical and horizontal scaling. In the case of slowness in clustered database by virtue of increase active users, database caching can be introduced.
Data centre can incur technical problems.
Described above architecture will allow system to fallback to remaining data centres without serious interruption.
One inconvenience will be that users that were using data centre that failed will have to login again to TeamDoctor system.
- What if file in the external system was updated after the request was created? The main core NFR was to make system highly available, data is stored in clustered RDBMS
but files are replicated using asynchronous messages. For example; request itself might be available to review in a given data centre but files might not yet be replicated,
which will cause TeamDoctor system to make a request to external system to download again attached file. Downloaded file might be different then file attached when creating request.
Fallback to try to download file from external system in case of missing file locally was included in sequence diagrams
but specific handling for this issue was not as this is exceptional case. When trying to view not in sync file update request state to cancelled
and send cancelation message to user that created the request.
New file attached to request (X-ray or MRI scan), that does not exist yet in external system, is not available/was not replicated yet in other data centre when reviewing request.
User should be presented with loading panel and explicit message. Cometd technology could be used to check file availability and in case of successful replication file could be displayed to end user.
Since the application contains very sensitive patient data, application security is very important
TeamDoctor application should have secured fine-grained authentication and role-based authorization mechanism. The application should be protect from internet attacks.