OSGi는 무엇을 해결합니까?

OSGi는 무엇을 해결합니까?

Wikipedia나 다른 사이트에서 OSGi에 대해 읽은 적은 있지만 큰 그림을 볼 수는 없습니다.컴포넌트 기반 플랫폼이며 실행 시 모듈을 새로고침할 수 있다고 되어 있습니다.또한 모든 곳에서 제공되는 "실용 사례"는 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 hell은 라이브러리 A가 라이브러리 B;version=2에서 작동하지만 라이브러리 C는 B;version=3에서만 작동한다는 문제입니다.표준 자바에서는 운이 없습니다.OSGi 환경에서는 모든 번들이 신중하게 버전 관리되고 공동 작업이 가능한 번들만이 같은 클래스 공간에서 함께 배선됩니다.이것에 의해, 번들 A와 C 모두 독자적인 라이브러리와 함께 기능할 수 있습니다.이 버전의 문제가 있는 시스템을 설계하는 것은 권장되지 않지만 경우에 따라서는 이 방법이 생명을 구할 수 있습니다.

심플 - OSGi API는 놀라울 정도로 심플합니다.코어 API는 1개의 패키지만이며 클래스/인터페이스는 30개 미만입니다.이 핵심 API는 번들 쓰기, 설치, 시작, 중지, 업데이트 및 제거에 충분하며 모든 수신기 및 보안 클래스를 포함합니다.매우 적은 API로 많은 기능을 제공하는 API는 거의 없습니다.

소형 - OSGi Release 4 Framework는 약 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 모듈의 핫 플러그 기능(적어도 현재)에는 그다지 관심이 없습니다.더 강력한 모듈식입니다.클래스 경로에서 언제든지 사용할 수 있는 수백만 개의 "퍼블릭" 클래스가 없으면 순환 종속성으로부터 잘 보호됩니다.공용 인터페이스에 대해 정말 생각해야 합니다. Java 언어 구성 "public"의 관점에서뿐만 아니라 라이브러리/모듈의 관점에서도 고려해야 합니다.다른 사람이 사용할 수 있도록 하고 싶은 컴포넌트는 무엇입니까?기능을 구현하기 위해 꼭 필요한 (다른 모듈의) 인터페이스는 무엇입니까?

핫플러그가 부속되어 있는 것은 좋지만, 핫플러그의 모든 조합을 테스트하는 것보다는 일반적인 애플리케이션을 재기동하고 싶다.

• 자동차의 모터를 끄지 않고도 교환할 수 있습니다.
• 고객의 요구에 맞추어 복잡한 시스템을 커스터마이즈 할 수 있습니다.이클립스의 힘을 보세요.
• 전체 구성 요소를 재사용할 수 있습니다.그냥 물건보다는 낫지
• 안정된 플랫폼을 사용하여 컴포넌트 기반 애플리케이션을 개발할 수 있습니다.이것의 이점은 엄청나다.
• 블랙박스 컨셉으로 컴포넌트를 작성할 수 있습니다.다른 컴포넌트는 숨겨진 인터페이스에 대해 알 필요가 없으며 공개된 인터페이스만 볼 수 있습니다.
• 같은 시스템에서 여러 개의 동일한 컴포넌트를 사용할 수 있지만 응용 프로그램을 손상시키지 않고 다른 릴리스에서 사용할 수 있습니다.OSGi는 Jar Hell 문제를 해결합니다.
• OSGi를 사용하면 CBD를 사용하여 시스템을 설계할 수 있는 사고방식을 개발할 수 있습니다.

Java를 사용하는 모든 사용자가 이용할 수 있는 많은 이점이 있습니다(지금 상기했습니다).

편집했습니다.OSGi 페이지는 내 것보다 더 심플한 답변을 주었다.

간단한 답변: OSGi 서비스 플랫폼은 표준화된 컴포넌트 지향 컴퓨팅 환경을 제공하여 네트워크 서비스를 연계합니다.이 아키텍처는 애플리케이션 구축, 유지보수 및 도입의 전반적인 복잡성을 크게 줄여줍니다.OSGi Service Platform은 재기동 없이 다양한 네트워크 디바이스에서 구성을 동적으로 변경할 수 있는 기능을 제공합니다.

Eclipse IDE와 같은 단일 응용프로그램 구조에서 새 플러그인을 설치할 때 재시작하는 것은 큰 문제가 아닙니다.OSGi를 완전히 구현하면 런타임에 플러그인을 추가하고 새로운 기능을 얻을 수 있지만 이클립스를 다시 시작할 필요는 없습니다.

다시 말하지만, 일상적인 소규모 애플리케이션 사용에는 큰 문제가 없습니다.

하지만 멀티컴퓨터, 분산형 애플리케이션 프레임워크에 대해 살펴보기 시작하면 바로 이 부분에서 흥미로운 점이 생기기 시작합니다.중요한 시스템의 가동 시간을 100% 확보해야 하는 경우 런타임에 구성 요소를 핫 스왑하거나 새로운 기능을 추가하는 기능이 유용합니다.물론 대부분의 경우 이 기능을 사용할 수 있지만 OSGi는 공통 인터페이스를 갖춘 작고 멋진 프레임워크에 모든 것을 번들하려고 합니다.

OSGi는 일반적인 문제를 해결할 수 있습니까?그건 잘 모르겠습니다.내 말은, 그럴 수도 있지만, 간단한 문제들 때문에 오버헤드가 그럴 가치가 없을 수도 있어.다만, 대규모 네트워크 애플리케이션을 취급하기 시작할 때는, 이 점을 고려해야 합니다.

OSGi에 열광하는 몇 가지 점:

1) 함축과 그 컨텍스트로더는 많은 기호가 있으며, 다소 비동기적일 수 있습니다(우리는 합류 내부에서 filix를 사용합니다).[main]이 거의 모든 동기에서 작동하는 순수 스프링(DM 없음)과 비교됩니다.

2) 핫 로드 후 클래스가 동일하지 않습니다.예를 들어, 휴지 상태일 때 tangosol 캐시 레이어가 있다고 가정합니다.OSGi 범위 외의 Fork.class로 채워져 있습니다.새 병을 핫로드해도 포크는 변하지 않습니다.클래스 [포크]!= 클래스 [포크]또한 직렬화 중에도 동일한 근본 원인으로 표시됩니다.

3)클러스터링

이러한 문제를 해결할 수 있지만, 아키텍처에 결함이 있는 것처럼 보이는 것이 큰 과제입니다.

핫플러그를 광고하시는 분들께..OSGi의 No.1 클라이언트?이클립스이클립스는 번들을 로드한 후 무엇을 하나요?

재기동합니다.

OSGi를 통한 코드 투척NoClassDefFoundError그리고.ClassNotFoundException(아마도 OSGi 컨피규레이션파일로 패키지를 내보내는 것을 잊었기 때문일 것입니다), ClassLoaders를 탑재하고 있기 때문에 클래스를 만들 수 있습니다.com.example.Foo캐스팅에 실패하다com.example.Foo두 개의 다른 클래스 로더에 의해 로드되는 두 개의 다른 클래스이기 때문입니다.Eclipse 플러그인을 설치한 후 Eclipse를 OSGi 콘솔로 부팅할 수 있습니다.

나에게 OSGi는 단지 복잡함을 더했을 뿐이며(그것은 내가 고민할 수 있는 정신적 모델을 하나 더 추가했기 때문이다), 예외 때문에 나는 OSGi가 제공하는 역동성을 전혀 필요로 하지 않았다.모든 모듈에 OSGi 번들 구성이 필요하기 때문에 번거롭지만 (대규모 프로젝트에서는) 결코 간단하지 않았습니다.

저는 나쁜 경험 때문에 그 괴물을 멀리하는 편이에요, 감사합니다.OSGi가 도입하는 클래스 로더 지옥보다 훨씬 쉽게 이해할 수 있기 때문에 차라리 항아리 의존 지옥이 낫습니다.

아직 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기가 빈 디스크 및 인텔 i5-3437U 1.9GHz CPU를 탑재한 머신에 탑재되어 있습니다.

이 업그레이드의 "장점"은 도입 개선(실가동)으로 판매되었습니다.이 활동은, 1년에 약 4회 실시해, 1년에 2-4개의 소규모의 픽스 도입을 실시합니다.하루에 15명(QA와 개발자)에게 45분을 더하면 정당화될 수 있을 것 같지 않다.대규모 엔터프라이즈 애플리케이션에서는, 애플리케이션이 코어 애플리케이션인 경우, 애플리케이션을 변경하는 것은 당연합니다(작은 변경은 큰 영향을 미칠 가능성이 있기 때문에, 기업 전체의 소비자와 커뮤니케이션을 취해 계획할 필요가 있습니다).이는 OSGi에 있어서 중대한 액티비티입니다.애플리케이션이 엔터프라이즈 애플리케이션이 아닌 경우(즉, 각 소비자가 자신의 사일로에 있는 데이터 사일로에 도달하여 다수의 애플리케이션을 호스트하는 서버에서 실행되는 경우) OSGi를 검토하십시오.적어도 그것은 지금까지의 내 경험이다.

If a Java based application requires adding or removing modules (extending the base functionality of application), without shutting down the JVM, OSGI can be employed. Usually if the cost of shutting down JVM is more, just to update or to enhance functionality.

Examples:

1. Eclipse: Provides platform for plugins to install, uninstall, update and inter-depend.
2. AEM: WCM application, where functionality change will be business driven, which can not afford down times for maintenance.

Note: Spring framework stopped supporting OSGI spring bundles, considering it as unnecessary complexity for transaction based applications or for some point in these lines. I personally do not consider OSGI unless it is absolutely necessary, in something big like building a platform.

I've been doing work with OSGi almost 8 or so years and I have to say that you should consider OSGi only if you have a business need to update, remove, install or replace a component on runtime. This also means that you should have a modular mindset and understanding what modularity means. There's some arguments that OSGi is lightweight - yes, that is true but there are also some other frameworks that are lightweight and easier to maintain and develop. Same goes to secure java blah blah.

OSGi requires a solid architecture to be used correctly and it's quite easy to make OSGi-system that could just as easily be a standalone-runnable-jar without any OSGi being involved.

The OSGi provides following benefit:

■ A portable and secure execution environment based on Java

■ A service management system, which can be used to register and share services across bundles and decouple service providers from service consumers

■ A dynamic module system, which can be used to dynamically install and uninstall Java modules, which OSGi calls bundles

■ A lightweight and scalable solution

It is also being used to bring additional portability of middleware and applications on the mobile side. Mobile side is available for WinMo, Symbian, Android for example. As soon as integration with device features occurs, can get fragmented.

At the very least, OSGi makes you THINK about modularity, code reuse, versioning and in general the plumbing of a project.

Others have already outlined the benefits in detail, I hereby explain the practical usecases I have either seen or used OSGi.

1. In one of our application, we have event based flow and flow is defined in plugins based on OSGi platform so tomorrow if some client wants different/additional flow then he just have to deploy one more plugin, configure it from our console and he is done.
2. It is used for deploying different Store connectors, for example, suppose we already have Oracle DB connector and tomorrow mongodb is required to be connected then write a new connector and deploy it and configure the details through console and again you are done. deployment of connnectors is handled by OSGi plugin framework.

There is already a quite convincing statement in its official site, I may quote as

The key reason OSGi technology is so successful is that it provides a very mature component system that actually works in a surprising number of environments. The OSGi component system is actually used to build highly complex applications like IDEs (Eclipse), application servers (GlassFish, IBM Websphere, Oracle/BEA Weblogic, Jonas, JBoss), application frameworks (Spring, Guice), industrial automation, residential gateways, phones, and so much more.

As for the benefits to developer?

DEVELOPERS: OSGi reduces complexity by providing a modular architecture for today’s large-scale distributed systems as well as small, embedded applications. Building systems from in-house and off-the-shelf modules significantly reduces complexity and thus development and maintenance expenses. The OSGi programming model realizes the promise of component-based systems.

Please check the details in Benefits of Using OSGi.

ReferenceURL : https://stackoverflow.com/questions/106222/what-does-osgi-solve