OSGi 에 대한 Wikipedia 및 기타 사이트에서 읽었습니다. 에 지만 실제로 큰 그림을 못합니다. 구성 요소 기반 플랫폼이며 런타임에 모듈을 다시로드 할 수 있다고 말합니다. 또한 모든 곳에서 제공되는 "실제 예제"는 Eclipse Plugin Framework입니다.
내 질문은 :
OSGi의 명확하고 간단한 정의는 무엇입니까?
어떤 일반적인 문제가 해결됩니까?
"일반적인 문제"란 "OSGi가 업무를보다 효율적이고 재미 있고 단순하게 만들기 위해 무엇을 할 수 있는가?"와 같이 매일 직면하는 문제를 의미합니다.
답변:
복잡성 감소-OSGi 기술로 개발한다는 것은 번들 (OSGi 구성 요소)을 개발하는 것을 의미합니다. 번들은 모듈입니다. 그들은 다른 번들에서 내부를 숨기고 잘 정의 된 서비스를 통해 통신합니다. 내부를 숨기면 나중에 더 자유롭게 바꿀 수 있습니다. 이렇게하면 버그 수가 줄어들뿐만 아니라 올바른 크기의 번들이 잘 정의 된 인터페이스를 통해 기능을 구현하기 때문에 번들 개발이 더 간단 해집니다. OSGi 기술이 개발 프로세스에서 수행 한 작업을 설명하는 흥미로운 블로그가 있습니다.
재사용 – OSGi 구성 요소 모델을 사용하면 응용 프로그램에서 많은 타사 구성 요소를 매우 쉽게 사용할 수 있습니다. 점점 더 많은 오픈 소스 프로젝트가 OSGi를 위해 JAR을 준비합니다. 그러나 상용 라이브러리도 기성품 번들로 제공되고 있습니다.
현실 세계 -OSGi 프레임 워크는 동적입니다. 번들을 즉시 업데이트 할 수 있으며 서비스가왔다 갔다 할 수 있습니다. 보다 전통적인 Java에 익숙한 개발자는이 기능을 매우 문제가있는 기능으로보고 이점을 보지 못합니다. 그러나 실제 세계는 매우 역동적이며 동적 서비스를 제공하면 많은 실제 시나리오에 완벽하게 일치합니다. 예를 들어, 서비스는 네트워크에서 장치를 모델링 할 수 있습니다. 장치가 감지되면 서비스가 등록됩니다. 장치가 사라지면 서비스가 등록되지 않은 것입니다. 이 동적 서비스 모델과 일치하는 놀라운 실제 시나리오가 있습니다. 따라서 애플리케이션은 자체 도메인에서 서비스 레지스트리의 강력한 기본 요소 (등록, 가져 오기, 표현 필터 언어로 나열 및 서비스가 표시되거나 사라질 때까지 대기)를 재사용 할 수 있습니다. 이것은 코드 작성을 절약 할뿐만 아니라 전 세계 가시성, 디버깅 도구 및 전용 솔루션에 구현 된 것보다 더 많은 기능을 제공합니다. 이러한 역동적 인 환경에서 코드를 작성하는 것은 악몽처럼 들리지만 운 좋게도 대부분의 고통을 없애는 지원 클래스와 프레임 워크가 있습니다.
간편한 배포 -OSGi 기술은 구성 요소의 표준이 아닙니다. 또한 구성 요소의 설치 및 관리 방법을 지정합니다. 이 API는 많은 번들에서 관리 에이전트를 제공하는 데 사용되었습니다. 이 관리 에이전트는 명령 쉘, TR-69 관리 프로토콜 드라이버, OMA DM 프로토콜 드라이버, Amazon EC2 용 클라우드 컴퓨팅 인터페이스 또는 IBM Tivoli 관리 시스템처럼 간단 할 수 있습니다. 표준화 된 관리 API를 사용하면 OSGi 기술을 기존 및 향후 시스템에 매우 쉽게 통합 할 수 있습니다.
동적 업데이트 -OSGi 구성 요소 모델은 동적 모델입니다. 전체 시스템을 중단하지 않고 번들을 설치, 시작, 중지, 업데이트 및 제거 할 수 있습니다. 많은 Java 개발자는 이것이 안정적으로 수행 될 수 있다고 생각하지 않기 때문에 처음에는 이것을 프로덕션에서 사용하지 않습니다. 그러나이를 개발에 한동안 사용한 후 대부분은 실제로 작동하고 배포 시간이 크게 단축된다는 것을 깨닫기 시작합니다.
적응 -OSGi 구성 요소 모델은 구성 요소의 혼합 및 일치를 허용하도록 처음부터 설계되었습니다. 따라서 구성 요소의 종속성을 지정해야하며 선택적 종속성을 항상 사용할 수있는 환경에 구성 요소가 있어야합니다. OSGi 서비스 레지스트리는 번들이 서비스를 등록, 가져 오기 및 청취 할 수있는 동적 레지스트리입니다. 이 동적 서비스 모델을 통해 번들은 시스템에서 사용 가능한 기능을 찾고 제공 할 수있는 기능을 조정할 수 있습니다. 이를 통해 코드를보다 유연하고 탄력적으로 변경할 수 있습니다.
투명성- 번들 및 서비스는 OSGi 환경에서 일류 시민입니다. 관리 API는 번들의 내부 상태 및 다른 번들에 연결되는 방법에 대한 액세스를 제공합니다. 예를 들어, 대부분의 프레임 워크는이 내부 상태를 보여주는 명령 셸을 제공합니다. 특정 문제를 디버깅하기 위해 응용 프로그램의 일부를 중지하거나 진단 번들을 가져올 수 있습니다. 수백만 줄의 로깅 출력을보고 굳 히지 않고 OSGi 응용 프로그램을 라이브 명령 셸로 디버깅 할 수 있습니다.
버전 관리 -OSGi 기술은 JAR 지옥을 해결합니다. JAR 지옥은 라이브러리 A가 라이브러리 B; 버전 = 2에서 작동하지만 라이브러리 C는 B; 버전 = 3에서만 작동하는 문제입니다. 표준 Java에서는 운이 좋지 않습니다. OSGi 환경에서 모든 번들은 신중하게 버전이 지정되며 협업 할 수있는 번들 만 동일한 클래스 공간에서 함께 연결됩니다. 이를 통해 번들 A와 C는 모두 자체 라이브러리와 함께 작동 할 수 있습니다. 이 버전 관리 문제로 시스템을 설계하는 것은 좋지 않지만 경우에 따라 생명을 구할 수 있습니다.
단순성 -OSGi API는 놀랍도록 간단합니다. 핵심 API는 하나의 패키지이며 30 개 미만의 클래스 / 인터페이스입니다. 이 핵심 API는 번들 작성, 설치, 시작, 중지, 업데이트 및 설치 제거에 충분하며 모든 리스너 및 보안 클래스를 포함합니다. API가 거의없는 기능을 제공하는 API는 거의 없습니다.
작음 -OSGi 릴리스 4 프레임 워크는 약 300KB JAR 파일로 구현할 수 있습니다. 이는 OSGi를 포함하여 애플리케이션에 추가되는 기능의 양에 대한 작은 오버 헤드입니다. 따라서 OSGi는 매우 작은 장치에서 작은 장치, 메인 프레임에 이르는 광범위한 장치에서 실행됩니다. 최소한의 Java VM 만 실행하도록 요청하고 그 위에 거의 추가하지 않습니다.
빠름 -OSGi 프레임 워크의 주요 책임 중 하나는 번들에서 클래스를로드하는 것입니다. 전통적인 Java에서는 JAR이 완전히 표시되고 선형 목록에 배치됩니다. 클래스를 검색하려면이 목록을 검색해야합니다 (종종 매우 길지만 150은 드문 일이 아닙니다) 반대로 OSGi는 번들을 사전 배선하고 각 번들에 대해 어떤 번들이 클래스를 제공하는지 정확히 알고 있습니다. 이러한 검색 부족은 시작시 중요한 속도 향상 요소입니다.
게으른- 게으른 소프트웨어가 좋고 OSGi 기술에는 실제로 필요할 때만 작업을 수행 할 수있는 많은 메커니즘이 있습니다. 예를 들어 번들을 열성적으로 시작할 수 있지만 다른 번들이이를 사용할 때만 시작되도록 구성 할 수도 있습니다. 서비스는 등록 할 수 있지만 사용할 때만 만들 수 있습니다. 이 사양은 엄청난 런타임 비용을 절약 할 수있는 이러한 지연 시나리오를 허용하도록 여러 번 최적화되었습니다.
보안 -Java는 맨 아래에 매우 강력한 세분화 된 보안 모델이 있지만 실제로 구성하기가 매우 어려웠습니다. 결과적으로 대부분의 안전한 Java 응용 프로그램은 보안이 없거나 기능이 매우 제한적인 이진 선택으로 실행됩니다. OSGi 보안 모델은 세분화 된 보안 모델을 활용하지만 번들 개발자가 요청 된 보안 세부 사항을 쉽게 감사 양식으로 지정하도록하여 환경 운영자가 완전히 책임을지게함으로써 유용성을 향상시킵니다 (원래 모델 강화). 전반적으로 OSGi는 하드웨어 보호 컴퓨팅 플랫폼을 여전히 사용할 수없는 가장 안전한 애플리케이션 환경 중 하나를 제공 할 것입니다.
비침 입성-OSGi 환경의 애플리케이션 (번들)은 자체적으로 남겨집니다. OSGi가 제한없이 VM의 거의 모든 기능을 사용할 수 있습니다. OSGi의 모범 사례는 Plain Old Java Objects를 작성하는 것이므로 이러한 이유로 OSGi 서비스에는 특별한 인터페이스가 필요하지 않으며 Java String 객체도 OSGi 서비스로 작동 할 수 있습니다. 이 전략을 통해 응용 프로그램 코드를 다른 환경으로 쉽게 이식 할 수 있습니다.
어디서나 실행- 됩니다. Java의 원래 목표는 어디에서나 실행하는 것이 었습니다. Java VM의 기능이 다르기 때문에 모든 코드를 어디에서나 실행할 수는 없습니다. 휴대폰의 VM은 뱅킹 애플리케이션을 실행하는 IBM 메인 프레임과 동일한 라이브러리를 지원하지 않을 수 있습니다. 처리해야 할 두 가지 문제가 있습니다. 먼저, OSGi API는 모든 환경에서 사용 가능한 클래스를 사용해서는 안됩니다. 둘째, 실행 환경에서 사용할 수없는 코드가 포함 된 번들은 시작하지 않아야합니다. 이 두 가지 문제는 OSGi 사양에서 처리되었습니다.
OSGi에서 다음과 같은 이점을 발견했습니다.
이를 통해 애플리케이션을 요청시로드되는 버전이 지정된 플러그인 아티팩트로 구성 할 수 있습니다. 각 플러그인은 독립형 구성 요소입니다. Maven이 빌드를 구성하여 빌드 할 특정 아티팩트 버전 세트에 의해 반복 가능하고 정의되도록 빌드하는 것처럼 OSGi는 런타임시이를 수행하도록 도와줍니다.
OSGi 모듈의 핫 플러그 기능 (최소한 현재)에 대해서는 신경 쓰지 않습니다. 더 강화 된 모듈성입니다. 언제라도 클래스 패스에 수백만 개의 "공용"클래스를 사용할 수 없기 때문에 순환 종속성으로부터 잘 보호 할 수 있습니다. 자바 인터페이스 "공용"구조뿐만 아니라 라이브러리 측면에서도 공용 인터페이스에 대해 생각해야합니다. / module : 다른 사람이 사용할 수있는 구성 요소는 무엇입니까? 기능을 구현하는 데 실제로 (다른 모듈의) 인터페이스는 무엇입니까?
핫 플러그와 함께 제공되는 것이 좋지만 핫 플러그 기능의 모든 조합을 테스트하는 것보다 일반적인 응용 프로그램을 다시 시작하고 싶습니다 ...
Java를 사용하는 모든 사람이 사용할 수있는 많은 이점이 있습니다 (지금 막 상기 한 내용).
명확성을 위해 편집되었습니다. OSGi 페이지가 내 것보다 더 간단한 답변을 주었다
간단한 답변 : OSGi 서비스 플랫폼은 네트워크 서비스 협력을위한 표준화 된 구성 요소 지향 컴퓨팅 환경을 제공합니다. 이 아키텍처는 응용 프로그램 구축, 유지 관리 및 배포의 전반적인 복잡성을 크게 줄입니다. OSGi 서비스 플랫폼은 재시작 없이도 다양한 네트워크 장치에서 구성을 동적으로 변경하는 기능을 제공합니다.
Eclipse IDE와 같은 단일 응용 프로그램 구조에서 새 플러그인을 설치할 때 다시 시작하는 것은 그리 큰 일이 아닙니다. OSGi 구현을 완전히 사용하면 런타임에 플러그인을 추가하고 새 기능을 사용할 수 있지만 일식을 다시 시작할 필요는 없습니다.
다시 말하지만 매일 큰 문제는 아니며 작은 응용 프로그램 사용입니다.
그러나 다중 컴퓨터의 분산 응용 프로그램 프레임 워크를 살펴보기 시작하면 흥미로운 부분이됩니다. 중요한 시스템에 100 % 가동 시간이 필요한 경우 런타임시 구성 요소를 핫스왑하거나 새로운 기능을 추가하는 기능이 유용합니다. 물론 지금은이 작업을 수행 할 수있는 기능이 있지만 OSGi는 모든 것을 공통 인터페이스가있는 멋진 작은 프레임 워크로 묶으려고합니다.
OSGi가 일반적인 문제를 해결합니까, 잘 모르겠습니다. 내 말은, 가능하지만 오버 헤드는 단순한 문제에 대해서는 가치가 없을 수 있습니다. 그러나 더 큰 네트워크로 연결된 응용 프로그램을 다루기 시작할 때 고려해야 할 사항입니다.
OSGi에 대한 견해를 불러 일으키는 몇 가지 사항 :
1) 함침과 컨텍스트 로더에는 많은 단점이 있으며 다소 비동기적일 수 있습니다 (우리는 felix를 합류 내부에서 사용합니다). [main]이 모든 동기화를 통해 거의 실행되는 순수한 스프링 (DM 없음)과 비교할 때.
2) 열간로드 후 클래스가 동일하지 않습니다. 예를 들어 최대 절전 모드에 탱고 솔 캐시 레이어가 있다고 가정 해보십시오. OSGi 범위를 벗어난 Fork.class로 채워져 있습니다. 새 병을 핫로드하고 포크가 변경되지 않았습니다. 클래스 [포크]! = 클래스 [포크]. 또한 동일한 기본 원인으로 직렬화 중에 나타납니다.
3) 클러스터링.
이러한 문제를 해결할 수는 있지만 이는 주요한 고통이며 아키텍처에 결함이있는 것으로 보입니다.
그리고 핫 플러깅을 광고하는 사람들에게 .. OSGi의 # 1 클라이언트? 식. 번들을로드 한 후 Eclipse는 무엇을합니까?
다시 시작됩니다.
은 OSGi는 코드 던져하게 NoClassDefFoundError하고 ClassNotFoundException뚜렷한 이유없이 (대부분의 아마 당신은 OSGi 프레임 구성 파일에 패키지를 수출하는 것을 잊었다 때문에); 클래스 로더 com.example.Foo가 com.example.Foo있기 때문에 실제로 두 개의 다른 클래스 로더에 의해로드 된 두 개의 다른 클래스이기 때문에 클래스 가 캐스팅되지 않을 수 있습니다 . Eclipse 플러그인을 설치 한 후 Eclipse를 OSGi 콘솔로 부팅 할 수 있습니다.
저에게 OSGi는 복잡성을 더했습니다 (왜냐하면 나에게 정신적 모델이 하나 더 추가 되었기 때문입니다). 나는 그것이 "제공하는"역 동성을 실제로 필요로하지 않았다. 모든 모듈에 대해 OSGi 번들 구성이 필요했기 때문에 방해가되었습니다. 분명히 더 큰 프로젝트에서는 간단하지 않았습니다.
나의 나쁜 경험 때문에, 나는 그 괴물과 떨어져있는 경향이 있습니다. 대단히 감사합니다. 오히려 클래스 의존성 지옥 OSGi가 소개하는 것보다 훨씬 쉽게 이해할 수있는 방법으로 jar 의존성 지옥으로 고통 받고 있습니다.
나는 아직 OSGi의 "팬"이 아닙니다 ...
Fortune 100 대 기업에서 엔터프라이즈 응용 프로그램을 사용하고 있습니다. 최근에 사용하는 제품이 OSGi 구현으로 "업그레이드되었습니다".
로컬 CBA 배포 시작 중 ... [2/18/14 8 : 47 : 23 : 727 EST] 00000347 CheckForOasis
마지막으로 배포되고 "다음 번들이 일시 정지 된 후 다시 시작됩니다"[2/18/14 9 : 38 : 33 : 108 EST] 00000143 AriesApplicat I CWSAI0054I : 애플리케이션 업데이트 조작의 일부로
51 분 ... 코드가 변경 될 때마다 ... 이전 버전 (OSGi 이외)은 이전 개발 시스템에서 5 분 이내에 배포됩니다.
16 기가 RAM 및 40 개의 무료 기가 디스크 및 Intel i5-3437U 1.9 GHz CPU가있는 머신
이 업그레이드의 "혜택"은 개선 된 (프로덕션) 배포로 판매되었습니다. 1 년에 약 4 회 정도의 소규모 수정 배포로 1 년에 약 4 회 정도하는 활동입니다. 15 명 (QA 및 개발자)에 하루 45 분을 추가하면 정당화 될 수 없다고 생각합니다. 대기업 응용 프로그램에서 응용 프로그램이 핵심 응용 프로그램 인 경우 응용 프로그램을 변경하는 것은 그렇습니다 (작은 변경은 영향을 미칠 수있는 큰 영향을 미칠 수 있습니다-기업 전체의 소비자와 의사 소통하고 계획해야 함). OSGi. 응용 프로그램이 엔터프라이즈 응용 프로그램이 아닌 경우 (예 : 각 소비자가 자신의 맞춤형 모듈이 자체 사일로 데이터베이스에서 자신의 데이터 사일로에 도달하고 많은 응용 프로그램을 호스팅하는 서버에서 실행되는 경우) OSGi를 살펴볼 수 있습니다. 적어도,
Java 기반 애플리케이션이 JVM을 종료하지 않고 모듈을 추가하거나 제거해야하는 경우 (애플리케이션의 기본 기능 확장) OSGI를 사용할 수 있습니다. 일반적으로 JVM 종료 비용이 더 많은 경우 기능을 업데이트하거나 향상시키기 만하면됩니다.
예 :
참고 : Spring 프레임 워크는 OSGI 스프링 번들 지원을 중단했습니다. 트랜잭션 기반 응용 프로그램이 나이 줄의 특정 지점에 대한 불필요한 복잡성으로 간주합니다. 플랫폼을 구축하는 것과 같은 큰 일에서 절대적으로 필요한 경우가 아니라면 개인적으로 OSGI를 고려하지 않습니다.
나는 거의 8 년 정도 OSGi와 함께 일해 왔으며 런타임에 구성 요소를 업데이트, 제거, 설치 또는 교체 해야하는 비즈니스가있는 경우에만 OSGi를 고려해야한다고 말해야합니다. 이것은 또한 모듈 식 사고 방식을 가지고 모듈성이 무엇을 의미하는지 이해해야 함을 의미합니다. OSGi가 경량이라는 몇 가지 주장이 있습니다. 물론 그렇습니다. 그러나 가볍고 유지 관리 및 개발이 쉬운 다른 프레임 워크도 있습니다. Java blah blah도 마찬가지입니다.
OSGi는 제대로 사용하기 위해 견고한 아키텍처가 필요하며 OSGi가 관여하지 않아도 독립형으로 실행 가능한 jar가 될 수있는 OSGi 시스템을 쉽게 만들 수 있습니다.
또한 모바일 측면에서 미들웨어 및 애플리케이션의 추가 이식성을 제공하는 데 사용되고 있습니다. 모바일 측은 WinMo, Symbian, Android 등에서 사용할 수 있습니다. 장치 기능과 통합되는 즉시 조각화 될 수 있습니다.
최소한 OSGi는 모듈성, 코드 재사용, 버전 관리 및 일반적으로 프로젝트의 배관에 대해 생각하게합니다.
다른 사람들은 이미 이점에 대해 자세히 설명 했으므로 OSGi를 보거나 사용한 실제 사용 사례를 설명합니다.
공식 사이트에는 이미 설득력있는 진술이 있습니다.
OSGi 기술이 성공한 핵심 이유는 실제로 놀라운 환경에서 작동 하는 매우 성숙한 구성 요소 시스템 을 제공하기 때문 입니다. OSGi 구성 요소 시스템은 실제로 IDE (Eclipse), 애플리케이션 서버 (GlassFish, IBM Websphere, Oracle / BEA Weblogic, Jonas, JBoss), 애플리케이션 프레임 워크 (Spring, Guice), 산업 자동화, 주거용 게이트웨이, 전화, 그리고 훨씬 더.
개발자에게주는 이점은 무엇입니까?
개발자 : OSGi는 오늘날의 대규모 분산 시스템과 소규모 임베디드 애플리케이션을위한 모듈 식 아키텍처를 제공하여 복잡성을 줄입니다. 사내 및 상용 모듈로 시스템을 구축하면 복잡성이 크게 줄어 개발 및 유지 관리 비용이 절감됩니다. OSGi 프로그래밍 모델은 컴포넌트 기반 시스템의 가능성을 실현합니다.
OSGi 사용의 이점 에서 세부 사항을 확인하십시오 .