동기화의 멋진 세상 - SyncML & XML -

동기화의 멋진 세상동기화의 멋진 세상- SyncML & XML -- SyncML & XML -

2002 년 1 월하인숙

정의 - 데이터 동기화

• 데이터동기화란 ?– 네트웍에 존재하는 둘이상의 논리적 장치간 특정 데이터를 일치시켜주는 기술

• Local : 시리얼 포트 , USB, IrDA( 적외선 ), SISC, Fibre Channel 등• Remote : HTTP, TCP/IP, WSP, NAS( 분산 스토리지 표준 ) 등

– 데이터 동기화 필드 활용• PDA OS : Active Sync (MS), Hot Sync(Plam)• DB : DB2 Anywhere(IBM), Oracle Lite(Oracle)• Device 제조사 : DataSync2000( 삼성 )• Web 포탈 : 각종 PIMS Service ( 한미르 , 라이코스 , MSDN 등 )• Enterprise Data : DR 시스템 , 자동 프로그램 배포프로그램

– 동기화 대상이 되는 데이터• PIMS : Mobile Device 의 개인정보로 대표되는 일정 , 주소록 , 메일 , 쪽지등• 핸드폰 /PDA : 각종 설치파일 , 이모티콘등• DB : Table, DML, User 권한

– 백업과의 차이점• 백업 : 한쪽에 존재하는 블록 데이터를 목적지 장치에 일괄 복사 ( 덮어쓰기 미러링 )• 동기화 : 동기화 모드에 따라 원시 데이터와 목적 데이타간의 데이터 일치

- Two-way : 서로간 변경된 데이터를 상대방 데이터에 반영- One-way : 백업과 같은 방식 , 한쪽의 데이터 변경을 다른 한쪽에 반영하는 방식

– 관련기술• 데이터 핸들링기술 (File, DBMS, Memory 등 )• 네트워킹 핸들링 기술 (Socket, Send/Receive Stream, 3(4)-Tier 핸들링 )• 메시지 핸들링 기술 ( 메시지 ENC/DEC)• 장애및 오류제어 기술 ( 분산환경에러 , DB 핸들링에러 – Rollback, re-Try, Log save)

데이터 일치성보장 기술

Mobile 업계의 SyncML 등장• 우선 골치아픈 Enterprise 쪽은 나중에 생각하자 .

– 데이터 동기화 - Mobile Device 에 쏟아지는 관심• 일반 개인 사용자의 PDA 보유율이 높음• 이동성 / 휴대성이 높은 PDA 를 기업에서 활발히 도입 ( 기업용 모바일 오피스 )• 핸드폰이 일정정도 리소스 보유 Device 로 변신

– 다중 장치간 데이터 동기화 요구 폭증• 개인 PC/PDA/ 핸드폰 /Web PIMS 서비스 간 동기화 요구

– 특히 활용도가 높은 PIMS 정보를 중심으로 벤더사 개발툴킷 발표• Active Sync SDK, HotSync Coduit SDK, 심비안 SDK 등• 대부분의 Mobile 벤더가 ‘자사표준’의 스펙으로 구현

– 벤더표준 동기화 문제점 발생• 타사 동기화 엔진과는 호환이 안됨• PIMS 서비스 업체 입장에서는 자사 동기화 엔진을 Mobile Device 에 설치해야 하는 부담• 대부분 Local 네트웍에 의존• PIMS 이외의 어플리케이션에 활용 불가능

– 기존 벤더표준을 토양 위에서 새로운 ‘상호운용성이 보장되는 동기화 표준’ 요구

자사표준 산업계표준

SyncML.org

http://www.syncml.org/

- 1 개의 스펙으로 구성- 데이터 동기화에 대한 기본 규칙 ( 처리 프로세서 ) 을 정의 동기모드별 교환 Command 명시 (7 가지 타입 ) 에러발생시 처리개념 , 인증 처리 명시 Anchor, Changelog, Map Table 개념 명시 라우팅 (Device, DB) 개념 설명- 최소한의 동기화 운영 규칙 상호운영성 확보

- 3 개의 스펙으로 구성 (HTTP, WSP, OBEX)- 프로토콜 스트럭쳐의 세팅값 설명- 프로토콜 스트럭쳐의 처리를 위한 프로세서 설명- 메시지 수신및 송신을 위한 상호운용성 확보

- XML base 3 개의 스펙으로 구성 SyncML Representation, Meta Info, Device Info- SyncML 메시지의 Elements 설명 Command, 컨테이너 /컨테인드 설명 각 엘리먼트 값의 의미 설명 MetaInfo : Data String 을 인식하기 위한 방법을 표준화 , Anchor Device Info : 리소스정보 , DB 메타정보- 동기화 메시지의 상호운용성 확보

PIMS

DB

File

- 동기화 데이터 인식 (고민의 원천 !!!) 을 위해 존재- SyncML 은 기본적으로 PIMS 데이터의 상호운용성을 확보해줌 vCard, vCalandar 등의 외부 스펙을 통해 공통 데이터 ENC/DEC 이외의 다른 데이터 포멧은 <Meta> 엘리먼트를 이용해 기술 (단지 기술일뿐 상대방인 인식 (!) 할수 있다는 보장은 없음 )

SyncML 스펙 Review

Transport Binding

SyncML Protocol

XML Representation

Content

SyncML 스펙카테고리

SyncML 스펙카테고리

SyncML 아키텍쳐 – 상호운용성 점검

<그림 01> SyncML 아키텍쳐

각 모듈 ( 서브시스템 ) 별 역할 (Role) 구분이 안됨 .. ^^;;SyncML Protocol

Transport Binding

XMLRepresentation

메시지 구조 상호운용성 – XML Representation

• SyncML Representation Protocol spec. (3-1)– SyncML 메시지 자체의 구조와 각 요소가 가지는 값의 의미를 설명– SyncML 메시지 구성요소

• <!ELEMENT SyncML (SyncHdr, SyncBody)>• 메시지와 패키지

- 패키지 : 논리적으로 단일한 메시지 단위 (물리적인 용량제한에 상관없는 메시지 전체 )- 메세지 : 물리적인 리소스 제한으로 인하여 패키지를 분할하는 각각의 sub-패키지를 의미 동기화 장치의 리소스 제한 또는 동기화 데이터가 리소스 크기를 넘어설때 발생 장치가 여유로울 경우 하나의 패키지는 하나의 메시지로 Send <Final>로 패키지의 마지막 메세지인지를 판단- 세션 : 전체 동기화가 이루어지기 위해 필요한 모든 패키지 교환의 총합 - 정리하면 : 하나의 세션의 다수의 패키지로 이루어지고 하나의 패키지는 하나이상의 메시지로 존재

• SyncML Header- 동기화 상대방의 Device 정보 (Device 라우팅 정보 ) 를 담고 있음- 인증에 관련된 정보와 SyncML 버전 정보 , Session 및 Message ID 에 대한 정보- <!ELEMENT SyncHdr (VerDTD, VerProto, SessionID, MsgID, Target, Source, RespURI?, NoResp?, Cred?, Meta?)>

• SyncML Body- 각 패키지 마다 다수의 Command 를 담는 컨테이너- <!ELEMENT SyncBody ((Alert | Atomic | Copy | Exec | Get | Map | Put | Results | Search | Sequence | Status | Sync)+, Final?)>


• SyncML Representation Protocol spec. (3-2)– SyncML 메시지 구성요소

• SyncML Command- 데이터 조작의 단위가 되는 Command- 단일 Command 안에는 다수의 Item 이 존재해 다수의 레코드 처리가 가능- 중요 Command

» 데이터 핸들링 : Add, Replace, Delete» 동기화 대상 데이터 라우팅 : Sync» 트랜젝션 처리 : Atomic» 동기화에 필요한 정보 교환 : Alert, Put, Get, Results» Map Table 유지 : Map» 모든 Command 의 처리 결과 : Status

라우팅 정보의 역활

어느 장치 ?SyncHeader/locURI 주소록

어떤 데이터 ?Sync/locURI Pkey:3

어떤레코드 ?Item/locURI

http://dgl.microsoft.com/mgnsrv.dll?1,en,j0312178

http://dgl.microsoft.com/mgnsrv.dll?1,en,j0229737

• SyncML Representation Protocol spec. (3-3)– spec. 예제

<SyncML> <SyncHdr> <VerDTD>1.0</VerDTD> <VerProto>SyncML/1.0</VerProto> <SessionID>1</SessionID> <MsgID>2</MsgID> <Target> <LocURI>IMEI:493005100592800</LocURI> </Target> <Source> <LocURI>http://www.syncml.org/server</LocURI> </Source> </SyncHdr> <SyncBody> <Status> <CmdID>1</CmdID> <MsgRef>2</MsgRef> <CmdRef>0</CmdRef> <Cmd>SyncHdr</Cmd> <TargetRef>http://www.syncml.org/server</TargetRef> <SourceRef>IMEI:493005100592800</SourceRef> <Data>200</Data> </Status>

<Sync> <CmdID>4</CmdID> <Target><LocURI>./dev-contacts</LocURI></Target> <Source><LocURI>./contacts/james_bond</LocURI></Source> <Replace> <CmdID>5</CmdID> <Meta> <Type xmlns='syncml:metinf'>text/x-vcard</type></Meta> <Item> <Target><LocURI>1023</LocURI></Target> <Data><!—vCard 로 포케팅된 데이터 String 이 여기 --></Data> </Item> </Replace> <Add> <CmdID>6</CmdID> <Meta> <Type xmlns='syncml:metinf'>text/x-vcard</type></Meta> <Item> <Source><LocURI>10536681</LocURI></Source> <Data></Data> </Item> </Add></Sync><Final/></SyncBody></SyncML>

우측 계속 ->


• SyncML Meta Information spec. (3-1)– 동기화 메시지가 아닌 동기화에 사용되는 ‘ Data’ 에 관심– 사용 1 : SyncML Message 의 개별 요소로 사용

• Anchor, Last, Next, FreeID, MaxMsgSize 등

– 사용 2 : 해당 ‘ Data’ 를 식별 (!) 할수 있는 공통의 스트럭쳐를 포함• Type, Format, Version, MetaInf, Mark 등• 기본적으로 XML Representation 에 속하는 3 개의 DTD, vCard 등 spec. 에서 언급하는 DTD 를

위한 NameSpace 제공• Data 엘리먼트는 SyncML 입장에서는 PCData 로 인식

- 따라서 Data 엘리먼트를 인식하기 위한 포메팅 식별자가 필요

• 식별 : 해당 Data 의 ENC/DEC 방법을 명시- Type, Format, Version, MetaInf, Mark 등- ENC/DEC 에 사용된 DTD 명시 ( 이를 XML 에서는 NameSpace 라고 부름 )- 결과적으로 SyncML 이 동기화 할때 필요한 다양한 String 포메팅 방법을 제공- vCard, vCalander 와 같은 B2B 에서 검증된 공통의 포메팅 방법이 아니라도 동기화에 사용할 수 있음

• 문제는 해당 데이터의 인식 (!!) 은 식별과는 별계의 문제- 식별은 XML 파서를 통과하면 속성값으로 NameSpace 가 확보됨- 그러나 확보된 NameSpace 를 가지고 Data 를 파싱하는 것은 전적으로 벤더의 몫

» 결과적으로 Data 인식의 상호운용성이 낮아짐» 모든 NameSpace 를 인식할 수 있는 파서를 채용하기에는 Device 의 리소스가 제한» PIMS 의 경우 반드시 vCard 나 vCalrander 와 같은 표준 포메팅를 사용» vCard 등으로 포메팅하기 힘든 경우 자사 포메팅 규칙및 해당 도메인에서 통용되는 NameSpce 사용

권장 (물론 상품카타로그와 같은 기본적인 DTD 표준이 정해지지 않은 상황에서는 한계가 있음 )

• SyncML 이 PIMS 데이터의 한계를 넘기 위해서는 반드시 보강될 필요가 있음


• SyncML Meta Information spec. (3-2)

동기화 데이터는 Item 엘리먼트에 String 으로 캡슐화<Item><Source>…<Data>PIMS 데이터들 </Data></Item>----------------------------------------------------SyncML 메시지 실예<Item> <Source>1</Source> <Data>하팀로코즌솔루션 3460-0772 서울시 서초구… </Data></Item>

하팀 로코즌 솔루션 3460-0772 서울시 서초구 …1 …

데이터Pkey

스트링으로 Formating 한 결과

하팀 , 로코즌 ,솔루션 ,3460-0772, 서울시 서초하팀 / 로코즌 /솔루션 /3460-0772/ 서울시 서초<name>하팀 </name><company name>로코즌</name;하팀 ,companyname;로코즌…

다양한 포멧이 존재( 서로다른 포멧을 적용한

Application 간의 동기화 불가능 )

String 으로 만들때 Formating 에 사용된 메타데이타 (DTD) 식별이 필요String 으로 만들때 Formating 에 사용된 메타데이타 (DTD) 식별이 필요

Meta Information SpecMeta Information Spec 의 메타데이타 식별 기능의 메타데이타 식별 기능


• SyncML Meta Information spec. (3-3)– spec. 예제

MetaInfomation DTD 식별<Alert> … <Item> <Target>..</..> <Meta> <Anchor xmlns='syncml:metinf'> <Last>234</Last> <Next>276</Next> </Anchor> …

DeviceInfomation DTD 식별<Put> … <Meta> <Type xmlns='syncml:metinf'> application/vnd.syncml-devinf+xml</Type> </Meta> <Item> <Source><LocURI>./devinf10</LocURI></Source> <Data> <DevInf xmlns='syncml:devinf'> <Man>Big Factory, Ltd.</Man> …

XML Representation 에 속하는3 개의 Namespace 식별

동기화 데이터 포메팅Namespace 식별

<Replace> <CmdID>5</CmdID> <Meta> <Type xmlns='syncml:metinf'>text/x-vcard</type></Meta> <Item> <Target><LocURI>1023</LocURI></Target> <Data><!—vCard 로 포케팅된 데이터 String 이 여기 --></Data> </Item> </Replace>


• SyncML Device Information spec. (2-1)– 동기화에 참여하는 서로간 장치 정보의 교환

• Man, Mod, OEM, DevType 등- <Man>HIS, Ltd.</Man><FwV>2.1a</FwV><DevTyp>PDA Type A</DevTyp>..

– 데이터 포메팅방식 결정• DataStore, RX, TX 등

- <DataStore>..<CTType>text/x-vard</CTType><VerCT>2.1</VerCT>.. </DataStore>

– 메타데이터 필드 결정• 장치와 리소스 제한에 따라 vCard(DTD) 를 구성하는 모든 엘리먼트를 사용하지 않음• 현실적으로도 각 벤더사마다 서로다른 Table 구조를 가지고 있음

- 비슷하기는 하지만 동일 (!) 한것은 아님 .

Client 가 Server측 장치로 동기화에 사용되는 모메팅 필드를 명시해서 전달

이름 회사명 전화번호 1 전화번호 2 FAX 번호1 …

Server측 스키마Pkey

고객명 직장명 핸드폰번호1

Client측 스키마

각 장치간 메타데이타가

다름 vCard( 데이터 포멧 스키마 ) 필드

전화번호 1 FAX 번호 …


• SyncML Device Information spec. (2-2)– spec. 예제

<DevInf xmlns='syncml:devinf'> <Man>Big Factory, Ltd.</Man> <Mod>4119</Mod> <OEM>Jane's phones</OEM> <FwV>2.0e</FwV> <SwV>2.0</SwV> <HwV>1.22I</HwV> <DevId>1218182THD000001-2</DevId> <DevTyp>phone</DevTyp> <DataStore> <SourceRef>./contacts</SourceRef> <DisplayName>Phonebook</DisplayName> <MaxGUIDSize>32</MaxGUIDSize> <Rx-Pref> <CTType>text/x-vcard </CTType> <VerCT>2.1</VerCT> </Rx-Pref> <Tx-Pref> <CTType>text/x-vcard</CTType> <VerCT>2.1</VerCT> </Tx-Pref> </DataStore>

<CTCap> <CTType>text/x-vcard</CTType> <PropName>BEGIN</PropName> <ValEnum>VCARD</ValEnum> <PropName>END</PropName> <ValEnum>VCARD</ValEnum> <PropName>VERSION</PropName> <ValEnum>2.1</ValEnum> <PropName>N</PropName> <PropName>TEL</PropName> <ParamName>VOICE</ParamName> <ParamName>CELL</ParamName></CTCap><SyncCap> <SyncType>01</SyncType> <SyncType>02</SyncType></SyncCap></DevInf>

우측 계속 ->

SyncML 과 XML• XML 은 SyncML 의 메시지 기술 (Writing) 언어

– XML Representation 카타로그에 들어가는 3 개의 스펙은 XML DTD 로 정의

– SyncML 을 이해하기 위한 XML 기본지식 (2-1)• DTD : 메시지 메타데이타 기술 언어

- <!ELEMENT Add (CmdID, NoResp?, Cred?, Meta?, Item+)>- <!ELEMENT Sync (CmdID, NoResp?, Cred?, Target?, Source?, Meta?, (Add | Atomic | Copy | Delete | Replace | Sequence)*)>

• NameSpace : 둘 이상의 DTD 를 혼용하여 XML doc 의 엘리먼트를 표현하려고 할때 사용

• 코드셋 - XML doc 는 컴퓨터 입장에서는 String 타입- 서로다른 OS/언어간 String 인식 방법 다름

» big/little 엔디안 , String 포멧 방식 등

- 따라서 동일한 방식으로 String 을 Stream 하는 방법이 필요 => 코드셋- Sun VM 의 경우 특정 세팅이 없으면 OS 가 사용하는 코드셋으로 String 스트림화- 메시지의 상호운용성을 보장하기 위해서는 반드시 동기화 장치간 코드셋의

일치화가 필요» 파서 선택시 가장 중요한 것은 다양한 코드셋의 제공 ( 특히 한글 , 한문 , 다양한 특수기호 )» 스트링의 길이가 크게 늘어나지 않는 코드셋을 선택

- 메시지 상호운용성 비교XML CORBA

Object call DOM, SAX CORBA Interface (POA, BOA, ORB)

Metadata defined DTD, XML Schemas, XML Data IDL

MessageENC/DEC

코드셋을 이용한 XML 문서의 스트림 변환

CDR 적용을 통한 스트림 변환

SyncML 과 XML– SyncML 을 이해하기 위한 XML 기본지식 (2-2)

• XML Writing 방법- Clear-text

» 가장 일바적인 Writing 방법 <Tag-name>Tab-Value</Tag-Name>» 장점 : 사람이 인식하기 쉬운 Tag-name 을 그대로 사용 파서를 구현할때 코딩이 쉬움» 단점 : Tag-name 이 XML doc 로 들어가기 때문에 메시지 사이즈가 길어짐 특히 코드셋 (2byte, 3byte) 에 따라 스트림화 했을 경우 사이즈 크게 늘어남» 지원 : Clear-base 파서는 상용 /공개용 풍부

- WBXML» WAP 포럼에서 제정» 무선의 네트웍이 안정적이지 않은 장치에서 사용하기 위해 메시지 사이즈를 작게하는데 초점» Code-page(1byte) 라는 것을 사용해 Namepace 를 변경» Tag-name 과 매칭되는 매칭값 존재

Tag-name 을 표현하는 1byte 에는 .. 각 bit 의 값으로 1byte 이상으로 매칭값을 사용하는지 /속성이 있는지 /Empty 가 아닌지 판단 2D2C3103”1.0”0001 (9byte) => <SyncML><SyncHdr><VerDTD>1.0</VerDTD> (37byte)» 장점 : XML doc 사이즈가 획기적으로 줄어듦 ( 대부분 Tag-name 이 2Byte 내외 ) 어떤 코드셋을 사용하든 Tag-name 의 크기는 동일하게 유지» 단점 : 인식하기 어렵고 Namespace 매칭값 /Tag-name 매칭값이 서로 약속되어 있어야함

데이터

De

vic

e2

데이터

De

vic

e1

메시지 프로세서 상호운용성 – SyncML Protocol• SyncML Sync Protocol spec.

– SyncML 내부 동작을 위해 사용되는 정보 , 인증 , 동기화 방법에 대한 표준

– Sync Protocol spec. 은 설명이 충분히 자세하지 않음 .• Sync Protocol 은 ‘이래야 한다’라는 결과를 말하지 그렇게 되기위해

해야할 과정을 설명하지는 않음 ( 대부분 구현 벤더의 몫 ) – Sync Client / Sync Server

• 최초 동기화 메시지를 보내는 쪽이 Sync Client (Pkg#1)– 동기화 완료된 데이타의 의미

Main DeviceMain Device

입력

메시지 프로세서 상호운용성 – SyncML Protocol• SyncML Sync Protocol spec.

– SyncML 내부 동작을 위해 사용되는 정보 (3-1)• ChangeLog

- ChangeLog 은 데이터의 변경에 대한 사항을 기록- 다수의 장치와 동기화 할때와 단일 장치와 동기화 할때의 고려하여 ChangeLog 를 만들어야 함- 향후 동기화 할때 동기화된 데이타인지 아직 하지 않아서 이번에 동기화 해야할 데이타인지를 판단하는 판단 근거가됨

- 서버 /클라이언트 모두에 존재- 동기화 도메인에서 사용하는 구현 방법

» Dirty bits : 변경된 데이터에 더티비트세팅 , 동기화 이후 Clear N:M 싱크 불가능 , 단일 장치와 동기화 할 경우 사용» Change time : 데이터 변경 시간을 기록 , 동기화 시간 이후 변경된 데이터만을 동기화 컴퓨터의 시간을 변경하는 경우 데이터 정합성 보장 못함» Change Counter : 변경시마다 변경카운터를 1씩 증가 , 동기화 카운터 이후 변경된 데이터만을 동기화 카운터를 얻기 위한 카운터 분배기 /락개념 구현 어려움

- Table 과 ChangeLog 와의 관계 » 방법 1 : Table 의 특정 필드를 ChangeLog 처럼 이용가능 Table 의 구조변경이 필요하다는 단점 Table 의 레코드 삭제시 n:m 싱크의 경우 문제발생 - > 데이터가 삭제되면 ChangeLog 도 삭제되므로 ..» 방법 2 : Table 와 ChangeLog 을 분리하여 구현

UID Data ChangeTime

1 Mis. Ha 20000521T081812Z

2 Mr. Kim 20000521T121300Z

3 'deleted' 20000522T093232Z

4 Mr. Lee 20000522T131212Z

UID Data

1 Mis. Ha

2 Mr. Kim

3 'deleted'

4 Mr. Lee

UID Type Change Counter

1 U 12

2 U 13

3 D 14

4 U 15

Dirty bits Change Time Change Counter

메시지 프로세서 상호운용성 – SyncML Protocol

• SyncML Sync Protocol spec. – SyncML 내부 동작을 위해 사용되는 정보 (3-2)

• Anchor- SyncML 동기화때 처음 오가는 메시지 (Alert Command) 에 Anchor 정보 탑재하여 교환- Anchor 를 쉽게 표현하여 ‘암호 맞추기’

» Last 와 Next 두가지 데이터를 가지는데» Last 는 이번 동기화때 약속했던 ‘암호’를 넣고 Next 는 이번 동기화가 성공하면 다음 동기화때 맞춰볼 암호를 세팅

- Anchor 값 : 숫자를 1씩 증가하거나 UTC Time Formating 으로 표현한 시간- DB 와 Item 단위로 Anchor 를 줄수 있음

» 즉 한번의 동기화로 다수의 DB 를 동기화 할 경우 다수의 Anchor 가 Alert Command 에 탑재되어 교환» Item 단위로 Anchor 를 주는 겂은 높은 레벨의 안정성을 보장하지만 실제 도메인에서 구현한 사례없음 (-

-;;)» Anchor 가 맞지 않을 경우 Slow 싱크 일어남 . 따라서 가장 최초 동기화때 반드시 Slow 싱크가 일어나게 되있음» Two-way 일 경우 내부에 저장될 Anchor 정보는 자신의 것 ( 보내줘야 하니까 ) 과 상대방 (확인해야 하니까 )

• Map Table (2-1)- 동기화할 데이터의 식별자가 동일하지 않을경우 필요- 서버쪽에 존재하여 서버 (GUID) 와 클라이언트 (LUID) 간 식별자를 매핑시켜주는 매핑테이블- PDA 나 핸드폰의 경우 embedded Storge 를 사용할 경우 대부분은 ID 할당은 OS 가 해줌

» 따라서 ID 가 클라이언트와 서버가 동일하다는 보장을 못함 .» Mobile 의 이러한 특성에 의해 Map Table 은 반드시 필요» N:M 싱크를 할경우 Map Table 를 이용하여 Add 와 Replace 를 구별하는데 사용할 수 있음 ( 구현 종속

적 .. --;;)

- Map Table 유지를 위하여 Map Command 존재

( 다음장 운영 시나리오 그림 )

LUID Data

LUID GUID

GUID Data

Map table

DatabaseServerClient Database

Local input

to Server, from Client <Map>…<MapItem><Target><Target><locURI>2001051800320010518003</locURI></Target><Source><Source><locURI>33</locURI>..</Map>

1 Mr. Ha

3 Mr. Lee

2 Mr. Kim

1 20010518001

2 20010518002

3 20010518003

20010518001 Mr.Ha

20010518002 Mr.Kim

20010518003 Mr.Lee

to Server, from Client <Add>…<Item><Source><locURI>22</locURI></Source><Date>Mr. KimMr. Kim</Date></Item></Add>

to Client, from Server <Add>…<Item><Source><Source><locURI>2001051800320010518003</locURI></Source><Date>Mr. LeeMr. Lee</Date></Item></Add>


– SyncML 내부 동작을 위해 사용되는 정보 (3-3)• Map Table (2-2)


LUID Data

1 Mr. Ha

2 Mr. Kim

3 Mr. Lee

GUID Data

20010518001

Mr. Ha

20010518002

Mr. Jo

20010518003

Mr. LeeChange Log information

Database

Server

Client

Database

to Client, from Server <Alert>…<Meta><Anchor xmlns=‘syncML….’><Last> <Last> 20000521T090000Z </Last></Anchor>

GUID Last writer ChangeTime

20010518001 Server 20000511T081812Z

20010518002 Server 20000600T121300Z

20010518003 Server 20000522T093232Z

Owner Anchor <Last> Sync Last Time

Client 14 20000500T000000Z

Server 20000521T090000Z

LUID GUID

1 20010518001

2 20010518002

3 20010518003

Map table

Anchor Information

Owner Anchor <Last> Sync Last Time

Client 14 20000521T093232Z

Server 20000521T090000Z

Anchor Information

①

③

Mr. JoMr. Jo

②

변경

to Server, from Client <Alert>…<Meta><Anchor xmlns=‘syncML….’><Last><Last>1414</Last><Next>15</next></Anchor>

<Replace>…<Item><Target><Target><locURI>22</locURI></Target><Date>Mr. JoMr. Jo</Date></Item></Add>

⑤

⑥


• SyncML Sync Protocol spec. – 동기화 시나리오 (5-1)

동기화 전 / 후

update

Insert

Map table유지

• SyncML Sync Protocol spec. – 동기화 시나리오

• 전체 동기화 Package

동기화할 DB : jamesbond, Device 정보

동기화할 DB : contacts, Device 정보 Package 1 에 대한 응답 정보

Replace LUID(24) “문상철” Package 2 에 대한 응답 정보

add GUID(BBB) “ 박자영” Package 3 에 대한 응답 정보

Map 정보 (52, AAA) Package 4 에 대한 응답 정보

Package 5 에 대한 응답 정보

목표 Device : ‘S’ 인증 정보

목표 Device : ‘C” , 인증 정보

목표 Device : ‘S’

목표 Device : ‘C’

목표 Device : ‘S’

목표 Device : ‘C’

Client (C) Server (S)

Package 1

Package 2

Package 3

Package 4

Package 5

Package 6


• Package #1 (Client -> Server)


<SyncML><SyncHdr> 동기화할 어플리케이션 및 그 어플리케이션 인증에 필요한 정보를 넣는다</SyncHdr><SyncBody><Alert> 동기화 타입과 동기화 할 대상 데이터 (Anchor 교환 ) 기술 </Aler

t><Put> 클라이언트의 서비스와 디바이스 정보를 여기에 담아 보낼 수 있다 .</Put><Get> 서버의 서비스와 디바이스 정보를 요청할 수 있다 . </Get></SyncBody></SyncML>

간략 설명

<SyncML><SyncHdr><VerDTD>1.0</VerDTD> SyncML DTD 의 버전정보 . <VerProto>SyncML/1.0</VerProto> SyncML 프로토콜의 버전<SessionID>1</SessionID> 메세지를 구별해 주는 ID(전송의 단위 )<MsgID>1</MsgID> XML 문서의 ID(전송의 단위 구별 )<Target><LocURI>http://www.syncml.org/sync- 서버 </LocURI></Target>동기화 하려는 상대편 어플리케이션의 URI(여기서는 SyncML 서버 )<Source><LocURI>IMEI:493005100592800</LocURI></Source>자신의 URI(여기서는 SyncML 클라이언트 )<Cred> Target app 에 Source app 가 인증이 요청될 때 보내지는 정보 <Meta><Type xmlns='syncml:metinf'>syncml:auth-basic</Type></Meta> <Data>QnJ1Y2UyOk9oQmVoYXZl</Data>

두가지 방법이 가능 base 64 와 MD5. 여기서는 basic 64 를 사용 .

</Cred></SyncHdr><SyncBody><Alert> 동기화 타입 지정 , 동기화 대상 데이터의 Anchor 를 교환<CmdID>1</CmdID><Data>200</Data> <Item> 동기화할 DB<Target><LocURI>SDB</LocURI></Target><Source><LocURI>CDB</LocURI></Source><Meta><Anchor xmlns='syncml:metinf'><Last>234</Last><Next>276</Next></Anchor> </Meta></Item></Alert><Put> 클라이언트의 서비스와 디바이스 정보를 여기에 담아 보낼 수 있다 . </Put><Get> 서버의 서비스와 디바이스 정보를 요청할 수 있다 . </Get><Final/> </SyncBody></SyncML>

• Package #2 (Server -> Client)


<SyncML><SyncHdr> 서버도 클라이언트에 인증을 받을 필요가 있다면 이 정보를 보내야 한다 .( 양방향 인증 )</SyncHdr><SyncBody> <Status> 각종 상태 정보를 보낸다 . Representation Protocol 스펙

</Status><Results> Get 을 통한 요청을 이곳을 통해 보내준다 . (Device DTD) </Results><Alert> TWO_WAY_ALERT 일 경우 서버도 동기화 할 DB 를 기술한다 .(Anchor) </Alert></SyncBody></SyncML>

간략 설명

<SyncML><SyncHdr> 서버도 클라이언트에 인증을 받을 필요가 있다면<Cred> 이 정보를 보내야 한다 .( 양방향 인증 )<Meta><Type xmlns='syncml:metinf'>syncml:auth-basic</Type></Meta><Data>QnJ1Y2UyOk9oQmVoYXZl</Data> </Cred></SyncHdr><SyncBody> Status 를 보낸다 .<Status> 세션에 대한 인증이 OK<MsgRef>1</MsgRef><CmdRef>0</CmdRef><Cmd>SyncHdr</Cmd><TargetRef>http://www.syncml.org/sync- 서버</TargetRef><SourceRef>IMEI:493005100592800</SourceRef><Data>212</Data> </Status><Status> 두 DB 상의 Anchor 교환이 성공함 .<MsgRef>1</MsgRef><CmdRef>1</CmdRef><Cmd>Alert</Cmd><TargetRef>SDB</TargetRef><SourceRef>CDB</SourceRef><Data>200</Data> <Item><Data><Anchor mlns='syncml:metinf'><Next>276</Next></Anchor></Data> Anchor 를 받은 쪽은 자신의 Anchor 정보를 이처럼 Status 에 넣어 보낸다 .</Item></Status><Results> Get 을 통한 요청을 이곳을 통해 보내준다 . (Device DTD) </Result

s><Alert> 서버도 동기화할 DB 에 대한 Anchor 정보를 보낸다 . <CmdID>1</CmdID><Data>201</Data> <Item><Target><LocURI>CDB</LocURI></Target><Source><LocURI>SDB</LocURI></Source>

<Meta><Anchor xmlns='syncml:metinf'><Last>200005021T081812Z </Last><Next>200005022T093223Z </Next></Anchor></Meta></Item></Alert><Final/> 현 Message 가 이 Package 의 끝임을 명시해

주는 태그</SyncBody></SyncML> </SyncBody></SyncML>

오른쪽 계속 ->

<SyncML><SyncHdr> </SyncHdr><SyncBody><Status> </Status> 패키지 #2 에서 온 정보에 대한 statu

s 를 보낸다 .<Sync> 실제 동기화 할 DB 에 대한 처리 command 를 묶는

역할을 한다 .<Meta> 현 db 의 free memory 와 free record 의 갯수를

기술 </Meta>각종 동기화를 위한 command<Replace> 갱신될 데이터들 </Replace><Add> 추가될 데이터들 </Add><Delete> 삭제될 데이터들 </Delete><Copy> 복사될 데이터들 </Copy><Exec> 실행시킬 어플리케이션 </Exec></Sync></SyncBody></SyncML>

간략 설명<SyncML><SyncHdr> 중략 </SyncHdr><SyncBody><Status> </Status> 패키지 #2 에서 온 정보에 대한 status 를

보낸다 .<Sync> 실제 동기화 할 DB 에 대한 처리 command 를 묶는 역할을

한다 .<CmdID>1</CmdID> 동기화할 DB<Target><LocURI>SDB</LocURI></Target><Source><LocURI>CDB</LocURI></Source><Meta> 현 db 의 free memory 와 free record 의 개수를 기술<Mem xmlns='syncml:metinf'><FreeMem>8100</FreeMem><FreeId>81</FreeId></Mem></Meta><Replace> DB 의 data 를 갱신해 주는 command<CmdID>2</CmdID><Item><Source><LocURI>24</LocURI></Source><Data>문상철</Data></Item></Replace></Sync></SyncBody></SyncML>




<SyncML><SyncHdr> </SyncHdr><SyncBody><Status> </Status> 패키지 #3 에서온정보에 대한 status 를 보낸다 .<Sync> 실제 동기화할 DB 에 대한 처리 Comma

nd 를묶는역할을 한다 .<Meta> 현 db 의 free memory 와 free record 의

갯수를 기술 </Meta> 각종 동기화를 위한 command

<Replace> 갱신될데이터들 </Replace><Add> 추가될데이터들 </Add><Delete> 삭제될데이터들 </Delete><Copy> 복사될데이터들 </Copy><Exec> 실행시킬어플리케이션 </Exec></Sync></SyncBody></SyncML>

간략 설명<SyncML><SyncHdr> </SyncHdr><SyncBody><Status> 각종 status </Status><Sync> 서버쪽 동기화 요청 사항을 위한 command 를 묶는

역할 … 중략 …<Add> 서버측의 add command 는 클라이언트로부터의 맵

정보 전송을 요구한다 .<CmdID>2</CmdID><Item><Source><LocURI>BBB</LocURI></Source><Data> 박자영 </Data></Item></Add></Sync></SyncBody></SyncML>




<SyncML><SyncHdr> </SyncHdr><SyncBody><Status> </Status><Map> LUID 와 GUID 를 매핑 시킨 정보 </Map></SyncBody></SyncML>

간략 설명<SyncML><SyncHdr> </SyncHdr><SyncBody><Status> </Status><Map> 클라이언트의 LUID 와 서버의 GUID 매핑을 위한

정보를 전송한다 .<CmdID>1</CmdID><Target><LocURI>SDB</LocURI></Target><Source><LocURI>CDB</LocURI></Source><MapItem><Target><LocURI>BBB</LocURI></Target> 임시 GUID<Source><LocURI>52</LocURI></Source> LUID</MapItem></Map></SyncBody></SyncML>




<SyncML><SyncHdr> </SyncHdr><SyncBody><Status> Map command 에 대한응답코드 </Sta

tus></SyncBody></SyncML>

간략 설명<SyncML><SyncHdr> </SyncHdr><SyncBody><Status> Map 에 대한 Status 를 보낸다 .<MsgRef>3</MsgRef><CmdRef>1</CmdRef><Cmd>Map</

Cmd><TargetRef>SDB</TargetRef><SourceRef>CDB</SourceRef><Data>200</Data></Status></SyncBody>

• SyncML Sync Protocol spec. – 동기화 타입

• Two-Way Sync- 자신의 데이터 변경을 상대방에게 적용하는 타입 - 클라이언트 , 서버가 서로의 데이터 사항을 메시지로 전송- 충돌 문제 발생

» 서버와 클라이언트가 동일한 데이터의 추가 / 변경을 요구하는 경우

» 정책 설정을 통한 ‘ Win 정책’ 필요- 가장 일반적이며 다른 동기화 타입 (One-Way from ** Only) 은 Two-way Sync 의 서브셋

• Slow Sync- Two-Way Sync 시 Achor 불일치 , 기타 내부정보의 손상으로 동기화 초기화가 필요할때 발생- 클라이언트의 모든 정보를 서버쪽에서 ‘ Field-by-Field’ 검토하여 동일하지 않은 부분을 검토

» 따라서 엄청난 시간과 자원이 소모

- 오류시 일어나는 다른 동기화 타입 (Refresh Sync From ** Only) 은 Slow Sync 의 서브셋

• One-Way Sync from Server/Client Only- 단방향 동기화

• Refresh Sync from Server/Client Only- One-Way Sync from Server/Client Only 시 Achor 불일치 , 기타 내부정보의 손상으로 동기화 초기화가 필요할때 발생

• Server Alerted Sync- 7 가지 동기화 타입중 Server 가 Client 에게 최초 메시지를 보내는 동기화 타입- 서버가 클라이언트에게 ‘어떤 정보’를 알람- 사용예 서버가 자신과 관련된 모든 클라이언트에게 특정 동기화 타입으로 동기화 하자고 할때


• SyncML Sync Protocol spec. – 동기화 타입에 따른 교환 Command 와 데이타


SyncML Impl.SyncML Impl.

RDBMS

Server


Client 1


Client 2

Two-way 싱크 (HTTP)

DesktopPC

임베디드DB

PDA 핸드폰

RMS

Two-way 싱크 (TCP/IP.. 아직 스펙은 없지만 ^^;;)

SyncML 구현예 – 시스템 구성

SyncML 구현예 – 소프트웨어 구성

동기화의 멋진 세상 - SyncML & XML -

Documents

Transcript of 동기화의 멋진 세상 - SyncML & XML -