PROVISIONING WINDOWS MOBILE DEVICES WITH SYNCML

아티클
06/23/2015

Going Places

SyncML을 사용한 모바일 장치 프로비저닝

Ramon Arjona

OMA란?
SyncML: 동기화를 위한 XML
SyncML 요소
SyncBody 요소
잠깐! 이것이 끝이 아니다
작업에 SyncML 투입

2008년 4월호 MSDN Magazine Going Places 칼럼에서 Mike Calligaro가 XML 파일과 DMProcessConfigXML API를 사용한 Windows Mobile 장치 프로비저닝에 대해 다룬 바 있습니다. 그 칼럼에서 Mike가 사용한 XML은 이전에 WAP(Wireless Application Protocol)라고 불리던 Open Mobile Alliance(OMA) Client Provisioning(OMA-CP) 표준을 기반으로 장치를 관리합니다.

몇 가지 장치를 관리하는 데는 OMA-CP로 충분하고 Mike도 칼럼에서 동시에 여러 장치로 프로비저닝 정보를 배포하는 방법을 제안하고 있습니다. 하지만 장기간에 걸쳐 수천 개의 장치를 체계적인 방식으로 프로비전해야 하는 경우는 어떨까요? 관리하려는 장치에 이미 설정된 소프트웨어와 레지스트리 설정을 알아야 한다면 또 어떨까요?

OMA-DM(OMA 장치 관리)는 이러한 대규모의 체계적인 프로비저닝에 사용됩니다. OMA-DM 프로토콜은 SyncML이라는 XML 언어를 기반으로 하며 엔터프라이즈 시나리오에서 장치를 프로비전하고 관리하는 데 사용됩니다. 이 칼럼에서는 OMA-DM 프로토콜에 사용되는 SyncML 문서의 구조에 대해 설명하겠습니다. 장치를 원격으로 지우는 경우 등 Windows Mobile 플랫폼의 구체적인 사용 시나리오를 소개하고, Mike의 칼럼에서 설명하는 XML과 OMA-DM를 사용하여 장치에서 브라우저 즐겨찾기를 설정하는 방법도 보여 드리겠습니다.

OMA란?

OMA는 모바일 사업자, 모바일 장치 제조업체, Microsoft를 비롯한 소프트웨어 공급업체 등 200여 개 업체가 모여 만든 업계 기구입니다. OMA는 WAP, Device Management, SyncML 등 시장에서 끊임없이 새로 등장하는 모바일 장치 표준을 관리할 일원화된 기구를 만들자는 취지로 지난 2002년에 설립되었습니다. 다양한 단체가 난립하면서 여러 곳에서 중복된 사업이 진행되는 데 문제 의식을 가진 업계 파트너들이 모여 주요 사업을 모두 하나의 기구 아래에서 진행하도록 한 것입니다.

OMA 표준은 상이한 기술 간에 표준화된 방식으로 통신이 가능하도록 하여 모바일 장치 및 네트워크 작업을 용이하게 합니다. SyncML과 OMA-DM은 이러한 개방형 프로토콜 환경을 대표하는 두 가지 기술입니다. 다른 프로토콜과 마찬가지로 이 두 프로토콜도 어느 정도는 공급업체마다 다르게 해석될 수 있고 공급업체에서 부가가치 창출을 위해 고유한 확장을 제공할 수도 있습니다. 그러나 공급업체별로 고유한 형식을 처리하려고 애쓰는 것보다 작업이 훨씬 쉽고 간단합니다.

SyncML: 동기화를 위한 XML

SyncML은 OMA로 정의되는 대부분의 프로토콜에 기반으로 사용되는 XML 기반 태그이며 SyncML 문서를 메시지라고 합니다. 메시지는 올바른 형식의 XML이어야 하지만 유효한 XML일 필요는 없습니다. 즉, 모든 요소에 서로 일치하는 열기 태그와 닫기 태그가 있어야 하고 모든 특성은 따옴표로 묶어야 합니다. 아니면 XML로 통칭되는 모든 문서에서 기본이 되는 올바른 형식에 대한 기본 정의를 따라야 합니다.

SyncML DTD(문서 형식 정의)도 있지만 이 형식 정의에 대해 송신자나 수신자의 유효성을 검사할 필요는 없습니다. 게다가 유효성 검사에는 메모리와 프로세서 시간이 추가로 요구되는데 모바일 장치에서는 이러한 메모리가 부족하기 마련입니다. 메시지에는 특정 OMA 프로토콜의 주요 작업을 수행하는 명령 요소가 포함됩니다.

SyncML과 OMA-DM은 전송 방식에 구애 받지 않습니다. HTTP 및 OBEX(Object Exchange)용 전송 바인딩이 정의되어 있으며 다른 바인딩도 정의할 수 있습니다. 때문에 SyncML과 OMA-DM은 무선으로 장치에 프로비전하는 데 매우 유용합니다. 표준에 맞는 장치 관리 서버에 SyncML과 OMA-DM을 사용하면 메모리 카드를 사용하거나 장치를 연결하거나 최종 사용자가 웹 사이트를 방문하는 등의 작업을 수행하지 않아도 장치에 구성을 배포할 수 있습니다.

이론적으로 SyncML 패키지에는 메시지가 하나 이상 포함됩니다. SyncML 패키지는 송신자와 수신자 간에 전송되는 모든 메시지를 포함합니다.

SyncML 요소

SyncML 문서는 루트 SyncML 요소, SyncHdr 요소로 정의되는 헤더, SyncBody 요소로 정의되는 본문으로 구성됩니다. SyncML 문서의 루트는 항상 다음과 같은 SyncML 요소입니다.

<SyncML xmlns='SYNCML:SYNCML1.1'>
...
</SyncML>

SyncML 요소는 SyncHdr 및 SyncBody 하위 요소를 포함합니다. SyncHdr 요소는 그림 1의 태그와 같은 모습입니다. 이 짧은 헤더에 수신자가 메시지를 처리하는 데 필요한 정보가 모두 들어 있습니다.

그림 1 SyncHdr

<SyncHdr>
  <VerDTD>1.2</VerDTD>
  <VerProto>DM/1.2</VerProto>
  <SessionID>1</SessionID>
  <MsgID>1</MsgID>
  <Target>
    <LocURI>https://mgmt.contoso.com/ </LocURI>
  </Target>
  <Source>
    <LocURI>urn:uuid:6D67E196-D082-4c91-A0DD-DEB3D1D58EB5</LocURI>
    <LocName>MyDeviceName</LocName>
  </Source>
  <Cred>
    <Meta>
      <Format xmlns="syncml:metinf">b64</Format>
      <Type xmlns="syncml:metinf">syncml:auth-md5</Type>
    </Meta>
    <Data>ODZlMDNiYmM1MjA1YTI3MDc5MDk2MDcwYTA4OGM2Zjg=</Data>
  </Cred>
</SyncHdr>

VerDTD 요소는 이 메시지가 OMA에서 정의한 SyncML Representation Protocol 버전 1.2를 준수한다는 사실을 나타냅니다. VerProto 요소도 이와 유사하게 OMA-DM 프로토콜 버전 1.2를 처리하는 메시지라는 사실을 나타냅니다. 버전 번호는 같지만 두 프로토콜은 서로 다릅니다. SyncML은 장치 관리 프로토콜(이 칼럼에서 설명할 내용)이나 동기화 프로토콜(SyncML의 원래 용도)과 같은 다른 OMA 프로토콜에 사용됩니다.

SessionID 요소는 SyncML 세션을 나타냅니다. 이 ID의 값은 길이가 4바이트 이하입니다.

MsgID는 세션 내에서 고유한 ID로, 송신자와 수신자 간의 대화를 추적하는 데 사용됩니다. 수신자가 결과를 응답으로 보낼 때 결과의 MsgRef 요소에 MsgID를 포함하여 응답 대상 메시지를 참조하게 됩니다.

Target 요소는 메시지의 수신자를 나타내고 Source 요소는 메시지의 송신자를 나타냅니다. 이 두 요소는 송신자 또는 수신자를 고유하게 식별하는 문자열이 들어 있는 LocURI 요소를 포함합니다. Target과 Source의 LocURI는 URL, URI 또는 URN이어야 합니다. 일반적으로 관리 서버에는 고유한 DNS 이름이 있기 때문에 송신자나 수신자가 관리 서버인 경우 관리 서버의 정규화된 도메인 이름이 LocURI에 사용되는 경우가 많습니다.

Target 요소와 Source 요소는 메시지에 주소를 지정하거나 라우팅하는 것과는 직접적인 관련이 없습니다. 이러한 작업은 장치 관리 응용 프로그램과 지원 전송 프로토콜에 일임됩니다.

모바일 장치는 RFC 4122에 정의된 대로 GUID를 나타내는 URN에 의해 자주 참조됩니다. 이러한 GUID는 주소 지정 대상 장치를 고유하게 나타냅니다. 이 GUID를 네트워크를 통해 연결 가능한 주소에 다시 매핑할지 여부는 응용 프로그램에 따라 결정됩니다. GUID는 특정 장치를 바로 직관적으로 나타내 주지는 않기 때문에 예제 응용 프로그램에서는 Source 요소에 SyncML 메시지를 보낸 장치의 이름이 들어 있는 LocName 요소를 추가합니다.

마지막으로 Cred 요소에는 송신자를 식별하는 정보가 들어 있습니다. 또한 이 메시지가 SyncML 표준에 정의되어 있고 보안 토큰이 Base 64로 인코딩된 MD5 인증 체계를 사용한다는 사실을 알리는 Meta 요소 쌍을 포함합니다. Meta 요소와 유사한 Data 요소에는 수신자가 송신자의 ID를 확인하는 데 사용할 수 있는 인증 토큰이 포함되어 있습니다.

SyncBody 요소

SyncBody 요소는 그림 2에 나와 있습니다. 여기서도 SyncHdr와 마찬가지로 Target 요소가 LocURI로 식별됩니다. SyncML의 요소 대부분은 LocURI로 식별됩니다. LocURI는 XML 문서의 중첩된 트리 구조와 유사한 중첩된 트리 구조에 따라 작성되지만 일련의 중첩된 XML 노드보다 처리하는 데 리소스가 많이 소요됩니다. 이 개념 트리의 루트는 "." 문자로 식별되므로 이 문자를 항상 지정해야 합니다.

그림 2 SyncBody 요소

<SyncBody>
  <Add>
    <CmdID>2</CmdID>
    <Item>
      <Target>
        <LocURI>./Vendor/MSFT/SwMgmt/Download/SetBrowserFavorite/PkgID
        </LocURI>
      </Target>
      <Data>pkg id setbrowserfavorite</Data>
    </Item>
    <Item>
      <Target>
        <LocURI>./Vendor/MSFT/SwMgmt/Download/SetBrowserFavorite/PkgURL
        </LocURI>
      </Target>
      <Data>http://content.contoso.com/download/SetBrowserFavorite.cab
      </Data>
    </Item>
  </Add>
  <Exec>
    <CmdID>3</CmdID>
    <Item>
      <Target>
        <LocURI>./Vendor/MSFT/SwMgmt/Download/SetBrowserFavorite/Operations/DownloadInstall        </LocURI>
      </Target>
    </Item>
  </Exec>
<Final/>
    </SyncBody>

이 트리에는 설치된 메모리 용량이나 OMA-DM을 통해 실행 가능한 실행 파일과 같은 모바일 장치에 대한 정보가 포함됩니다. LocURI는 이 장치 정보 트리를 참조하는 데 사용되며 항상 전체 URI여야 합니다. 즉, 항상 장치 루트에서 주소를 지정할 특정 리프까지 지정되어야 하고 부분 URI나 상대 URI는 이 OMA-DM 사양에서 허용되지 않습니다.

앞서 필자가 "개념적" 트리라고 한 것에 주목해야 합니다. SyncML 및 OMA-DM 사양은 이 정보를 실제로 지원 저장소에 보존하는 방법과 관련하여 모바일 장치나 장치 관리 서버에 대해 세부적인 구현 방식을 규정하지 않습니다. SyncML은 데이터를 트리와 같이 취급하여 주소를 지정하도록 하고 있지만 관계형 데이터베이스, 장치 또는 서버 레지스트리, 휘발성 메모리, 일련의 플랫 파일 또는 다른 방법으로 저장할 수도 있습니다. 이 사양은 실제로 이 데이터를 보호하는 데 사용되는 메커니즘과는 완전히 별개입니다.

루트 노드 아래에는 DevInfo, DevDetail 및 Vendor라는 중요한 하위 노드가 3개 있습니다. DevInfo 노드에는 장치 제조업체, 장치 UI에 설정된 언어 및 장치 ID에 대한 정보가 들어 있습니다. DevDetail 노드에는 장치 하드웨어 버전이나 장치에서 지원되는 최대 URI 길이와 같이 공급업체와는 관계없는 장치 관련 정보가 들어 있습니다. 장치에 대한 다른 유용한 정보는 대부분 Vendor 노드에 저장되어 있습니다. OMA-DM 사양에 따라 구현자는 OMA-DM 프로토콜에 대한 확장을 Vendor 노드에 배치해야 합니다. 따라서 Windows Mobile 장치를 프로비전하거나 관리할 때는 대부분의 작업을 Vendor 노드에서 수행하게 됩니다.

원격 지우기

장치에 무언가를 수행하도록 지시할 때는 언제나 Exec 명령이 사용되지만 극히 제한된 몇 가지 작업은 OMA-DM을 통해 장치에 명령을 내릴 수 있습니다. Windows Mobile 장치에서 OMA-DM으로 트리거할 수 있는 다른 기능으로 원격 지우기가 있습니다. 원격 지우기는 Exchange에서 Windows Mobile 클라이언트에 제공되는 지우기 기능과 유시하며 장치를 분실하거나 도난 당했을 때 매우 유용합니다. OMA-DM으로 장치를 지우는 명령은 다음과 같습니다.

<Exec>
  <CmdID>3</CmdID>
  <Item>
    <Target><LocURI>./Vendor/MSFT/RemoteWipe/doWipe</LocURI></Target>
  </Item>
</Exec>

OMA-CP를 사용하여 장치를 지울 수도 있습니다. 따라서 원하는 경우 프로비저닝 XML이 포함된 CAB 파일을 만들어 OMA-DM 다운로드를 통해 장치에 배포할 수 있습니다. 그러면 CAB 파일의 내용이 OMA-DM를 사용하여 호출되는 것과 같은 RemoteWipe CSP로 라우팅됩니다.

앞서 살펴본 SyncBody 요소에는 Add 요소가 하나 있습니다. 이 Add 요소는 수신자에게 장치 정보 트리에 노드를 하나 이상 추가하도록 지시합니다. Microsoft에서 구현한 OMA-DM은 Add 명령이 장치에 없는 노드가 포함된 LocURI를 참조할 경우 루트에서 리프에 이르는 모든 노드를 장치 정보 트리에 삽입하는 암시적 추가를 지원합니다. 이 확장을 사용하지 않으면 노드를 한 번에 하나씩 트리에 추가해야 하기 때문에 대역폭과 프로세서 시간을 빠르게 소모하게 되고 결국 사용자의 사용 환경에 악영향을 미칩니다.

예의 Add 명령은 URL이 content.contoso.com/download/SetBrowserFavorite.cab인 장치의 소프트웨어 관리를 위해 Download 노드에 요소를 추가합니다. 궁극적으로 이 URL은 장치의 CSP(구성 서비스 공급자)로 라우팅(동시에 Download CSP 호출)되고 CSP는 이 URL로 지정된 콘텐츠에 대해 가져오기를 시도합니다.

Add 명령 뒤에는 Exec 명령이 따라옵니다. Exec 명령은 장치에 작업을 수행하도록 지시합니다. 예에서는 ID가 SetBrowserFavorite.cab인 패키지를 다운로드하여 설치하도록 장치에 지시하고 있습니다.

Exec 명령 다음에 있는 Final 요소는 수신자에게 이 세션의 마지막 SyncML 메시지임을 알립니다. Final 요소가 없으면 수신자가 뒤따르는 SyncML 메시지가 더 있는 것으로 간주하게 됩니다.

ActiveSync를 통해 장치에 CAB 파일을 복사하여 설치할 수 있는 경우에는 일반적으로 OMA-DM를 사용하여 장치에 CAB 파일을 설치할 수도 있습니다. CAB 파일은 장치에서 신뢰되는 인증서를 사용하여 서명해야 합니다. 유효한 인증서를 사용하여 파일에 서명하지 않으면 CAB 파일을 설치할 수 없습니다. ActiveSync를 통해 서명되지 않은 CAB 파일을 설치할 때는 이와 다른 동작이 나타납니다. ActiveSync를 통해 서명되지 않은 파일을 설치하는 경우 장치의 정책에서 이러한 설치가 허용된다면 서명되지 않은 CAB를 설치할지 여부를 묻는 메시지가 나타납니다.

반면 Windows Mobile 장치에서 OMA-DM 프로토콜은 이러한 메시지를 표시하지 않습니다. 바로 작업이 실패하고 관리되는 프로그램 애플릿의 오류 코드가 포함된 오류 메시지가 표시되고 관련 오류 코드가 장치 관리 서버로 다시 보내집니다. ActiveSync는 장치를 실제로 소유하고 있을 때 사용자가 시작하는 반면 OMA-DM은 장치가 사용자에게 없을 때 원격 에이전트에 의해 시작되므로 이러한 동작의 차이는 당연한 것이라고 할 수 있습니다.

Download CSP는 먼저 지정된 URL에서 콘텐츠를 가져온 다음 CAB 파일을 검사하여 서명되어 있지 않으면 오류를 발생시킵니다. CAB 파일이 서명되어 있으면 CAB 파일의 압축을 풀고 파일의 콘텐츠를 적절하게 라우팅합니다. CAB에 소프트웨어가 포함되어 있으면 장치에 소프트웨어가 설치되고 OMA-CP 프로비저닝 XML(예: Mike가 칼럼에서 만든 CAB 파일)이 포함되어 있으면 장치에 프로비저닝 XML이 적용됩니다. CAB 파일에 영화나 홈 화면 같은 일반 콘텐츠가 들어 있으면 장치 파일 시스템에 해당 콘텐츠가 저장됩니다.

관리되는 프로그램 애플릿은 OMA-DM을 통해 장치에 CAB 파일을 설치하려는 시도를 성공 여부에 관계없이 모두 기록합니다. 설치가 완료되면 장치는 OMA-DM 표준에 따라 정의된 코드를 새 OMA-DM 세션에서 관리 서버로 다시 보냅니다.

잠깐! 이것이 끝이 아니다

Windows Mobile 장치는 SyncML에 지정된 명령 요소의 하위 집합에 응답합니다. 앞에서 설명하지 않은 몇 가지 명령 요소를 소개하겠습니다.

Alert 명령은 송신자가 수신자에게 필요한 내용을 알리는 데 사용됩니다. 예를 들어 대기 상태에서 다시 세션을 시작하도록 장치에 알리는 알림을 관리 서버에서 장치로 보낼 수 있습니다. 또는 UI를 통해 최종 사용자에게 표시해야 할 정보가 들어 있는 알림도 보낼 수 있습니다.

Atomic 요소는 모두 한 단위로 성공하거나 실패한 것으로 처리되어야 할 다른 명령을 그룹화하는 데 사용됩니다. 이는 여러 명령이 서로 연관되어 있고 일부만 성공할 경우 장치가 잘못되거나 알 수 없는 상태로 될 수 있는 경우에 중요합니다. Add 명령 3개를 Atomic 요소로 그룹화하지 않으면 각각 독립적으로 성공하거나 실패하게 되고 관리 서버에 대한 응답 메시지도 각각 별개로 3개가 생성됩니다.

Delete는 Add에 반대되는 명령으로, 장치 트리에서 노드를 제거합니다. 하위 노드가 있는 경우에는 하위 노드까지 제거됩니다. 기본 제공 DevInfo 노드와 그 하위 노드를 비롯한 일부 노드는 제거할 수 없으며 해당 노드를 제거하려 하면 오류 코드가 생성됩니다. Replace 명령은 장치 트리에서 지정된 노드를 바꿉니다.

Get 명령은 장치 트리에서 정보를 쿼리하여 SyncML 메시지를 통해 송신자에게 반환하는 데 사용됩니다. 예를 들어 현재 장치에서 사용 가능한 저장소 용량을 가져오려는 경우 다음과 같은 Get 명령을 보내게 됩니다.

<Get>
  <CmdID>3</CmdID>
  <Item>    
    <Target>
      <LocURI>./Vendor/MSFT/DeviceInformation/TotalStorage</LocURI>
    </Target>
  </Item>
</Get>

Result 명령은 Get에 대한 응답으로 전송되며 Get에서 요청된 노드의 값을 포함합니다.

Sequence 요소는 노드를 특정한 순서로 그룹화하는 데 사용됩니다. 차례로 처리해야 할 명령이 있는 경우 Sequence 요소에 그룹화하지 않으면 실행 순서가 보장되지 않습니다.

마지막으로, Status 요소는 특정 작업에서 반환된 성공 또는 실패 코드를 포함합니다. 일반적으로 상태 코드 200은 성공을 나타냅니다.

작업에 SyncML 투입

SyncML은 장치 관리용이 아니라 장치 동기화용으로 출발한 프로토콜입니다. SyncML을 기반으로 한 OMA 동기화 프로토콜 구현은 장치에서 일정 및 연락처 정보를 동기화할 수 있도록 하는 데 자주 사용됩니다. SyncML의 기본 프로토콜 사양은 동기화 요구 사항뿐만 아니라 관리 요구 사항까지 해결해 줍니다. 즉, 기본 SyncML Representation Protocol에는 OMA-DM에 사용되지 않는 요소와 동기화에 사용되지 않는 요소까지 포함되어 있습니다.

SyncML 사양은 다양한 문제 영역을 다루기 때문에 처음 접하면 다소 혼란스러울 수 있습니다. 동기화와 관리는 중복되는 부분도 있지만 전혀 다른 분야입니다. 따라서 프토로콜 표시 사양을 살펴볼 때 관리에 사용되는 SyncML 요소와 동기화에 사용되는 요소를 개념적으로 분리하여 생각하면 이해하기 쉽습니다.

OMA-DM을 통해 장치를 프로비전하려면 관리 서버가 있어야 합니다. Microsoft System Center Mobile Device Manager 2008과 같은 상용 제품은 물론, 비상업용 SyncML 라이브러리와 구현도 제공되고 있습니다. 이렇게 공급업체와 구현 개발자가 선택할 수 있는 옵션의 폭이 넓다는 것은 한편으로 OMA-DM을 사용하여 통신하는 장치와 서버를 만들기가 어려울 수 있다는 의미기도 합니다. 그러나 OMA 표준을 사용하는 여러 장치를 통합하는 데 따른 어려움은 서로 관련이 없는 이기종의 전용 통신 방법을 사용하여 상호 운용되도록 장치를 구현하는 어려움에 비하면 아무 것도 아닙니다. OMA 설립 이전의 모바일 시장 상황을 보면 쉽게 알 수 있듯이 말입니다.

질문이나 의견이 있으면 goplaces@microsoft.com으로 보내시기 바랍니다.

Ramon Arjona는 Microsoft Windows Mobile 팀에서 수석 테스트 책임자로 일하고 있습니다.

추가 리소스