'기타/BONDI'에 해당되는 글 5건

  1. 2010.11.02 BONDI Feature Access (1) 372
  2. 2010.08.12 PendingOperation 4
  3. 2010.08.03 BONDI Security & policy 3
  4. 2010.08.03 policy examples 1
  5. 2010.08.02 BONDI API design patterns 1
기타/BONDI2010. 11. 2. 17:04



BONDI Feature Access


Features의 인식과 구성에 관한것과 웹애플리케이션에서 그 정보에 어떻게 억세스하는지에 대한 요구사항에 대해 설명한다.


요구사항 요약과 원리

BONDI Web app의 의존성은 하나 이상의 features의 구성에 의해 결정된다.

하나의 Feature는 웹런타임에서 제공하는 연관된 기능에 대응된다. 이는 자바스크립트 인터페이스와 웹런타임의 동작에 대한 집합으로 정의된다.

하나의 feature는 유일한 IRI로 구분되며 BONDI web app에 의해서 의존성을 표현하는 하나의 유닛이다.

BONDI는 하나의 feature를 정의하거나 몇개의 feature를 정의하기도 한다. 각각은 인터페이스를 정의한다. BONDI framework에서 JavaScript API를 확장하고 싶다면 대응되는 feature를 반드시 정의해야 한다. JavaScript API와 feature를 추가하였다면 feature-set도 또한 정의해야 한다. IRI로 구분이 되며 feature들의 집합이다. 


framework과 연관된 요구사항들은 아래의 원칙들로 규합된다.

1. Feature 추가 : JavaScript API의 집합은 고정되어 있지 않다. 그리고 나중에 확장되기를 기대하고 있다. 

2. Feature 혁신 : 각 JavaScript API들은 스스로 시간이 지남에 따라 진화한다. 새로운 디바이스의 능력을 반영하기도 하고 새로운 유스케이스 또는 에러 수정, 이전 버전의 JavaScript의 결점을 보완하는것등을 통해서 진화한다. 

3. feature 정의의 분산 : feature의 정의는 어느 집단에 의해 제한되지 않는다. 누구나 정의가능하다(다만 다른디바이스와 호환은 포기).  feature의 정의는 단말생산자, 네트워운영자, 특별히 관심있는자, 각 서비스제공자나 퍼블리셔들에 의해 정의가능하다. 

프레임웍은 또한 동적으로 feature를 제공하기 위한 방안을 고려하여 설계 되었다.

4. 동적 feature 제공 : 확장메커니즘을 통해서 필드에 존재하는 디바이스에 새로운 feature를 추가할 수 있는 기능. 이 기능은 일반적으로 디바이스 플래싱을 다시하는 방법이 아니다. 확장메커니즘은 OS에서 제공가능한 방법이 되며 ActiveX나 브라우져의 플러그인등이 그방법이 될수 있다. 하지만 이 메커니즘은 반드시 제공되어야 하는 것은 아니며 feature 제공을 위해 표준화가 완전히 이루어진것도 아니다.

이런 원리가 의미하는것은 아래에 설명된다.

5. Feature들(interface와 구현을 포함하는)는 IRI로 구분이 가능하다.

6. 모든 Web App(website or widget)은 feature를 사용하기 위해 반드시 feature를 정의해야 한다.  이 정보는 Widget Recource의 Widget Configuration Document에 선언되어 있거나 또는 BONDI-defined API를 이용하여 프로그램으로 선언한수도 있다.

이 선언은 다음을 허용한다.

  - 웹런타임이 그 feature를 제공하는지 확인한다.

  - feature의 동적 제공을 허용한다.

  - 웹어플리케이션이 그 feature를 사용할 수 있는지 확인하는 억세스컨트롤을 허용한다.

  - 웹런타임이 어떤 feature를 로드하고 바인드해야 하는지 결정하는데 필요.

  - Widget User Agent가 위젯을 설치하기 전에 웹런타임에서 동작가능한 위젯인지 결정하는데 필요.


BONDI는 자체적으로 두종류의 feature를 정의한다.

1. BONDI JavaScript APIs : 이 feature는  BONDI-defined API와 직접적으로 연관된다. http://bondi.omtp.org/api/로부터 정의되어진다.

2. BONDI processing assertions : metadata와 assertions그리고 웹어플리케이션을 처리하기 위해 관련된 다른 directive들로 구성된다. http://bondi.omtp.org/meta/로부터 정의되어 진다.


위젯을 위해서 BONDI는 Widget Configuration Document에서 <feature> 태그로 위젯의 feature의존성을 기술할 수 있다.


의존성의 표현

BONDI는 다음 4가지를 정의한다.

1. Device Capability

2. JavaScript API

3. Feature

4. Feature Set


WebApplicaiton은 feature 의존성을 반드시 명시적으로 기술해야 한다. 웹런타임은 해당 feature가 명시적으로 요구되지 않은 상태에서는 유효한 feature가 없고 Security Policy에 의해 허용되면 접근가능지는 것을 보장해야 한다.

활성화된 접근성은 허용된 Web Application에 대해서만 유효하다.


요구사항

AS-0351 : 웹런타임은 반드시 명시적으로 연관된 feature를 기술하고 그 권한을 획득한 경우에만 JavaScript API를 사용할수 있게 해주어야 한다.

AS-0552 : 이미 유효한 feature가 있는지 결정할 수 있어야 함.


의존성의 정적 선언

Widget Configuration Document에 <widget> tag의 <feature> tag에 name과 required 속성으로 기술한다.

ex)

<widget xmlns="http://www.w3.org/ns/widgets" version="5602:5719M"id="http://tests.bondi.omtp.org/widgets/appconfig.wgt" width="640" height="480">

<name>BONDI appconfig compliance</name>

<author email="hendry@aplix.co.jp">Kai Hendry</author>

<feature name="http://bondi.omtp.org/api/bondi.requestfeature" />

</widget>

존성의 프로그래밍 표현

BONDI-defined APIrequestFeature를 통해서 표현 가능하다.

PendingOperation requestFeature(

      in RequestFeatureSuccessCallback successCallback,

      in ErrorCallback   errorCallback,

      in DOMString       name);


이 함수는 명명된 feature를 비동기로 요청을 하며 리턴값으로 pending operation object를 받는다. 성공하면 successCallback이 호출되며 실패하면 errorCallback에 DeviceAPIError가 발생한다. 


요청된 feature와 연관된 JavaScript API가 존재하면 모든 API들의 global property들이 successCallback이 호출되기 전에 접근가능해진다. 보통 해당 API set의 root object를 생성하며 생성이 성공하면 successCallback에 인자로 넘겨진다. 

Posted by 삼스
기타/BONDI2010. 8. 12. 16:33

BONDI interface API에서 PendingOperation은 비동기 호출에 있어서 중요한 요소이다.

이는 비동기 호출을 동기적으로 할 수 있는 방안을 제공하기도 한다. 즉 비동기 호출이지만 동기적으로 처리하고 싶을 때 사용할 수 있다.

아래와 같이 두개의 함수가 준비되어 있다.

PendingOperation.

        interface PendingOperation {
                boolean cancel();

                void wait();
        };

동작을 취소할 수 있는 방안을 제공하기 위해 고안된 비동기적으로 리턴하는 인터페이스이다.

cancel 함수

비동기적으로 백그라운드로 동작중인 동작의 취소를 호출한다. 이 함수는 항상 바로 리턴한다. false 리턴은 pending operation이 이미 끝났거나 기술적인 한계로 인해 cancel이 성공하지 못했을 때 한다. 결과적으로 동작은 완료 여부는 연계된 callback에 의해 결정난다. true 리턴은 취소가 성공했을 때 한다. 취소된 pending operation의 callback은 호출되지 않는다. wait중인 pending operation에 대해 cancel을 호출하면 false를 리턴한다. 즉 cancel은 성공하지 않는다.

wait 함수

비동기적인 동작이 끝날때 까지 대기한다. BONDI 비동기 메소드를 동기메소드인양 사용코자 할 때 사용가능하다.  동작이 끝날때 까지 thread는 대기 한다. 관련된 callback이 모두 처리된 후 리턴한다. 


아래의 예에서 "Feature loading accomplished"보다 "SUCCESS"나 "ERROR"가 먼저 뜨게 된다.
Code example
 var loadingsuccessful = 0;
 
 function successCB()
 {
                alert("SUCCESS");
                loadingsuccessful = 1;
 }
 
 function errorCB()
 {
                alert("ERROR");
                loadingsuccessful = 0;
 }
 
 function loadFeatureSynchronously()
 {
                var asyncop = bondi.requestFeature(successCB, errorCB, "http://bondi.omtp.org/api/messaging");
                asyncop.wait(); // waiting for messaging API to be loaded
                alert("Feature loading accomplished");
      return loadingsuccessful; // if 1, the messaging API was loaded synchronously and successfully
 }
 
 // The bondi.requestFeature() method is asynchronous by design.
 // bondi.requestFeature() start dummy asynchronous operation.
 // The call to loadFeatureSynchronously() results in SUCCESS or ERROR prompt prior to Feature loading accomplished prompt.
 
Posted by 삼스
기타/BONDI2010. 8. 3. 17:39
BONDI는 하드웨어 자원에 접근할 수 있는 방안을 제공하는 기술이기 때문에 아무런 보안 제약사항이 없이 지원될 경우 사용자 개인정보가 유출되는 등 심각한 문제가 발생할 수 있다.

따라서 Security framework와 policy를 지원한다.

아래 그 특징을 나열하였다.

1. 어플리케이션 단위의 접근권한정책을 제어할 수 있다.
2. XML문법으로 기술되며 XACML spec(OASIS)에 정의되어 있는 보안모델을 따른다.
3. Widget과 Web application은 기본적으로 BONDI API에 접근되지 않는다.
4. 개개의 Widget과 Web application별로 사용하고자 하는 API에 대한 policy file로 관리된다.

이 는 명시적으로는 사용자에게 아래와 같은 통지 메세지를 띄우는 등의 형태로 구현될 수 있다.

"이 애플리케이션은 인증되었으며(digital signature), geolocation APIs에 접근가능합니다"라는 메세지를 표시하여 사용자에게 통지

제한적인 기본 API지원
 일반적으로 아주 제한적인 API들은 사용이 가능하다. 
 1. file system의 경우 application에 할당된 local hard disk에 접근하는것까지 허용
 2. Network access는 오직 하나만의 web site만을 접근가능하도록 한다.

XACML에 비하여 BONDI의 security는 아주 단순하다. 
  - namespace를 하나만 사용한다, XACML은 여러개의 XML namespace를 사용한다.
  - policy markup문법은 더 단순하며 policy를 정의하는데 주안점을 둔다.

실세계에서 적용하기 위해 아직 완전하지 않는 두가지가 있다.

1. 누가 다양한 환경에서의 policy file을 작성할 것인가.
  mobile cell network 운영자 또는 서비스사, 단말사, 브라우져제공자, 사용자등... 누가 할것인가???
2. 어떤 UX를 제공할것인가. 
  각각 API에 대한 접근권한을 허용하는 것을 어디에서 할것인가..


Posted by 삼스
기타/BONDI2010. 8. 3. 13:40
permit policy

<!-- has target for http://www.omtp.org/GigGuide -->
<policy-set combine="first-matching-target">

  <policy combine="first-applicable" description="catch">
    <rule effect="permit">
      <condition>
        <resource-match attr="device-cap" match="webvm.bind"/>
      </condition>
    </rule>
    <rule effect="permit"></rule>
  </policy>

</policy-set>



deny policy

<!-- has target for http://www.omtp.org/GigGuide -->
<policy-set combine="first-matching-target">

  <policy combine="first-applicable" description="catch">
    <rule effect="permit">
      <condition>
        <resource-match attr="device-cap" match="webvm.bind"/>
      </condition>
    </rule>
    <rule effect="deny"></rule>
  </policy>

</policy-set>


prompt policy
<!-- has target for http://www.omtp.org/GigGuide -->
<policy-set combine="first-matching-target">

  <policy combine="first-applicable" description="catch">
    <rule effect="permit">
      <condition>
        <resource-match attr="device-cap" match="webvm.bind"/>
      </condition>
    </rule>
    <rule effect="prompt-blanket"></rule>
  </policy>

</policy-set>





Posted by 삼스
기타/BONDI2010. 8. 2. 11:01
http://bondikorea.wordpress.com/2010/02/22/the-bondi-api-design-patterns-version-1-1/

The BONDI API Design Patterns – Version 1.1

BONDI 1.1 api에 대해 알아보기 앞서, api를 좀 더 잘 이해하기 위해  The BONDI API Design Patterns – Version 1.1 에 대해 알아보겠습니다.

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를 포함할 수도 있습니다.

Posted by 삼스