소개

오늘날의 어플리케이션들은 점점 더 복잡해진다. 이러한 복잡성의 대부분은 예를 들어 다양한 디바이스, 운영체제 환경 또는 고객 요구사항등 다양한 구성을 지원할 필요성에서 비롯된다. 과거에 개발된 거대한 통짜 어플리케이션(Monolithic application)은 오늘날 요구되는 필요한 유연성을 제공하지 않거나 혹은 엄청난 비용을 유발시킨다.

많은 회사들은 이러한 사실을 인지하고, 동적 플러그인 모델에 기초한 최신의 소프트웨어 아키텍처에 기초하고 있다. 이 모델에서 그들은 런타임에 필요로하는 동적으로 로딩되는 공유 라이브러리인 플러그인을 위한 로더와 실행 환경(또는 컨테이너)으로 동작하는 매우 기초적인 뼈대 어플리케이션을 구현한다. 어프리케이션의 모든 기능들은 추가 요구에 따른 어플리케이션으로 추가되어 질 수 있는 플러그인으로 제공된다. 자바 개발자는 OSGi 재단(http://www.osgi.org/)과 쉽게 이용할 수 없는 표준 환경이 없는 C++에 의존하는 회사에 의해 개발된 OSGi(TM) 서비스 플랫폼 스펙(OSGi는 상표 또는 미국 또는 다른 나라 또는 둘다의 OSGi 얼라이언스의 등록 상표임)에 기초한 프레임웍과 같이 쉽게 이용할 수 있는 다양한 구현과 그들 자신의 시스템을 구현해야만 하는것 사이에 (?)

이것이 개방형 서비스 플랫폼(Open Service Platform, OSP)이 있는 이유이다. OSP는 개발, 배포, 구동, 네트웍에 기초한 어플리케이션을 관리하는 모듈러를 위한 서비스 기반, 컴포넌트 기반 환경을 제공하는 C++ 기반 미들웨어 이다. 이와 같이, OSGi 서비스 플랫폼이 자바에 대한것이라면, OSP는 C++을 위한것이다. 사실, OSP의 디자인은 OSGi 서비스 플랫폼으로 부터 많은 아이디어와 영감을 가져왔다.

OSP의 이러한 컴포넌트 기반 아키텍처는 소프트웨어 개발에서 증가하는 문제에 직면한다: 개발되고 유지되어야 하는 많은 수의 응용 프로그램 구성. 표준화된 OSP 컴포넌트 아키텍처는 이러한 구성 프로세스를 현저하게 간단하게 한다.

OSP 아키텍처 개요

개방형 서비스 플랫폼(Open Service Platform)은 아래 그림에서 제시된 계층화된 아키텍처에 기반한다. OSP의 핵심은 C와 C++ 표준 라이브러리와 POCO Core 라이브러리로 구성된 포터블 실행 환경이다. 포터블 실행 환경에 상위의 계층은 서비스 레지스트리, 생명 주기 관리, 번들 관리 그리고 표준 서비스이다. OSP 프레임웍에 기반한 어플리케이션 특화 번들들은 실제 어플리케이션 로직을 구현한다.

포터블 실행 환경(Portable Runtime Environment)

포터블 실행 환경은 OSP 아키텍처의 중앙에 위치한다. POCO Core 라이브러리 뿐만 아니라 C와 C++ 표준 라이브러리에 기반한 것은 다음과 같이 OSP 계층 상위에 플랫폼 독립 저 수준 서비스를 제공 한다:

  • 파일 시스템 접근
  • 멀티스레딩 지원
  • 공유 라이브러리와 클래스 로딩
  • 통지와 이벤트
  • 로깅
  • XML 파싱
  • 구성 데이터 처리
  • TCP/IP 소켓과 다양한 프로토콜(HTTP, FTP, SMTP, POP3 등) 지원
  • 다양한 유틸리티 클래스와 함수들

운영체제의 인터페이스로부터 고립된(독립된) 어플리케이션에 의해, 포터블 실행 환경은 컴파일 될 수 있도록 작성된 어플리케이션이 같은 소스 코드로부터 모든 것, 다른 운영체제 플랫폼과 프로세서 구조에서 구동되고 컴파일 되어질 수 있는 어플리케이션을 작성하도록 만들어다(?)

서비스 레지스트리(Service Registry)

서비스 레지스트리는 다른 번들들에 의해 제공된 서비스를 발견하는 것 뿐만 아니라, 다른 번들들에 의해 이용가능하도록 그것들을 만들기 위한 서비스를 등록하기 위한 번들을 허용한다. 번들들은 한번에 어플리케이션에 나타나거나 사라질 수 있기 때문에, 서비스 레지스트리는 또한 번들들은 다른 번들들이 시스템으로 부터 사라질 때 알려줄 수 있는 통지 매커니즘을 제공한다(?).

번들은 어떤 속성들을 갖는 서비스를 위한 서비스 레지스트리를 쿼리하기 위해 간단한 쿼리 언어를 사용해서 어떤 서비스를 발견할 수 있다.

생명 주기 관리(Life Cycle Management)

번들은 아래 그림에서 보여주는 것처럼, 잘 정의된 생명 주기를 잘 준수한다. OSP에서 생명 주기 관리는 다음에 윤곽이 보여진, 이 라이플 사이클을 준수하는 시스템의 모든 번들에서 보장한다.

번들은 어플리케이션으로 설치되고, installed 상태로 생명 주기를 시작한다. Installed 상태로 부터, 번들은 uninstalled 또는 resolved 가 될 수 있다. 번들을 resolve하는 것은 다른 번들에 모두 의존성을 결정하고, 모든 필요한 번들이 이용가능한다는 것을 확인하는 것을 의미한다. 오로지 성공적으로 resolved된 번들만이 started될 수 있다. 번들을 start하는 것은 로드되고 호출될 Bundle Activator인 번들에 의해 제공된 특별한 클래스의 원인이 된다. Bundle Activator는 그 다음 번들의 서비스들을 등록 처리하고, (서비스 될)번들이 제공하는 모든 필요한 단계를 수행한다. Bundle Activator가 이 작업을 성공적으로 완료한 다음에, 번들은 Active 상태가 된다. Active 번들은 다시 stopped가 될 수 있고, 시스템으로 부터 제거될 수도 있다(uninstall).

번들 관리(Bundle Management)

OSP에서 번들 관리 계층은 파일 시스템뿐만 아니라 번들에 포함된 공유 라이브러리의 로드에서의 번들의 물리적 저장소를 다룬다.

번들은 특정 디렉토리 구조에 저장된 파일들(manifest, 공유 라이브러리, 데이터 파일들, 구성 파일들, 리소스 파일들 등)의 집합이다. 좀더 쉬운 개발을 위해, 번들은 Zip 파일 포맷()을 사용하여 압축된 형태일 수 있다. OSP의 향후 버전에서는 번들에 암호화된 서명을 하는 것이 가능해질 것이고, 번들의 컨텐츠를 암호화할 것이다.

번들은 다양한 운영체제 플랫폼과 하드웨어 구조를 위한 공유 라이브러리의 멀티플 버전을 포함 할 수 있다. 번들 관리는 현재 운영체제를 위한 공유 라이브러리의 올바른 버전과 하드웨어 아키텍처가 로딩되어지는 것을 확실히 해준다. 이것은 예를 들어 윈도우즈와 리눅스 시스템 둘다에 배포되는 단일 번들을 제공하는 것이 가능하게 만들어 준다.

표준 서비스들(Standard Services)

OSP는 일반적으로 필요한 기능들을 구현하는 다양한 표준 서비스와 함께 온다. 예제들은 HTTP 서버, 이메일 메시지 전송 지원, 웹기반 번들 관리 뿐만 아니라 구성과 참조 저장 서비스를 포함한다.

macchina.io 0.7.0

Copyright © 2017, Applied Informatics Software Engineering GmbH(CC BY 3.0)

results matching ""

    No results matching ""