서 론
의료시장이 개방되고 관련 법규가 신설, 변화되면 의료시장 내∙외적으로 협업에 대한 비즈니스 요구가 발생할 것이다. 의 료 협업 및 서비스 요구에 신속하게 대응하기 위해서는 의료 IT 환경이 관련 업무를 구성하는 업무프로세스 단위로 필요한 서비스를 제공할 수 있어야 한다. 비즈니스 영역의 개선은 프 로세스 중심으로 개선 요구사항을 정의하고 충족시켜야 하며 이를 통해 프로세스의 지속적인 진화가 가능하다. 외부 병원∙
기관과 협업 할 프로세스를 지원하는 서비스를 제공함으로써 신속한 협업 업무 구성은 물론 서비스의 재사용이 향상된다
[1]. 최근 비즈니스 환경 변화에 신속하고 유연하게 대응하면 서도 안정성과 비용 절감의 장점을 제공하는 SOA에 대한 관 심이 고조되고 있다. 비즈니스 비전과 요구사항을 분석해 이를 기술과 접목시키는 것은 SOA 구현의 핵심적인 순서이다. 하 지만 SOA 비즈니스 사례나 전문 인력의 부족 문제 등이 시장 활성화의 걸림돌로 지적되면서 이러한 문제점들을 해결하고 성공적으로 SOA 프로젝트를 수행하기 위해서는 장단기 목표 별로 점진적인 도입을 위한 전략과 방법론이 필요하다[2].
SOA를 통해 IT 가용 능력을 극대화하여 의료기관의 경쟁력 및 역량을 강화시킬 수 있을 것으로 기대되며 의료정보와 IT의 밀접도가 높아지고, 이익 극대화 노력과 애플리케이션 통합에 있어 단순화와 표준화 추진과 장기적인 관점에서 유지보수의 비용 감소 노력이 증가됨에 따라 애플리케이션의 콤포넌트화 와 재사용성 등이 요구되어지고 있다[1, 3].
기존의 시스템 설계시 일반적으로 기관의 애플리케이션 자 산들은 개발 당시의 비즈니스 프로세스를 반영하고 있으며, 프 로세스 변화에 대해서는 매번 소스코드 수정 및 추가적인 패키
의료 IT의 서비스 지향 아키텍처 접근 방법에 관한 연구
박 선 영1∙김 남 현2
1연세대학교 대학원 생체공학협동과정, 2연세대학교 의과대학 의학공학교실
A Study for Approach Service Oriented Architecture to Medical Information Technology
S. Y. Park1, N. H. Kim2
1Graduate Program in Biomedical Engineering, Yonsei University
2Department of Medical Engineering, College of Medicine, Yonsei University
= Abstract =
The current medical environment, Service Oriented Architecture(SOA) is to start applying the sys- tem. Service-oriented design paradigm is attended for improving reusability, ease of integration, flexi- bility, development agility of software. SOA through loose coupling, introduces fare more flexibility into a system composed of connected application. In this study we propose a method of approach SOA to Medical Information Technology and example.
Key words: Service Oriented Architecture, Enterprise Service Bus, Reuse
본 연구는 보건복지부 보건의료연구개발사업의 지원에 의하여 이루어진 것임 (A102076).
통신저자: 김남현, (120-752) 서울특별시 서대문구 신촌동 134 연세대학교 의과대학 의학공학교실
Tel: 02-2228-1915, Fax: 02-392-4358 E-mail: [email protected]
지 커스터마이즈(customize)가 필요하다[4]. 따라서 비즈니 스 프로세스 변화를 위해서는 적지 않은 시간과 노력을 들여야 하며, 경우에 따라서는 경직된 애플리케이션 구조로 인해 비즈 니스 프로세스 변경이 현실적으로 불가능 할 수 있다. 기존에 는 object-oriented architecture(OOA) 모델링을 통해 전자 건강 정보 기록 시스템 아키텍처를 설계하였으나 근래에는 SOA, 웹서비스, 그리드 컴퓨팅, 오픈 소스 소프트웨어 등을 이용하여 시스템 아키텍처를 설계한다[5].
SOA는 IT를 기반으로 비즈니스 프로세스가 효율적으로 결 합 하도록 도와주며, 표준 소프트웨어 인터페이스를 통해 시스 템을 재구축 하지 않고서도 비즈니스 환경 변화에 빠르게 대응 할 수 있도록 지원한다. 따라서 고객 서비스와 시장 대응 능력 을 가속화시키며, 전략 변화에 따른 새로운 시스템 출시 기간 을 감소 시켜줌으로써 결과적으로 의료기관의 경쟁력과 비즈 니스 역량을 강화시켜 준다는 장점을 갖는다. 또한 SOA의 경 제적인 이점도 SOA 도입에 긍정적인 작용을 하고 있다[1, 3].
IT 관점에서 보면, 의료 정보 시스템 범위를 확대하는 동안 많 은 IT 그룹이 내∙외부적으로 필요한 컴포넌트나 자산을 개발 해 왔을 것이다. 즉, 기술적 자산의 양은 지속적으로 늘어날 것 이지만 모든 가능한 컴포넌트와 자산을 모으고 관리할 일반적 인 라이브러리가 없다는 게 문제다. 이를 해결하려면 기능들을 서비스화 하여 재사용 해야 한다[1, 6]. 서비스는 상호 협력하 거나 함께 결합되는 수많은 서비스 또는 단일 애플리케이션으 로 이루어질 수 있다. 중요한 점은 SOA를 도입한다고 해서 반 드시 레거시 애플리케이션을 다시 작성하거나 패키지 애플리 케이션을 교체할 필요는 없다[7].
본 논문에서는 의료 IT 시스템의 일부인 생체신호 측정 시스 템에 서비스 지향적 모델링을 적용하였다. SOA 엔터프라이즈 기반 구조가 애플리케이션과 서비스 사이의 표준화된 통신 메 커니즘을 제공한다. 또한 하부 조합되는 심전도나 혈압 시스템 의 서비스의 내부 변경이 일어나 체계를 수정한다 하더라도 그 서비스를 사용하고 있는 생체신호 측정 애플리케이션에는 영 향을 주지 않는다. 즉 다양한 레거시 시스템들과의 복잡성은 생체신호 측정 애플리케이션에게는 보이지 않게 된다. 레거시 시스템은 SOA 환경에 통합될 수 있다. SOA는 서비스를 이용 하여 신뢰성 있는 애플리케이션을 신속하게 구현할 수 있는 환 경을 제공한다[8].
1. SOA의 개념
SOA는 소프트웨어를 공유와 재사용 하기 위하여 분산 객 체의 형태로 존재하는 컴포넌트들간에 메시지(Message) 통신 을 통해 정보를 교환하는 느슨하게 연결된(Loosely Coupled)
형태의 소프트웨어 아키텍처이다[4, 8, 9]. 개별 컴포넌트들은 미리 약속된 표준 메시지인 SOAP(Simple Object Access Protocol)로 송수신 한다(그림 1) [9].
그러나 SOA 기반 프로젝트라 하여 반드시 SOAP를 사용하 거나 WSDL로 서비스를 정의하지는 않는다. SOA 기반 프로 젝트는 CORBA로 구성될 수도 있으며 DCOM으로 구성될 수 도 있다. 물론, 가정 보편적인 서비스 호출 메커니즘으로 플랫 폼 특성에 영향을 받지 않는 웹서비스를 사용하는 것이 일반적 이다[9]. SOA는 기존에 제공하는 서비스(컴포넌트)를 재사용 하기 위해 ESB(Enterprise Service Bus)를 이용하여 공개 하며, 이를 이용하여 새로운 트랜잭션의 생성이 가능하다[10- 12]. ESB는 통합을 위한 기반이 되는 분산, 플랫폼 중립적, 개방 표준 지향적인 메시징 미들웨어(Middleware)의 프레임 워크를 의미한다. 즉, ESB는 SOA를 위한 엔터프라이즈급 통 합 메시지 백본(Backbone)이다[12]. ESB는 다음과 같은 특 성을 가진다[2].
□ XML 기반의 동기/비동기 SOAP 메시징
□ 안정적이고 신뢰성을 보장하는 메시징
□ Intelligent routing and intermediaries
□ 데이터 변환(XSLT, XQuery)
□ 웹서비스를 통한 외부 컴포넌트와 통신
□ QoS(Quality of Service) 및 보안
ESB를 이용하면 커넥션(Connection) 수를 줄일 수 있다.
여기서는 각각의 애플리케이션은 참조하는 다른 제공자 (Provider)의 영향을 받지 않고 단지 ESB에서 Exception만 처리하면 보다 안정적인 시스템을 구성할 수 있다. ESB를 이 해할 수 있는 가장 중요한 개념은 강결합(Tightly Coupled)와 약결합(Loosely Coupled) 애플리케이션의 개념이다. 여기서 강결합은 RPR(Re mote Procedure Call) 스타일의 프로그 램으로 CORBA, DCOM, RMT, ActiveX, SOAPv1.0과 1.1 이 여기에 속한다. 각각의 시스템은 메서드(Method)를 호출 하여 구성하는 방식이기 때문에 동기적(Synchronous) 시스
그림 1. 컴포넌트간 커뮤니케이션
템을 구성하게 한다. 따라서 이러한 형태의 시스템을 구축할 때에는 반드시 Error Handling이나 Recovery Logic을 구성 할 필요가 있다. 그림 2에서 각각의 애플리케이션을 연결하기 위해서는 n(n-1)/2의 연결선을 구성해야 한다. 따라서 하나의 애플리케이션이 추가되면 n2의 수만큼 커넥션(Connection)의 수가 증가하게 된다. 아래와 같이 애플리케이션이 5개인 경우 5*4/2=10개의 커넥션이 필요하며, 6개인 경우는 15개의 커넥 션이 필요하게 된다. 따라서 하나의 애플리케이션이나 서비스 의 장애가 있을시에는 전체 시스템의 장애를 가져오게 되므로 All-or-Nothing의 시스템 구성을 야기한다[13].
반면, 약결합(Loosely Coupled)은 MOM(Message Oriented Middleware)의 기본이 되는 개념으로 그림 3과 같 이 각각의 애플리케이션은 Message interface를 두어 Message backbone을 통해 다른 애플리케이션과 메시지를 주 고 받음으로써 비동기적(Asynchronous) 방식으로 서로 간의 시스템을 연계한다. 따라서 하나의 애플리케이션의 장애는 Message backbone을 통해 장애를 처리하므로 다른 애플리케 이션에 영향을 미치지 않는다. 약결합에서의 애플리케이션 수 와 각각의 연결하는 커넥션의 수는 같다. SOAP v1.2, WSDL 2.0, WS-BPEL, JAX-RPC v2.0에 약결합 개념이 반영되어 있다 [13, 14].
2. SOA 애플리케이션의 특성
SOA에서는‘서비스’지향이라는 개념이 중요하며 이 서비 스들이 독립적으로 유지되어야 한다. 각 서비스는 각 기업의 특정한 기준에 따라서 캡슐화가 되며 그 서비스의 크기는 작을 수도, 클 수도 있다(그림 4)[9]. 서비스로 구성된 자동화 솔루 션을 구축할 때, 각 서비스는 개별적인 단계나 여러 단계의 서 브 프로세스를 캡슐화하여 구성이 가능하다. 어떤 경우 하나의 서비스가 전체 프로세스를 캡슐화 하기도 한다. 이 또한 서비 스가 될 수 있다. 웹서비스와 동일하게 서비스 지향 에서도 메 시지, 오퍼레이션, 서비스, 프로세스가 존재한다. 메시지는 커 뮤니케이션 단위, 오퍼레이션은 작업 단위, 서비스는 처리로직 의 단위로써 작업 단위의 집합. 프로세스는 자동화 로직의 단
위로써 작업단위를 묶어 놓은 집합이다.
현존하는 아키텍처 대부분 프로그램 중심적으로 만들어졌 다. 즉, 애플리케이션이 프로그래머의 입장에서 만들어진 것이 다. SOA 중심의 애플리케이션은 내부에 포함된 비즈니스 로 직은 세부사항을 감추는 블랙박스와 같다. 기존의 방식과 달리 프로세스는 단계 별로 각각을 대표하는 비즈니스 서비스로 분 해된다. 이러한 하부 애플리케이션은 업무의 요구사항을 만족 시키는 프로세스의 능력을 생성해낸다. 이것은 조직 내에서 프 로세스의 이용과 하위 애플리케이션의 재사용을 통해 가능하 다. SOA는 기술 아키텍처가 아니라 비즈니스 아키텍처 측면 에서 생각하도록 강요한다. 결국, SOA가 완벽하게 구축된다 면 변화하는 비즈니스 요구와 매순간 바뀌는 시장 조건들에 대 한 기업의 적응력은 크게 높아지게 된다[8, 9].
재료 및 방법
1. 서비스 지향 모델링과 아키텍처에 대한 접근 방법 기존의 방식과 달리 SOA에서 애플리케이션은 프로세스를 위해 개발된다. SOA는 여전히 컴포넌트를 사용하여 컴포넌트 의 일부 또는 전부를 캡슐화 하지만 전체 모델링에서 애플리케 이션 로직을 분할하는 방식과 분할된 로직의 프로세싱 로직의 위치 등 서비스의 생성에 집중한다. 여기서 서비스는 로직의
그림 2. 강결합(Tightly Coupled)의 구성도 그림 3. 약결합(Loosely Coupled)의 구성도
그림 4. 서비스 로직 캡슐화 방식
독립된 단위로서 존재하며 비즈니스 프로세스는 일련의 서비 스들로 분할 할 수도 있고 각 프로세스의 실행 부분에 책임을 부여할 수도 있다. 후보 서비스 도출 단계는 서비스 지향 분석 프로세스의 전단계에서 수집한 정보를 구조화 하는 작업이다.
여기서 후보 서비스란 비즈니스 목표를 달성하기 위해 비즈니 스가 요구하고 정보기술 시스템이 제공하는 소프트웨어 자산 들의 집합을 말한다. 여러 가지 비즈니스 모델 문서로 부터 업 무 담당자와의 요구사항 등에 이르기까지 다양한 출처에서 필 요한 정보를 얻을 수 있다. 이 단계에서는 공개(노출)이 결정 될 대상 서비스를 선정 하여 도출된 후보 서비스들 가운데 비 즈니스 및 목적에 부합하는 서비스를 선정 한다.
본 논문에서는 그림 5의 생체신호 측정 프로세스에서 비즈 니스 프로세스를 분해하여 오퍼레이션 후보를 식별하고, 오케 스트레이션 로직 추상화, 서비스 후보 생성과 서비스 조합 식 별의 과정을 이용하여 서비스를 도출 하였다[9].
결 과
1. 서비스 지향 설계
의료 IT 부문의 기존 레거시 자원인 생체 신호 측정 시스템 을 서비스로 모듈화 시키고 비즈니스 자원으로 재활용 하였다.
주요 서비스 선정 기준은 비즈니스 목적에 부합해야 하며, 충 분히 독립적 이어서 교체 및 조립이 용이 해야 한다. 내∙외부 에 공통으로 존재하는 경우, 복수의 소비자로부터 서비스 제공 요청을 받아 재사용성이 높은 경우와 동일한 비즈니스 목표 또 는 비즈니스 프로세스를 지원하는지에 따라 표 1의 SOA 적용 시스템을 선정 하였다.
지금까지의 서비스 후보를 가지고 프로세스 범위 내에서 발
생할 수 있는 가장 일반적인 시나리오 집합을 식별하였고 임시 비즈니스 서비스 레이어와 애플리케이션 서비스 레이어를 형 성하는 서비스 후보들을 식별 하였다.
∙생체신호(혈압∙심전도) 디스플레이
∙HL7 v3.0 데이터 변환
위 2개의 서비스 후보들은 범용적 이고 재사용 가능하며 비 즈니스에 독립적인 로직을 표현한다. 이 서비스 후보 집합이 임시 애플리케이션 서비스를 구축한다. 필요한 비즈니스 로직 을 실행하는 컨트롤러로서 애플리케이션 서비스를 조합하였다 (그림 6).
표 1. SOA 적용 시스템 시스템 구성 설 명
관련 시스템 생체신호 측정 시스템 프로세스 ■ 혈압 심전도 데이터 측정
■ 혈압 심전도 파형 저장
■ 생체신호 디스플레이
■HL7 v3.0 데이터 변환 오퍼레이션 ① 혈압 심전도 데이터 수신
② 혈압 심전도 데이터 디스플레이
③ 혈압 심전도 데이터 획득
④ 혈압 수치 심전도 데이터 변환 (HL7v3.0 변환 모듈)
⑤ 혈압 심전도 데이터 자료 구조에 저장
⑥ 사용자 측정 종료
⑦ 혈압 심전도 파형 로컬 저장
⑧ 혈압 수치 심전도 데이터 수신
⑨ 혈압 수치 심전도 프로토콜 해석
⑩ 혈압 수치 심전도 파형 디스플레이
⑪XML 형태의HL7 메시지로 변환됨
그림 5. 시스템 아키텍처
그림 6. SOA 서비스 조합에 의한 애플리케이션
결 론
SOA 시장이 활성화 되기 위해서는 비즈니스 및 아키텍처 관점에서의 의료 IT의 SOA 도입 사례가 증가해야 한다. 이를 위해서는 SOA가 단순한 IT 아키텍처를 넘어 비즈니스와 IT가 유 기 적 으 로 융 합 되 는 수 단 으 로 서 정 착 되 어 야 하 며 , ROI(Return of Investment)에 대한 명확한 정의와 측정 기 준이 제시되어야 한다. SOA가 성공적으로 구축되기 위해서는 SOA가 특정 제품이나 기술이 아닌 아키텍처 차원에서 접근되 어야 한다. 그리고 SOA가 최종적으로 전사적으로 도입되어야 큰 효과를 볼 수 있지만, 우선적으로는 빠른 ROI가 기대되는 부분에 먼저 적용한 뒤 점차 확대해 나가는 방안이 필요하다.
효과가 큰 부분에 우선적으로 적용하고 단계별로 확대해 나가 도록 유도해야 한다. 그리고 수많은 서비스와 프로세스들을 통 합하고 연계하기 위해서는 거버넌스와 데이터 보완에 대한 전 략도 제공되어야 할 것이다.
SOA의 의료 부문 적용은 의료 IT 안에 SOA를 완전히 내재 화 하기 위해서는 적잖은 시간이 걸릴 것이다. 그렇지만 SOA 는 지속적으로 현재 상태를 개선하고 시스템 아키텍처 안에서 서비스 컴포넌트 조합에 의한 애플리케이션 개발을 통해 변화 관리를 수행 할 것이며, 다변화 되는 의료 업무 환경을 뒷받침 할 수 있다.
본 논문에서 제시한 의료 IT 부문의 SOA 적용 접근에서 보 듯이 SOA 사례 부족과 구축 비용 및 시간에 대한 이슈로, 관 심에 비해 의료 서비스에 실제 적용은 아직 활발하게 진행되고 있지 않다. 하지만, 차세대 아키텍처로써 현재의 많은 소프트 웨어 아키텍처의 문제점을 해결할 수 있는 방안이며, 이 접근 은 가능한 의료 IT 리소스를 사용해 비용을 절감하는 동시에 비즈니스 필요에서 부터 프로젝트 개발을 시작해 의료업계 변
화에 솔루션을 전달함으로써 비즈니스 목표를 더 성공적으로 달성할 수 있게 해준다. 지속적인 연구와 노력을 통해 적용 방 안을 발전 시키고 실제 프로젝트에의 점진적 적용과 검증이 필 요 할 것이다.
참 고 문 헌
1. IBM. MOHW SOA Pilot Project 결과보고서, 2008.
2.임철홍, 홍도식, 최정준. ESB기반 SOA Appli -cation에 대한 S/W Architecture 관점의 평가와 개선 방안에 대한 연구, 한국 IT서비스학회지 제5권 제2호, 2006.
3. EHR 핵심공통기술 연구개발 사업단. 제4차 심포지엄 : 인증체 계, PHR 현황 및 EHR아키텍처 논리설계, 2009.
4.노수갑, 한국HP컨설팅사업본부. 어댑티브 애플리케이션 아키 텍처의 구성과 기대효과, 컴퓨터월드, 2005.
5. Chunhua Weng, Betty A. Levine, Seong K. Mun. Software Architecture and Engineering for Patient Records: Current and Future, Military Medicine, vol.174,5:27, 2009.
6.박춘복. SOA 기반의 외래환자 진료정보시스템 구현에 관한 연 구, 경북대학교 박사학위논문, 2009.
7.정찬기. 국방 엔터프라이즈 아키텍처(MND EA)에 서비스 지향 아키텍처(SOA)의 적용방안에 관한 연구, Journal of Information Technology and Architecture, 2007.12.
8.에릭 마크스, 마이클 벨. SOA 서비스 지향 아키텍처 : 비즈니스 와 IT를 위 한 전략과 구현 지침서, 엠플래닝, 2007.
9.토마스 얼. SOA : 서비스 지향 아키텍처 개념에서 설계, 구현까 지, 에이콘, 2008.
9. FAN Wei. Research on Technology Develop -ment of Human Resource Management Infor -mation System, Management Science and Engineering, Vol.3 No.2 pp.34-37, 2009.
10. Service Oriented Architecture - Part 1 CBDi Journal, Oliver Slim, 2003.
11. Allan Brown. Using Service-Oriented Architec-ture and Component-Based Develo pment to Build Web Service Applications, white paper published on the Rational Software, 2003.
12. SOA 표준기술 가이드, 삼성SDS 인트라넷혁신팀, 2006. 2.
13.서명일. 안정적인 웹 서비스 제공을 위한 미들웨어 시스템 구현 에 관한 연구, 연세대학교 석사학위논문, 2007.
14. Dave Chappell. Enterprise Service Bus, 2004. 6.
대한의학영상정보학회지 2010;16:37-41
=초 록=
서비스 지향 아키텍처(SOA)란 서비스로 정의되는 분할된 애플리케이션 조각들을 단위로 느슨하게 연결하여, 하나의 완성된 애플리케이션으로 만드는 아키텍처이다. SOA를 적용하면 기존의 프로그래밍 방식에서 탈피하 여, 애플리케이션 전체나 일부가 서비스 개념으로 인식되어 쉬운 조립(Assembly)을 통해 새로운 비즈니스 시스 템을 빠르게 개발할 수 있다. 본 논문에서는 의료 IT분야에 SOA 적용 방안을 제안하며 간단한 사례를 들어 설명 한다. 비록 조직에 SOA 적용은 필요하지만 한번에 의료 시스템 전체에 접근하는 것은 바람직 하지 않다. 따라서 단계적이고 체계적인 SOA 적용 방안을 제시하여 아키텍처 측면의 장점을 활용 할 수 있도록 하여 현실화된 아 키텍처로서 SOA가 차세대 의료 정보 시스템에 도입되고 활용될 수 있도록 하고자 한다.
