International Journal of Advanced Computer Science, Vol. 2, No. 2, pp. 56-64, Feb. 2012.

Building an Intelligent Health System Using an Evolutionary Architectural Model of Middleware

Christopher Chiu, Avtar Singh Kohli & Zenon Chaczko
Abstract Health Information Systems in industry are undergoing a paradigm shift in uniformity. The needs for health professionals to utilize universal patient records require various legacy health applications to be integrated in a logical, orderly process. The Smart Hospital Management System is an infrastructure solution that seeks to unify health patient management subsystems together while retaining the existing performance and reliability requirements of the individual subsystems. The infrastructure oriented application of The Open Group Architecture Framework, presented in this research work, ensures that integrity and an enterprise-level perspective are considered throughout the development process. This includes a consideration of the problem space and scenarios, constraints, requirements, risks, enablers and inhibitors of the legacy application architectures. The proposed integration solution with TOGAF components, addresses the need for health institutions to unify their legacy operations in a consistent and best practice compliant manner to ensure universal patient records are thorough, comprehensive and provide robust security mechanisms to make certain that privacy regulation compliance and protection against identity theft are vital.

Manuscript
Received: 25,Jun., 2011 Revised: 7,Sep., 2011 Accepted: 7,Jan., 2011 Published: 15,Mar.,2012

Keywords
Smart Hospital System, Open Group Architecture Framework (TOGAF), Integration Frameworks, Service Oriented Architecture (SOA)

of the health industry stakeholders. The diagram below depicts the TOGAF methodology which has been employed to ensure the integration of legacy health applications is executed in a coordinated manner, with minimal disruption to current health operations. An assessment of the integration build is detailed in Section 9 of this paper, using the Architectural Trade-off Analysis Method (ATAM) [2]. Iteration through the eight phases of the TOGAF core model are accomplished to ensure contextual information is obtained to aid in requirements management: A. Architecture Vision (Section 2); B. Business Architecture (Section 3); C. Information Systems Architecture (Section 4); D. Technology Architecture (Section 5); E. Opportunities and Solutions (Section 6); F. Migration Planning (Section 7); G. Implementation Governance (Section 8); and H. Architecture Change Management (Section 9).

1. Introduction
The consolidation of health information records has primarily been driven by the need of industry compliance to reduce data duplication and prevent inconsistency in patient information. A further motivation is also to provide convenience to health professionals and patients to easily access records in simplified manner. The Smart Hospital System (SHS) is a unified solution aimed at presenting an architectural integration framework using The Open Group Architecture Framework (TOGAF) Architecture Development Method Version 9.0 [1]. The main concern of TOGAF is the Architecture Development Method (ADM), which seeks to develop enterprise architecture descriptions [1] that meet the needs
Christopher Chiu, Avtar Singh Kohli and Zenon Chaczko are with the University of Technology, Sydney, Faculty of Engineering & IT (christopher-chiu@uts.edu.au, avtar-s.kohli@alumni.uts.edu.au, zenon-chackzo@uts.edu.au.)

Fig. 1. Iteration Cycles of the TOGAF Model [1]

Christopher Chiu et al.: Building an Intelligent Health System Using an Evolutionary Architectural Model of Middleware.

57

2. Architecture Vision
The architectural vision for the SHS Integration Project consist of the core business mandates to re-engineer a new IT Integration Platform and Framework that unifies legacy applications with support for new services to the meet future needs of the health institution. TOGAFs ADM is comprehensive and flexible in achieving required perspectives like technology, data, business and application level requirements. Unlike other enterprise scale frameworks and practices such as Zachman [3], Federal Enterprise Architecture (FEA) [4] or Gartner [5], they were found to be less suitable as they require more documentation and far greater reliance on domain experts.

Fig. 2. Zachman Matrix Grid [3]

Fig. 3. FEA Model [4]

Zachman Framework defined architecture can only be considered complete when all the cells of the grid are complete with valid information sets as shown above, this may not be feasible in the context of integration projects where specific points at initial stages are unclear. As for FEA depicted below, the complexity and demands for all taxonomies [4] to be generated as a resultant set of
International Journal Publishers Group (IJPG)

elaborate, cross-agency reference models, consist of the five core reference models (RMs): Business, Component, Technical, Data and Performance [4]. The FEA process is aimed at the development of segmented architectures which is a four-step process of architectural analysis, design, investment strategy and project management. In comparison to FEA, TOGAFs ADM has nine iterative steps which can be tailored to project needs [6]. The nature of the problem statement, in terms of integration demands that enterprise scale integration to be vendor neutral and be process complete [6], is that TOGAF is ranked highest by formalizing the requirements of the SHS stakeholders. Furthermore, prioritizing the business domain needs will improve the efficiency of existing patient healthcare practices, while catering for future demands on the SHS system are considered from a holistic perspective [7]. They have been identified in terms of responsiveness, flexibility, reliability, robustness and cost-effectiveness: Responsive to Future Needs: Respond to future business demands of the health institution; including scalability for new applications, devices and users; Deployable to New Locations: Be deployed quickly at any new location within a restricted timeframe, and with minimal configuration and no new development or customization required; Reliable for High Workloads: Reliably service a current workload for a centralized hospital serving a population of up to 1 million; that scales for a minimum 10,000 user accounts and 200 concurrent users to potential new workloads projected of up to 100,000 user accounts and up to 5,000 concurrent users; Available in Uptime: Provide 99.999% uptime availability, equating to a total of 5 minutes of downtime in a year; Efficient to Service Multiple Locations: Be efficient enough to be able to simultaneously service several hospitals and mobile units in geographically diverse areas of the country; Cost Effective: Have no additional operational costs compared to the current infrastructure; Unified in Accessibility: Have a single unified UI from all applications; Compatible with Legacy Applications: Integrate the current legacy applications, including the Patient Management System (PIMS), Accounting and Payroll Package (APP) and Enterprise Relationship Package (ERP) applications with minimal effort; and Flexible in Application Providers: Provide flexibility in choice of application providers, to minimize vendor lock-in.

58

International Journal of Advanced Computer Science, Vol. 2, No. 2, Pp. 56-64, Feb. 2012.

3. Business Architecture Model

The Business Architecture Model identifies the main users of the SHS system, to create a boundary context model from a high-level perspective. This ensures the relevant stakeholders are identified in the finalized architecture model [8]-[9]. The following diagram depicts the main actors of the SHS problem space, and their interaction with the main subsystems and legacy application services:

Fig. 5. Components of the APP Legacy Application

A.) Patient Information Management System

The PIMS platform is a three-tiered architecture that consists of an interface layer front-end, a middleware layer for business service hosting and management, and a data-store layer containing patient information, staff payroll data and equipment data store. A web service request handler is an enterprise service bus to manage the suite of business services of patient health records, diagnoses, staff to patient associations and medical infrastructure record management.

Fig. 4. The Boundary Context Model of the SHS

1.) Administrator
A user with administrator privileges to the SHS; access is provided to all applications and components within the SHS. The administrator has access to complete administration and maintenance functionalities.

2.) Standard User

A user with no administrator privileges to the SHS; restricted access is provided through the Unified Interface only. No SHS functionalities are available to this user. Users have access based on their user profile to specific functionalities within the existing legacy PIMS, APP and ERP systems.

3.) External System

An external system that can access specified services through the Application Integration Framework. The following figures include the legacy architectural representations of PIMS and APP platforms:

A.) Accounting and Payroll Package System

The accounting and payroll system is responsible for the financial accountability of the health institution. Financial records of patients, including private and public insurance details, along with drug inventory management and patient billing information is stored in a common data store layer. The two core interfaces of the system include an Accounting System Interface for third-party financial packages and an External Reporting Interface for governance and legal compliance purposes to the relevant health department authorities.

Fig. 6. Components of the PIMS Legacy Application

International Journal Publishers Group (IJPG)

Christopher Chiu et al.: Building an Intelligent Health System Using an Evolutionary Architectural Model of Middleware.

59

4. Information System Architecture

The SHS Database is an aggregation of the Database Components of all SHS Applications deployed in the system. The deployed SHS Application Components are hosted on SHS Application Servers which are bound to each SHS Software Agent. Each agent is aware of the SHS Application Components that are available on the server. This is achieved through a synchronous association between the business services and business orchestration data store. The purpose of this association is to harmonies PIMS patient records with the APP medical department billing records against each patient. The SHS Interface Server hosts the SHS Web Portal and the SHS Web Service. The web services of all the deployed SHS Applications are aggregated according to complimentary functionality, and both these aggregations are hosted on the SHS Interface Server. The SHS Server is a centralized server application that interacts with all the SHS Agents in the system, and orchestrates the application integration process. Physical redundancy of the SHS Server is achieved through a primary and backup server with hardware fail-over, while database backup schedules are performed nightly. Secure remote maintenance by technical administrators ensures for regular and continuous vigilance against security intrusions and denial-of-service attacks on the system.

result in a significant investment in the health institutions IT infrastructure needs. This is an unrealistic consideration, noting that the purpose of implementing a middleware integration model is to achieve cost efficiencies, and as such it should be clearly demonstrable that savings can be achieved in system maintenance and end-user usability. In light of these concerns, two final candidate solutions were considered:

1.) Data Rewrite

This requires a manual reconciliation of conflicting data in the data stores, and modifying the associated business logic to conform to this. This approach is not considered as a long-term solution as it is potentially intrusive to the legacy applications, and can pose a major risk to the stability of these applications.

2.) Data Integration via Separate Database

This approach envisages a separate data store called the Enterprise Data Integration Service which will contain information for data mapping amongst the existing legacy data, as well as the location of where the new and legacy data exists. The Business Service component will query the Enterprise Data Integration Service upon receiving a client request, in order to find the location of the required information to service the client request. This information is then used to invoke the appropriate legacy application logic to perform the requested task.

5. Technology Architecture
1.) Evaluation of Technology Architecture A.) Evaluation Criteria
The evaluation was based on researching available enterprise-scale environments and cross-checking the reviews, advantages, constraints and stability from various accompanying documentation and research studies by the authors. Investigative interviews with medical personnel and management staff is necessary to establish clear guidelines on determining the appropriate criterion to consider in this stage of process.

B.) Evaluation Methods

The purpose of selecting IIS 7 and JBoss 6.0 is related to the suitability of an Enterprise-level Application runtime for legacy and proprietary applications written in the Java, C# and C++ programming languages. IIS is used as PIMS is written in the .NET Framework within the Microsoft Windows operating environment [10]; while APP operates in JBoss on a UNIX deployment server, which was considered to be more suitable in comparison to Jetty, Apache or Tomcat deployment services [11]. In addition, the added breadth of operating platforms being used by the legacy applications require key-subject matter experts to consider the risks of using particular software technologies in the final middleware implementation.

Fig. 7. SHS Integration Architecture (Conceptual View)

Currently, the service applications are operating separately without sharing medical and patient information records. Due to the high likelihood of data duplication in the data-stores of the applications, this would result in increased physical data management overhead and potential conflicts between common patient records, thus resulting in the inevitable concern of merging the legacy entities together. Furthermore, maintenance costs must be minimized to ensure the feasibility of implementing the middleware integration model in a seamless manner. Otherwise, this will
International Journal Publishers Group (IJPG)

60

International Journal of Advanced Computer Science, Vol. 2, No. 2, Pp. 56-64, Feb. 2012.

C.) Benefits
The core benefit of a hybrid approach of running separate runtime environments and an ESB to allow seamless request/response style integration, include less development and modification on the APIs of existing legacy systems and clear separation of middleware [12], improves performance (logical queues) and security [13] (Separate Single Sign-on (SSO) module and Encrypted HTTPS connection). This ensures that all users can be monitored effectively and efficiently in a secure manner, while maintaining a consistent interface to allow medical staff to perform their desired operations in the SHS.

D.) Drawbacks
The scalability of the system, by adding more independent web applications, would pose major configuration surgery if implementation does not address data synchronization issues appropriately. Due to the extensive use of web services, the indicative factors of Performance and Quality of Service may be impacted due to the transfer of large data structures between systems. One common example is the format conversion between two applications, such as image conversion of x-ray, ultrasound, computer-assisted tomography scans and magnetic resonance imaging scans.

Fig. 9. Deployment View

F.) Enablers and Inhibitors

The availability of source code for the legacy systems and other available resources to build a suitable ESB that meets all stakeholders needs to be considered. The clear separation of application components, middleware and medical domain data allow developers to make initial strategies on integration process through the ESB and web services in a seamless manner. This ensures that quality is continuously maintained throughout the development process. In some cases, limited low-level design considerations as well as poorly documented source code can cause not only serious delays, but even inhibit possible (time related) opportunities.

6. Opportunities and Solutions

The opportunities presented by the integration solution can be viewed in form of the core quality attributes of the SHS system. This takes into consideration the performance, usability, reliability and security attributes and the architectural solutions to address the relevant concerns:

Fig. 8. Execution View of the SHS

E.) Technological Constraints

The execution of APP on JBoss and PIMS on IIS, along with the integration Enterprise Service Bus (ESB) supporting two applications deployed on these diversified runtime environments, may cause developers potential programmatic concerns. Common problem include the differences of directory separator symbols (i.e. Windows (/) and UNIX (\)), and maintaining the consistency between Date and Data formats. The processing times vary in a live-environment and depend on the legacy applications internal performance and system dependencies, which will have consequential effects on the performance compliance of the finalized SHS system.

1.) Performance
The clear separation of middleware that uses high-performance enterprise-class message queuing solution results in this component being a performance enabler. The extensive use of web services for other messaging (especially internal communication) results performance constraints. The design of the messaging modules should employ todays intelligent asynchronous middleware technologies such as AMPS to minimize volume of wasteful queries [14]. Data security compliance and extensive traffic across modules means more performance constraints across system units. However, this can be managed by using web servers having sufficient capacity for the projected loads. Caching of service endpoints, scale-out of web components based on performance requirements and use of enterprise
International Journal Publishers Group (IJPG)

Christopher Chiu et al.: Building an Intelligent Health System Using an Evolutionary Architectural Model of Middleware.

61

class technologies need reflection.

2.) Usability
A separate module dedicated to providing management services of the system is an enabler for the usability attribute. Implementation of a user controls which are minimalistic from provisioning and command initiation perspective yet powerful enough to minimize guesswork, are very much the aim of defining such requirements which guide developers to design ergonomic process flows. A separate module for the Instrumentation Logger is an additional enabler for usability, such that audits can be conducted without impacting on the overall maintenance of the SHS system. This will allow system administrators to easily track transactions through the system for the following purposes: Troubleshooting, Debugging and Auditing (for compliance to organizational processes, corporate governance and statutory compliance).

Fig. 10. Security Context of the SHS System

3.) Reliability
Runtime reliability shall be ensured in the system by having redundant failover modules identified and implemented based on projected data traffic. The redundancy adds extra cost and maintenance which be taken into account while configuring data retention schedules. The failover data links, load balancers, mirrored disks, back up servers to cover hardware infrastructure is insufficient where software middleware/agents are prone to synchronization issues, data corruption and security threats on core connections. Defining requirements around data integrity for verification of keys/ids/credentials and records validation without forming new bottlenecks is important. This ensures that both software and hardware redundancy criteria is met in the middleware integration model, a key factor in achieving 99.999% reliability business mandates. Stateless services allow load-balancing of critical components using specialized hardware devices. Non-runtime reliability shall be assured by having all newly developed modules specifically designed to cater to the boundary conditions of Initialization, Failure, Recovery and Termination.

7. Migration Planning
The SHS aims to smooth out any incompatibilities by following a migration plan which aims to address common issues and challenges faced by enterprise level amalgamation of applications. These challenges have been addressed by satisfying the transition attributes of the SHS system architecture: Adaptability: The use of generic components and infrastructure components for future changes. Standardizing documentation of APIs and testing specifications for new modules which could be designed as plugins or extensions. The publishing of new service modules could be tightly governed by an enterprise governance-compliant certification application and signing program. Simplicity: The proposed architecture uses the minimum number of components in the simplest possible way or least complex design; the encapsulation of business logic which is health industry specific should be made to be configurable for easy transition through and beyond changing government regulations on data security, privacy and consumer protection. Flexibility: The modular architecture proposed can be re-combined, enhanced, and scaled-out in a variety of manners, giving flexibility at deployment and maintenance phases of the development cycle; Modularity: The use of layers, components, and modular techniques aid in a highly robust internal structure, enhancing overall system reusability; the idea of pluggable modules which interconnect and harness upon under-utilized system resources for unified

4.) Security
The entire SHS System shall be deemed to be running within an enterprise-level firewall environment. Core security is covered from five dimensions: SSO which is on the Authentication Gateway; Encrypted Data Access within Business Services; Random Queue number allocation by the Message Broker; Double Firewall and Instrumentation Logger for auditing security intrusions. The aims of enterprise-wide security model are to maintain confidentiality of users, Integrity of data, access control by owners, authorization, secure authenticated access and non-repudiation. A layered architecture is employed with critical assets in the inner area as proposed the figure below.

International Journal Publishers Group (IJPG)

62

International Journal of Advanced Computer Science, Vol. 2, No. 2, Pp. 56-64, Feb. 2012.

service delivery. A qualified example is the hybrid VOIP messaging system where data sharing is a plugin with voice and conferencing capabilities. Consistency: The consistent use of the underlying philosophy behind designing the component responsibilities and interfaces, and special attention being given towards achieving a final list of similarly-sized components to enhance reusability with overall aesthetics of the proposed architecture; The compliance to health standards such as HL7 [15] or government controlled reporting practices are to be clearly reflected by designing modules which mimic Clinical records communication in prescribed format and layout. The perspective of consistency is not merely confined to data [16], but applies to system behavior and responsiveness to new extensions/modules in a predictably accurate flow. Orthogonality: The clear-cut responsibilities of the various components without overlap, aids in the orthogonality of the components within the overall system boundary. As an example, in the health system one of problems is excessive paper work for routine clinical tests of same individual and the missing carry-forward of information with clarity. The SHS design aims to rectify such anomalies through notification alerts which allow administrators to minimize potential data duplication between modules [16]. A strategic part of the migration is risk analysis and mitigation strategy planning, with common risks including bottlenecks in the service bus (i.e. frequent congestion of the message router), inconsistent entity-mappings in databases and insufficient monitoring, auditing and logging mechanisms for troubleshooting. The system architecture should quantify the technical benchmarks based on current statistics to better guide the priorities during development process for migration.

in identifying effective processes and organizational structures. This is to ensure that the complete set of business responsibilities associated with architecture governance can be clarified, communicated, and managed effectively by all stakeholders of SHS [1]: Implementing Control: Cover the creation and monitoring of all architectural components and activities, to ensure the effective introduction, implementation, and evolution of architectures within the organization; Ensuring Compliance: A system to ensure compliance with internal and external standards and regulatory obligations. This is a quality and reliability indicator for the final build of the SHS system; Establishing Management: Processes that support effective management of the above processes within agreed parameters of the health institution; Ensuring Accountability: Developing practices that ensure accountability to a clearly identified stakeholder community, both inside and outside the organization.

9. Architecture Change Management

The objective of the final phase is to establish an architecture change management process for the new enterprise architecture baseline. This process provides for the continual monitoring of such things as new developments in technology and changes in the business environment (in the scope of health practice), and for determining whether to formally initiate a new architecture evolution cycle [17]. Some of the key inclusions in the SHS change control sheet considered important by the authors, as part of the internal quality review process emphasized by TOGAF [1] are as follows:

1.) Change Request

This includes the following details: Originator Information; Items to be Changed; Description; Cost Estimate, Priority, Constraints, Implications, Risks and Version Upgrades.

8. Implementation Governance
Implementation governance is a significant aspect of architecture governance, which covers the management and control of all aspects of the development and evolution of enterprise architectures and other architectures within an enterprise [6]. To aid the process effective use of tools such as online code repositories, build management, ticket management, testing and code reviews management which are an enabler to provide transparency over the implementation process where architects can assess the project on demand. This is a crucial phase which forms an Architectural Contract between the architecting organization and the sponsor of the enterprise architecture. It is intended to assist

2.) Change Evaluation

This includes consideration of the request based on what components are affected, related changes, work required, criterion listings and budgetary impacts.

3.) Change Implementation

This contains the architectural adjustments required and/or approved, technological changes including new component introductions, and timeline information. The key challenge is to keep all systems current with advancement of new extensions, developments, data sets, perspectives and interfaces as to deliver a robust health system infrastructure.
International Journal Publishers Group (IJPG)

Christopher Chiu et al.: Building an Intelligent Health System Using an Evolutionary Architectural Model of Middleware.

63

4.) Key Performance Indicators

The qualitative evaluation and merits of the SHS architectural transition was performed using the Architectural Tradeoff Analysis Method (ATAM) as defined by the Software Engineering Institute of Carnegie Mellon University [2]. The assessment criterion was specified according to the migration planning transition attributes in Section 7 of this paper:

10. Conclusion

The SHS System meets the health industrys need for consolidated patient records through the use of TOGAF by reducing the need for rework on legacy applications to fit into the new unified framework. This is achieved by investigating the candidate architecture models, frameworks and patterns that match the category of integration facilitators, to ensure the health institutions demands for scalability and extensibility is realized. The frameworks TABLE 1: ATAM ASSESSMENT OF SHS VS. LEGACY ARCHITECTURE architectural development method is effective in assessing the failure in services delivery in health industry and Legacy PIMS and APP SHS Integrated Enterprise Architecture Architecture provided new perspectives to better define system Quality Attribute Rank Quality Attribute Rank requirements from various stakeholder perspectives, 6/10 9/10 inclusive of health professionals and administrators. It also Adaptability Adaptability Legacy applications built Integration platform provides an efficient transition of the system from legacy on different platforms integration using W3C Web applications to its eventual role as a comprehensive health (Java and .NET), no Service Platform for standard administration application for universal patient recording. interconnectivity between interconnectivity between components subsystems The final SHS architecture satisfies the business case 5/10 8/10 requirements by allowing legacy systems to be interfaced Simplicity Simplicity Two separate business Unified architecture provides with additional features that are robust, secure and meet logic components have single sign-on (SSO) feature regulatory standards.
separate login/sign-on functionality for each subsystem to authenticate users to allow global accessibility to functions, thus reducing 2 sign-on panels to 1 SSO (50% reduction in login) Flexibility Integrated architecture utilizes a Enterprise Data Integration Service (EDIS) database with failover, reducing data duplication from 2 to 1 database (50%) Modularity SHS Architecture has been designed using a unified Enterprise Service Bus (ESB), unifying external client, management and staff users Consistency The core architecture integrates an ESB with business orchestration rule-sets, ensuring that all legacy and future services are compliant according to HL7 reporting standards Orthogonality Integrated architecture prevents overlap of business responsibilities through a unified authentication system (SSO) and database (EDIS) Architecture Summary Integrated platform unifies legacy and new services together for extensibility

Acknowledgements
8/10

Flexibility Legacy applications run separate database subsystem for persistence of health and staff records

5/10

Richard Raban (PhD), Rajesh Shenoy and Sepehr Madavi from the UTS Faculty of Engineering and IT are acknowledged for their assistance in the SHS Project.

References
7/10

Modularity Each legacy application has been designed according to their own architectural and end user specifications Consistency Legacy applications apply different design software patterns for implementation, each compliant to their relevant specifications Orthogonality Each legacy application has been designed with their own core responsibilities in mind Architecture Summary Each subsystem runs independent of each other

5/10

6/10

8/10

6/10

8/10

33/60

48/60

[1] TOGAF Version 9.0 Enterprise Edition, website: www.opengroup.org/togaf/, last viewed 15/11/2009 [2] www.sei.cmu.edu/architecture/tools/atam/ Software Architecture Analysis Methodologies, Software Engineering Institute, Carnegie Mellon University, Last viewed 3/4/2011 [3] J.A. Zachman, "A Framework for Information Systems integration framework," (1987) IBM Systems Journal, Vol 26, No 3, IBM Publications [4] Federal Enterprise Architecture Model, Website: http://www.whitehouse.gov/omb/e-gov/fea/, Last Viewed 4/04/2011 [5] C. Szyperski, Emerging Component Software Technologies, Strategic Comparison, Software Concepts & Tools, Vol 19, No 1, pp. 2-10, 1998 [6] R. Sessions, (2007), A Comparison of the Top Four Enterprise-Architecture Methodologies, Website: msdn.microsoft.com/en-us/library/bb466232.aspx, Last Viewed 11/05/2011 [7] B. Moulton, Z. Chaczko, & M. Karatovic, "Updating Electronic Health Records with Information from Sensor Systems," (2009) Journal of Convergence Information Technology Vol. 4, No. 4. [8] E. Freeman & D. Gelernter, "Lifestreams: A Storage Model for Personal Data," (1996) SIGMOD Record, vol. 25, no. 1, pp. 80-86 [9] U. Wilensky & M. Resnick, New thinking for new sciences: immediate role of an application integration framework for Constructionist approaches, San Francisco Press, CA, 2005 [10] Microsoft Corporation, Application Architecture for .NET: Designing Applications & Services, Website:

International Journal Publishers Group (IJPG)

64

International Journal of Advanced Computer Science, Vol. 2, No. 2, Pp. 56-64, Feb. 2012.

msdn.microsoft.com/en-us/library/ms954595.aspx, Last viewed 4/11/2009 [11] M. Fisher, R. Lai, S. Sharma, & L. Moroney, Java EE and .NET Interoperability, Integration strategies, patterns and Best Practices, Prentice Hall, Sun Microsystems Press, 2006 [12] L. Bass, P. Clements, & R. Kazman, Software Architecture in Practice, Addison-Wesley Longman Publishing Co., Inc, 1998 [13] L. Dobrica & E. Niemela, "A Survey on Software Architecture Analysis," (2002) IEEE Transactions on Software Engineering, vol. 28, no. 7, pp. 638-653 [14] P. Kruchten, H. Obbink, & J. Stafford, The Past, Present and Future of Software Architecture, IEEE Software, March-April 2006 [15] Health Level Seven International Standards, Website: http://www.hl7.org/, Last Viewed 3/05/2011 [16] C. Britton & P. Bye, IT Architecture and Middleware, Strategies for Building Large Integrated Systems, 2nd Edition, Addison-Wesley, 2004 [17] M. Rosen, B. Lubinky, K.T. Smith, & M.J. Bacle, Applied SOA, Service-Oriented Architecture and Design Patterns, Wiley Publishing, 2008

Christopher Chiu is a PhD Research Candidate at the University of Technology, Sydney. His experience in agent-based software architectures lead to his research interests into Java agent technologies in Sensor Actuator Networks for the medical health sector. Avtar Singh Kohli is a Software Engineering and Finance Graduate at the University of Technology, Sydney. His industrial expertise in enterprise web application development has led to his continued interest in middleware technologies and applications for health and business enterprise domains. Zenon Chaczko (PhD) is ICT Group Head for the University of Technology, Sydney. His domain knowledge in biomimetic software architecture and middleware, software engineering project management and object oriented design and technology has led to his best paper award in CASYS 2009 for Anticipatory Biomimetic Middleware.

International Journal Publishers Group (IJPG)