우선 제가 예전에 정리해둔 자료입니다. (해당 Spec의 내용을 그대로 옮겨온 것 입니다.)

*BONDI

A Widget is understood to be an interactive single purpose application for displaying and/or updating local data or data on the Web, packaged in a way to allow a single download and Installation on a user’s machine, mobile phone, or mobile Internet Terminal

Web Application

An Application authored using web formats that makes use of Scriptable APIs, e.g. an installed Widget, web based Application or hybrid.

*JIL

A JIL Widget is a composition of HTML, JavaScript, and CSS combined as a package that can be deployed on a JIL compatible mobile handset. The widget package is self-contained; the package includes all of the support files that are needed by the widget. With this approach, the widget can become a standalone application that does not require any external resources. Any external access issues in running a widget can be safely handled or even avoided.

*W3C http://www.w3.org/TR/widgets/

Widgets are full-fledged client-side applications that are authored using Web standards and packaged for distribution. They are typically downloaded and installed on a client machine or device where they run as stand-alone applications, but they can also be embedded into Web pages and run in a Web browser. Examples range from simple clocks, stock tickers, news casters, games and weather forecasters, to complex applications that pull data from multiple sources to be “mashed-up” and presented to a user in some interesting and useful way (see [Widgets-Landscape] for more information).

*W3C http://www.w3.org/TR/widgets-land/

A widget is an end-user’s conceptualization of an interactive single purpose application for displaying and/or updating local data or data on the Web, packaged in a way to allow a single download and installation on a user’s machine or mobile device. A widget may run as a stand alone application (meaning it can run outside of a Web browser), or may be embedded into a Web document. In this document, the runtime environment on which a widget is run is referred to as a widget user agent and a running widget is referred to as an instantiated widget. Prior to instantiation, a widget exists as a widget resource.

그리고, BONDI_Architecture_and_Security_v1.1 에 나오는 내용입니다.

Web Application – The term used generically to refer to an application delivered using web technology, whether as a Website or a Widget.

Widget – An interactive application for displaying and/or updating local data or data on the Web, packaged in a way to allow a single download and installation on a user’s machine or mobile device.

끝으로, 보시는 바와 같이 Web Application 이 Widget을 포괄하는 것을 확인할 수 있습니다.

저번에는 런던 센터였지만, 이번에는 서쪽으로 좀 떨어진 윈저에서 같은 회사 Test Leader 이신 Chris님과 함께 BONDI TestFest를 아래와 같이 3일간  진행하였습니다. (추가 2일은 WAC 미팅)

Day 1

그 동안 메일로 오고간 정황상, BONDI 1.11을 위한 RI는 어느정도 완료되었고, 따라서 그에 따른 Test 만 잘 수행할 수 있다면 된다고 생각했었다.

하지만 역시, 그렇지는 않았다. 설상가상으로 오전 11시까지는 인터넷(WiFi) 설정도 안되었으니 말이다.

이 번 TestFest의 소개와 업무 분담을 하고 나니, 바로 점심을 먹으러 갈정도로 오전은 진척이 없었다. (우리나라에서는 있을 수 없는 일이지만, 역시나 다들 여유가 넘쳤다. 항상 !!)

오후에는 contact module 의 test framework 중에서 버그가 몇 개 있어서 수정하였고, 금방 5시가 되었다.

옆방에는 저번 Seattle 미팅이 취소되는 바람에 Conference Call에서 결정하지 못 한 사항들에 대해서 논의되는 자리가 있었는데, 저녁에는 모두 같이 모여서 식사와 음료(?)를 하였다.

Day 2

contact module에 대해서 어느정도 완료하고, 추가적으로 messaging module 쪽을 보기로 하였다.

역시 코딩/디버깅을 하니 시간이 너무 너무 잘 갔다.

결과는 test framework 자체보다는 RI가 구현이 덜 되어서(혹은 WebVM의 한계) , 우리가 할 수 있는 것이 그리 많지는 않았다.

다음 날이 TestFest의 마지막 날이라(실제적으로는 OMTP BONDI TestFest의 마지막), 우리는 좀더 잘 하기 위해서 호텔에 와서도 일부 업무를 계속 진행하였다.

Day 3

TestFest 마지막 날…

마지막 날이라 뭔가 좀더 아웃풋을 내기 위해서 오전부터 집중해서 달렸는데, emulator 나 device 모두 crash가 계속 되는 바람에 삽질의 연속이었다.

이는 비단 우리뿐만이 아니었다. Messaging은 정말 최악의 선택이었다 ㅠㅠ.

Messaging 을 포함하여 다른 모듈은 계속 f/up을 하기로 하고, 적당한 선에서 (적당한 이유와 함께) TestFest를 종료하였다.

어쨌든, BONDI 1.11 spec은 곧 나올 것이며,  비록 Test Framework이 완벽하지 않더라도 이해해 주시길… WinMo 자체의 문제도 있고^^.

그럼 여기까지 하고 다음에 또 뵙겠습니다.

p.s) 좀 더 자세한 얘기와 특히 WAC 관련은 여기서 다룰 수 없어서 아쉽네요. (회사 보안상의 이유로 ㅠㅠ)

바라건대, 7월부터는 wackorea 로 찾아뵐 수 있을지 모르겠습니다.^^

이번에는 bondi RI의 소스를 build 해서 실행하는 방법에 대해서 알아보겠습니다.

1. windows mobile 개발 환경 구성

bondi RI는 windows mobile 환경에서 설치 및 실행되므로 아래 개발 환경이 우선 설치 되어야 합니다.

- visual studio 2005 Professional or Team system editions

- windows mobile 6 professional SDK

visual studio 2005에서는 professtional 이상의 버전을 사용해서 windows mobile 개발이 가능합니다. 이 버전 이상이 설치 되어있다면 windows mobile 6 professional SDK를 mircosoft site에서 다운로드 받아 설치합니다. (다운로드 바로 가기)

2. bondi RI source

개발 환경이 구축되면 이제 bondi RI 소스와 bondi RI의 구동에 필요한 webvm SDK를 설치합니다.

omtp에서는bondi RI의 소스를 svn으로 관리를 하므로 svn에 필요한 client 프로그램을 설치하면 아래 주소에서 받을 수 있습니다. 필자는 윈도우용 svn client인 tortoisesvn 를 이용했습니다.

http://svn.omtp.org:8080/svn/bondi/trunk

현재 svn에는 인증을 필요로 합니다.  bondi development site에 회원가입을 하고 가입 확인 메일을 받으면 가입한 ID/PW로 인증이 가능합니다.

3. webvm SDK

webvm은 browser에서 PIM, Geolocation 등의 native feature를 사용하기 일종의 plug-in 입니다. bondi APIs에서는 다양한 종류의 native featrue를 사용하므로 browser에서 이 부분을 연결하기 위해서 bondi RI(windows mobile)에서는 webvm을 이용합니다.  그러므로 bondi RI를 build 하기 위해서는 webvm SDK가 필요합니다.

webvm에 대한 상세 내용은 http://webvm.net/ 를 참고하십시오.

그럼 이제 build 필요한 마지막 부분인 webvm SDK를 설치해야 합니다.  http://sdk.webvm.net/에서 이름, 메일 정보등을 입력하고면 메일로 다운로드 가능한 주소를 보내줍니다. ( 테스트용으로 받기위해서 요청을 했을 때 답변 메일에 3시간 정도가 소요되었습니다.)

다운로드 SDK의 압축을 풉니다. 그리고 아래의 경로를 windows 경로에 추가합니다.

WEBVMHOME=C:\path\to\your\webvm-sdk

이 경로의 include/webvm.h 파일을 이용하기 위한 내용이므로 꼭 추가해 주어야 합니다.

4. build

모든 환경이 준비 되었으면 visual studio 로  {bondi RI source path}\ri\build\wince\build.sln 프로젝트를 load하고 target을 Windows Mobile 6 Professional SDK (ARMV4I) 로 설정한 다음 build를 실행합니다.

bondi RI는 지속적인 수정이 되고 있는 상태이기 때문에 build 에 대해서 관리가 되지 않아서 무수한 에러와 만나게 될지도 모릅니다. 그럼에도 build 해서 실제 실행되는 부분을 확인하기 위해서는 에러를 직접 해결해야 합니다. : p

2010.04.01 기준의 소스를 받았을 때 발생한 에러에 대해서는 아래 내용을 적용하면 정상적으로 build가 되니 참고하십시오.

- fixed build error

• C:\Program Files\Microsoft Visual Studio 8\VC\ce\include\comdef.h (240 line) 을 수정.  int nLen = ::lstrlen(m_pszMsg);   부분을 다음으로 변경   int nLen = lstrlen(m_pszMsg);
• C:\path\to\your\webvm-sdk\include\webvm.h 파일을 {bondi RI source path}\ri\module\common\webvm.h 파일로 교체
• MessagingCommon project 를 삭제하고 {bondi RI source path}\ri\module\common\messagingCommon2\wince\messagingCommon.vcproj 를 새로운 project로 Add. 추가로 WCommsLog project properties -> input lib에서 messsagingCommon을 messagingCommon2로 변경.
• bondi_FeatureCallback_decl.h 를 include 한 부분 주석 처리

2010.04.01 소스는 위에 부분의 수정으로 build가 가능합니다.

5. Run bondi RI

이상 없이 build 가 완료되면 {bondi RI source path}\ri\build\wince\bin\ 아래에 BondiSetup1-016d.cap 파일이 생성됩니다. 이 설치 파일을 windows mobile emulator에서 설치하면 정상적으로 bondi RI가 실행되는 것을 확인할 수 있습니다.

참고로 아래 부분을 수정하면 debug mode로 emulator에서 실행도 가능합니다. (마찬가지로 2010.04.01 소스 기준으로 추후에 다르게 변경 될 수 있습니다.)

• userAgent project를 Set as Startup project로 선택
• package project properties -> Deployment -> Register Output No로 변경
• userAgent project properties -> Deployment -> Remote Directory를 %CSIDL_PROGRAM_FILES%\bondi 로 변경

6. conclusion

bondi 에서 배포하는 RI source는 계속적인 수정과 버전 관리 process의 부재로  build & run 에는 아직 여러가지 문제들이 있습니다. 그렇지만 bondi APIs 의 내부적인 동작에 대해서 관심이 있다면 현재 참고할 수 있는 유일한 reference입니다.

Compliance 그룹(of BONDI) 의 의장이신 리스께서 아래와 같은 Agenda로 미팅을 주관해 주셨습니다.

• Testfest에 대한 소개 및 목적
• BONDI Test Framework 소개 및 Test 작성방법
• 그리고, Test 작성하는 간단한 샘플
• 둘째날 부터는 계속 test code를 넣고, 서로 리뷰를 하였습니다.

날짜별로 좀 더 자세히 얘기하자면 아래와 같다.
(일련의 모든 사항을 적기보다는 느낌을 중심으로 작성했습니다.)

Day 1

먼저 리스가 의장이 된 이유를 (아무도 나서는 이가 없어서 어쩔 수 없이 이렇게 되었다고 말함) 꺼내면서 미팅이 시작되었다. (60정도 되어보이는 백발 개발자의 겸손함과 지혜를 엿볼 수 있었음.)

그리고, Test code가 실제 BONDI 페이지에 연결된 svn에 바로 commit 되는 것이라 놀라지 않을 수 가 없었다. WebVM 담당자인 카이(Kai) 말로는 실제로 어떤 이가 파일 자체를 날려서, 일일이 복구하는 일도 생겼었다고-_-;

참가한 사람이 그렇게 많지 않아서(10명정도), 2~3명이 한팀이 되어서 주요 모듈을 맡아서 Test 작성이 시작이 되었다. 물론 나랑 같이 간 Denny와 같은 팀이였으며, 우리가 맡은 모듈은 Contact 이었다. (사실 이 때까지만 해도 BONDI test framework 에 대한 동작방식은 이해할 필요가 없어서, 깊이 있게 보지는 않았었다. 바로 이게 우리가 좀더 잘 할 수 있었는데 부족했던 부분이 아닌가 한다.)

Day 2

우리는 스펙의 문장 하나하나를 면밀히 분석하여, assertion 들을 리스트업 하였다.  예를들어 If any argument is wrong the ErrorCallback will be invoked with a DeviceAPIError INVALID_ARGUMENT_ERROR 이 있으면, 실제로 인자가 잘 못 들어갔을 경우 ErrorCallBack을 리턴하는 지와 그때 Error 코드가  INVALID_ARGUMENT_ERROR 인지를 체크해야한다.

실제 Contact의 경우에는 다른 모듈에 비해서 작업이 너무나 안되어 있었다. 그래서 우리는 대부분의 코드를 처음부터 다시 작성해야 했으며, 많은 삽질을 하는 계기가 되었다. ㅠㅠ.

또한 우리는 Browser based 뿐 아니라 Widget에 대해서도 돌아갈 수 있도록 호텔에 와서도 열심히 삽질을 하였다. (RI가 너무 구현이 안되어있어서, 실제로 테스트 해볼 수 있는 것은 거의 없었다.)

Day 3

계속되는 코딩… (중략)

그러나, 이 날은 저녁에 한국 식당에 가서 소주한잔을 할 수 있는 여유가 있었다. 사실 한국에 1년간 산 적이 있는 카이가 가자고 제안했으며, 브라이언도 기꺼이 동행해서 4명이서 즐거운 저녁시간을 보냈다.

Day 4

… (중략) 마치며,

If no filter is passed all the contacts will be returned 의 경우 실제로 제대로 돌아가는 지 확인할 Test assertion을 찾을 수 가 없었다.

혹, 관심있는 분은 어떻게 하면 이 것을 검증할 수 있는지 생각해보길 바랍니다.

p.s) 제가 다니는 회사와 관련된 정보나 아직 확정되지 않은 것에 대해서는 일부러 언급하지 않았습니다.
그리고, 다음 Codefest는 7월에 열릴 예정인데, 그때는 좀더 나은 모습을 보일 수 있도록 미리 노력을 많이 하도록 하겠습니다.

이번에는  device API에 접근을 위해 접근을 요청한 widget이 API에
접근이 가능한 widget인지를 확인에 이용되는 subject element와
attribute 에 대해서 알아보도록 하겠습니다.

이 subject element 는 API에 접근이 가능한 widget 혹은 접근이
불가능한 widget을 구분하여 API에 접근하는 것을 제어할 수
있습니다. 일반 휴대전화에도 있는 white list/black list 라고
생각하면 더 이해하기 쉬울 것 같습니다.

그럼 이제부터 subject element 에 대해서 알아보도록 하겠습니다.

2. Subject element

이 subject element 는 BONDI에서 정의한 XML format 에 포함되는
element 로 widget 하나 혹은 여러 widget을 묶음으로 관리하기 위한
element 입니다.  이 element 는 subject-match라는 child element 를
가지고 있고, subject-match에 widget을 분류하는 attribute 들이
있습니다. 그럼 widget을 분류 하기위한 attribute가 어떠한 것이
있는지 알아보도록 하겠습니다.

 위의 표와 같이 여러가지의 attribute 들이 정의 되어 있습니다.
각 subject-match는 위의 attribute 를 하나씩 포함을 하고 있으며
여러개의 subject-match를 포함하고 있는 subject element 는
포함된 subject-match의 value 가 모두 TRUE 이어야만
subject 가 TRUE가 됩니다.

이렇게 하여 사업자, 제조사 그리고 사용자가 원하는 widget에게
필요한 만큼만 resource 를 open 함으로 악의적의 공격으로 부터
device 를 보호할 수 있게 됩니다.

3. Opinion

이번에는 subject에 관련된 것들을 알아보았습니다. 이 보안은
몇 번을 강조해도 지나치지 않다고 생각하는데요. 특히, widget
website에서도 device 의 resource 에 접근이 가능해지면서
보안은 더 중요시 되고 있는 것 같습니다. PC에도 중요한 정보가
많이 있겠지만 mobile device 의 경우는 많은 사람의 연락처 등
PC 못지 않게 혹은 PC보다 더 중요하고 많은 개인정보를 담고
있습니다. 보안 관련 솔루션을 개발하는 개발자들이 아무리
잘만들더라도 개인이 소홀이 할 경우 중요한 개인 정보는
해커들의 손에 넘어가게 되어 있습니다. 언제나 보안을 신경쓰는
습관을 들이는 것이 최고의 보안이 아닐까 생각합니다.
그럼 다음에 또 뵙겠습니다.

Reference

http://bondi.omtp.org/1.1/security/BONDI_Architecture_and_Security_Appendices_v1.1.pdf

오는 3월 8일부터 11일까지 런던 OMTP 사무실에서, BONDI Codefest가 열립니다.

Codefest 이벤트는 BONDI RI (레퍼런스 구현)가 BONDI 스펙에 따라 얼마나 잘 개발되었는지와 BONDI 스펙이 얼마나 잘 구현되었는지(실용성)를 동시에 확인할 수 있습니다.  또한 BONDI 스펙을 이용해서 새로운 위젯도 만들어서, 서로 가치를 나누는 자리이기도 합니다.

아직 자세한 일정은 나오지 않은 상태지만, 오가는 메일 내용을 볼 때 test 및 compliance가 주내용이라고 합니다. 보다 궁금하신 사항이 있으면, 댓글이나 메일 주시구요.

실제 진행되는 내용은 Codefest 참석 후, 후기를 올리도록 하겠습니다.
첫 Codefest이지만, 다행히 동료와 함께 참석하게 되어서 많은 준비를 해 갈 수 있을 듯 하네요.

BONDI 는 API 들을 정의하고, 이 API에 접근을 요청하는 Widget 의 접근을
제어하여 악의적인 요청으로 부터 device 를 보호하고 있습니다.

현재 BONDI는 XACML (eXtensible Access Control Markup Language )을
기반으로 compact 한 XML format 을 이용하여 API에 대한 접근을 제어하고
있습니다.
( 참고 : http://bondi.omtp.org/1.1/security/bondixml.rnc.txt - DTD)

이 포스트에서는 복잡한 알고리즘 보다는 실제 접근 제어에 사용되는
efftect value 인 Prompt-x에 대해서 알아보기로 하겠습니다.

2. Prompt-x

effect 에 들어갈 수 있는 value 는 총 5가지가 있다. 그 value 는 다음과 같습니다

• permit – This effect allows requested access without user interaction.
• deny – This effect denies requested access without user interaction.
• prompt-oneshot – This effect allow requested access after explicit confirmation by the user.
• prompt-session – This effect allow requested access after explicit confirmation by the user.
• prompt-blanket – This effect allow requested access after explicit confirmation by the user.

이 중 permit과 deny는 별다른 user interaction이 없는 value 이므로
별다른 혼란이 없이 사용되어 집니다.  하지만 prompt-x로 되어 있는 것들은
명백한 사용자의 확인에 의해서만 해당 API에 접근할 수 있는 value입니다.

prompt 의 경우 각 value별로 적용이 가능한 option을 보여주는 대화상자
(dialog)로 user와 interaction을 하게 됩니다. 이제 prompt 의 종류별로
어떠한 조건으로 user와 interaction 하는지 알아 보겠습니다.

2.1 prompt-oneshot

이 value의 spec을 먼저 보면 다음과 같습니다.
“deny always”, “deny this time”, “allow this time”
이 것은 user의 확인을 요하는 dialog에서 위와 같은 list를 주어
user 에게 해당 request 에 대한 확인을 요청하게 됩니다.
그 후 user는 위에 정해진 값 중 한가지를 선택하여 request에 대한
제어를 하게 됩니다.

(prompt-oneshot의 범위 : 해당 API에 대한 요청에 단 한 번만 유효함
                                      이후 동일 API에 대한 요청이 있으면 다시
                                       user의 확인 후 API 접근 가능.
                                      -단, deny always의 경우 WRT engine이 종료 
                                       될 때까지 유지)

2.2 prompt-session

이 value의 spec을 먼저 보면 다음과 같습니다.
prompt-oneshot options plus “deny for this session”,
“allow for this session” 이 것은 prompt-oneshot 에 있는
option에 다음과 같은 ”deny for this session”,
“allow for this session” list를 추가하여 user의 확인을
요하는 dialog를 띄워 user 에게 해당 request 에 대한
확인을 요청하게 됩니다. 그 후 user는 위에 정해진 값 중
한가지를 선택하여 request에 대한 제어를 하게 됩니다.

(prompt-session 의 범위 : widget application이 실행되어 있는 상태)

2.3 prompt-blanket

이 value의 spec을 먼저 보면 다음과 같습니다.
prompt-session options plus “allow always”.
이 것은 prompt-session 에 있는 option에 다음과 같은 ”allow always” 
list를 추가하여 user의 확인을 요하는 dialog를 띄워 user 에게 해당
request 에 대한 확인을 요청하게 됩니다.
그 후 user는 위에 정해진 값 중 한가지를 선택하여 request에 대한
제어를 하게 됩니다.

(prompt-blanket 의 범위 : WRT engine이 실행되어 있는 상태
                                        단, engine 이 static module 로 구동 될 경우
                                         terminal 이 off 되기 전까지)

3. Opinion

어떠한 보안도 100%로 안전하다고 볼 수는 없지만 현재 BONDI에서는 보안 문제에 상당히 많이 힘쓰고 있습니다. 처음에는 단순히 XML file에 접근제어 값을 넣어 제어하던 방식에서 현재는 signed policy document, provisioning 을 통한 policy update 등 많은 발전이 있었습니다. 그래도 부족한 점이 있겠지만 이렇게 계속 보안에 힘을 쏟는다면 그래도 사용자가 안전하다고 믿고 사용할 수 있는 product가 될 것이라 믿습니다. 마지막으로 제 포스트에 문제가 있으면 답글로 남겨 주시면 리뷰 후 정정 하도록 하겠습니다.

4. Reference

http://bondi.omtp.org/1.1/security/BONDI_Architecture_and_Security_Appendices_v1.1.pdf

1. windows mobile  6.x  emulator install

windows mobile 개발자라면 visual studio가 설치된 상태에서 window mobile SDK를 이용해서 emulator 실행을 간단히 할 수있겠지만 windows mobile 개발 환경이 없는 상황에서도 실행할 수 있는 Device Emulator를 이용하는 방법을 설명하겠습니다.

우선 아래 두 가지를 다운로드 받습니다.

- Microsoft Device Emulator 3.0 – Standalone Release

- Windows Mobile 6 Localized Emulator Images : 해당 지역의 emulator 이미지를 다운로드.

Device emulator는 windows mobile emulator 이미지를 실행하기 위한 툴입니다. 그리고 bondi RI가 windows mobile 6 이상을 지원하므로 그 이상의 emulator 이미지를 설치합니다.

정상적으로 설치가 되었다면 Device emulator와 windows mobile 6 이미지는 아래 각각의 디렉토리에 있게 됩니다.

- Device emulator 실행 경로 : C:\Program Files\Microsoft Device Emulator\1.0

- windows mobile 6 이미지 경로 : C:\Program Files\Windows Mobile 6 SDK\PocketPC\Deviceemulation

windows mobile 6이미지 아래의 경로를 보면 \ 0412디렉토리 아래에 이미지 파일들과  Pocket_PC_XXX 라는 이름의 이미지 스킨 파일들이 있습니다.

이제 Device emulator 설치 경로에 있는 DeviceEmulator.exe를 이용해서 이 중 하나의 이미지를 실행해 보겠습니다.

DeviceEmulator.exe는 command 기반의 프로그램입니다.  아래와 같이 옵션을 주고 실해을 합니다.

C:\Program Files\Microsoft Device Emulator\1.0\DeviceEmulator.exe” {이미지 파일의 경로} /skin {스킨 xml 파일 경로} /memsize 256

여기서 이미지 파일의 위에 설명한 것과 같이 \ 0412 디렉토리 아래의 이미지이름이며 스킨 xml 파일은 \Pocket_PC_XXX 아래에 있는 xml 파일의 경로를 지정합니다.  옵션들이 정확하다면 아래와 같은 emulator가 실행됩니다. 상세한 옵션은 DeviceEmulator.exe /? 로 확인하시면 됩니다.

이제 위의 emulator 기반에서 bondi RI를 설치하고 실행해 보겠습니다.

2. bondi RI install

bondi RI는 아래의 링크에서 다운로드 합니다.

- bondi RI : email을 등록하고 라이센스에 동의하면 email로 download 링크가 전송됩니다.

다운 로드 받은 파일의 압축을 풀면 BONDI 1.0 (alpha) SDK\Phone Distribution\BondiSetup1-006.CAB 파일을  windows mobile에 전송을 합니다. 전송은 windows mobile emulator의 File > configuration > general tab에서 Shared folder 기능을 이용하면 됩니다.

BondiSetup1-006.CAB 파일의 설치는 일반 windows mobile 프로그램 설치 방법과 동일합니다.

설치과 완료되면 windows mobile emulator의 프로그램에 Bondi라는 항목이 생성되고 실행을 하면 아래와 같은 화면이 나오게 됩니다.

bondi API 를 테스트 하고 실행하기 위해서 bondi RI를 windows mobile 환경에서 실행해 보았습니다. bondi API를 실행 테스트하기 위해서는 이외에 몇가지 다른 방법이 있는데 이는 reference link의 주소를 참고하십시오.

3. Reference Link

Bondi develping widgets : http://bondi.omtp.org/usebondi/Webpages/devtools.aspx

1. Introduction

BONDI는 API들를 정의하고, 이 BONDI interface들은 WebIDL과 Documentation(doxygen과 유사하게)로 기술되어 있습니다.

BONDI Module 은 BONDI interface들로 구성되어 있으며, 확장자가 “.widl”인 하나의 파일로 기술됩니다.

이 Module은 앞으로도 증가할 것이기 때문에, WebIDl과 Documentaion을 어떻게 구성해야하는지에 대한 rule을 정의할 필요가 있습니다.

본 문서에서는 이 Rule에 대해 정의하고 있습니다.

2. WebIDL patterns

BONDI API는 WebIDL (W3C’s interface definition language)으로 기술되어 있습니다.

2.1. Error Handling

WebIDL에서는 methods, getters 그리고 setters에서 exception 과 exception시 전달되는 object의 발생이 가능합니다.

WebIDL exception은 상속구조를 가질 수 없습니다.

하지만  BONDI module에서는 각 module 마다 자신의 error interface를 가질 수 있습니다.

그래서 BONDI에서 계층적 error를 지원하기 위해서는 BONDI error interface를 사용하여야 합니다.

• BONDI WebIDL 은 Exception에 대해 정의하지 않는다.
• BONDI WebIDL의 모든 error interface는 BONDI generic error interface에서 상속받는다. GenericError는 ECMAScript Error에서 상속받는다.
• GenericError에서 상속받은 object interface는 BONDI의 함수,  attribute getter, attribute setter를 통하여 인스턴스화 될 수 있다.
• Error object는 object의 prototype 및 constructor 그리고 GenericError object의 attribute인 “error code”에 의해 식별될 수 있어야 한다.
• Security와 관련된 error interface는 SecurityError에서 상속받으며, SecurityError는 GenericError에서 상속받는다.
• Error code 상수(constant)는
  • 대문자로 정의된다.
  • 접미사 “_ERROR”를 사용한다.
  • 단어는 “_”로 사용하여 구분된다.
  • DeviceAPIError interface 는 Common error code를 포함하며, GenericError에서 바로 상속받는다.
  • Module 에서 정의하는 error 상수는 0 부터 시작된다.
  • Common error code 는 10,000 – 19,999 구간에서 정의된다.
  • Security 관련 error 는 20,000 – 29,999 구간에서 정의된다.

WebIDL definition

interface Error {

        readonly attribute DOMString name;

        readonly attribute DOMString message;
};

interface GenericError : Error {

        readonly attribute unsigned short code;
};

interface DeviceAPIError : GenericError {

        const unsigned short UNKNOWN_ERROR           = 10000;

        const unsigned short INVALID_ARGUMENT_ERROR  = 10001;

        const unsigned short NOT_FOUND_ERROR         = 10002;

        const unsigned short PENDING_OPERATION_ERROR = 10003;

        const unsigned short IO_ERROR                = 10004;

        const unsigned short NOT_SUPPORTED_ERROR     = 10005;
};

interface SecurityError : GenericError {
        const unsigned short PERMISSION_DENIED_ERROR = 20000;
};

2.2. Asynchronicity

BONDI WebIDL에서 비동기 함수는

• 최소 2개의 parameter를 갖는다. 첫 번째는 SuccessCallback interface에서 상속받는 함수이며, 두 번째는 ErrorCallback interface에서 상속받는 함수이다.
• 비동기 함수는 에러를 발생시키지 않고, ErrorCallback를 통하여 에러를 전달한다.
• PendingOperation object를 리턴한다. 리턴값이 null이라면 비동기 함수가 이미 호출되었음을 의미한다.
• PendingOperation 은 object의 “cancel” 함수 호출을 통하여 비동기 함수의 실행을 취소할 수 있습니다.
• 이 “cancel” 함수는
  • 동기 방식으로 동작한다.
  • 항상 성공적으로 수행된다.
  • 리턴값이 true 이면 이미 callback 함수가 호출되었음을 의미한다.
  • false이면 성공적으로 취소되었음을 의미한다.

WebIDL definition

[Callback] interface SuccessCallback {

        void onSuccess(in Object ob);

};

[Callback] interface ErrorCallback {

        void onError(in Error error);

};

interface PendingOperation {

        boolean cancel();

};

2.2.1. How to combine APIs with architecture and security principles?

BONDI API의 설계시 ” BONDI Architecture & Security”의 원칙을 반드시 만족시켜야 합니다.

“BONDI Architecture & Security” 률은 아래와 같다.

• BONDI의 security policy를 따르는 함수는 비동기 방식으로 동작한다.
• attribute는 security policy를 따르지 않는다.

2.3. Namespaces and interface structure

BONDI Module 은 BONDI interface들로 구성되어 있는데, 이 계층을 나타내기 위해 WebIDl의 “implements” keyword를 사용합니다.

예를들어

Window implements bondiObject;

으로 정의된 경우 bondi interface가 Window object의 property임을 나타냅니다.

module bondi {
	interface bondi {
		...
        PendingOperation requestFeature (in RequestFeatureSuccessCallback successCallback,
                in ErrorCallback errorCallback,
                in DOMString name)
            raises (DeviceAPIError, SecurityError);
		...
	};

	interface bondiObject {
		readonly attribute bondi bondi;
	};

	Window implements bondiObject;
};

module calendar {
	interface CalendarManager {
	...
	...
	};

	interface Calendar {
	...
	...
	};

	interface CalendarManagerObject {
		readonly attribute CalendarManager calendarManager;
	};
	bondi implements CalendarManagerObject;

};

2.4. Data records, supported property keys and filters

BONDI API는 data와 관련된 검색 연산을 수행합니다.

BONDI module과  interface는 검색시 통일된 방법으로 filter를 표현하고 있습니다.

ECMAScript는 object의 property를 동적으로 추가할 수 있는데, 이는 매우 유용한 확장 구조입니다..

반면 저장 가능한 object를 다루기는 어려워 집니다.

왜냐하면, 어떤 platform에서는 미리 정의된 property와 그 값에 대해서만 저장할 수 있기 때문입니다.

그래서 상호 운영성의 측면에서 최소한의 property set을 정의할 필요가 있습니다.

그 결과, 다음과 같은 범주로 property를 나누게 되었습니다.

• interoperable data-carrying properties,
• platform-specific data-carrying properties,
• application-specific data-carrying properties,
• administrative properties.

property를 이러한 범주로 나누기 위해서,

저장 가능한 정보를 담고 있는 property들은 접미사  ”Properties”가 붙는 interface로 구성되도록 하였습니다.

예를 들면, contact의 경우 다음과 같은 기본 interface를 갖도록 처음 설계되었습니다.

    interface Address {
        attribute DOMString country;
        attribute DOMString postalCode;
    };

    interface Contact {
        readonly attribute DOMString id;
        attribute DOMString name;
        attribute DOMString email;
        attribute Address address;
	};

contact interface의 property 중 name, email, address 는 contact의 정보를 담고 있습니다.

반면 id 는 contact 정보가 아닌 관리상의 정보를 담고 있으며 platform에서 값을 할당하기 때문에 읽기 전용 속성을 가지고 있습니다.

따라서 아래와 같이 property-set 을 나눌 수 있습니다.

    interface ContactProperties {
        attribute DOMString name;
        attribute DOMString email;
        attribute Address address;
	};
    interface Contact : ContactProperties {
        readonly attribute DOMString id;
	};

• contact의 정보를 담고 있는 property는 ContactProperties interface로 구성한다.
• Contact interface  ContactProperties interface로 부터 상속받는다.

“interoperable data-carrying properties”는 XXXProperties interfaces에 속하며 모든 platform에서 사용 및 저장 가능하도록 구현되어야 하는 필수 property-set 입니다.

“platform-specific data-carrying properties”는 특정 platform에서만 사용 가능한 property 입니다.

“application-specific data-carrying properties”는 특정 application 에서만 사용 가능한 property 입니다.

XXX (XXXProperties 와 구별하기 위해) interface는 filter object를 생성할 때 사용됩니다.

그리고 지원하지 않는 filter object의 property는 구현부에서 무시해야 합니다.

<filter object의 생성 Rule>

• filter object는 XXX object의 JSON 형식으로 표현됩니다.

• filter interface는
  • GenericFilter로 부터 상속받는다.
  • XXX interface를 기반으로 하는 XXXFilter interface는 반드시 존재해야 한다.

• filter 연산의 결과 데이터는 아래 규칙에 의해 연산된다.
  • filter object에 property가 나열되지 않았다면, 해당 property 의 모든 값 그리고 전체 데이터가 대상임을 의미한다.
  • filter object에 포함된 property는 서로간에  SQL “AND”와 같은 연산방식으로 처리된다.
  • filter object가 null이라면, 전체 데이터를 반환한다.
  • 반환되는 result-set의 정렬 순서는 구현부에서 결정한다.

3. Architectural patterns

3.1. Versioning

BONDI interface는 앞으로도 계속 발전할 것이며, interface 들도 계속 수정도 될 것입니다.

앞으로 release될 버전은 method나 attribute가 추가되거나 삭제 또는 수정될 수 있습니다.

이 변경에 대처하기 위해 versioning model이 필요합니다.

BONDI API versioning은 API feature의 IRI 에 기반하여 정의되어 있습니다.

만약 feature의 기능이 변경되었다면, 새로운 IRI가 추가되어야 합니다.

3.2. API coverage by features

BONDI API는 사용자의 privacy 보호를 위해 security policy와 관련되어 있습니다.

몇 몇 API는 security 제한으로 접근이 되지 않을 수도 있고, 또 다른 API들은 해당 platform 이나 User Agent에서 유효하지 않을 수도 있습니다.

BONDI에서는 feature를 사용하여 API에 대한 접근 권한 제어를 하고 있습니다.

• 먼저 접근하려는 API들의 feature를  configuration 문서 (또는 프로그램적인 방법으로) 에 기술한다.
• 그리고 API의 접근요청이 오면, 접근에 대한 동의여부를 결정한다

이를 위해 모든 method, attribute, constant 는 적어도 하나의 feature에 속해야 합니다.

3.3. Feature-sets

Rich Web Application은 많은 BONDI API들를 사용합니다.

그리고 BONDI security model을 만족하기 위해 많은 feature를 configuration 문서 (또는 프로그램적인 방법으로)에 정의해야 합니다.

이는 Application 에 성능 저하를 줄 수 있으며, configuration 문서작성을 힘들게 합니다.

이를 해결하기 위해 BONDI에서는 feature-set을 정의합니다.

feature-set은 하나 이상의 feature를 포함하고 있습니다.

그리고 각 module은 적어도 하나 이상의 feature-set이 정의되어야 합니다.

festure-set은 module의 모든 feature를 포함할 수도 있습니다.

“The alliance plans to initially use both the JIL and OMTP BONDI requirements, evolving these standards into a common standard within the next 12 months. Ultimately, we will collectively work with the W3C for a common standard based on our converged solution to truly ensure developers can create applications that port across mobile device platforms, and in the future between fixed and mobile devices.”

올해 들어 가장 획기적인 뉴스가 아닌가 하네요. 게다가 JIL 과 BONDI를 기본으로 하여 1년안에 표준을 만든다니 !!.  이제는 Web language 공부를 정말 깊이있게 해야할 때가 아닌가 합니다. 요즘 느끼는 것이지만, JavaScript 를 누가 쉽다고 했는지,…

전 세계 30억명 이상의 가입자를 가진 대표적인 24개 통신 기업들과 3개 제조사가 공동으로 내년초 `앱스토어’ 도매장터를 만든다.

전 세계 이동통신 가입자 3분의 2 이상을 커버하는 상위 24개 통신사들이 공동으로 앱스토어를 만든다는 점에서 `글로벌 슈퍼 앱스토어’의 탄생이 예고됐다.

KT는 15일(현지시간) 스페인 바르셀로나에서 개막한 세계 최대 모바일 전시회인 `모바일 월드 콩그레스(MWC; Mobile World Congress) 2010′에서 전 세계 대표적인 24개 통신사가 참여하는 `도매 애플리케이션 커뮤니티(WAC, Wholesale App Community)’를 창설한다고 발표했다.

WAC에는 KT와 SK텔레콤을 비롯해 AT&T(미국), 버라이존 와이어리스(미국), 아메리카 모빌(멕시코), 프랑스텔레콤(프랑스), 도이체텔레콤(독일), NTT도코모(일본), 텔레포니카(스페인), MTN 그룹(남아공), 텔레콤 이탈리아(이탈리아), 텔레노어(노르웨이), 텔리아 소네라(스웨덴), 스프린트(미국), 보다폰(영국), 차이나유니콤(중국) 등 가입자 기준으로 세계 상위 20개 통신사가 모두 참여한다.

또 제조업체로는 삼성전자, LG전자, 소니에릭슨 등 3개사가 WAC를 지지한다고 밝혀 WAC와 공동 보조를 취하기로 했다.

WAC는 내년초 글로벌 앱스토어를 선보일 계획이다.

애플의 앱스토어가 특정 업체가 운영하는 소매 개념이라면, WAC가 구축하는 앱스토어는 도매장터 개념으로, 전 세계 통신사가 자사의 앱스토어와 연동해서 세계 각지에서 개발된 애플리케이션을 공급받을 수 있게 된다.

이는 궁극적으로 애플리케이션의 개발과 공급을 위해 전 세계적으로 통일된 글로벌 앱스토어 생태계가 완성되는 것을 의미한다.

전 세계 애플리케이션 개발자에게는 표준화된 개발 환경이 제공되고, 통신 사업자에게는 애플리케이션 조달의 규모의 경제가 마련돼 각종 새로운 서비스와 사업 기회를 창출, 무선데이터 시장을 획기적으로 활성화 시킬 수 기폭제가 된다고 KT는 설명했다.

WAC는 구축하는 앱스토어를 스마트폰을 중심으로 일반 휴대전화에서도 이용할 수 있도록 하고 앞으로 각종 모바일 기기 및 점진적으로 PC와 TV로도 확대할 수 있게 한다는 계획이다.

KT는 올해 초부터 유일한 아시아 사업자로서 AT&T, 도이체텔레콤, 프랑스텔레콤, 텔레포니카 등 4개사와 함께 WAC 창설을 주도해 왔으며, 이번 `MWC 2010′ 개막을 하루 앞둔 14일 이사회 회의에서 나머지 통신사들도 참여하는 전격적인 합의에 이르게 됐다고 밝혔다.

WAC 참여 업체들은 상반기 중 연합체 구성을 완료하고 전 세계 애플리케이션 개발자 풀(Pool)을 구성해 W3C 기반의 애플리케이션 프로그래밍 인터페이스인 API(Application Programming Interface) 규격에 따라 본격적인 앱스토어 구축에 들어갈 계획이다.

KT 등 통신사들이 이같이 공동 앱스토어 구축에 나서기로 합의한 것은 애플, 구글 등 비(非) 통신 업체들이 주도하는 앱스토어로 인해 개발자들이 단말기마다 다른 표준을 맞춰야하는 등 어려움이 많았기 때문이며, 애플리케이션 주도권 상실에 대한 위기의식도 작용한 것으로 풀이된다.

표현명 KT 개인고객 부문 사장은 “WAC 탄생에 KT가 세계이동통신사업자협회(GSMA) 이사로써 주도적인 역할을 했다”며 “국내 고객들은 풍부한 애플리케이션을 이용할 수 있게 되고 개발자들도 거대한 해외 시장에 진출할 수 있는 기회를 갖게 되는 것”이라고 강조했다.

참고>

Wholesale Applications Community (Wholesale ApplicationsCommunity)

30억명 이용 `슈퍼 앱스토어’ 만든다