KR100959173B1 - 컴포넌트 아키텍처 - Google Patents

Abstract

기기를 제어하기 위한 자가편성 소프트웨어는 최소 2개의 컴포넌트를 담고 있다. 각각의 컴포넌트는 다른 컴포넌트들과 연결하기 위한 적어도 하나의 인터페이스를 구비하는데, 컴포넌트들의 각각 자체는 컴포넌트 규칙들을 정의하는 정보를 담고 있다. 컴포넌트들에 담겨 있는 컴포넌트 규칙들은 컴포넌트들이 각각의 다른 컴포넌트들과 연결되어서 외부의 규칙 데이터베이스들이 필요하지 않도록 하는 방법을 정의한다.

Description

컴포넌트 아키텍처{Component architecture}

본 발명은 전반적으로 컴포넌트 아키텍처들에 관한 것이다. 더 구체적이지만 전적으로는 아닌 것으로, 본 발명은 이동 기기들을 위한 자가관리(self-managing) 컴포넌트 아키텍처에 관한 것이다.

컴포넌트 아키텍처들은 소프트웨어 업계에서 널리 사용되고 있다. 재구성가능한 아키텍처들은 모바일 미들웨어 및 자가관리 시스템들에서 그것들의 관련성 때문에 최근에 주의를 끌고 있다.

모바일 애플리케이션 플랫폼들의 공통적 속성은 환경의 활력이다. 서비스들은 지리적인 위치 또는 다른 단말들에 대한 근접도에 기초하여 이용 가능할 수 있거나 이용가능하지 않을 수 있게 된다. 이용 가능한 서비스들 및 그것들의 요구된 속성들(대역폭, 기기 속성들, 이를테면 화면 크기)에 기초하여, 애플리케이션들은 자신들을 적응시킬 수 있고 그것들의 통신에 소용이 되는 미들웨어가 필요해진다. 널리 사용되고 있는 접근방법은, 컴포넌트 모델을 사용하는 것과 새로운 컴포넌트들을 애플리케이션들에 추가하고 애플리케이션들로부터 제거하는 것에 의해 또는 애플리케이션 컴포넌트들을 다른 미들웨어 컴포넌트들에 연결하는 것에 의해 컴포넌트들의 연결("배선")을 동적으로 변경하는 것이다.

동적 배선(wiring)은 이른바 반사형(reflective) 미들웨어에 필요하다. 반사형 미들웨어는 프로그램이 자신 소유의 코드 베이스 및 미들웨어의 코드 베이스에 관한 정보에 액세스 가능하게 하는 반사 원리에 기초하고 있다. 그때에 프로그램은 행동 패턴들을 분석할 수 있고 그 행동을 적응시킬 수 있다. 이것을 달성하는데 요구되는 변경은, 잘 알려진 계층적 분해를 사용하여 실현될 수 없는 애플리케이션 로직을 위해 중요할 수 있고 지름길이 될 수 있다.

추가적인 배경 기술은 여기에 참조로써 통합되는 다음의 참고문헌들에 개시되어 있다: Jeremy S. Bradbury et al.: A Survey of Self-Management in Dynamic Software Architecture Specifications, Proc. of the International Workshop on Self-Managed Systems (WOSS'04), Newport Beach, California, USA, October/November 2004; Marija Mikic-Rakic and Nenad Medvidovic: Support for Disconnected Operation via Architectural Self-Reconfiguration. 모든 그런 아키텍처들은 컴포넌트 시스템을 기술하기 위해 약간의 외부 정의 언어를 사용하는 것처럼 보인다. 종래 기술은 주로 추론 엔진과 규칙 설명에 집중한다.
Kon, F., "Automatic configuration of component-based distributed systems", PhD thesis, University of Illinois at Urbana-Champaign, 2000는 컴포넌트간 의존도의 명백한 표현이 효율적, 구성가능한 및 신뢰성 있는 컴포넌트 기반 시스템들의 개발에 기본이라는 것을 증명한다. 분산형 컴포넌트 시스템들에서 의존도들을 관리하기 위한 일반 아키텍처가 제시되고 이 아키텍처의 구체적인 구현예가 기술된다. 이 아키텍처는 자동 구성 서비스, 컴포넌트 구성기 프레임워크 및 재구성 에이전트 프레임워크의 3가지 부분으로 나누어진다.
Georgiadis, I., Magee, J. & Kramer, J., "Self-organising software architectures for distributed systems", WOSS'02, 2002는 컴포넌트들이 그것들의 상호작용을 전체 아키텍처 사양서에 호환하는 방식으로 자동으로 구성되는 자가편성 소프트웨어 아키텍처를 개시한다. 그 목적은 아키텍처 제약을 분산형 시스템들의 자가편성 아키텍처들의 사양서, 디자인 및 구현을 위한 토대로서 유지하면서도 작성 및 후속하는 발전에 필요한 명시적인 관리 정도를 최소화하는 것이다.
Georgiadis, I., 'Se1f-organising distributed component software architecutes", PhD thesis, University of London, 2002는 구조가 컴포넌트를 사용하여 소프트웨어 아키텍처 항목들에서 지정되는 분산형 시스템들의 자동 작성 및 재구성에 관계가 있다. 더 상세하게는, 이 논문은 아키텍처상의 제약, 조정하는 재구성 작용들의 생성, 및 그 작용들을 잠재 분산형 방식으로 실행이라는 3가지 하위 문제들에 관계한다.

알려진 종래 기술은 중앙집중식(centralized) 규칙 엔진을 사용하지만, 불행히도 그 규칙 엔진을 위한 철저한 규칙 베이스를 생성하는 것은 어렵고, 규칙 엔진의 오작동의 경우에는, 자가적응(self-adaptation)은 실패할 것이다.

본 발명의 목적은 종래 기술의 문제들을 적어도 완화하고 및/또는 새로운 기술적 대안을 제공하는 것이다.

본 발명의 제1양태에 따르면, 각각의 컴포넌트가 다른 컴포넌트들과의 연결을 위한 적어도 하나의 인터페이스를 구비하는 적어도 2개의 컴포넌트를 구비하는 자가편성(self-organising) 소프트웨어를 포함하는 기기로서, 자가편성 소프트웨어는 계층적 컴포넌트 모델에 따라 편성되고 컴포넌트들의 각각은 컴포넌트들에 저장되는 정보를 그 컴포넌트가 다른 컴포넌트들에 연결 가능한지에 따라 컴포넌트 규칙들을 정의하는 메타정보로서 담고 있는 기기가 제공된다.

유익하게는, 자가편성 소프트웨어는 외부 규칙 데이터베이스들에 독립하여 동작될 수 있다.

컴포넌트들은 컴포넌트들의 인터페이스들이 다른 컴포넌트들의 인터페이스들에 연결 가능한지에 따라 인터페이스 규칙들을 정의하는 정보를 더 담고 있을 수 있다. 기기는 컴포넌트 규칙들보다 인터페이스 규칙들이 우위에 있도록 추가로 구성될 수 있다.

컴포넌트 규칙들 및/또는 인터페이스 규칙들은 만족되어야 할 어떤 조건을 요구하는 옵션적인 규칙들을 담고 있을 수 있다.

유익하게는, 컴포넌트 규칙들보다 우위에 있고 조건부 규칙들을 제공하는 인터페이스 규칙들은, 각각이 추가의 유연성을 제공할 수 있다. 유익하게는, 이것은 일부 인터페이스들의 존재가 보통의 컴포넌트 규칙들보다 우위에 있는 특수한 의미를 가지는 것을 허용한다. 예를 들면, 단지 어떤 컴포넌트 인터페이스들만이 연결될 수 있다고 언급하는 것이 필요할 수 있다. 이 경우, 컴포넌트 규칙은 연결을 사용할 수 없게 할 수 있지만 인터페이스 규칙은 그것을 사용 가능하게 할 수 있다. 그 결과는 인터페이스 규칙들이 지정되었던 인터페이스들은 연결될 수 있지만 다른 인터페이스들은 그렇게 할 수 없다는 것이다.

각각의 컴포넌트 및 또는 각각의 인터페이스는 주어진 가중치 또는 우선순위에 연관될 수 있고 상기 기기는 이 가중치들 또는 우선순위들에 의존하여 인터페이스들을 연결하도록 구성될 수 있다. 유익하게는 우선순위들 또는 가중치들은 컴포넌트들의 소망하는 조합들 또는 연결들을 지원하는 재연결 프로세스를 강화할 수 있다.

컴포넌트들의 각각 또는 적어도 일부는 수명을 가지는 컴포넌트들이 수명 후에 삭제되는 기설정된 옵션적으로 개별적인 수명에 연관되어 있을 수 있다.

삭제

컴포넌트 규칙들 및/또는 인터페이스 규칙들은 컴포넌트들에 메타정보로서 저장될 수 있다. 메타정보는 다음 옵션들 중의 어느 것을 포함할 수 있다: 당해 컴포넌트에 연결될 수 있는 다른 컴포넌트의 요구된 속성 및 그것의 값을 정의하는 필수 속성들; 당해 컴포넌트에 연결하려는 다른 컴포넌트가 존재한다면 주어진 값을 가져야만 하는 상기 다른 컴포넌트의 속성을 정의하는 조건부 속성들; 및 다른 컴포넌트의 속성이 연결하지 않아야 한다는 값들을 정의하는 금지 속성들. 속성들의 값들은 단일 값으로서, 범위들로서 또는 복수의 값들 및/또는 범위들로서 주어질 수 있다.

컴포넌트들은 그것들의 메타정보를 노출할 수 있는 프리미티브 컴포넌트들을 구비할 수 있다. 컴포넌트들은 다른 컴포넌트들의 연결들을 배치하는 것에 의해 다른 컴포넌트들을 포함할 수 있는 하나 이상의 복합 컴포넌트들로서 복합 컴포넌트에 포함되는 다른 컴포넌트들에 의존하여 메타정보를 노출할 수 있는 하나 이상의 복합 컴포넌트들을 구비할 수 있다.

유익하게는, 복합 컴포넌트, 또는 컨테이너는 복수 개의 컴포넌트들이 통일된 방식으로 함께 작용하도록 그리고 하나의 강화 컴포넌트로서 보이도록 할 수 있는 복합 단위를 생성할 수 있다. 유익하게는, 복합 컴포넌트는 프리미티브 컴포넌트들 및 복합 컴포넌트들의 어느 한쪽이나 양쪽을 포함할 수 있다.

복합 컴포넌트는 복합 컴포넌트에 포함되는 컴포넌트들을 담기 위한 도메인 저장소에 연관될 수 있다. 도메인 저장소는, 도메인에서 연결되어 있지 않고 아직 만기가 되지 않은 컴포넌트들을 저장할 수 있다. 컨테이너는 도메인 저장소를 유지하도록 그리고 컴포넌트들이 복합 컴포넌트에 참가하는지 또는 복합 컴포넌트를 떠나는지에 의존하여 컴포넌트들을 도메인 저장소 속으로 그리고 도메인 저장소 밖으로 옮기도록 구성될 수 있다.

컴포넌트들은 컴포넌트가 참가할 수 있는 컨테이너를 결정하는 슈퍼 속성들을 가질 수 있다.

상기 기기는 컴포넌트가 도메인 저장소 속에 삽입될 때 복합 컴포넌트에 포함되는 모든 컴포넌트들 재연결하도록 구성될 수 있다. 상기 기기는 최근의 재연결들로부터 어떤 새로운 재연결을 구별할 수 있는 재연결 식별을 확립하도록 구성될 수 있어, 도메인 저장소 내의 각각의 컨테이너는 새로운 재연결 동안 그것이 점검되었는지를 인식할 수 있다.

유익하게는, 상기 기기는 컴포넌트 아키텍처의 환경의 변경들에 기초하여 필요한 컴포넌트 배선들을 결정할 수 있다.

유익하게는, 상기 기기는 생물학적 세포들의 행동을 모방하는 것으로 보일 수 있다. 컴포넌트는 각각이 특유의 유형인 옵션적 및 필수 인터페이스들로 나누어지는 인터페이스들 또는 포트들을 포함할 수 있다. 컴포넌트는 모든 필수 인터페이스들이 다른 컴포넌트들에 연결될 때 기능할 수 있게 될 수 있다. 함께 연결하려는 컴포넌트들이 공통 유형의 인터페이스들을 가지는 경우에만 컴포넌트가 다른 컴포넌트에 연결될 수 있다.

상기 기기는 활동적이 아닌 컴포넌트들(예를 들어, 모든 그것들의 필수 인터페이스들은 점유되지 않았다)을 저장하도록 구성될 수 있다. 상기 기기는, 새로운 컴포넌트가 시스템에 추가될 때, 일치하는 인터페이스들을 검색하기 위해 이용 가능한 컴포넌트들의 인터페이스들을 점검하도록 추가로 구성될 수 있다.

유익하게는, 시스템은 새로운 유형의 자가관리형 컴포넌트 아키텍처를 제공할 수 있다. 종래에 알려진 자가관리형 컴포넌트 아키텍처와는 달리, 적응에 관한 지식(규칙들 또는 제약들)은 컴포넌트들의 인터페이스들 내에 구성될 수 있다. 바꾸어 말하면, 서술(description) 파일들의 어떠한 부가적인 중앙집중형 데이터베이스도 적응을 통제하는데 필요하지 않다.

컴포넌트들은 다른 벤더들에 의해 제공될 수 있다. 일부 컴포넌트들은, 예를 들어, 개방 소스 소프트웨어(OSS)에 기초하여 제공될 수 있는 반면, 일부 다른 컴포넌트들은 상업적일 수 있고 특허 라이선스들에 의존할 수 있다. 이것은 OSS를 이용하는 애플리케이션의 비보호 부분들을 제공하는 것을 추가로 가능하게 할 것이다.

본 발명의 제2양태에 따르면 기기를 제어하기 위한 자가편성 소프트웨어로서, 자가편성 소프트웨어는 계층적 컴포넌트 모델에 따라 편성되고 각각의 컴포넌트가 다른 컴포넌트들과의 연결을 위한 적어도 하나의 인터페이스를 구비하는 적어도 2개의 컴포넌트를 구비하며, 컴포넌트들의 각각은 컴포넌트들에 저장되는 정보를 그 컴포넌트가 다른 컴포넌트들에 연결 가능한지에 따라 컴포넌트 규칙들을 정의하는 메타정보로서 담고 있는 자가편성 소프트웨어가 제공된다.

본 발명의 제3양태에 따르면 계층적 컴포넌트 모델에 따라 편성된 소프트웨어를 자가편성하는 방법에 있어서, 각각의 컴포넌트가 다른 컴포넌트들과의 연결을 위한 적어도 하나의 인터페이스를 구비하고 컴포넌트 규칙들을 정의하는 메타정보를 저장하는 적어도 2개의 컴포넌트를 식별하는 동작, 메타정보로부터 컴포넌트들의 각각에 특유한 컴포넌트 규칙들을 얻는 동작, 및 규칙들에 기초하여 컴포넌트들의 각각이 다른 컴포넌트들에 연결 가능하게 되는 방법을 결정하는 동작을 포함하는 방법이 제공된다.

소프트웨어는 데이터 매체로 운반되거나 및/또는 저장되는 또는 데이터 신호에 삽입되는 컴퓨터 제품 또는 제품들로서 제공될 수 있다. 소프트웨어는 또한 하나 이상의 기기들(배포형 모델)에 의해 호스팅 될 수 있다.

종속 청구항들과 전술의 실시예들은 본 발명의 다른 실시예들에 관련된다. 실시예들에 포함되고 본 발명의 특정 양태에 관련하는 주제는 본 발명의 다른 양태들에 필요한 변경을 가하여 적용될 수 있다.

이제 본 발명의 실시예들이 첨부 도면들을 참조하여 예로써만 설명될 것인 데, 도면들 중에서

도 1a는 본 발명의 실시예에 따른 장비의 블록도를 보이며;

도 1b는 도 1a의 장비에 의해 사용되는 소프트웨어 환경의 요소들의 세부사항의 블록도를 보이며;

도 2는 본 발명의 실시예에 따른 계층적인 컴포넌트 아키텍처 모델을 보이며;

도 3은 컴포넌트 인터페이스들의 예시적인 연결을 보이며;

도 4는 컴포넌트 네트워크들을 변경하기 위해 우선순위들을 사용하는 것을 예시하며;

도 5는 최우선 컴포넌트 속성들을 인터페이스 속성들과 함께 도시하며;

도 6은 양방향 컴포넌트 인터페이스들을 도시하며;

도 7은 데모 그룹들을 생성하는 것을 도시하며;

도 8은 개별 데모 컴포넌트들을 삭제하는 것을 도시하며;

도 9는 데모 애플리케이션에서 그리드 및 탭형(tabbed) 보기 사이의 변경에 관한 컴포넌트 연결 재배치구성을 도시하며;

도 10은 데모 애플리케이션에서 성능 모니터를 가동시키는 것에 관한 컴포넌트 연결 재배치구성을 도시하며;

도 11은 계층에서 컴포넌트 그룹들을 옮기는 것을 도시하며;

도 12는 데모 애플리케이션의 연결들을 재배치함에 있어 프레임워크의 및 컴포넌트들의 동작을 도시하는 세로 스케줄을 가지는 인과관계 도표를 보인다.

다음에서, 2가지 예가 도면들에 관해서 기술될 것이다. 이것들 둘 다는 동적 배선을 가지는 컴포넌트 아키텍처들을 예시한다. 이들 2가지 예 중의 어느 것이라도 도 1a에 보인 장비(100)로써 수행될 수 있다.

도 1a는 동적 유선 애플리케이션들, 즉, 요구된 특징들이 로딩되고 실행되며 새로운 특징들 또는 컴포넌트들이 동작 동안에 도입되도록 자신을 자동적으로 적응할 수 있는 소프트웨어를 실행하기 위한 장비(100), 이를테면 이동 통신 기기(MCD)를 보인다. MCD(100)는 통신 블록(110), 사용자와의 데이터 교환(입력 및 출력)을 위한 사용자 인터페이스(120), 장비(100)에 전력을 공급하기 위한 배터리(130), 컴퓨터 프로그램 코드(141) 및 장기간 데이터(142)를 저장하기 위한 지속성 또는 비휘발성 메모리(140), 빠른 처리를 위해 데이터를 버퍼링하기 위한 작업 메모리(150), 및 저장된 컴퓨터 프로그램 코드를 실행하고 그것에 의해 MCD(100)의 다른 부분들의 동작을 전반적으로 제어하기 위한 프로세서(160)를 포함한다. 통신 블록(110)은 전형적으로는 컴퓨터 사용자 데이터와 아마도 프로그램 코드도 셀룰러 네트워크로 수신하고 및/또는 전송할 수 있는 셀룰러 무선통신망 호환성 유닛과 같은 무선 블록이다.

도 1b는 도 1a의 장비에 의해 사용되는 소프트웨어 환경의 요소들의 세부에 대한 블록도를 보인다. 이 요소들은 전형적으로는 지속성 메모리(140)에 저장된 컴퓨터 프로그램 코드(141)로 구성되고, 바닥으로부터 세어서 서로 적층되어 실행되는 다음과 같은 주요 요소들, 즉 운영 체계(1410), 자바 실행 환경(JRE)과 같은 객 체 지향 플랫폼(1411), 프랙털 컴포넌트 프레임워크의 줄리아 2.1 구현과 같은 일반 컴포넌트 프레임워크 소프트웨어(1412), 컴포넌트들을 자동으로 연결하기 위해 필요한 동적 컴포넌트 배선 프레임워크 애플리케이션(1413) 및 프레임워크 애플리케이션(1413)의 제어 하에 제어기 아키텍처 소프트웨어 위의 별도의 컴포넌트 인스턴스들로서 실행할 수 있는 복수 개의 소프트웨어 컴포넌트들(1414)을 포함한다. 객체 지향 플랫폼(1411)은 객체 생성, 객체 메소드들의 호출(invocation)과 같은 객체 추상화(abstraction)를 제공하는 소프트웨어 시스템일 수 있다.

컨테이너들에 포함되는 복수의 소프트웨어 컴포넌트들은 전형적으로는 이른바 프리미티브 컴포넌트들, 즉, 동적 합성에서 사용을 위해 그것들의 제약들을 노출할 수 있는 컴포넌트들이다.

컨테이너들은 밑에 있는 프레임워크(1413)에 대한 메소드 호들을 이용하는 것에 의해 또는 그렇지 않으면 그 프레임워크에게 그렇게 하도록 지시하는 것에 의해, 추가의 복합 컴포넌트들을 포함하여, 복합 컴포넌트에 포함되는 다른 컴포넌트들을 재배치할 수 있다. 복합 컴포넌트가 관리하는 컴포넌트들의 모음(collection)은 복합 컴포넌트의 도메인이라고 한다. 복합 컴포넌트들은 또한 그것들의 제약들을 프레임워크(1413)(이것들을 컴포넌트들로부터 질의할 수 있다)를 통해 프리미티브 컴포넌트가 하는 것과 동일한 방식으로 노출할 수 있다. 복합 컴포넌트들은 추가로 컴포넌트들을 복합 컴포넌트 속에 및 복합 컴포넌트 밖으로 전달할 때에 참여할 수 있다.

컴포넌트들이 실행을 위해 메모리에 컴퓨터 실행가능 코드로서 저장될 수 있 다는 것과 컴포넌트들이 실행될 때 작업 메모리(150)에서 그것들 소유의 풋프린트를 점유하고 프로그램 또는 컴포넌트 인스턴스들로서 서비스한다는 것은 객체 지향 프로파일들로부터 잘 알려져 있다. 이 문서에서, 컴포넌트 인스턴스들은, 지속성 메모리에서 그것들의 물리적 저장소가 논의되지 않는 한, 간결함을 위해 일반적으로 컴포넌트들이라고 한다. 여기에서의 다른 실시예들의 목표는 불필요하게 메모리를 소비하는 컴포넌트 인스턴스들로부터 작업 메모리(150)를 자유롭게 하는 것이다. 컴포넌트들의 파괴와, 다른 용어들은 작업 메모리(150)에서 컴포넌트의 표현의 삭제를 기술하기 위해 의도된 반면, 컴포넌트 자체는 컴포넌트가 필요할 때마다 동일한 코드를 계속적으로 얻는 것을 피하기 위해 지속성 메모리(140)에서 전형적으로 유지된다.

제1예

상황에 따라 네트워크 기반 또는 독립형 사용을 위해 MCD(100)에서 실행하는 기업 인벤토리 애플리케이션이 있다. 기업 인벤토리 애플리케이션은 애플리케이션이 고속 링크에 의해, 공설(public) 인터넷에 대한 고속 네트워크에 의해, 기업 네트워크에 대한 저속 연결에 의해 기업 네트워크에 연결되어 있는지 또는 애플리케이션이 기업 네트워크에 결코 연결되어 있지 않은지에 의존하여 다르게 동작하고 있다. 애플리케이션은 UI 컨테이너를 포함하여 데이터 액세스 컴포넌트들에 연결되는 몇 개의 사용자 인터페이스(UI) 컴포넌트들을 담고 있다. UI 컴포넌트들은 항상 존재하는 필수(mandatory) 컴포넌트들과 애플리케이션이 어떤 정황(context) 또는 정황들에서 사용될 때에만 존재하는 보조 UI 컴포넌트들을 포함한다. 데이터 액세 스 컴포넌트들은 다음의 방식으로 사용되는 통신 채널에 의존한다:

■ 애플리케이션이 고속 링크를 통해 기업 네트워크에 연결할 수 있을 때, UI 컨테이너는 제품 또는 상세한 제품 문서화의 영상들과 같은 일부 컴포넌트들을 인벤토리 또는 현재 재고 수준에 추가한다. 고속 링크 때문에 서버의 대기시간이 낮고 동기식 통신이 가능할 때 데이터 액세스 컴포넌트는 서버에 직접 연결한다. 데이터 액세스 컴포넌트는 기업 인증 컴포넌트를 이용한다. 그것에 의해 데이터 액세스 컴포넌트는 기업 환경에 어울리는 통신 프로토콜, 이를테면 공통 객체 요구 브로커 아키텍처(common object request broker architecture; CORBA)를 사용한다. 또한 애플리케이션은 재고 정보를 온-디바이스(on-device) 데이터베이스에 미연결식 사용을 위한 계획된 간격으로 자동으로 복제한다.

■ 애플리케이션이 공설 인터넷에만 연결될 수 있고 기업 서비스들을 이용하도록 인증되지 않았을 때, 애플리케이션에는 이를테면 웹 서비스들을 통해 공설로(publicly) 제공되는 제한된 인벤토리 서비스들에 대한 액세스가 주어진다. 이 제한된 인벤토리는 현재 재고 수준을 질의하는 것을 허용하지 않고, 덜 상세한 제품 문서화가 이용가능하다. 그래서, 이용 가능하지 않은 데이터를 디스플레이하는 UI 컴포넌트들이 제거되고 데이터 액세스 컴포넌트는 서비스 가능 데이터 액세스 컴포넌트에 의해 교환되도록 UI 컨테이너는 애플리케이션을 이용 가능한 제한된 데이터에 적응시킨다. 복제 컴포넌트들은 또한 제거된다.

■ 저 대역폭 통신만이 이용 가능할 때, UI 컨테이너는 애플리케이션의 호스트 기기 위에서 국소적으로 복제된 데이터베이스를 사용하기 위해 애플리케이션을 복귀시킨다. 기기 저장 공간이 휴대형 기기에서 부족하므로, 세부사항은 이용할 수 없다. 반대로, UI는 더 적은 UI 컴포넌트들을 담고 있고 데이터 액세스 컴포넌트는 국소적으로 복제된 데이터베이스에 연결한다. 저속 복제 컴포넌트가 설치된다. 동시에, 다른 통신 프로토콜이 선택될 수 있는데, 저속 베어러가 적당하게 적응된 복제 전략으로부터 이익을 얻기 때문이다. 또한, 복제는 자동이 아닌데 그것이 기기의 완전한 통신 대역폭을 잠재적으로 소모하는 장기적인 프로세스이기 때문이다. UI 컨테이너는, 복제를 수동으로 개시하기 위해 그리고 복제가 진행하는 동안 상태 표시를 나타내기 위해 지시된 컴포넌트들로써 UI를 갱신한다.

■ 네트워크에 대한 연결이 없을 때, UI 컨테이너는 모든 복제 특징들을 제거한다.

도 2는 본 발명의 실시예에 따른 계층적 컴포넌트 모델을 보인다. 도 2는 개별적으로 제1 및 제2 복합 컴포넌트들인 컴포넌트들(C1_1 및 C2_1)(즉, 다른 컴포넌트들의 컨테이너들)과 컨테이너들(C1_1 및 C2_1)이 포함하는 컴포넌트들(C1 내지 C8)을 포함하여 다수의 컴포넌트들을 보인다. 제1컨테이너는 2 미연결 컴포넌트(C1 및 C2)를 담고 있는 반면, 3개의 다른 컴포넌트는 연결된다("서로 배선된다"고 알려짐). 컴포넌트들은 인터페이스들(일명 포트들)을 통하여 통신한다. 인터페이스들은 옵션일 수 있거나 필수일 수 있다(도 3 참조). 인터페이스는 유형화되는데, 즉, 공통 유형의 인터페이스들만이 연결 가능하다. 컴포넌트는 그것의 필수 인터페이스들의 모두가 다른 컴포넌트들에 연결된 경우에만 기능을 할 수 있다. 도 3에서, 양쪽 컴포넌트들인 A 및 B는 그것들의 필수 인터페이스들이 연결되어 있고 그것들의 옵션적 인터페이스 들 중의 하나 또한 연결된다. 컴포넌트 A는 하나의 미연결 옵션적 인터페이스를 가지지만 필수 인터페이스들이 연결되어 있으므로, 양쪽 컴포넌트들은 기능을 할 수 있다.

컴포넌트 모델은, 본 발명에 대한 뒤늦은 지혜(hindsight)를 사용하여, 살아 있는 생물학적 세포의 프로세스들과 닮았다는 것을 알 수 있다. 자가관리 로직이 "게놈"에 따라 생성되는 컴포넌트들에 분산되어 있다. "게놈"은 생성되어야만 하는 컴포넌트들의 목록에 상응한다. 이 컴포넌트들은 유형화된 인터페이스들을 가지고 만일 모든 요구된 인터페이스들이 만족된다면, 즉, 만일 올바른 유형 및 수량의 미연결 인터페이스를 가지는 다른 컴포넌트들이 있다면, 컴포넌트는 자동으로 연결된다. 미연결 컴포넌트들은 시스템에서 자유롭게 순환하고, 그것들의 수명이 다할 때까지 저장된다.

컴포넌트들은 또한 스스로 파괴될 수 있다. 예를 들면 만일 어떤 컴포넌트가 기설정된 시간 동안 요구를 받지 않으면, 그것은 자신을 파괴할 수 있고 그래서 전체 컴포넌트 네트워크를 잠재적으로 파괴할 수 있다. 이것은 메모리가 절약되도록 미사용 기능들이 청소되는 것을 허용한다. 요구가 도착할 때, 컴포넌트 연쇄(chain)는 게놈으로부터 재건될 수 있다.

컴포넌트들은 컴포넌트 네트워크상에 충분한 제어를 가지며, 그것들은 기존의 연결을 파기할 수 있고 그것들 자신을 기존의 컴포넌트 네트워크들 속에 구축할 수 있고, 그것들은 "게놈" 부분들의 처리를 착수할 수 있거나 다른 컴포넌트들을 시스템 속에 해제(release)할 수 있거나 또는 그것들은 게놈 자체를 변경할 수도 있다. 그 결과는 자가-적응 로직이 개별 컴포넌트들 속에 배포되고, 단지 다른 컴포넌트들을 시스템 속에 주입하거나 "게놈"를 연장하는 것에 의해 용이하게 확장될 수 있다는 것이다.

컴포넌트 연결들을 제어하기 위해, 속성들이 컴포넌트들 및 컴포넌트 인터페이스들에 지정될 수 있다. 속성들은 예컨대 "이 컴포넌트는 속성 a=5인 컴포넌트들에만 연결될 수 있다" 또는 "이 컴포넌트는 속성 a=5인 컴포넌트들에 연결되지 않아야 한다" 또는 "이 컴포넌트는 임의의 값으로 설정된 속성 "a"를 가지는 컴포넌트에 연결될 수 있다"와 같은 규칙들을 표현할 수 있다. 컴포넌트 프레임워크는 컴포넌트들 중에 단순 또는 복합 정합 규칙들을 사용할 수 있다.

컴포넌트 인터페이스들에 지정되는 속성들은 컴포넌트들에 지정되는 속성들에 덮어쓸 수 있다. 예를 들면, 컴포넌트 속성이 이 컴포넌트는 값 5의 속성 "a"(a=5)를 가지는 컴포넌트에 연결되지 않아야 한다는 것을 정의할 수 있다. 인터페이스에 지정된 속성은 이 규칙에 덮어쓸 수 있고, 이 인터페이스가 속성 a=5를 가지는 다른 컴포넌트의 개개의 인터페이스를 요구한다는 것을 나타낼 수 있다. 이 경우, 인터페이스에 지정된 속성 규칙들은 컴포넌트에 지정된 속성들보다 우위에 있다. 도 5는 이 효과를 보여준다.

2개의 컴포넌트가 연결될 수 있는지를 결정하기 위해 사용되는 속성 집합 외에, 컴포넌트가 부모(parent) 컴포넌트의 도메인 속에 놓일 수 있는지를 결정하는데 이용되는 다른 속성 집합이 있다. 이 속성 집합은 슈퍼 속성들이라고 불린다. 컴포넌트는 부모 컴포넌트의 도메인 속에 시험적으로 놓일 수 있고 그 다음 그것의 슈퍼 속성들은 부모 컴포넌트의 보통의 속성들에 대하여 일치될 수 있다. 만일 일치하는 것이 있으면 컴포넌트는 이 도메인 속에 놓일 수 있고 이 도메인의 컴포넌트들에 연결될 수 있다. 만일 일치하는 것이 없으면, 컴포넌트는 이 도메인 속에 놓일 수 없고 저장이 종료되게 하거나 이 도메인 밖으로 나가게 될 것이다.

이 아키텍처가 사용되는 환경에 따라, 컴포넌트들은 서로 통신하기 위해 국소적 메소드 호출들 또는 원격 프로토콜을 사용할 수 있다.

인터페이스들도, 그것들에게 지정되며 인터페이스들이 연결되어야 하는 순서를 나타내는 우선순위들을 가진다. 이것은 하나의 컴포넌트가 자신을 이미 연결된 컴포넌트들의 네트워크 속에 삽입하는 것을 가능하게 한다. 만일 기존의 연결들의 우선순위들이 도입(incoming) 컴포넌트의 인터페이스 우선순위들보다 낮고 도입 컴포넌트가 기존의 컴포넌트 네트워크에 연결될 수 있다면, 가장 높은 우선순위의 인터페이스 연결이 이긴다. 그래서, 도입 컴포넌트는 오래된 컴포넌트(들)를 교체할 수 있고 도입 컴포넌트는 오래된 컴포넌트들 가운데 자신을 구축할 수 있다(도 4 참조).

미연결 필수 인터페이스들을 가지는 컴포넌트들은 미해결이라고 말해질 수 있고, 소유 컴포넌트에 지정되는 저장 영역에 저장된다(도 2 참조). 컴포넌트들은 그것들이 저장소에서 소비할 수 있는 (아마도 무제한인) 수명을 가진다. 만일 컴포넌트가 저장 수명을 초과하면, 그것은 파괴된다.

응용 프로그램은 그것의 새로운 컴포넌트들을 도메인에 도입한다. 컨테이너의 도메인은 프레임워크를 사용하여 (재)연결되는데, 즉, 프레임워크는 복합 컴포 넌트를 대신하여 역할을 한다. 프레임워크는 컴포넌트들을 연결하고, 미연결 컴포넌트들을 복합 컴포넌트에 속한 저장소에 넣어서 각각의 복합 컴포넌트가 자신 소유의 저장소를 가지게 한다.

컴포넌트들은 새로운 컴포넌트를 그것들의 도메인에 도입하기 위한 메커니즘을 가진다. 새로운 컴포넌트들이 복합 컴포넌트의 도메인에 도입될 때, 해결 프로세스는 시작한다. 이 프로세스 동안, 인터페이스 유형들, 우선순위들 및 저장소의 미사용 컴포넌트들은 새로운 컴포넌트 네트워크(이것은 오래된 것과 동일할 수 있다)를 생성하는데 이용된다. 해결 프로세스의 끝에 새로운 컴포넌트 네트워크는 셋업되고 미사용 컴포넌트들은 저장소에 넣어진다.

컴포넌트들은 이출(export) 및 이입(import) 필터들에 기초하여 도메인들 사이에서 밖으로 나가게 되거나 들여와 진다. 이출 필터는 미연결 컴포넌트 저장소의 컴포넌트들에 대해 작용한다. 이출 필터에 의해 선택된 컴포넌트들은 이 도메인의 저장소로부터 제거되고 부모 컴포넌트의 저장소에 놓이고 그 다음 부모 컴포넌트의 도메인은 해결된다. 마찬가지로, 이입 목록이, 부모 컴포넌트의 미연결 컴포넌트 저장소의 컴포넌트들을 선택하고 그것들을 자식 도메인에 들여와서 해결을 프롬프트한다. 이출 및 이입 필터들은 부모 및 자식 도메인들 사이의 미연결 컴포넌트들의 흐름을 지배한다.

제2예

Dynacomp라고 불렀던 모델 구현예가 다음으로 기술된다. Dynacomp는 프랙털 프레임워크의 위에 "E. Bruneton and T. Coupaye and J. Stefani , Recursive and dynamic software composition with sharing , In Proceedings of the 7 th ECOOP International Workshop on Component-Oriented Programming ( WCOP "02), Malaga (Spain), June 2002"에 의해 기재된 바와 같이 구축된다. Dynacomp 프레임워크는 프랙털의 복합 및 프리미티브 컴포넌트 유형들을 확장하는 2 유형의 컴포넌트들을 사용한다. 프랙털의 특징들에 부가적으로 다음의 기능들이 Dynacomp 컴포넌트 유형들에 의해 제공된다.

Dynacomp 모델을 기술할 때에 사용되는 용어들은 다음으로 설명되고 그 뒤에 자바 기반 사례 연구가 설명된다.

제약은 개개의 컴포넌트 인스턴스들에 의해 제공된다. 그러므로, 컴포넌트 인스턴스들은 이 제약에 의해 재연결 절차를 직접 제어한다. 컴포넌트들은 프랙털 프레임워크에서 이미 이용 가능한 상당히 제한된 메타정보에 더하여 추가의 메타정보를 담고 있다. 다음의 메타정보들이 이 예에서 사용된다.

인터페이스 이름: 각각의 인터페이스는 이름이 지어지고 동일한 이름을 가지는 인터페이스들만이 연결될 수 있다. 인터페이스 이름 규약은 프랙털 네트워크로부터 직접 온다.

인터페이스 방향: 프랙털 네트워크 클라이언트(발신) 및 서버(착신) 인터페이스들 외에, 동적 합성 프레임워크는 양방향 인터페이스 유형을 도입하는데, 도 6을 참조하라. 컴포넌트 노출 양방향 인터페이스는 논리적으로 동일한 이름을 가지는 하나의 클라이언트와 하나의 서버 인터페이스를 가진다. 프랙털 제한 때문에, 실제 이름들은 동일하게 될 수가 없다. 하나의 양방향 인터페이스는 다른 양방향 인터페이스에만 연결될 수 있다. 양방향 인터페이스는 랜덤 방향에서 연결되는데, 예를 들면, 제1컴포넌트의 클라이언트 인터페이스는 제2컴포넌트의 서버 인터페이스에 연결된다. 제1컴포넌트 상의 서버 인터페이스는 제2컴포넌트의 클라이언트 인터페이스는 미연결인 채로 남아 있다. 양방향 인터페이스들은 동일한 유형의 어떤 컴포넌트 인스턴스들이 서로 연결되어야만 한다는 스테이트먼트(statement)를 나타낼 수 있다. 양방향 인터페이스의 개념 없이, 이 스테이트먼트는 연결 그래프에서 루프를 생성할 것이고 그래서 컴포넌트 네트워크는 시작될 수 없다.

인터페이스 다중도: 프랙털은 홀로인 것(singleton)과 모음 기수(collection cardinality) 사이에 차이를 만든다. 자동 합성은 허용된 인터페이스 연결들의 더 정밀한 설명을 필요로 한다. Dynacomp는 "H. Cervantes and R. S. Hall , Automating Service Dependency Management in a Service - Oriented Component Model , ICSE CBSE6 Workshop, 2003"에 의해 설명된 서비스 바인더의 기수 설명을 채택한다. 인터페이스(클라이언트와 서버)의 기수는 하나, 하나 이상, 영 또는 하나, 영 또는 그 이상의 연결들일 수 있다. 기수는 클라이언트 및 서버 인터페이스들 둘 다를 위해 지정될 수 있다.

인터페이스 우선순위: 우선순위는 모든 컴포넌트 인터페이스들에 할당된다. 우선순위는 검색 기준을 만족하는 다수의 컴포넌트 인터페이스들이 있는 경우에 어떤 컴포넌트 인터페이스를 연결을 위해 선택할지를 결정한다. 연결하려는 인터페이스들의 우선순위들은 추가되고 가장 큰 합을 가지는 인터페이스 쌍은 연결을 위해 선택된다.

컴포넌트와 인터페이스 속성: 서비스 바인더와 닮았다면, 컴포넌트 인스턴스 또는 인터페이스 속성들을 일치시키는 것에 의해 컴포넌트 인스턴스 기수들을 좁히는 것이 가능하다. 서비스 바인더는, 개방 소스 서비스 게이트웨이 주도(Open Source Service Gateway Initiative; OSGi) 서비스 속성 규약에 따라, 속성들이 컴포넌트의 개개의 인터페이스들에 지정되는 것을 허용한다. Dynacomp는 인터페이스에 지정된 속성들에 의해 무시될 수 있는 컴포넌트들에 우선적으로 속성들을 지정한다. 이 속성들은 매우 단순한 패턴 언어에 따라 일치된다. 이 언어는, 다른 컴포넌트는 어떤 값을 가지는 어떤 속성을 가지고 있어야만 한다(필수 속성)는 것과, 다른 컴포넌트는 어떤 속성을 가질 수 있고 이 경우에 값은 일치하는 컴포넌트의 값과 동일하게 되어야만 한다(옵션적 속성)는 것 및 다른 컴포넌트는 어떤 값을 가지는 어떤 속성을 가지는 것이 허용되지 않는다(금지 속성)는 것을 기술할 수 있다. 패턴 또는 제약 언어는 풋프린트-복잡도 타협점(trade-off)이다. 더 복잡한 제약 언어가 유리하지만 더 많은 메모리와 재연결 시간을 요한다.

슈퍼 속성들: 컴포넌트들은 컨테이너가 그 속에 놓일 수 있는 컨테이너 컴포넌트를 결정하는 슈퍼 속성들을 가질 수 있다. 컴포넌트는 그것의 슈퍼 속성들이 컨테이너의 속성들과 일치하는 경우에만 컨테이너 속에 이입될 수 있다. 정합(matching) 규칙들은 컴포넌트 및 인터페이스 속성들의 그것들과 동일하다.

이출 및 이입 목록들: 컨테이너들은 어떤 컴포넌트들이 이 컨테이너의 도메인을 떠날 수 있고 어떤 컴포넌트들이 이 컨테이너 속으로 옮겨질 수 있는 지를 제어하는 이출 및 이입 목록들을 가질 수 있다. "CHAM , or P. Inverardi , A.L. Wolf , Formal Specification and Analysis of Software Architectures Using the Chemical Abstract Machine Model, IEEE Transactions on Software Engineering , volume 21, no . 4, 1995"는 유사(resembling) 메커니즘을 가지지만 CHAM은 그것을 컴포넌트들 대신에 데이터 항목들에 적용한다. 이출 및 이입 목록들은 인터페이스 이름들을 담고 있다. 만일 미연결 컴포넌트가 이출 또는 이입 목록에 관한 이름을 가지는 인터페이스를 가진다면, 그것은 더 높은 (둘러싸는) 도메인에 이출될 수 있거나 또는 더 높은 도메인으로부터의 컴포넌트는 이 도메인 속으로 이입될 수 있다. 이입은 컴포넌트의 슈퍼 속성들이 도메인의 속성들과 일치하는 경우에만 일어난다.

타임아웃: 미연결 컴포넌트들은 타임아웃 후 "만기가 되"고 프레임워크에 의해 저장소로부터 제거된다.

생성 시간: 프레임워크는 컴포넌트들이 생성될 때 타임스탬프를 그 컴포넌트들에 배치한다. 이 타임스탬프는 컴포넌트 나이에 기초하여 충돌 해결 로직을 이행하기 위해 사용될 수 있는데, 예를 들면, 만일 컴포넌트가 도메인의 일부 다른 컴포넌트와 충돌하고 있다는 것을 그 컴포넌트가 검출한다면, 살아남는 컴포넌트는 덜 오래된 것일 수 있다.

생성 목록: 각각의 컴포넌트에는 생성 목록이 할당된다. 이것은 컴포넌트 이름들의 목록이다. 이 목록은 또한 레이블들을 포함할 수 있다. 생성 목록은 한 집합의 컴포넌트들을 도메인에 삽입하는 것에 의해 도메인이 재배치되어야 하는 방법에 관한 시나리오라고 간주될 수 있다. 어떤 이벤트가 발생할 때, 이벤트 핸들러는 어떤 레이블을 생성 목록에서 조사할 수 있고, 이 레이블부터 시작하여 다음 레이블까지 생성 목록 내에 이름이 있는 모든 컴포넌트들을 생성할 수 있다. 이 활동은 컴포넌트 자체(자신의 생성 목록을 사용하는 것)에 의해 또는 다른 컴포넌트의 생성 목록을 전문화하거나 처리하는 컴포넌트에 의해 행해질 수 있다.

인터페이스 이름, 방향, 다중도 및 우선순위는 동일한 유형의 각각의 컴포넌트에 대해 공통이며, 다른 메타정보는 컴포넌트 인스턴스마다 설정될 수 있다.

먼저, 컴포넌트가 컨테이너의 도메인 속에 삽입되고 프레임워크는 도메인을 배치구성한다. 이것은 프레임워크가 컴포넌트 인스턴스를 시작하도록 하기 위해 일어난다. 컴포넌트들은 그것들의 제약에 따라 중단되며, 연결되고, 연결된 컴포넌트들은 의존성 순서로 시작되고 미연결 컴포넌트들은 도메인의 저장소 속에 놓인다. 저장소의 컴포넌트들은 더 높은 도메인으로 이출될 수 있거나, 이 도메인에 있는 컨테이너의 도메인 속에 이입되거나 또는 만일 미연결 컴포넌트의 타임아웃이 만기가 되었다면 삭제된다. 정확한 알고리즘은 아래에서 기술된다. 이 설명의 목적으로 시스템 내에 미리 존재하는 컴포넌트들의 집합은 C라고 표시된다. 삽입하는 컴포넌트는 c _i 라고 표시되고 컴포넌트가 삽입되는 도메인이 무엇인지는 c _p 라고 표시된다. c의 도메인에 있는 컴포넌트들의 집합은 child (c)라고 표시되고 c가 상주하는 컨테이너는 parent(c)라고 표시된다. parent (c)는 이론적으로는 하나의 집합이지만 Dynacomp는 하나의 컴포넌트가 다수의 도메인의 부분일 수 있는 프랙털 특징을 지원하지 않는다. Dynacomp 모델에서 c ∈ C인 임의의 c에 대해 |parent (c)| ≡ 1이 다.

재연결 절차에는 식별 번호가 지정된다. 이 재연결 ID는 고유할 것임에 틀림없어(연속 재연결 패스들은 다른 ID들을 가져야만 한다) 각각의 컨테이너는 이 재연결 패스에 의해 방문되었는지를 인식할 수 있게 된다.

c _i 는 프랙털 수준에서 c _p 의 서브컴포넌트로서 추가된다.

c | c ∈ child ( c _p )인(즉, c ∈ child ( c _p )의 조건을 만족하는) 모든 c는 중단되고 컴포넌트는 분리된다.

c _p 도메인에 있는 컴포넌트들(저장소의 그것들을 포함)은 재연결된다. 인터페이스들을 연결할 때, 프레임워크는 인터페이스 이름들, 속성들, 방향 및 다중도를 고려한다. 재연결 시간을 최소화하기 위해, 알고리즘은 탐욕적이고, 그것은 가장 높은 우선순위를 가지는 인터페이스들을 연결하고, 더 많은 컴포넌트가 결국 비 탐욕(non-greedy) 전략으로 연결될 수 있는지를 고려하지 않는다는 점에 주의한다. 연결 패스 후 컴포넌트들은 컴포넌트의 각각의 필수 인터페이스가 연결될 때 해결된다고 말해질 수 있다. 미해결의 컴포넌트는 저장소에 넣어진다.

저장소는 아래쪽으로, c _p 의 복합 서브컴포넌트들 쪽으로 전파된다. 각각의 복합 서브컴포넌트는 어떤 컴포넌트를 저장소에 이입할 수 있는지(저장소의 어떤 컴포넌트는 그것의 이름이 복합 서브컴포넌트의 이입 목록에 있는 인터페이스를 가짐)와 저장소의 컴포넌트들의 슈퍼 속성들이 복합 서브컴포넌트의 그것들과 일치하는지가 검사된다. 만일 어떤 컴포넌트가 복합 서브컴포넌트에 이입될 수 있다는 것이 확인되면, 그 서브컴포넌트는 이입 후 재연결된다. 부수효과로서, c _p 도메인에서 다른 재연결 패스를 요구하는 복합 서브컴포넌트는 해결될 수 있다.

저장소의 컴포넌트들이 타임아웃에 대해 점검된다. 컴포넌트가 저장소에 들어갈 때, 그것의 타임아웃을 위한 기준이 설정된다. 이 기준 시간은 타임아웃을 계산하기 위해 사용된다. 만일 컴포넌트의 타임아웃이 만기가 되면, 프레임워크는 그 컴포넌트를 제거한다.

만일 어느 복합 서브컴포넌트라도 해결되었다면, 컴포넌트들은 다시 분리되고 다른 반복이 발생한다. 이것은 무한 반복일 수 있다는 점에 주의한다. 이것은 이 알고리즘에 의해 해결될 수 있는 컴포넌트 네트워크들을 생성할 것이 기대되는 프로그래머의 잘못이라고 간주된다.

c _p 도메인의 모든 컴포넌트들이 의존성 순서로 시작된다. "Michael C. McFarland, Tutorial on High - Level Synthesis , 25 th ACM / IEEE Design Automation Conference , 1988 IEEE"에 기재된 ASAP(Simple As Soon As Possible) 스케줄이 계산되고 더 낮은 ASAP 시간을 가지는 컴포넌트들이 먼저 시작된다. 이 프로세스 동안 복합 서브컴포넌트들은 재귀적으로 시작되며 - 복합 서브컴포넌트들이 시작될 때, 그 도메인의 모든 서브컴포넌트 또한 시작된다.

컴포넌트 네트워크는 컴포넌트들이 시작될 때 변할 수 있다. 예를 들면 일부 컴포넌트의 startFc() 메소드는 컴포넌트 자체 또는 다른 일부 컴포넌트를 삭제할 수 있고, 그래서 연결된 컴포넌트들은 미해결로 될 수 있다. 만일 어떤 컴포 넌트가 컴포넌트 네트워크의 시작 동안 미해결로 된다면, 전체 재연결 절차는 재시작된다.

여전히 저장소에 있는 컴포넌트들은 parent ( c _p )에 전파된다. 이 프로세스는 c _p 의 이출 목록, parent ( c _p )의 슈퍼 속성들 이출하는 컴포넌트의 속성들에 의해 제어된다. 만일 이출이 성공적이라면, 이출된 컴포넌트는 c _p 도메인으로부터 제거되고, parent(c _p )의 도메인에 놓이고 그 다음 parent ( c _p )는 재연결된다. 재연결 ID를 사용하는 것에 의해 프레임워크는 재이입이 가능했다라고 해도 이출된 컴포넌트가 이 재연결 패스 동안 c _p 도메인 속으로 재이입되지 않을 것임을 보증한다. 이것은 부모 및 자식 컨테이너들 사이의 컴포넌트로써 "핑-퐁"을 방지한다.

알고리즘의 최적화 기준만이 최적의 전역 컴포넌트 배치구성을 근사화한다는 것이 이해되어야만 한다. 탐욕(greedy) 연결 알고리즘은 그것이 높은 우선순위 인터페이스들에 대해 할 수 있는 만큼의 많은 수의 컴포넌트들을 연결한다. 만일 컴포넌트가 어떤 도메인에서 연결될 수 있다면, 비록 컴포넌트가 다른 도메인에 대해 이출되거나 이입될 수 있고 그 다른 도메인의 우선순위 합이 더 높을 수 있을지라도 그 다른 도메인에서 이 컴포넌트를 연결하도록 시도하는 것은 결코 하지 않을 것이다. 컴포넌트 개발자들은 이 사실을 알고서 컴포넌트 메타정보를 사용하여 그들이 소망하는 연결들을 생성하여야 할 것이다.

사례 연구: Java2D 데모

동적 합성이 다음에서 친근한 Java2D 데모 애플리케이션에 대해 데모로서 설명될 것이다. Java2D는 표준 Java 2D API의 그래픽의 능력들을 데모로 보여주기 위한 예의 프로그램으로서 모든 썬 마이크로시스템즈 자바 개발 키트로서 출하된 스윙(Swing) 애플리케이션이다. Java2D 데모 및 밑에 있는(underlying) Java 2D API는 전적으로 자바로 구현되고 데모는 상당히 동적이라서 쓰레기 수거기(garbage collector)에 상당한 부하를 준다. 히프(heap)에 필요한 메모리는 라이브 객체들의 크기들의 합뿐만이 아니고 현실적인 성능을 달성하기 위해, 수 배 더 많은 메모리가 필요하다. Java2D는 컴포넌트들 속에 팩토링(factoring)될 수 있어서 사용자는 그녀가 필요로 하는 때에만 인스턴스생성(instantiation)을 할 수 있다. 미사용 서비스들은 인스턴스생성되지 않을 것이고 그러므로 메모리는 절약될 수 있다. 동적 합성이 이 버전에서 어떻게 가능하게 되는지를 증명하기 위해 리팩토링된 Java2D에서 발생하는 컴포넌트 인스턴스생성 및 재연결의 몇 가지 사례들이 보이게 된다. 처음의 상호작용은 사용자가 사용할 수 있는 데모 집합에 그녀가 데모들을 추가하는 것을 허용한다(도 7). 데모들은 데모 그룹들로 분류되고 하나의 데모 그룹은 하나의 탭에서 표현된다. Java2D 코어 애플리케이션(메인 프레임과 인트로)은 java2d 컴포넌트의 하나의 인스턴스에 의해 표현된다. 먼저 데모 그룹이 생성된다. 하나의 데모 그룹은 하나의 복합 DemoGroupContainer에 의해 표현된다. 이 복합 컴포넌트는 하나의 데모 그룹 컴포넌트 인스턴스(DemoGroupArcsCurves, DGAC)와 영(제로) 이상의 데모 컴포넌트 인스턴스들을 담고 있다. 먼저 DemoGroupContainer와 DemoGroupArcsCurves는 java2d가 있는 동일한 도메인 속에 생성된다. 데모 그룹을 위한 슈퍼 속성과 컨테이너를 위한 속성이 있다. (demogroup=arcscurves). 이것은 데모 그룹이 동일한 demogroup 속성을 가지는 컨테이너 속에만 놓일 수 있다는 것을 의미한다. 2개의 컴포넌트가 생성된 후, 재연결은 시작된다. 컴포넌트들 중의 어느 것도 연결될 수 없는데 컨테이너의 내부 인터페이스들이 연결되지 않았고 데모 그룹 슈퍼 속성이 java2d의 부모의 속성들과 일치하지 않고 그러므로 그것들 양쪽 다가 저장소에 놓이기 때문이다. 그러나 컨테이너는 데모 인터페이스로써 컴포넌트들을 이입할 수 있고 그래서 데모 그룹은 컨테이너에 이입되고 컨테이너는 재연결된다. 이때 연결이 성공하며, 컨테이너의 필수 내부 인터페이스들은 연결되고 컨테이너는 해결된다. 그러면, 이것은 java2d의 수준에서 재연결을 트리거하고 java2d와 컨테이너는 그것들의 데모 인터페이스들을 통해 연결된다. 컴포넌트들이 재시작될 때, java2d는 그것의 데모 클라이언트 인터페이스의 연결 벡터를 점검하고 만일 검출된 새로운 데모 연결이 검출된다면, java2d는 그룹의 이름을 질의하며, 탭을 생성하고, 탭에 대한 데모 그룹 컴포넌트에 의해 생성된 Java2D 애플리케이션의 사용자 인터페이스 상의 데모 그룹을 위해 확보된 탭에 데모 그룹 컴포넌트에 의해 생성된 묘화(drawing) 영역을 추가한다. 데모 컴포넌트들은 데모 그룹 속에 비슷하게 놓인다. 그러나 데모 컴포넌트가 그룹으로부터 제거되는 때의 상호작용은 흥미롭다(도 8). 이 경우 java2d는 DemoItemDestructor 컴포넌트의 인스턴스를 그것의 도메인 속에 생성하고, 그것의 속성들을 데모 컴포넌트를 담고 있는 DemoGroupContainer 속에 소멸자(destructor) 컴포넌트가 이입될 그리고 그 파괴자 컴포넌트가 제거하려는 데모 컴포넌트에만 연결될 그런 방식으로 설정한 다(demogroup 및 demoitem 속성들은 컨테이너를 선택하고 그래서 데모 컴포넌트를 선택하기 위해 사용된다). 소멸자의 demoitem 인터페이스의 우선순위는 상승하여서 만일 소멸자가 데모 컴포넌트의 도메인 속에 전파되면, 그것은 데모 컴포넌트를 데모 그룹 컴포넌트로부터 "훔칠" 것이다. 컴포넌트들이 재시작될 때, 소멸자는 데모 컴포넌트와 그것의 자체 트리거링 재연결 둘 다를 파괴한다. 그 효과는 데모 컴포넌트가 존재하지 않게 한다는 것이다. 데모 그룹들은 그것들이 동일한 표면상의 그리드나 탭형 페인(tabbed pane)의 탭들 상에 개별적으로 데모들을 표현할 수 있다는 특징을 가진다. 도 12를 참조하면, Java2D가 컴포넌트화되었을 때, 이 기능은 DemoGroupTabbedPane(DGTP) 컴포넌트 인스턴스를 데모 그룹 및 데모 컴포넌트들(도 9) 사이에 삽입(121)하는 것에 의해 리팩토링되었다. DemoGroupTabbedPane은 데모 그룹이나 데모 컴포넌트들보다 높은 우선순위들을 가지는 클라이언트 및 서버 demoitem 인터페이스들 양쪽 다를 가진다. DGAC는 DBTP의 생성을 요구한다(122). 그래서, 데모 그룹 재연결 후, 클라이언트 인터페이스는 DemoGroupTabbedPane의 서버 인터페이스에 연결될 것이고(123) 모든 데모 컴포넌트들은 DemoGroupTabbedPane의 클라이언트 인터페이스에 연결될 것이다. 이것은 DemoGroupTabbedPane가 탭형 페인을 사용하여 데모 컴포넌트들을 디스플레이하고 숨기는 것을 허용한다. 프랙털은 동일한 이름의 인터페이스들을 컴포넌트들이 가지는 것을 허용하지 않는다는 것에 주의한다. Dynacomp는 논리적으로 동일한 이름들을 생성하기 위해 네임 맹글링(name mangling)을 제공한다. 그리드 보기로 되돌아가게 전환하는 것은 DemoGroupTabbedPane 컴포넌트가 파괴된 다음 재연결되는 것을 요구하는데 그 이유 는 이것이 데모 컴포넌트들을 다시 그것들의 데모 그룹에 연결할 것이기 때문이다. 이것은 다른 DemoGroupTabbedPane을 생성하는 것에 의해 달성된다. DGAC는 프레임워크에 다른 DGTB를 생성할 것을 요구하고(124) 그러면 다른 DGTB는 DemoGroupContainer에 삽입된다(125). DemoGroupTabbedPane은 옵션적인 양방향 표지기(marker) 인터페이스를 가진다. 만일 하나의 DemoGroupTabbedPane이 도메인에 있으면, 표지기 인터페이스는 연결되지 않는다. 그러나 만일 다른 DemoGroupTabbedPane이 있으면, 표지기 인터페이스들은 연결된다. DemoGroupTabbedPane이 시작되고 그것의 표지기 인터페이스에 연결된 다른 컴포넌트가 있다는 것을 발견(126)할 때, 그것은 그 컴포넌트 및 자신 둘 다를 파괴한다(127). 재연결 후, DemoGroupTabbedPanes는 없어지고 데모들은 그것들의 데모 그룹에 다시 연결된다(128).

도 10은 데모 애플리케이션에서 성능 모니터를 가동시키는 것에 관한 컴포넌트 연결 재배치구성을 도시한다. Java2D는 성능 모니터 특징을 가진다. 데몬스트레이션들은 인스턴트 성능(예를 들면, 초당 프레임수)을 측정하고 이 데이터를 그것을 디스플레이하는 성능 모니터에 보낸다. 성능 모니터를 사용 가능하게 하고 불가능하게 하는 것은 더미 구현물(implementation)(그것은 단지 스터브 코드만을 가지고 아무것도 디스플레이하지 않는다)을 실제 구현물로 교체하고 되돌리는 것에 의해 행해진다. 원래 MissingPerformanceMonitor 컴포넌트(더미 구현물)는 인스턴스생성되고 연결된다. 사용자가 성능 모니터를 사용 가능하게 할 때, PerformanceMonitor의 인스턴스가 생성된다. 2개의 성능 모니터들은 DemoGroupTabbedPane 인스턴스들이 이전의 시나리오에서 했던 것과 같이 표지기 인터페이스에 의해 서로의 존재를 감지한다. 이 경우, 그러나, 컴포넌트는 표지기 인터페이스를 통하여 연결된 컴포넌트의 생성 시간을 점검한다. 생성 시간은 컴포넌트 프레임워크에 의해 유지된다. 컴포넌트는 어느 것이 더 오래된 것인지에 의존하여 자신 또는 다른 컴포넌트를 파괴한다. 컴포넌트들은 재연결되고 새롭게 생성되는 성능 모니터는 동작가능하게 된다. 계층적 컴포넌트 구조들에서 동적 합성의 능력을 데모로 보여주기 위해, 새로운 특징이 Java2D에 추가되었다. 이 특징은 현재의 데모 그룹 탭을 다른 Java2D 메인 프레임 쪽으로 옮기는 것을 허용한다. 이것은 다른 java2d를 다른 도메인에서 인스턴스생성하는 것에 의해 실현된다(도 11). 그 도메인은 다른 appcontainer 속성을 가진다. 이출 및 이입 필터들은 미연결 데모 그룹 컨테이너들이 이 제2의 도메인으로 옮겨지고 이 제2의 java2d 인스턴스와 연결되는 그런 방식으로 셋업된다. 이것을 하기 위해, 데모 그룹(데모 그룹과 데모 컴포넌트들)의 모든 컴포넌트들을 보유하는 컨테이너 컴포넌트의 appcontainer 슈퍼 속성을 변경하고 재연결을 요구하는 것이면 충분하다. 컴포넌트 네트워크가 시작될 때에는, 전체 데모 그룹 컴포넌트 집합은 제2의 도메인으로 옮겨지고 제2의 java2d 인스턴스에 연결된다.

구현예 및 결과들

테스트 런(run)들은 사용자가 사용하는 특징들만을 로딩하는 것에 의해 메모리를 절약하는 것이 실지로 가능하다는 것을 증명했다. 측정들은 또한 계층적 배치구성의 동적 재구성이 최종 사용자 애플리케이션들에 대해 낮은 기능정 지(blackout) 횟수를 제공할 수 있다는 것을 보여주었다.

연결들의 수는 - 그러므로 재연결 알고리즘의 실행 시간은 - 만일 컴포넌트들이 "평평한" 구성 대신에 계층적으로 배치된다면 감소될 수 있다는 것이 보여질 수 있다. 본 발명을 사용할 때, 연결들의 수는 어떤 적지않은(non-trival) 그룹화(그래서 그룹들이 하나를 넘는 컴포넌트들로 구성되고, 하나를 넘는 그룹들이 있다)에 대해 더 낮다.

이 기술분야의 통상의 기술자는 본 발명의 컴포넌트 아키텍처가 이 기술분야에서 알려진 것들보다 훨씬 더 유연하다는 것 또한 인정할 것이다. 이 유연성은 컴포넌트 아키텍처를 배타적이게는 아니지만 자가관리 특징들을 구현하는데 특히 적합하게 그리고 각별히 모바일 애플리케이션들의 경우에 적합하게 만든다. 이 아키텍처는 잘 알려진 프로그래밍 패러다임들을 개선된 방식들로 쉽게 구현하는 것이 가능한데, 예를 들면 아키텍처가 강력한 이벤트 핸들링(이벤트들은 이벤트를 다루기 위해 다른 컴포넌트들을 사용할 수 있는 컴포넌트들이다), 양태(aspect) 지향 프로그래밍(컴포넌트 분해능은 시스템에서 크로스 커팅 효과를 초래할 수 있다) 및 에이전트 기반 아키텍처들(컴포넌트들은 에이전트로서 역할을 할 수 있다)를 제공한다.

본 발명의 특정 구현예들과 실시예들이 기술되었다. 이 기술분야의 숙련된 사람에게는 본 발명이 위에 제시된 실시예들의 상세한 설명으로 제한되지 않고, 그것은 본 발명의 특징들로부터 벗어남 없이 동등한 수단을 사용하여 다른 실시예들로 구현될 수 있다는 것이 명확하다. 본 발명의 범위는 첨부의 특허청구범위에 의 해서만 제한된다.

Claims (25)

1. 메모리;

   상기 메모리에 저장된 컴퓨터에 의해 실행가능한 프로그램 코드; 및

   상기 프로그램 코드를 실행하도록 구성된 프로세서를 포함하는 기기에 있어서,

   상기 프로세서는 상기 기기의 동작을 제어하고,

   상기 프로그램 코드는 각각의 컴포넌트가 다른 컴포넌트들과의 연결을 위한 적어도 하나의 인터페이스를 구비하는 적어도 2개의 컴포넌트를 구비하는 자가편성(self-organising) 프로그램 코드를 포함하고, 상기 자가편성 프로그램 코드는 계층적 컴포넌트 모델에 따라 편성되고 컴포넌트들의 각각은 컴포넌트들에 저장되는 정보를 그 컴포넌트가 다른 컴포넌트들에 연결 가능한지 여부를 정하는 컴포넌트 규칙들을 정의하는 메타정보로서 담고 있는 기기.
2. 제1항에 있어서, 컴포넌트들은 컴포넌트들의 인터페이스들이 다른 컴포넌트들의 인터페이스들에 연결 가능한지 여부를 정하는 인터페이스 규칙들을 정의하는 정보를 더 담고 있는 것을 특징으로 하는 기기.
3. 제2항에 있어서, 상기 기기는 컴포넌트 규칙들보다 인터페이스 규칙들이 우위에 있도록 추가로 구성되는 것을 특징으로 하는 기기.
4. 제2항에 있어서, 컴포넌트 규칙들 및/또는 인터페이스 규칙들은 만족되어야 할 어떤 조건을 요구하는 옵션적인 규칙들을 담고 있는 것을 특징으로 하는 기기.
5. 제3항에 있어서, 컴포넌트 규칙들 및/또는 인터페이스 규칙들은 만족되어야 할 어떤 조건을 요구하는 옵션적인 규칙들을 담고 있는 것을 특징으로 하는 기기.
6. 제1항 내지 제5항 중 어느 한 항에 있어서, 각각의 컴포넌트 및 또는 각각의 인터페이스는 주어진 우선순위에 연관되고 상기 기기는 이 우선순위들에 의존하여 인터페이스들을 연결하도록 구성되는 것을 특징으로 하는 기기.
7. 제1항 내지 제5항 중 어느 한 항에 있어서, 컴포넌트들의 각각 또는 적어도 일부는 기설정된 옵션적으로 개별적인 수명에 연관되어 있고, 상기 기기는 미연결 컴포넌트들을 그것들의 수명이 다한 후에 삭제하도록 구성되어 있는 것을 특징으로 하는 기기.
8. 제1항 내지 제5항 중 어느 한 항에 있어서, 메타정보는, 당해 컴포넌트에 연결될 수 있는 다른 컴포넌트의 요구된 속성 및 그것의 값을 정의하는 필수 속성들; 당해 컴포넌트에 연결하려는 다른 컴포넌트가 존재한다면 주어진 값을 가져야만 하는 상기 다른 컴포넌트의 속성을 정의하는 조건부 속성들; 및 다른 컴포넌트의 속성이 연결하지 않아야 한다는 값들을 정의하는 금지 속성들이라는 옵션들 중의 어느 것을 구비하는 것을 특징으로 하는 기기.
9. 제1항 내지 제5항 중 어느 한 항에 있어서, 컴포넌트들은 그것들의 메타정보를 노출할 수 있는 프리미티브 컴포넌트들을 구비하는 것을 특징으로 하는 기기.
10. 제1항 내지 제5항 중 어느 한 항에 있어서, 컴포넌트들은 다른 컴포넌트들의 연결들을 배치하는 것에 의해 다른 컴포넌트들을 포함할 수 있는 하나 이상의 복합 컴포넌트들로서 복합 컴포넌트에 포함되는 다른 컴포넌트들에 의존하여 메타정보를 노출할 수 있는 하나 이상의 복합 컴포넌트들을 구비하는 것을 특징으로 하는 기기.
11. 제1항 내지 제5항 중 어느 한 항에 있어서, 컴포넌트들은 다른 컴포넌트들의 연결들을 배치하는 것에 의해 다른 컴포넌트들을 포함할 수 있는 하나 이상의 복합 컴포넌트들로서 복합 컴포넌트에 포함되는 다른 컴포넌트들에 의존하여 메타정보를 노출할 수 있는 하나 이상의 복합 컴포넌트들을 구비하고; 복합 컴포넌트는 복합 컴포넌트에 포함되나 연결되지 않는 컴포넌트들을 담기 위한 도메인 저장소에 연관되는 것을 특징으로 하는 기기.
12. 컴퓨터 프로그램을 저장한 컴퓨터에 의해 판독가능한 저장매체에 있어서,

    상기 컴퓨터 프로그램은 기기에 의해 실행되어 상기 기기를 제어하기 위한 컴퓨터에 의해 실행가능한 자가편성 프로그램 코드를 포함하고, 상기 자가편성 프로그램 코드는 계층적 컴포넌트 모델에 따라 편성되고 각각의 컴포넌트가 다른 컴포넌트들과의 연결을 위한 적어도 하나의 인터페이스를 구비하는 적어도 2개의 컴포넌트를 구비하며, 컴포넌트들의 각각은 컴포넌트들에 저장되는 정보를 그 컴포넌트가 다른 컴포넌트들에 연결 가능한지 여부를 정하는 컴포넌트 규칙들을 정의하는 메타정보로서 담고 있는 컴퓨터에 의해 판독가능한 저장매체.
13. 제12항에 있어서, 컴포넌트들은 컴포넌트들의 인터페이스들이 다른 컴포넌트들의 인터페이스들에 연결 가능한지 여부를 정하는 인터페이스 규칙들을 정의하는 정보를 더 담고 있는 것을 특징으로 하는 컴퓨터에 의해 판독가능한 저장매체.
14. 제13항에 있어서, 상기 기기는 컴포넌트 규칙들보다 인터페이스 규칙들이 우위에 있도록 더 구성되는 것을 특징으로 하는 컴퓨터에 의해 판독가능한 저장매체.
15. 제12항 내지 제14항 중 어느 한 항에 있어서, 컴포넌트 규칙들은 만족되어야 할 어떤 조건을 요구하는 옵션적인 규칙들을 담고 있는 것을 특징으로 하는 컴퓨터에 의해 판독가능한 저장매체.
16. 제12항 내지 제14항 중 어느 한 항에 있어서, 컴포넌트 규칙들 및/또는 인터페이스 규칙들은 만족되어야 할 어떤 조건을 요구하는 옵션적인 규칙들을 담고 있는 것을 특징으로 하는 컴퓨터에 의해 판독가능한 저장매체.
17. 제12항 내지 제14항 중 어느 한 항에 있어서, 각각의 컴포넌트 및 또는 각각의 인터페이스는 주어진 가중치 또는 우선순위에 연관되고 상기 자가편성 소프트웨어는 이 가중치들 또는 우선순위들에 의존하여 인터페이스들을 연결하도록 구성되는 것을 특징으로 하는 컴퓨터에 의해 판독가능한 저장매체.
18. 제12항 내지 제14항 중 어느 한 항에 있어서, 컴포넌트들의 각각 또는 적어도 일부는 수명을 가지는 컴포넌트들이 수명 후에 삭제되는 기설정된 옵션적으로 개별적인 수명에 연관되는 것을 특징으로 하는 컴퓨터에 의해 판독가능한 저장매체.
19. 제12항 내지 제14항 중 어느 한 항에 있어서, 상기 자가편성 소프트웨어는 데이터 매체 또는 데이터 신호로 운반되거나 저장되는 것을 특징으로 하는 컴퓨터에 의해 판독가능한 저장매체.
20. 메모리; 상기 메모리에 저장된 컴퓨터에 의해 실행가능한 프로그램 코드; 및 상기 프로그램 코드를 실행하도록 구성된 프로세서를 포함하는 기기를 제어하는 방법에 있어서, 상기 방법은

    계층적 컴포넌트 모델에 따라 자가편성 프로그램 코드를 편성하고,

    각각의 컴포넌트가 다른 컴포넌트들과의 연결을 위한 적어도 하나의 인터페이스를 구비한 적어도 2개의 컴포넌트를 식별하고,

    메타정보로부터 컴포넌트들의 각각에 특유한 컴포넌트 규칙들을 얻고,

    상기 규칙들에 기초하여 컴포넌트들의 각각이 어떻게 다른 컴포넌트들에 연결되지를 결정하는 방법.
21. 제20항에 있어서, 컴포넌트들은 컴포넌트들의 인터페이스들이 다른 컴포넌트들의 인터페이스들에 연결될 수 있는지를 정하는 인터페이스 규칙들을 정의하는 정보를 더 담고 있는 것을 특징으로 하는 방법.
22. 제21항에 있어서, 컴포넌트 규칙들 및/또는 인터페이스 규칙들은 만족되어야 할 어떤 조건을 요구하는 옵션적인 규칙들을 담고 있을 수 있는 것을 특징으로 하는 방법.
23. 제20항 내지 제22항 중 어느 한 항에 있어서, 컴포넌트들은 다른 컴포넌트들의 연결들을 배치하는 것에 의해 다른 컴포넌트들을 포함할 수 있는 하나 이상의 복합 컴포넌트들로서 복합 컴포넌트에 포함되는 다른 컴포넌트들에 의존하여 메타정보를 노출할 수 있는 하나 이상의 복합 컴포넌트들을 구비하는 것을 특징으로 하는 방법.
24. 삭제
25. 삭제

Images