A Distributed Application Comparison for the Use in Health Care

Table of Contents

1. Introduction

2. Technology Review

2.1 CORBA

2.2 Web Services

3. A Comparison Overview

4. Evaluation

4.1 Data Model

4.2 Transport Protocol

4.3 Security

5. Conclusion

6. References

1. Introduction

The Health Care Authority is looking to use a distributed computing infrastructure to allow medical professionals to gain access and update patients medical records. Such an infrastructure would allow General Practitioners (GP), Hospital Consultants and Pharmacists to access patients records faster, to see medical history and update them with diagnoses, treatments, medication and allergies. In return, patients will receive better and faster treatment from GP’s, Hospitals and Pharmacies due to them all having access to the same up to date information.

The aim of this report is to show how both distributed object systems (CORBA) and distributed web-based services (Web Services) could be used for the development of such a distributed application within the Health Care system. A comparison is made between both CORBA and Web Services (WS), which shows how similar they are and how they can both be used to serve the same purpose. Therefore, an evaluation of three key features is discussed, showing both their strengths and weaknesses.

2. Technology Review

2.1 CORBA

The Common Object Request Broker Architecture (CORBA) is a distributed object system and is a standard by the Object Management Group (OMG). CORBA is designed to provide interoperability and uses components such as Common Data Representation (CDR), Interface Definition Language (IDL) and Naming Service.

CDR is a transfer syntax and is used for the mapping of data types. These data types are defined within the IDL and are used for transfer between clients using protocols TCP/IP, IPX/SPX, etc. The IDL is the description of a component within an application programming interface (API). The IDL has its own independent language, which can be mapped to many programming languages, so that software components are able to communicate with one another. The naming services is used for the naming of objects that have been defined. This makes the objects easier to find on servers (much like a registry), which makes CORBA geographically scalable.

2.2 Web Services

WS is a distributed web-based system, they are designed to support interoperable machine-to-machine interaction over a network. WS is made up of three main components such as Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL) and Universal Description, Discovery and Integration (UDDI).

SOAP is a message protocol specification for exchanging information over HTTP (TCP/IP) using Extensible Markup Language (XML). The WS receives requests and responses using SOAP packets, and it allows synchronous and asynchronous messaging. The WSDL is a specification for the description of WS definitions and is also the interface of the WS. Within the XML file a WSDL is written in, it describes how to use and connect to the WS. The WSDL also allows the WS to be mapped to programs and software. Finally, is the UDDI, which is a registry for storing and retrieving WS. The registry is for the description of the WS, so potential requestors can discover them; these registries can be either public or private.

3. A Comparison Overview

Table 1 (Vassilopoulos et al., 2006) shows a high-level overview of comparisons between CORBA and WS. There are many comparable features that work in simpler ways. It is said that whatever CORBA can do, WS can do and vice versa (Gokhale et al., 2002). In section 4, a more detailed comparison of key features such as data model, transport protocol and security are evaluated.

Table 1: A Comparison Overview

4. Evaluation

4.1 Data Model

The data model is how applications are designed. CORBA is independent of hardware platforms and software such as Windows, Unix and IBM mainframes, and allows the use of many different programming languages such as C, C++, C#, Java and Python for IDL mapping. While CORBA is built using a true object-oriented component, it is also tightly coupled. Tight coupling is a technique where objects are dependent on other objects and if an object is changed, then they all need changing. This means it is strongly typed and benefits from finding exceptions at runtime due to incompatible message formats (Slama et al., 2004). However, due to the complexity of the tightly coupled approach, it is believed by Henning (2009) that the use of CORBA for API’s makes them larger than necessary. Henning also suggests the mapping of IDL modules with a programming language can lead to problems such as thread safety, exception safety and memory management.

Likewise, WS are also independent of hardware, software and programming languages. In contrast, WS are of a non-object notion and focusses on the communication of messages. Furthermore, WS are a simplified way of building services that can interact with one another. WS are extensible; have a great interoperability and are built in a loosely coupled way (w3.org, 2013). Loose coupling is a technique were two or more hardware and software are linked to services that do not depend on one another. However, according to Myerson (2008) loose coupling in WS requires substantial redundancies, unlike tight coupling which keeps redundancies to a minimum.

4.2 Transport Protocol

The General inter-ORB Protocol is used in CORBA for the interoperability and for the mapping of various connection-oriented transport protocols. GIOP is able to run over TCP/IP using a specialised version of GIOP, and this is known as Internet Inter-ORB Protocol (IIOP). OMG (2011) deems it simplistic to ensure independent and compatible implementation. However, corporate policy and the use of a firewall may cause problems. This is due to firewalls blocking unwanted traffic, meaning it would affect unencrypted and SSL-encrypted IIOP. Therefore, firewalls would need specific extensions for TCP layer proxies or the firewall becoming a trusted host with access to cryptographic information or HTTP/HTTPS tunnelling, which could threaten security (Lang, 2000).

In contrast, Web Services uses SOAP to send messages over HTTP, which is built on top of TCP/IP (Tanenbaum and Steen, 2007). This means it has access on port 80 of all firewalls and looks like it is posting to a web page, making this a simplistic approach compared to GIOP (IIOP). However, this simplicity comes at a cost in how WS performs. IIOP is some more than twice as fast and does not change significantly in performance when the size or type of argument is changed (the number of simultaneous clients). Whereas, the performance of WS lags due to the length of a SOAP message and the time it takes to parse and format an XML message over HTTP (Artemio et al., 2012).

4.3 Security

CORBA has its own security services called CORBAsec which can be applied to many security protocols. It helps to secure areas such as authentication, authorisation, data integrity, confidentiality, replay, reordering and non-repudiation (McHale, 2007). CORBAsec has two levels of conformance. Level 1 specifies how to secure established connections between clients and servers, and is done without the need for writing security-specific code. Level 2 is for the more complex and security-aware applications, where a superset of level 1 allows finer control over security policies. However, according to Alireza et al (2000) CORBAsec has its problems and weaknesses. It is said that authorisation is weak due to the predefined access rights that have limited validity, security audit records are not secure, non-repudiation is somewhat incomplete and in need of components such as delivery authority and secure storage, and interoperability of CORBAsec solutions has its challenges.

 Whereas, WS uses web services security (WSS) which are extensions of SOAP. Similar to CORBAsec, WSS helps to secure authentication, authorisation, data integrity and confidentiality (Mukherjee at el., 2013). Moreover, the WSS consists of components such as WS-Security, XML-Encryption, XML-Signature, WS-Trust, WS-SecureConnection and much more. However, like CORBAsec, WSS has its weaknesses too. WSS has many available options and is flexible, which makes it prone to increased erroneous use. It is also said with the use of XML encryption, firewalls may not be able to detect XML attacks or vulnerabilities (Nordbotten, 2009).

5. Conclusion

While the Health Care Authority are looking to use a distributed computing infrastructure to improve patient’s medical records and treatment, both CORBA and WS offer a valid solution. Although, both CORBA and WS are similar in many ways, they both have their weaknesses. Therefore, the choice may come down to either wanting a complex, object-oriented and tightly coupled approach of CORBA or a simplistic, non-notion of objects and loosely coupled approach of WS. Moreover, a key decision for any choice must be for the protection of the patient’s medical records, where the security of any distributed object system or distributed web-based system for areas such as authentication, authorisation, data integrity and confidentiality are a priority. However, the security solutions offered by both CORBA (McHale, 2007) and WS (Nordbotten, 2009) are not a complete solution.

6. References

• Alireza, A., Lang, U., Padelis, M., Schreiner, R. and Schumacher, M. (2000). The Challenges of CORBA Security. Sicherheit in Netzen und Medienströmen. pp61-72. doi: 10.1007/978-3-642-58346-9_6
• Artemio, S., Leonardo, B., Hugo, J., Carlos, M.J., Marco, A. and Carlos, P.J. (2012). Evaluation of CORBA and Web Services in Distributed Applications. Proceedings of the 22nd International Conference on Electrical Communications and Computers (CONIELECOMP). pp97-100. doi: 10.1109/CONIELECOMP.2012.6189889
• Gokhale, A., Kumar, B. and Sahuguet, A. (2002). Reinventing the Wheel? CORBA vs. Web Services. [online] Available: https://wwwconference.org/proceedings/www2002/alternate/395/index.html. [Accessed 14th October 2019].
• Henning, M. (2008). The Rise and Fall of CORBA. Communications of the ACM. 51 (8), pp52-57. doi: 10.1145/1378704.1378718.
• Lang, U. (2000). CORBA security on the web – an overview. Future Generation Computer Systems. 16 (4), pp417-421. doi: 10.1016/S0167-739X(99)00065-5
• McHale, C. (2007). CORBA Explained Simply. 1^st ed. [ebook] Available: http://www.ciaranmchale.com/corba-explained-simply/. [Accessed 15th Oct 2019].
• Mukherjee, S., Beg, R., Srivastava, A. and Khan, R. (2013). Overview of secured web services specifications. Proceedings of 2013 IEEE Conference on Information Communication Technologies. pp4-9. doi: 10.1109/CICT.2013.6558052
• Myerson, J.M. (2008). Tight-coupling Web services in the SOA. [online] Available: http://www.ibm.com/developerworks/library/ws-soa-tightcoupling/index.html. [Accessed 14th October 2019].
• Nordbotten, N.A. (2009). XML and Web Services Security Standards. IEEE Communications Surveys Tutorials. 11 (3), pp4-21. doi: 10.1109/SURV.2009.090302
• OMG. (2011). Common Object Request Broker Architecture (CORBA) Specification, Version 3.1.1. [online] Available: https://www.omg.org/spec/CORBA/3.1.1/Interoperability/PDF. [Accessed 10th October 2019].
• Slama, D., Banke, K. and Krafzig, D. (2004). Enterprise SOA: Service-Oriented Architecture Best Practices. Upper Saddle River, NJ: Prentice Hall.
• Tanenbaum, A.S. and Maarten, S. (2007). Distributed systems: principles and paradigms. 2^nd ed. Upper Saddle River, NJ: Pearson Prentice Hall.
• Vassilopoulos, D., Pilioura, T. and Tsalgatidou, A. (2006). Distributed technologies CORBA, Enterprise JavaBeans, Web services: a comparative presentation. Proceedings of the 14th Euromicro International Conference on Parallel, Distributed, and Network-Based Processing (PDP’06). pp1-5. doi: 10.1109/PDP.2006.29
• W3C. (2012). Web Services Activity Statement. [online] Available: https://www.w3.org/2002/ws/Activity. [Accessed 7th October 2019].