u-City 구축용 플랫폼과 상황인식, 보안
▲ 이상선 핸디소프트 CTO
연재순서
1회. U-City 구축을 위한 u-서비스 플랫폼
2회. BPM/SOA 관점에서의 u-City 구축용 플랫폼
3회. U-City 구축용 플랫폼과 상황인식, 보안
4회. U-City 구축용 플랫폼의 Green IT에의 응용
본 시리즈의 1~2회 차에서 u-City서비스 플랫폼의 중요성과 플랫폼 내에서BPM/SOA의 역할에 대하여 개괄하였다. u-서비스 운영의 효율성 및 효과성을 제고하기 위하여는 BPM이 매우 큰 역할을 하지만 u-서비스가 궁극적으로 발현되는 것은 각종 유비쿼터스 디바이스들을 통해서이다. 따라서 본 회에서는 이러한 디바이스에서 실질적으로 서비스가 운영되기 위해 플랫폼상의 디바이스의 운영단에 위치하는 'u-서비스 제공 시스템' (이하 '서비스제공시스템'이라 함)의 소개와 각종 디바이스간의 효과적인 인터페이스와 서비스의 관리 및 제공 방안을 제시하고자 한다. 또한 현존하는 각종 다양한 디바이스 및 디바이스 운영 소프트웨어(OS)나 소프트웨어의 환경에서 u-City 서비스를 지원할 때의 한계점 및 그 극복방안의 일례를 제시하고자 한다.
1. 서언
「都市(도시)」라는 어원은 사람이 많이 모여 사는 곳을 말하는「都」와 물건을 사고 파는 「市」라는 뜻으로 일반적으로 「都市」란 일정한 영역을 갖고 그 안에서 정치, 경제, 사회, 문화적 활동을 하는 곳을 말한다. 이러한 도시에서의 모든 시/공간적인 환경과 정보통신기술, 컴퓨터기술이 그 속에서 살아가는 사람들이 어우러지는 것이 유비쿼터스 도시(u-City)일 것이다. 다시 말해 u-City는 정보통신 기술과 유비쿼터스 컴퓨터 기술이 결합되어 창조된 고도화된 정보화 도시를 말한다. 이러한 u-City 실현을 위한 SW기반이 u-City 플랫폼이며, u-City 플랫폼을 기반으로 서비스가 구축된 곳에서 사는 거주민 각 개개인은 도처에 구축되어 있는 정보 시스템과 서비스 인프라를 통하여 전혀 의식하지 않은 상태에서도 자연스럽게 u-City 서비스를 제공받을 수 있다.
한편, 이러한 u-City 서비스는 실생활 속에서 접하는 사무기기, 가전기기, 컴퓨터, PDA, 휴대폰 등의 다양한 디바이스를 통해서 제공받게 되며, 다양한 디바이스를 통해 u-서비스를 제공하기 위해서는 서비스에 적합한 SW가 장착되어야 할 것이다.
이때 장착되는 SW를 효과적으로 관리하기 위하여 일종의 부가적인 관리 SW가 필요할 것이다. 마치 Windows의 패치를 도와주는 업데이트 에이전트와 유사하다고 할 수 있다. 이러한 에이전트가 미리 설치되어 최종 서비스 SW 가 잘 운영 될 수 있도록 도움을 주는 것이다.
예를 들어, 특정 지역에 u-City플랫폼을 기반으로 구축된 영역(Zone)이 있다고 하자, 이러한 영역 내에는 이미 특정 서비스를 제공하는 A라는 디바이스가 있고, 사용자가 에이전트가 설치된 B라는 장치를 들고 진입한다. 이때 B에 설치된 에이전트는 A와의 통신으로 해당 영역(Zone)에서 받을 수 있는 특정 서비스 SW를 A를 통해 전달받아 B에 장착하여 서비스를 제공 받을 수 있도록 해주는 역할을 한다. 이러한 장치 간 커뮤니케이션과 복잡한 과정을 거쳐 서비스를 받는 것에 있어서 해당 디바이스 및 그 디바이스에서 운영되는 OS는 매우 다양할 것이다. 디바이스 종류 및 OS가 다양한 상황 하에서는 각각에게 맞는 '에이전트'가 개별적으로 개발될 수 밖에 없을 것이다. 이렇게 된다면 한 개의 서비스를 위해 중복적인 개발과 그에 따른 어려움을 겪을 수 밖에 없게 된다. 결국 현실적으로 다양한 디바이스들의 환경에 맞는 u-City 서비스를 모두 지원하기는 사실상 불가능하다.
따라서 소개하고자 하는 내용은 다양한 디바이스들이 OSGi(Open Service Gateway Initiative) 프레임워크를 지원하고 있기 때문에 OGSi를 채택하여 이러한 문제점을 해결하고자 하는 것이다. 여러 디바이스에 공통된 OSGi 프레임워크 기반 하에 구동되는 OS는 독립적인 번들 형태의 에이전트를 개발하고, 또 개별 디바이스의 기능들은 웹 서비스 형태의 개방형 서비스로 제공되도록 함으로써 문제점으로 기술한 내용을 해결 할 수 있을 것이다. 이렇게 되면 새로운 디바이스가 출시되더라도 신속한 적용이 가능하여 일관성 있고 안정적인 u-City 서비스를 제공할 수 있을 것으로 기대된다. u-City 플랫폼 내에서 디바이스 운영/관리를 위한 디바이스 플랫폼은 [그림1]에서 볼 수 있다.
▲ <그림1> u-City 플랫폼에서의 디바이스 운영/관리
2. OSGi 프레임워크
OSGi(Open Service Gateway Initiative)는 1999년에 썬마이크로시스템즈, IBM, 에릭슨 등에 의해 구성된 개방형 표준 단체로서 로컬 네트워크들과 각종 디바이스에서 관리될 수 있는 서비스들을 네트워크를 통해서 전달하고 배포하는 방안에 대한 개방된 표준을 제정하는 것에 목적을 두고 있다. 여기서는 각종 관련자들(서비스 제공자, 개발자, 소프트웨어 업체, 디바이스 및 설비회사들)을 위해 상호 호환 가능한 서비스를 개발, 배포, 관리하는 개방적이고도 공통된 아키텍처를 제공한다.
▲ <그림2> OSGi 프레임워크 개괄
따라서, OSGi에 호환성을 가지고 설계된 시스템은 다른 기술이 새로 추가되고 통합될 경우에도 원래 시스템의 무결성(Integrity)을 손상시키지 않고도 확장될 수 있고, 표준이 공개되며 누군가에 소유가 귀속되지 않아 로열티 없이 표준의 이용이 자유롭다. OSGi 프레임워크가 탑재된 각종 디바이스에 OSGi표준을 따르는 소프트웨어 모듈(Bundle)을 자유롭게 작성하여 배포할 수 있고, OSGi 표준 호환성을 가지며 Java로 작성된 모든 소프트웨어는 Java의 하드웨어 독립성의 이점을 그대로 활용 할 수 있다.
물론 OSGi표준이 업계표준으로 완전히 자리잡을 것인가에 대하여는 이견도 있지만, 현재 많은 디바이스들이 OSGi표준과 호환성을 이루어가고 있는 현실을 감안하여 표준화를 지향하는 본 연구에서는 표준의 한 예로서 OSGi가 탑재된 디바이스를 기초로 하고 있다.
3. u-City 서비스 제공 시스템의 구성
? 에이전트 번들과 서비스 번들
일반적으로, 디바이스 상에서 서비스를 OSGi 프레임워크 기반으로 실현시키기 위하여는 디바이스의 기능을 구현한 모듈을 개별적으로 '번들'이라는 것으로 구성하게 된다. 소개하고자 하는 것은 디바이스 고유의 기능과 여러 디바이스간의 공통적인 요소 기능을 분리하여 관리/운영하려고 하는 것이다. 이하 각각을 '서비스 번들'및 '에이전트 번들'이라 부르며 번들 분리 운용의 구체적 목적 및 이점은 다음과 같다.
○ 서비스 번들:
① 디바이스의 기능에 충실하게 개발할 수 있도록 함으로써 디바이스 제조 업체와 일반사용자 및 개발자들의 참여형 개발 환경을 제공한다.
② u-City플랫폼의 서비스 번들 개발에 대한 웹 서비스 표준 템플릿을 제공함으로써 u-City플랫폼 상 디바이스 협업이 용이한 환경을 제공한다.
○ 에이전트 번들:
① u-City플랫폼 내 디바이스상 작동되는 기능들(서비스 번들)을 관리한다.
② u-City플랫폼과 디바이스의 통신, 인증, 관리 기능들을 에이전트 번들의 기능으로 묶음으로써 서비스 번들에서의 복잡성과 해당 기능의 중복 개발을 방지한다.
③ u-City플랫폼에서 서비스를 지원하기 위해 디바이스 업체마다 개발되어야 하는 기능을 여러 디바이스에 공통으로 작동될 수 있게 함으로써 u-City플랫폼과의 호환성을 높인다. 이로써 u-City플랫폼에서 각종 디바이스들을 신속하게 지원할 수 있다.
? u-City 서비스 제공 시스템 전체 이미지
u-City 서비스 제공 시스템은 크게 보면 존 서버, 복수의 디바이스(사용자 디바이스, 서비스 디바이스), 그리고 존 서버와 디바이스 간의 통신을 위한 네트워크로 구성된다. 이하에서 각 구성 요소에 대하여 좀더 살펴 보기로 한다.
▲ <그림3> u-City 서비스 제공 시스템의 망 구성도
[그림 3]은 u-City 서비스 제공 시스템의 망 구성도를 나타낸다. 여기서, u-City 서비스 제공 시스템은 존 서버ⓛ, 복수의 디바이스②, 그리고 존 서버ⓛ와 디바이스② 간의 통신을 위한 네트워크③로 구성된다. 존 서버ⓛ는 네트워크③를 통하여 디바이스②와 통신하고 디바이스②에 에이전트 번들을 제공하여 디바이스②의 OS의 타입 및 하드웨어의 타입에 관계없이 u-City 서비스를 제공받을 수 있도록 한다.
디바이스②에는 휴대폰, PDA, UMPC등의 단말기가 포함되며, 존 서버ⓛ로부터 네트워크③를 통하여 에이전트 번들을 다운받아 다양한 u-City 서비스를 제공받을 수 있다. 일례로, 디바이스②가 u-City 플랫폼이 구축되어 있는 곳에 진입할 경우 존 서버ⓛ와 통신하여 우선 에이전트 번들을 다운받아 진입한 곳의 냉/난방 상태에 대한 정보를 받거나 냉/난방기를 제어하는 등의 기능을 수행할 수 있다.
네트워크③는 존 서버ⓛ와 디바이스② 간에 통신이 가능하게 하는 매개체로서 유무선 네트워크를 포함할 수 있다. 무선 네트워크의 경우 블루투스, 무선랜, 지그비(ZigBee), CDMA이동망 등이 포함되며 특별히 제한되지는 않는다.
? 존 서버(zone server)
▲ <그림4> 존 서버의 블록도
존 서버①는 [그림 4] 에 나타낸 것처럼 각 디바이스에 설치될 각종 파일들(에이전트 번들③, 디바이스 제조 업체에서 제공하는 웹 서비스 형태의 서비스 번들④, OSGi 프레임워크 설치 파일 등)을 보존 및 관리하고 있으며, 이 파일들을 전송/설치/관리하는 브로커②로 구성된다.
에이전트 번들③은 어느 디바이스에서나 동일한 기능을 수행할 수 있도록 한 종류의 번들 파일로 존재하며, 궁극적으로는 요청된 디바이스로 전송되어 활성화 된다. 전송된 후에는 디바이스 내 서비스 번들④을 관리하고, 존 서버①의 브로커②로부터 요청이 있을 시 서비스 번들④의 상태를 파악하여 제공한다.
또한 에이전트 번들③은 타 디바이스의 서비스 기능을 호출하는 역할도 한다. 단, 타 디바이스를 호출할 때에는 직접 타 디바이스를 호출하는 것이 아니라 존 서버①내의 브로커②를 통하여 간접적으로 호출하게 된다. 즉, 웹 서비스 방식의 프로토콜을 이용하여 타 디바이스와의 협업 환경을 제공하게 되는 것이다.
서비스 번들④은 디바이스의 기능을 제공하며 제조 업체에서 웹 서비스 형태의 OSGi 프레임워크에 올라가는 번들로 제작된다.
브로커②는 서비스 번들④을 관리하는 기능을 한다. 구체적으로는 존 서버①와 디바이스간의 통신을 통하여 존 서버① 영역 내 디바이스들의 목록을 관리하고, 각 디바이스의 기능(서비스) 목록 및 상태을 관리한다.
? 디바이스의 소프트웨어 아키텍처
▲ <그림5> 디바이스의 소프트웨어 아키텍쳐
[그림 4]는 디바이스([그림 3]의 ②)의 소프트웨어 아키텍처를 도시한 블록도이다. 최하위 레이어로서 하드웨어 및 그 하드웨어에 설치되는 OS③가 위치하고, 최하위단 바로 위에 운영 환경인 자바 환경④이 설치되며, 그 윗단에 OSGi 프레임워크⑤가 설치된다.
그림에서도 알 수 있듯이 에이전트 번들①은 존 서버([그림 4])와 사용자 디바이스([그림 5])상에 공히 존재하게 된다.
4. 서비스 제공/실행 절차
OSGi기반 u-City 서비스 제공 시스템의 서비스 제공 방법은 다음과 같이 단계별로 요약할 수 있다.
① 사용자 디바이스가 u-City 플랫폼 존(zone) 내에 접근하여 존 서버에 에이전트 번들 제공을 요청하는 단계; (☞[그림 6])
② 존 서버가 상기 요청에 따라 에이전트 번들을 디바이스에 제공하고 디바이스가 자기 디바이스 내에 설치하는 단계; (☞[그림 6])
③ 디바이스가 필요로 하는 서비스 번들을 확인하고, 필요한 서비스 번들의 제공을 존 서버에 요청하는 단계; (☞[그림 7])
④ 존 서버가 서비스 번들을 디바이스에 제공하여 설치하는 단계; (☞[그림 6])
⑤ 디바이스가 서비스 목록을 존 서버에 요청하는 단계; (☞[그림 8])
⑥ 존 서버가 이 요청에 응하여 타 서비스 디바이스로부터 서비스 목록을 받아 사용자 디바이스에 전달하는 단계; (☞[그림 8])
⑦ 사용자 디바이스가 수신한 서비스 목록을 참조하여 서비스의 실행을 존 서버에 요청하고, 존 서버는 이 요청에 응하여 서비스 디바이스의 서비스 번들을 호출하여 서비스를 수행하는 단계; (☞[그림 9])
u-City 서비스 제공 시스템에서 서비스가 실행되는 과정의 사례를 블록도를 이용하여 살펴보자.
▲ <그림6> u-City 서비스 제공 시스템에 의한 서비스 실행과정((1),(2))
[그림 6]은 디바이스에 에이전트 번들을 설치하는 과정을 보여주고 있다. 여기에서는 설명을 위해 1개의 존 서버① 및 2개의 디바이스(가),(나)가 있다고 가정한다. 디바이스(가)는 서비스를 제공하는, 예컨대 실내 난방기능을 제공하는 냉/난방기와 같은 '서비스 디바이스'일 수 있고, 디바이스(나)는 상기 냉/난방기가 제공하는 서비스에 대한 정보를 수신할 수 있는 PDA 등의 '사용자 디바이스'일 수 있다.
먼저, (사용자) 디바이스(나)가 u-City 플랫폼 존 내에 접근하여 존 서버①내의 브로커④에 에이전트 번들②의 제공을 요청한다ⓐ. 브로커④는 디바이스(나)로부터의 요청에 따라 에이전트 번들②을 디바이스(나)에 제공하여 디바이스(나) 내에 설치할 수 있도록 한다ⓑ. 이후 설치된 에이전트 번들②은 디바이스(나)에 필요한 서비스 번들③을 확인한다ⓒ.
▲ <그림7> u-City 서비스 제공 시스템에 의한 서비스 실행 과정((3),(4))
다음으로 [그림 7]은 사용자 디바이스에 필요한 서비스 번들의 설치 단계를 나타낸다. 즉, 디바이스(나)에 설치된 에이전트 번들②이 확인한 것처럼, 본 디바이스(나)에 필요한 서비스 번들③의 제공을 브로커④에 요청한다ⓓ.
존 서버①내의 브로커④는 이러한 요청에 응하여 디바이스(나)에 필요한 서비스 번들③을 디바이스(나)에 제공하고 디바이스(나)는 제공된 서비스 번들③을 설치한다ⓔ.
▲ <그림8> u-City 서비스 제공 시스템에 의한 서비스 실행 과정((5),(6))
[그림 8]은 사용자 디바이스와 서비스 디바이스 간의 통신(정보 수수) 과정을 보여준다. 사용자 디바이스(나) 내의 에이전트 번들②은 존 서버①의 바운더리내에서 사용가능한 서비스 목록을 브로커④에 요청한다ⓕ. 브로커④는 이러한 요청에 응하여 존 서버①의 영역 내에서 관리하고 있는, 예컨대 서비스 디바이스(가)가 제공하는 서비스 목록을 디바이스(가)에 요청한다ⓖ. 디바이스(가)는 브로커④의 요청에 응해 자신이 제공 가능한 서비스 목록을 브로커④에 제공한다ⓗ. 브로커④는 서비스 디바이스(가)로부터 수신한 서비스 목록을 사용자 디바이스(나)의 에이전트 번들②에 전달한다ⓘ.
▲ <그림9> u-City 서비스 제공 시스템에 의한 서비스 실행 과정(7)
마지막으로 [그림 9]에서는 서비스 디바이스의 기능(Action)을 활성화 시키는 과정을 보여주고 있다. 사용자 디바이스(나)의 에이전트 번들②은 위에서 수신한 서비스 목록을 참조하여 서비스 디바이스(가)가 제공하는 서비스의 실행을 브로커④에 요청한다ⓙ. 브로커④는 이 요청에 응해 디바이스(가)에 웹 서비스 형태의 서비스 번들을 호출한다ⓚ. 서비스 디바이스(가)는 상기 서비스 번들의 호출에 응하여 호출된 서비스를 수행하게 된다ⓛ.
5. 마무리
본 회에서는 디바이스에서 실질적으로 서비스가 운영되기 위한 요소로 'u-서비스 제공 시스템'과 디바이스의 서비스 운영과 관련된 '에이전트'에 대한 소개를 하였다. 디바이스 마다 개별적으로 개발되어야 하는 에이전트 기능들을 OSGi 프레임워크의 번들로 단일 개발하는 것은 에이전트의 재사용성과 효용성이 높아지는 장점이 있으며, 에이전트의 기능을 통일시키는 것은 디바이스 마다 에이전트의 기능이 동일해져 u-City 플랫폼 존 내의 서비스 제공 구조가 단순해 질 수 있다. 서비스 번들의 기능은 디바이스를 개발한 디바이스 업체에서 웹 서비스 형태의 서비스로 개발하므로 서비스 기능성 면에서는 충실성을 담보할 수 있을 것이다. 이것은 표준화된OSGi 프레임워크를 기반으로한 서비스들이기 때문에 서비스 개발 업체의 참여가 용이하고 디바이스 간 협업이 용이할 뿐 아니라 기존의 서비스의 재사용 및 융복합을 통한 새로운 u-City 서비스를 쉽고 빠르게 적용하는 효과를 기대할 수 있겠다.
※ 본 연구는 지식경제부 및 정보통신연구진흥원의IT핵심기술개발사업의 일환으로 수행하였다.