무선 인터넷 서비스가 활성화 되고 무선 단말기가 널리 보급됨에 따라 무선 단말기의 데이터와 PC 혹은 회사 내의 서버와의 데이터 동기화 문제가 이슈로 떠오르고 있다. 무선 단말기의 운영 플랫폼이 다양하고 네트워크 프로토콜이 다양함에 따라 광범위한 이기종 간의 데이터 동기화를 위해서는 표준화가 필요하다. SyncML은 이러한 데이터 동기화의 표준으로서 산업체에 의해 주도되어 발전되고 있다. 본 고에서는 SyncML 의 스펙인 표현 프로토콜, 동기화 프로토콜, 트랜스포트 바인딩에 대해 기술하고 SyncML개발 도구인 SyncML RTK을 소개한다. ▧
I. 서 론
무선 인터넷 기술이 발전하고 PDA, PocketPC, PDA폰 같은 무선 단말기를 이용한 무선 인터넷 서비스가 활성화 됨에 따라 사용자는 회사나 가정에 있는 데이터를 장소와 시간에 구애 받지 않고 이용할 수 있는 이동 컴퓨팅 시대가 도래하였다.
이동 사용자는 네트워크에 항상 연결되어 있는 것은 아니기 때문에 네트워크에 저장된 데이터를 항상 이용할 수 있는 것은 아니다. 그래서 사용자는 네트워크로부터 데이터를 검색하고 그것을 이동 단말기에 저장한 후 그 데이터를 접근하고 처리하게 된다. 사용자는 정기적으로 네트워크에 재접속하여 이동 단말기에서 변경된 데이터를 네트워크 저장소에 전송하고 네트워크 저장소에 갱신된 데이터를 전송 받아 동기화를 유지한다.
그런데 현재 각 플랫폼에 맞게 독립적으로 개발된 응용 서비스들은 제한된 타입의 데이터 저장소로부터 몇몇의 제한된 디바이스하고만 상호 데이터 동기화를 유지하고 있다. 각각의 프로토콜은 단지 몇 개의 트랜스포트하고만 동작하고 몇 개의 디바이스에서만 구현되었다. 대부분의 동기화 응용 서비스들은 네트워크상에서 서로 다른 통신 프로토콜을 사용한다.
이와 같이 상호 호환되지 않는 동기화 기술은 사용자의 작업, 디바이스 생산자, 서비스 제공업자, 응용 개발자들을 복잡하게 한다. 공통된 데이터 동기화 기술의 부재는 이동 디바이스 사용의 성장을 저해하고 사용자의 데이터 접근과 이동 데이터 서비스의 전달을 제한한다.
이러한 문제점을 극복하기 위하여 데이터 동기화 표준 작업이 진행되고 있는데 SyncML이 바로 그것이다. 본 고에서는 SyncML을 소개하고 표준화 진행 상황과 개발자가 이를 활용할 수 있는 방법 등을 기술한다.
II. SyncML의 개요
1. SyncML의 탄생 배경
이동 컴퓨팅 환경이 도래하고 무선 단말기들이 널리 사용됨에 따라 사용자들은 장소나 시간에 구애 받지 않고 정보를 이용할 수 있게 되었다. 사용자는 무선 단말기에서 어플리케이션이나 정보를 활용한 후 갱신된 데이터는 사무실이나 집에 있는 컴퓨터와 동기화를 수행해 일치된 데이터 정보를 이용하거나 네트워크에 연결된 데이터를 전송 받아 이용한다. 그런데 무선 단말기의 운영 플랫폼과 개발 도구가 다양하고 통신 프로토콜 또한 다양하기 때문에 무선 단말기의 데이터와 네트워크에 연결된 데이터와의 동기화는 제한된 단말기와 제한된 데이터에서만 이루어지고 있다. 따라서 이들 데이터 간의 동기화에 대한 표준화 필요성이 대두되었고 이동 단말기 제조 업체 중심으로 공통된 데이터 동기화 프로토콜에 대한 산업계 표준을 제정하기에 이르렀는데 그 결과물이 SyncML이다.
2. 표준화 활동 단체
SyncML 표준화 작업은 Ericsson, IBM, Lotus, Motorola, Nokia, Palm Inc., Psion, Starfish Software 회사들에 의해 주도되고 있으며 전세계적으로 660여 회사들이 SyncML을 지원하겠다고 발표하였다. 그리고 국내에서도 20여 업체가 SyncML을 이용한 제품 및 기술 개발을 진행하고 있다.
위 업체들은 SyncML아키텍처 명세, SyncML 표현 프로토콜 및 동기화 프로토콜의 명세, 공용 트랜스포트 프로토콜과의 바인딩, 공용 프로그래밍 언어를 위한 인터페이스, 공개된 프로토콜 구현 프로토타입 개발 등의 작업을 하고 있다.
3. 표준화 명세 목록
공식적으로 2000년 12월에 SyncML 1.0 버전이 출시되었고 2001년 5월에는 SyncML 1.0.1 버전이 출시되었다. 본 고에서는 SyncML1.0.1을 기반으로 기술한다. 발표된 명세 문서들은 <표 1>과 같다.
4. SyncML 프레임워크
SyncML은 개념적인 데이터 동기화 프레임워크와 데이터 동기화 프로토콜을 정의한다. (그림 1)에서 점선 내부가 프레임워크 영역이다.
프레임워크는 SyncML 표현 프로토콜과 개념적인 SyncML Adapter, SyncML Interface로 이루어져 있다. “App A”와 “App B”는 데이터 동기화를 제공하는 서비스들이다. 서비스와 디바이스는 HTTP, WSP, OBEX 와 같은 네트워크 트랜스포트를 통해 연결되어 있다. Sync Engine은 데이터 동기화 프로토콜을 구현하고 응용 서비스가 이를 이용한다. Sync Server Agent는 네트워크로 접근하는 Sync Engine을 관리하고 클라이언트 어플리케이션과 데이터 동기화를 통신한다. Sync Server Agent의 이러한 기능들은 SyncML I/F를 호출함으로써 수행된다. SyncML I/F는 SyncML Adapter에 대한 API이고 SyncML Adapter는 originator와 recipient가 SyncML 형식을 갖춘 객체들을 전달하기 위하여 이용하는 개념적인 프로세스이다. SyncML Client Agent는 SyncML I/F를 통해 App B가 네트워크와 SyncML Adapter에 접근할 수 있도록 한다.
III. SyncML 스펙 분석
1. 표현 프로토콜
표현 프로토콜이란 데이터 동기화에 참여한 엔터티들간에 전달되는 잘 정의된(well-defined) 메시지를 말한다. 이 메시지는 산업계 표준인 XML 문서로 표현되는데 반드시 검증된 문서일 필요는 없다. 표현 프로토콜은 “blind push” 명령 구조에 기반한 동기화 모델뿐만 아니라 요청/응답에 기반한 동기화 모델도 지원한다. 이 때 “blind push” 모델은 WSP에 바인딩하여 구현할 수 있고, 요청/응답 모델은 HTTP에 바인딩하여 구현할 수 있다.
표현 프로토콜은 인터넷 표준인 MIME 컨텐츠 타입으로 사용될 수 있는데 SyncML 메시지에 대한 XML 표현인 application/vnd.SyncML+xml과 WBXML 바이너리 표현인 application/ vnd.SyncML+wbxml이 있다.
가. SyncML메시지
SyncML 메시지는 “SyncML”이라는 root 엘리먼트 타입을 갖고 있으며 이 엘리먼트 타입은 SyncML 메시지에 대한 부모 컨테이너로 작용한다. SyncML 메시지는 “SyncHdr”이라는 엘리먼트 타입의 헤더와 “SyncBody”라는 엘리먼트 타입의 바디로 구성되어 있다. 헤더는 SyncML 메시지의 버전 정보와 라우팅 정보를 지정하고 바디는 하나 이상의 SyncML 커맨드들에 대한 컨테이너이다. 다음은 간단한 SyncML 메시지의 예이다.
<SyncML xmlns=‘SYNCML:SYNCML1.0’>
<SyncHdr>
<VerDTD>1.0</VerDTD>
<Source>
<LocURI>http://www.datasync.org/servlet/syncit</LocURI>
</Source>
</SyncHdr>
<SyncBody>
<Get>
<CmdID>0363</CmdID>
</Get>
</SyncBody>
</SyncML>
나. SyncML 패키지
패키지는 하나 이상의 SyncML 메시지를 포함하는데 동기화의 기본 단위가 된다. (그림 2)는 3개의 패키지를 나타내고 있다.
다. 커맨드
SyncML 커맨드는 개개의 엘리먼트 타입으로 지정되고 동기화 데이터나 메타 정보를 포함해서 SyncML 커맨드의 명세를 기술하는 다른 엘리먼트 타입에 대한 컨테이너로 작용한다. SyncML 커맨드는 요청 커맨드와 응답 커맨드로 구성되어 있다. 요청 커맨드에는 Add, Alert, Atomic, Copy, Delete, Exec, Get, Map, Put, Replace, Search, Sequence, Sync 등이 있고 응답 커맨드는 Status, Results가 있다. 커맨드 엘리먼트는 <표 2>와 같다.
동기화할 상대와 최초로 교환하는 커멘드
투웨이, 원웨이 등의 동기화 방식의 교환, Anchor 정보 교환
트랜젝션 처리의 영역을 설정하는 커맨드
Atomic 은 Atomic 에 포함된 커맨드 중 하나의 커맨드라도 실패한다면 이미 실행된 커맨드를 Rollback 시킴
순차적인 처리를 위한 커맨드
Add, Delete, Replace 등의 커맨드를 Sync 와 함께 사용하여 동기화 대상에 대한 정보 획득
데이터를 추가하라는 커맨드
데이터를 복사하라는 커맨드
데이터를 삭제하라는 커맨드
상대 장치에 데이터가 존재하는 경우 수정 처리, 데이터가 없는 경우 추가 처리를 요구
상대편 장치의 정보를 보내 달라는 커맨드
자신의 장치 정보를 담는 커맨드
서버와 클라이언트 장치가 서로 다른 데이터 식별 ID를 이용하는 경우 서버에서 맵 테이블을 만들어서 서로의 ID를 일치시킴
Search, get 커맨드의 결과값을 반환하는데 이용
상대편 데이터 베이스를 검색하는데 필요한 정보를 담는 커맨드
상대편 장치의 특정 프로세스를 실행시키는 커맨드
요청 처리를 하고 결과를 반환하는 커맨드
라. Mark-up 언어 기술
SyncML 문서를 표현하기 위한 Mark-up 엘리먼트는 공용 엘리먼트, 메시지 컨테이너 엘리먼트, 데이터 기술 엘리먼트로 구성되어 있다. 이 엘리먼트 타입은 사용 목적, 부모 엘리먼트, 컨텐츠나 사용에 있어서의 제약, 컨텐츠 모델 그리고 사용 예를 보임으로써 정의된다.
1) 공용 엘리먼트
공용 엘리먼트 타입은 다른 수많은 SyncML엘리먼트 타입에 의해 사용되는데 <표 3>과 같다.
2) 메시지 컨테이너 엘리먼트
메시지 컨테이너 엘리먼트에는 SyncML 메시지에 대한 컨테이너를 지정하는 SyncML과 SyncML메시지 내에 있는 정정 또는 라우팅 정보에 대한 컨테이너를 지정하는 SyncHdr, SyncML 메시지의 바디나 컨텐츠에 대한 컨테이너를 지정하는 SyncBody가 있다.
3) 데이터 기술 엘리먼트
데이터 기술 엘리먼트는 분리된 SyncML 데이터를 지정하는 Data, 아이템 데이터에 대한 컨테이너를 지정하는 Item, 부모 엘리먼트 타입에 대한 메타 정보를 지정하는 Meta가 있다.
마. 디바이스 정보 DTD
성공적인 데이터 동기화를 위해서는 사용 가능한 메모리, 아이템 식별자, 지원되는 로컬 데이터베이스와 같은 디바이스 정보 교환이 필수적이다. 디바이스 정보 DTD는 데이터 동기화 클라이언트 디바이스의 용량에 대한 정보를 표현하는 데 사용되는 XML 문서 타입을 정의한다.
디바이스 정보 문서는 잘 정의된 문서이나 검증된 문서일 필요는 없으며 XML 네임스페이스를 사용한다. 네임 스페이스의 URI는 http://www.syncml.org/docs/defint_v101-20010530.dtd 이다.
SyncML 디바이스 정보 문서는 MIME 컨텐츠 타입으로 구별할 수 있는데 “application/vnd. SyncML-devinf+xml”과 “application/vnd.SyncML-devinf+wbxml” 두 가지 컨텐츠 타입이 있다.
디바이스 정보 DTD에서 정의한 엘리먼트는 CTCap, CTType, DataStore, DataType, DevID, DevInf, DevTyp, DisplayName, DSMem, Ext, FwV, HwV, Man, MaxGUIDSize, MaxID, MaxMem, Mod, OEM, ParamName, PropName, Rx, Rx-Pref, SharedMem, Size, SourceRef, SwV, SyncCap, SyncType, Tx, Tx-Pref, ValEnum, VerCT, VerDTD, XNam, XVal 등이 있다.
바. 메타 정보 DTD
메타 정보란 표현, 상태, 타입, 객체의 컨텐츠 또는 속성에 대한 파라미터 혹은 속성을 말하는데 SyncML 표현 프로토콜에서 사용된다. 메타 정보 DTD에 있는 엘리먼트 타입은 http:// www.SyncML.org/docs/SyncML_metainf_v101_20010530.dtd URI와 관련된 네임스페이스 내에서 정의된다.
메타 정보 DTD에서 정의한 엘리먼트는 Anchor, EMI, Format, FreeID, FreeMem, Last, Mark, MaxMsgSize, Mem, MetInf, Next, MextNonce, ShareMem, Size, Type 등이 있다.
2. 동기화 프로토콜
가. 변경 로그 정보
동기화 프로토콜은 서버와 클라이언트가 동기화 과정 중에 발생한 변경을 추적하도록 요구한다. 즉 클라이언트와 서버는 데이터베이스의 데이터와 관련된 변경들에 대한 변경 로그 정보를 관리할 책임이 있다. 변경 타입은 치환, 첨가, 삭제 등이 될 수 있다. 동기화 프로토콜은 변경 로그 정보가 관리되는 포맷에 대해서는 명세하지 않는다.
나. 동기화 앵커
동기화 앵커는 동기화 이벤트를 나타내기 위한 String 값으로 date/time 형식으로 이루어지며 Last와 Next 두 가지가 있다. Last는 송신 기기의 마지막 동기화가 일어났던 시간, Next는 송신 기기의 현재 동기화 시간을 나타낸다. 서버와 클라이언트는 서로 Alert 명령의 메타 정보 내에 앵커 정보를 교환한다. 서버는 반드시 수신한 클라이언트의 Next 동기화 앵커를 저장하여야 하고 수신 기기는 Alert 명령에 대한 Status에 Next 동기화 앵커를 반송하여야 한다. 동기화 앵커를 받은 디바이스는 이전에 보관한 Next 동기화 시간과 현재 받은 상대 기기의 Last 동기화 시간을 비교하여 동일하면 동기화가 된 걸로 간주하고 다르면 동기화를 요구할 수 있다.
다. 데이터 아이템의 식별자 매핑
동기화 프로토콜은 클라이언트와 서버가 데이터베이스에 있는 데이터에 대해서 자신의 식별자를 갖고 있다는 원칙에 바탕을 두고 있다. 그런데 이 식별자들이 서로 일치하지 않을 수 있기 때문에 서버는 아이템들에 대해서 매핑 테이블을 관리하고 있어야 한다. 하지만 프로토콜에서는 매핑 테이블의 구조나 운영 방식에 대해서 기술하고 있지 않다. 클라이언트에 있는 데이터 식별자를 LUCID라고 하고 서버에 있는 데이터 식별자를 GUID라고 한다.
(그림 3)은 동기화가 이루어진 이후의 식별자 매핑 테이블의 예를 보이고 있다.
라. 충돌 해결
클라이언트와 서버가 동일한 아이템을 변경할 때 충돌이 발생한다. 일반적으로 충돌 해결은 서버에서 이루어지지만 클라이언트에서 충돌 해결이 되는 것을 배제하지는 않는다. SyncML 프로토콜에서는 충돌 해결 방법 자체에 대해서는 명시하지 않고 있으며 단지 SyncML 표현 프로토콜이 충돌 해결의 정책에 대한 상태 코드를 제공한다.
마. 동기화 타입
SyncML은 7가지의 동기화 타입을 정의하는데 이는 <표 4>에 나타나 있다.
바. 동기화 과정
동기화 과정이 수행되기 이전에 동기화 초기화가 필요하다. 동기화 초기화는 첫째 SyncML 수준에서 클라이언트와 서버간에 인증을 처리하고, 둘째 어떤 데이터베이스가 동기화 할 것이며 프로토콜 타입은 무엇인지 알려주고, 셋째 서비스와 디바이스 용량에 대한 정보를 교환할 수 있도록 한다. 첫째와 둘째는 SyncML 표현 프로토콜의 Alert 커맨드를 사용하여 수행된다. 셋째는 SyncML 표현 프로토콜의 Put, Get 커맨드와 디바이스 정보 DTD를 사용해서 수행된다.
(그림 4)는 Two-way Sync 동기화 타입이 어떻게 동기화를 하는지 시나리오를 보여 준다.
클라이언트는 변경된 정보를 먼저 보내는 디바이스가 된다. 클라이언트로부터 전송 받은 정보에 따라 서버는 동기화 요청을 처리하고 클라이언트로부터 전송 받은 데이터는 서버에 있는 데이터와 비교되고 통합된다. 그리고 나서 서버는 변경된 데이터를 클라이언트로 전송하며 클라이언트는 서버로부터 전송 받은 데이터로 자신의 데이터베이스를 갱신한다.
3. 트랜스포트 바인딩
트랜스포트 바인딩은 SyncML 메시지를 통신 프로토콜과 바인딩하여 전송하기 위한 요구 조건을 기술한 것으로 HTTP 바인딩, WSP 바인딩, OBEX 바인딩이 포함되어 있다.
가. HTTP 바인딩
HTTP 프로토콜은 HTTP 어플리케이션을 지원하는 두 네트워크 컴퓨터 사이에 요청/응답 형태의 통신을 정의하는 것으로 WWW 의 프로토콜로 사용되고 있으며 무선 SyncML 클라이언트와 서버를 연결하는 가장 이상적인 프로토콜이다. 일반적으로 요청을 하는 쪽이 HTTP 클라이언트가 되고 요청을 받는 쪽이 HTTP 서버가 되는데 HTTP 서버가 HTTP 요청을 먼저 하는 “push” 기술에 대한 표준이 나오고 있지만 현재 스펙에는 “push” 기술은 포함되어 있지 않다.
HTTP 바인딩은 HTTP를 통해 SyncML을 통신하기 위한 요구사항을 정의하고 있다. SyncML은 MIME 미디어 타입으로 등록된다.
1) 연결 요구 조건
HTTP는 일반적으로 TCP 상에서 연결되지만 반드시 TCP를 통한 연결일 필요는 없다. 접속 포트는 80번이 기본적으로 사용되지만 다른 번호를 사용할 수 있다. HTTP 1.1 이상에서 지속적인 연결을 지원하지만 SyncML클라이언트는 HTTP 요청을 할 때 매번 재접속하여야 한다. 연결 해제도 SyncML클라이언트에게 책임이 있다. 서버가 타입아웃이 되는 경우에는 SyncML 클라이언트가 새로운 HTTP 세션을 확보해야 한다.
2) SyncML 메시지 교환
HTTP 연결이 확보되면 SyncML메시지가 전송될 수 있다. HTTP 요청에서 SyncML 메시지를 전송하기 위해 POST 메쏘드가 사용된다. HTTP 요청의 바디는 항상 SyncML메시지를 포함하고 있어야 하고 바디의 컨텐츠 타입은 적절한 SyncML 메시지 컨텐츠 타입이어야 한다.
3) 전송 커맨드
POST 메쏘드는 반드시 사용해야 하고 OPTIONS, GET, HEAD, PUT, DELETE, TRACE, CONNECT 메쏘드는 선택적으로 사용할 수 있다. 헤더 중에서 Cache-Control 헤더는 반드시 사용해야 하고 Connection, Date, Pragma, Trailer, Transfer-Encoding, Via, Warning 헤더는 선택적으로 사용할 수 있다. 이 외에 요청 헤더와 응답 헤더에서 반드시 지원해야 할 헤더와 선택적으로 지원해야 할 헤더들을 정의하고 있다.
다음은 간단한 HTTP 요청의 예이다.
POST ./servlet/syncit HTTP/1.1
HOST: http://www.syncml.org.host.com
Accept: application/vnd.syncml-xml
Accept-Charset: utf-8
Accept-Encoding: chunked
Accept-Language: en-US
Authorization: Basic QWxhZGRobjpvcGVuIHNlc2FtZQ==
Content-Type: application/vnd.syncml-xml; charset=”utf-8”
User-Agent: Foo Bar Sync Products v3.4
Cache-Control: no-store
Transfer-Encoding:chunked
BD
<SyncML>
<SyncHdr>
<VerDTD>1.0</VerDTD>
<LocURI>http://www.datasync.org/servlet/syncit</LocURI>
</SynHdr>
<SyncBody>
<Sync>
<CmdID>1234</CmdID>
</Sync>
</SyncBody>
</SyncML>
나. WSP 바인딩
WAP 아키텍처에서 세션 계층 프로토콜 패밀리를 WSP(Wireless Session Protocol)라고 한다. WSP 두 개의 세션 서비스에 상위 레벨 어플리케이션 계층을 제공하는데 하나는 연결 모드 서비스이고 다른 하나는 비연결 모드 서비스이다.
WSP 바인딩 스펙에는 한 패키지에 여러 메시지를 전송하는 방법, MIME 헤더 타입 요구 조건, 연결 지향 세션, 비연결 서비스, 서버에서 클라이언트로 데이터를 push하기, SCR(Static Conformance Requirement) 등이 기술되어 있다.
다. OBEX 바인딩
OBEX는 객체를 교환하기 위한 프로토콜이다. 처음엔 적외선 통신을 위해 고안되었으나 Bluetooth에 의해 채택되었으며 RS232, USB 그리고 WAP에서 사용된다. OBEX 는 세션 기반 프로토콜이고 한 세션에서 여러 요청/응답 교환을 허용한다. 세션이 확보되면 데이터는 PUT 요청을 통해서 전송된다.
OBEX 바인딩 스펙에는 SyncML을 OBEX에 바인딩하기 위한 요구 사항을 정의하는데 SyncML 클라이언트와 서버가 OBEX 연산의 지원 여부, 연결 절차, MIME 헤더 타입 조건, OBEX CONNECT 요청의 필드 조건, OBEX 연결을 통한 SyncML 데이터 교환, OBEX 접속 단절 등에 대한 요구 사항이 기술되어 있다.
IV. SyncML 개발 도구
SyncML 스펙을 구현하기 위한 한 참조 모델로서 SyncML.org에서 제공하는 SyncML RTK(Reference ToolKit) 이 있다. RTK는 Window 32-bit 플랫폼, Palm OS 플랫폼을 지원하고 있으며, 향후 EPOC와 Linux 플랫폼을 지원할 예정이다. GNU Mingw32, Microsoft Visual Studio C++, Metrowerks(Paml OS 상에서) 환경에서 테스트되었고 C 언어로 구현되었다. (그림 5)는 RTK의 구조를 나타낸다.
SyncML Core는 어플리케이션에 제공하는 SyncML API를 구현한다. 이 코어 계층은 플랫폼 독립적이며 SyncML 관리자, SyncML 커맨드 구축자, SyncML 커맨드 전파자를 포함한다.
그 밑에 있는 플랫폼 의존적인 플러그인 계층은 코어 모듈에 기능을 제공하기 위해 사용된다. 세번째 계층인 라이브러리 계층은 메모리 할당이나 스트링 처리 같은 플랫폼에 의존적인 라이브러리 함수들을 캡슐화 하고 있다.
SyncML API에 의해 정의된 함수를 도와주기 위해서 어플리케이션은 콜백 함수들을 구현해 주어야 한다. 이 콜백 함수들은 입력되는 동기화 커맨드를 처리하는데 SyncML 문서를 파싱할 때 SyncML RTK에 의해서 호출된다.
통신 함수들은 SyncML의 영역이 아니다. 하지만 SyncML 지원 소프트웨어를 더 쉽게 개발하는데 있어서 HTTP, OBEX, WSP 프로토콜을 지원하는 통신 툴킷은 SyncML RTK를 사용하는 데 도움을 준다.
V. 결 론
본 고에서는 XML에 기반한 동기화 표준인 SyncML의 표준화 동향에 대해 정리하였다. SyncML 의 탄생 배경을 설명하였고 SyncML스펙인 표현 프로토콜, 동기화 프로토콜, 트랜스포트 바인딩과 SyncML개발 도구인 SyncML RTK에 대해 설명하였다.
동기화 표준이 제정됨에 따라 독립적으로 실행되던 응용 프로그램들이 상호 자료를 교환할 수 있게 되고 어느 네트워크에 연결된 데이터라도 동기화 할 수 있는 기반이 닦임에 따라 자료의 활용도를 높일 수 있게 되었고 사용자에게 편리하게 정보를 제공할 수 있게 되었다. 국내에서는 몇몇 업체를 중심으로 SyncML 개발이 활발히 이루어지고 있으며 SyncFest 를 통과한 업체들도 등장하고 있다.
SyncML 이 널리 사용되고 사용자들에게 더 많은 혜택을 주기 위해서는 SyncML 을 이용한 응용 서비스와 응용 프로그램 개발이 필요하다. 특히 SyncML은 무선 인터넷 상의 플랫폼에서 무선 인터넷이 갖는 제약 사항을 어느 정도 보완할 수 있기 때문에 무선 인터넷 서비스 분야에서 적극적으로 활용되기를 기대해 본다.
<참 고 문 헌>
[1] SyncML Representation Protocol, Version 1.0.1, www.syncml.org, 2001.
[2] SyncML HTTP Binding, Version 1.0.1, www.syncml.org, 2001.
[3] SyncML OBEX Binding, www.syncml.org, 2001.
[4] SyncML over WSP, Version 1.0.1, www.syncml.org, 2001.
[5] SyncML Device Information DTD, www.syncml.org, 2001.
[6] SyncML Meta-Information DTD Version 1.0.1, www.syncml.org, 2001.
[7] SyncML white paper, www.syncml.org, 2001.
[8] SyncML Reference Toolkit manual, www.syncml.org, 2001.
이상은 이상윤 님의 논문을 캡쳐 하였습니다.