동기화의 멋진 세상 - 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 자사표준 산업계표준

동기화 데이터 인식(고민의 원천!!!)을 위해 존재 • SyncML은 기본적으로 PIMS 데이터의 상호운용성을 확보해줌 • vCard, vCalandar등의 외부 스펙을 통해 공통 데이터 ENC/DEC • 이외의 다른 데이터 포멧은 <Meta> 엘리먼트를 이용해 기술 • (단지 기술일뿐 상대방인 인식(!) 할수 있다는 보장은 없음) DB File PIMS • XML base 3개의 스펙으로 구성 • SyncML Representation, Meta Info, Device Info • SyncML 메시지의 Elements 설명 • Command, 컨테이너/컨테인드 설명 • 각 엘리먼트 값의 의미 설명 • MetaInfo : Data String을 인식하기 위한 방법을 표준화, Anchor • Device Info : 리소스정보, DB 메타정보 • - 동기화 메시지의 상호운용성 확보 • - 1개의 스펙으로 구성 • 데이터 동기화에 대한 기본 규칙(처리 프로세서)을 정의 • 동기모드별 교환 Command 명시 (7가지 타입) • 에러발생시 처리개념, 인증 처리 명시 • Anchor, Changelog, Map Table 개념 명시 • 라우팅(Device, DB) 개념 설명 • 최소한의 동기화 운영 규칙 상호운영성 확보 • 3개의 스펙으로 구성 (HTTP, WSP, OBEX) • 프로토콜 스트럭쳐의 세팅값 설명 • 프로토콜 스트럭쳐의 처리를 위한 프로세서 설명 • - 메시지 수신및 송신을 위한 상호운용성 확보 SyncML 스펙 Review SyncML 스펙 카테고리 Content XML Representation SyncML Protocol Transport Binding

Transport Binding SyncML Protocol XML Representation SyncML 아키텍쳐 –상호운용성 점검 각 모듈(서브시스템)별 역할(Role) 구분이 안됨 .. ^^;;

메시지 구조 상호운용성 – 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?)>

메시지 구조 상호운용성 – XML Representation • 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 주소록 어떤레코드? Item/locURI Pkey:3

메시지 구조 상호운용성 – XML Representation • 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> 우측 계속 ->

메시지 구조 상호운용성 – XML Representation • 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 데이터의 한계를 넘기 위해서는 반드시 보강될 필요가 있음

메시지 구조 상호운용성 – XML Representation • SyncML Meta Information spec. (3-2) 동기화 데이터는 Item 엘리먼트에 String으로 캡슐화 <Item><Source>…<Data>PIMS 데이터들</Data></Item> ---------------------------------------------------- SyncML 메시지 실예 <Item> <Source>1</Source> <Data>하팀로코즌솔루션3460-0772서울시 서초구… </Data> </Item> 스트링으로 Formating한 결과 데이터 Pkey 1 하팀 로코즌 솔루션 3460-0772 서울시 서초구 … … 하팀,로코즌,솔루션,3460-0772,서울시 서초 하팀/로코즌/솔루션/3460-0772/서울시 서초 <name>하팀</name><company name>로코즌</ name;하팀,companyname;로코즌… 다양한 포멧이 존재 (서로다른 포멧을 적용한 Application 간의 동기화 불가능) String으로 만들때 Formating에 사용된 메타데이타(DTD)식별이 필요 Meta Information Spec의 메타데이타 식별 기능

메시지 구조 상호운용성 – XML Representation • SyncML Meta Information spec. (3-3) • spec. 예제 XML Representation에 속하는 3개의 Namespace 식별 동기화 데이터 포메팅 Namespace 식별 MetaInfomation DTD 식별 <Alert> … <Item> <Target>..</..> <Meta> <Anchor xmlns='syncml:metinf'> <Last>234</Last> <Next>276</Next> </Anchor> … <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> 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> …

전화번호1 FAX 번호 … 메시지 구조 상호운용성 – XML Representation • 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측 장치로 동기화에 사용되는 모메팅 필드를 명시해서 전달 Server측 스키마 Pkey 1 이름 회사명 전화번호1 전화번호2 FAX 번호 … 각 장치간 메타데이타가 다름 vCard(데이터 포멧 스키마) 필드 1 고객명 직장명 핸드폰번호 Client측 스키마

메시지 구조 상호운용성 – XML Representation • 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 스트림화 • 메시지의 상호운용성을 보장하기 위해서는 반드시 동기화 장치간 코드셋의 일치화가 필요 • 파서 선택시 가장 중요한 것은 다양한 코드셋의 제공 (특히 한글, 한문, 다양한 특수기호) • 스트링의 길이가 크게 늘어나지 않는 코드셋을 선택 • 메시지 상호운용성 비교

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 매칭값이 서로 약속되어 있어야함

데이터 Device1 데이터 입력 Device2 메시지 프로세서 상호운용성 – SyncML Protocol • SyncML Sync Protocol spec. • SyncML 내부 동작을 위해 사용되는 정보, 인증, 동기화 방법에 대한 표준 • Sync Protocol spec.은 설명이 충분히 자세하지 않음. • Sync Protocol은 ‘이래야 한다’라는 결과를 말하지 그렇게 되기위해 해야할 과정을 설명하지는 않음 (대부분 구현 벤더의 몫) • Sync Client / Sync Server • 최초 동기화 메시지를 보내는 쪽이 Sync Client (Pkg#1) • 동기화 완료된 데이타의 의미 Main 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을 분리하여 구현 Change Time Change Counter Dirty bits

메시지 프로세서 상호운용성 – 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 존재 • (다음장 운영 시나리오 그림)

Local input 메시지 프로세서 상호운용성 – SyncML Protocol • SyncML 내부 동작을 위해 사용되는 정보 (3-3) • Map Table (2-2) Client Database Database Server 1 Mr. Ha 20010518001 Mr.Ha 2 Mr. Kim 20010518002 Mr.Kim 3 Mr. Lee 20010518003 Mr.Lee Map table 1 20010518001 2 20010518002 3 20010518003 to Server, from Client <Add>…<Item><Source><locURI>2</locURI></Source><Date>Mr. Kim</Date></Item></Add> to Client, from Server <Add>…<Item><Source><locURI>20010518003</locURI></Source><Date>Mr. Lee</Date></Item></Add> to Server, from Client <Map>…<MapItem><Target><locURI>20010518003</locURI></Target><Source><locURI>3</locURI>..</Map>

메시지 프로세서 상호운용성 – SyncML Protocol ⑥ 변경 Mr. Jo ⑤ ① ② ③ Server Database Map table Client Database Change Log information Anchor Information Anchor Information to Server, from Client <Alert>…<Meta><Anchor xmlns=‘syncML….’><Last>14</Last><Next>15</next></Anchor> to Client, from Server <Alert>…<Meta><Anchor xmlns=‘syncML….’><Last> 20000521T090000Z</Last></Anchor> <Replace>…<Item><Target><locURI>2</locURI></Target><Date>Mr. Jo</Date></Item></Add>

메시지 프로세서 상호운용성 – SyncML Protocol • SyncML Sync Protocol spec. • 동기화 시나리오(5-1) 동기화 전/후 update Insert Map table 유지

메시지 프로세서 상호운용성 – SyncML Protocol • SyncML Sync Protocol spec. • 동기화 시나리오 • 전체 동기화 Package Client (C) Server (S) Package 1 목표 Device : ‘S’인증 정보 동기화할 DB : jamesbond, Device 정보 목표 Device : ‘C” ,인증 정보 동기화할 DB : contacts, Device 정보 Package 1에 대한 응답 정보 Package 2 Package 3 목표 Device : ‘S’ Replace LUID(24) “문상철”Package 2에 대한 응답 정보 목표 Device : ‘C’ add GUID(BBB) “박자영”Package 3에 대한 응답 정보 Package 4 Package 5 목표 Device : ‘S’ Map정보(52, AAA) Package 4에 대한 응답 정보 목표 Device : ‘C’ Package 5에 대한 응답 정보 Package 6

메시지 프로세서 상호운용성 – SyncML Protocol • SyncML Sync Protocol spec. • 동기화 시나리오(6-1) • Package #1 (Client -> Server) <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> 간략 설명 <SyncML> <SyncHdr> 동기화할 어플리케이션 및 그 어플리케이션 인증에 필요한 정보를 넣는다 </SyncHdr> <SyncBody> <Alert> 동기화 타입과 동기화 할 대상 데이터(Anchor교환) 기술 </Alert> <Put> 클라이언트의 서비스와 디바이스 정보를 여기에 담아 보낼 수 있다. </Put> <Get> 서버의 서비스와 디바이스 정보를 요청할 수 있다. </Get> </SyncBody> </SyncML>

메시지 프로세서 상호운용성 – SyncML Protocol • SyncML Sync Protocol spec. • 동기화 시나리오(6-2) • Package #2 (Server -> Client) <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) </Results> <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> 각종 상태 정보를 보낸다. Representation Protocol 스펙 </Status> <Results> Get을 통한 요청을 이곳을 통해 보내준다. (Device DTD) </Results> <Alert> TWO_WAY_ALERT일 경우 서버도 동기화 할 DB를 기술한다.(Anchor) </Alert> </SyncBody> </SyncML> 오른쪽 계속 ->

메시지 프로세서 상호운용성 – SyncML Protocol • SyncML Sync Protocol spec. • 동기화 시나리오(6-3) • Package #3 (Client -> Server) <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> 패키지 #2에서 온 정보에 대한 status를 보낸다. <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 Protocol • SyncML Sync Protocol spec. • 동기화 시나리오(6-4) • Package #4 (Server -> Client) 간략 설명 <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> 패키지 #3에서 온 정보에 대한 status를 보낸다. <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 Protocol • SyncML Sync Protocol spec. • 동기화 시나리오(6-5) • Package #5 (Client -> Server) 간략 설명 <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> </Status> <Map> LUID와 GUID를 매핑 시킨 정보 </Map> </SyncBody> </SyncML>

메시지 프로세서 상호운용성 – SyncML Protocol • SyncML Sync Protocol spec. • 동기화 시나리오(6-6) • Package #6 (Server -> Client) 간략 설명 <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> <SyncHdr> </SyncHdr> <SyncBody> <Status> Map command에 대한 응답 코드 </Status> </SyncBody> </SyncML>

메시지 프로세서 상호운용성 – SyncML Protocol • 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 Protocol • SyncML Sync Protocol spec. • 동기화 타입에 따른 교환 Command와 데이타

SyncML 구현예 –시스템 구성 Server RDBMS DesktopPC SyncML Impl. Two-way 싱크 (TCP/IP.. 아직 스펙은 없지만 ^^;;) Two-way 싱크 (HTTP) SyncML Impl. SyncML Impl. RMS 임베디드 DB PDA 핸드폰 Client 1 Client 2

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

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