Service-oriented Architecture in Medical Software: Promises and Perils

Abstract

In the current issue of JAMIA , Kawamoto and Lobach1 propose a software framework intended to facilitate widespread, effective, clinical decision support. The proposed framework embraces a service-oriented-architecture (SOA) approach. Service-oriented-architecture is a philosophy of design described as “the software equivalent of Lego bricks,”2 where a toolset of mix-and-match units (“services”), each performing a well-defined task, can reside on different machines (including geographically separated ones), ready to be used when needed. The most widespread implementations of SOA involve the use of Web services, where a given computational resource/service can be invoked by a remote machine via messages composed in XML and sent over HTTP, so that they can operate across firewalls. Think of a Web service, in its simplest form, as a subroutine that can be called over the Internet. Thanks to success stories such as Amazon.com,3 and at software giants such as SAP,4,5 the status of SOA in the business information technology (IT) domain has risen meteorically. The Kawamoto and Lobach paper1 reiterates the following potential benefits of SOA: Some IT articles, however, present a “caveat emptor” skepticism about SOA.6,7 One must carefully inspect the claimed benefits of SOA closely, examine its potential drawbacks, and take a balanced approach to any proposed new SOA application while taking into consideration past lessons from business IT. In software design, simplification through problem decomposition into semi-independent units (subroutines, classes) is an important, incontrovertible principle. In SOA, where the units (services) lead a relatively autonomous existence (e.g., units are free to reside on physically separate hardware), …

Ähnliche Arbeiten