CORBAMed

CORBA and CORBAMed

Learning Goals:
Know the motivation behind the object oriented approach in the context of medical informatics
Know how CORBAMed relates to CORBA

CORBAMed is the division of CORBA that is devoted to the domain of healthcare. CORBA is, very roughly, a set of standards for general computing, and is not specific to medical informatics. CORBA grew out of an initial premise that something called 'object orientation' is the solution to certain computing problems that typically arise when trying to build and maintain very large and complex systems. Very big systems are very hard to build, mostly because pretty soon none of the people working on the thing can remember what the huge majority of the programming code does - because the person who wrote it has left the company, or they wrote it so long ago that they can't remember what it does, or because there is simply so much of it that nobody can remember it all at once. Whenever programming continues under these circumstances, things generally end up with a big and unstable mess. Change one bit of code and the whole thing stops working, and nobody knows why.

CORBA (Common Object Request Broker Architecture) is a branch of OMG (Object Management Group), which is itself affiliated with ISO

Optional: What is object orientation ?

Optional Learning Goals:
Know the basic elements of Object Orientation as a technical computing approach

Object orientation is a general computing technology that is becoming accepted as a good way to break a monster programming task into lots of smaller and more manageable pieces, or objects. In a really OO environment, everything is an object - a button on the screen, the screen itself, the integer 10, a variable, an external application, a set of record items extracted from a database.

All objects have two parts:

• Data - the state of the object, for example:
  • the value of a variable
  • whether a button is pushed
  • the colour of the screen
  • the number of record items in the list
• Operations - all the operations to access or change the data, for example:
  • divide yourself by 3 and tell me the result
  • tell me whether you are pushed or not
  • change the screen colour to green
  • delete the last record item

Objects interact by sending messages to each other and then doing something with the reply. Each message will ask for an operation (method) to be executed by the receiving object. The sender has no idea - and does not care - how the receiver does its stuff. Maybe all the necessary computation is performed by an operation known directly to that object. Maybe the object delegates the work out to lots of other objects. It doesn't matter to the sender - all it cares about is the reply.

Having characterised what an object is, and how they interact, the key characteristics of the overall OO approach are object polymorphism, inheritance and encapsulation (bet you're glad you asked now).

• Polymorphism = many objects can respond to the same message in different ways
• Inheritance = objects can be, and usually are, organised into an object class hierarchy that allows an object to inherit all of the message answering behaviours and state properties of its ancestors.
• Encapsulation = the fact that the state of an object is protected from the outside world, and can only be fiddled with by means of the message interface.

Object inheritance is a very powerful way of achieving re-use of code, so that the initial development of a complex system can be more efficient. But the real value of the OO approach comes into play when you're trying to maintain or extend an already huge system. Perhaps the most important point about the OO technique is that a message from one object to another can only ever say what it wants done, and can never know or say how it is to be done. This means that a programmer can change how a specific object implements its behaviour without having to worry about how the rest of the code base will work. Because other people programming the rest of the system were never allowed to know how the object did its thing in the past, they could not write code that relied on (or worked around) some peculiarity of that previous implementation. Therefore, so the theory goes, because of encapsulation you can change an object's implementation as much as you like just as long as you don't change its behaviour.

Object orientation , therefore, aims chiefly to improve both the efficiency of programming effort by improving code re-use and also the scalability of the whole thing through encapsulation.

Introducing CORBA

CORBA is an object oriented technology standard for specifying how two programs, from any vendors, can interact and communicate. CORBA, therefore, specifies the nature of an interface (API) between two pieces of software. CORBAMed focusses on the special problems that arise when those two pieces of software happen to be pieces of a healthcare IT system.

The CORBA interface and, therefore, the CORBAMed interface, is based on three building blocks:

• an interface definition language (IDL)
• An Object Request Broker (ORB) device specification
• A standard request protocol (IIOP)

Very roughly, the CORBAMed specification (written in IDL) is a formal expression of what functions a compliant server must support. Armed with the same IDL, a potential remote piece of software therefore knows what it can ask a compliant server to do - what questions can be asked, and how to ask them.

An ORB is a software device that keeps track of all the objects involved in a given client-server dialogue.

IIOP is the language within which the dialogue is conducted.

CORBA is a very successful, prominent and important technology in computing generally.

The activities of CORBAMed continue but are currently (2000) to a great extent subsumed within HL7.

More information about CORBA and CORBAMed is available from their web sites (e.g. the CORBA FAQ).