[java] OSGi는 무엇을 해결합니까?

JAVA / 글쓴이

OSGi 에 대한 Wikipedia 및 기타 사이트에서 읽었습니다. 에 지만 실제로 큰 그림을 못합니다. 구성 요소 기반 플랫폼이며 런타임에 모듈을 다시로드 할 수 있다고 말합니다. 또한 모든 곳에서 제공되는 “실제 예제”는 Eclipse Plugin Framework입니다.

내 질문은 :

  1. OSGi의 명확하고 간단한 정의는 무엇입니까?

  2. 어떤 일반적인 문제가 해결됩니까?

“일반적인 문제”란 “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 사양에서 처리되었습니다.

출처 : www.osgi.org/Technology/WhyOSGi

답변

OSGi에서 다음과 같은 이점을 발견했습니다.

  • 각 플러그인은 자체 클래스 로더가있는 버전이 지정된 아티팩트입니다.
  • 각 플러그인은 포함 된 특정 jar 및 기타 특정 버전의 플러그인에 따라 다릅니다.
  • 버전 관리 및 격리 된 클래스 로더로 인해 동일한 아티팩트의 다른 버전을 동시에로드 할 수 있습니다. 애플리케이션의 한 구성 요소가 한 버전의 플러그인에 의존하고 다른 구성 요소가 다른 버전에 의존하는 경우 둘 다 동시에로드 할 수 있습니다.

이를 통해 애플리케이션을 요청시로드되는 버전이 지정된 플러그인 아티팩트로 구성 할 수 있습니다. 각 플러그인은 독립형 구성 요소입니다. Maven이 빌드를 구성하여 빌드 할 특정 아티팩트 버전 세트에 의해 반복 가능하고 정의되도록 빌드하는 것처럼 OSGi는 런타임시이를 수행하도록 도와줍니다.

답변

OSGi 모듈의 핫 플러그 ​​기능 (최소한 현재)에 대해서는 신경 쓰지 않습니다. 더 강화 된 모듈성입니다. 언제라도 클래스 패스에 수백만 개의 “공용”클래스를 사용할 수 없기 때문에 순환 종속성으로부터 잘 보호 할 수 있습니다. 자바 인터페이스 “공용”구조뿐만 아니라 라이브러리 측면에서도 공용 인터페이스에 대해 생각해야합니다. / module : 다른 사람이 사용할 수있는 구성 요소는 무엇입니까? 기능을 구현하는 데 실제로 (다른 모듈의) 인터페이스는 무엇입니까?

핫 플러그와 함께 제공되는 것이 좋지만 핫 플러그 ​​기능의 모든 조합을 테스트하는 것보다 일반적인 응용 프로그램을 다시 시작하고 싶습니다 …

답변

  • 유사하게 말하면, 자동차의 모터를 끄지 않고도 모터를 바꿀 수 있습니다.
  • 고객을 위해 복잡한 시스템을 사용자 정의 할 수 있습니다. Eclipse의 힘을보십시오.
  • 전체 구성 요소를 재사용 할 수 있습니다. 단순한 물체보다 낫습니다.
  • 안정적인 플랫폼을 사용하여 구성 요소 기반 응용 프로그램을 개발합니다. 이것의 장점은 엄청납니다.
  • 블랙 박스 컨셉으로 컴포넌트를 구축 할 수 있습니다. 다른 구성 요소는 숨겨진 인터페이스에 대해 알 필요가 없으며 게시 된 인터페이스 만 볼 수 있습니다.
  • 동일한 시스템에서 여러 동일한 구성 요소를 사용할 수 있지만 응용 프로그램을 손상시키지 않고 다른 릴리스에서 사용할 수 있습니다. OSGi는 Jar Hell 문제를 해결합니다.
  • OSGi를 사용하면 CBD로 시스템을 설계 할 생각

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 의존성 지옥으로 고통 받고 있습니다.