2013-08-07 3 views
0

유지 관리가 쉽고 새로운 번들을 더 빨리 구현하기 위해 사용자 정의 OSGI 플랫폼에서 Glassfish로 이동하려고합니다.OSGI GlassFish의 번들 간 통신

마이그레이션하는 동안 문제가 발생했습니다. 따라서 BundleA와 BundleB는 서비스 참조를 통해 통신해야합니다. 참조 용 인터페이스는 사용자 정의 플랫폼의 기본 번들 인 BundleC에 있습니다. BundleC 없이는 플랫폼 자체를 포함하여 아무 것도 시작되지 않습니다. 그래서 BundleC에 인터페이스를 넣었습니다. BundleB는 인터페이스를 구현하고 시작할 때 서비스로 등록하는 클래스를 가지고 있으며 BundleA는 해당 서비스를 사용합니다.

글래스 피쉬 (Glassfish)로 이동하면서 이미 적절한 OSGI 플랫폼을 제공하고 있기 때문에 이전 BundleC가 필요하지 않습니다. BundleC를 제거한 후에 클래스를 내보내고 가져 오거나 시작을 위해 하나의 번들을 포함하는 것 이외에 적절한 번들 통신을 제공하는 방법은 무엇입니까? BundleA와 BundleB를 결합하지 않고 "거의"독립적으로 만들고 싶습니다.

이 사건에 대한 해결책이 있습니까? 또는 BundleC가 여전히 중간웨어로 필요합니까? 이 2 수명주기가 의미

     Service  
    +-------+        +-------+ 
    | A |---get------|>---register-------| B | 
    +-------+    .     +-------+ 
     !     .      ! 
     !   [service package]    ! 
     !     .      ! 
     !    +-------+     ! 
     \----import-->| C |<---import-------/ 
        +-------+ 

:

답변

1

제대로 아키텍처를 이해한다면 올바른 것을 수행하고 있다고 생각합니다. 현재 Glassfish를 OSGI 컨테이너로 사용하고 있기 때문에 서비스 정의를 제외하고는 번들 C에 아무것도 필요하지 않습니다. 인터페이스.

번들 C - 서비스 인터페이스 만 정의해야합니다 (구현을 제공하지 않음). 번들 B - 번들 C로 정의 된 서비스 인터페이스를 구현하고 OSGI 컨테이너에 해당 인터페이스의 서비스 공급자로 등록합니다.

번들 A는 - 그것은 내가 피하려고 노력하고있는 일을하는 경우

+0

어쨌든 그 번들 C를 제거 할 수 있습니까? 이 구현 이외의 다른 것들을 의미합니까? – stephanruhl

+1

물론 원하는 경우 번들 C를 제거 할 수 있습니다. 번들 B에서 인터페이스를 정의해야합니다. B가이를 정의하고 구현하기 때문에 C를 제거 할 수 있습니다. 그러나 인터페이스의 구현 (또는 버전)이 여러 개있을 것으로 예상되는 경우 C의 인터페이스 정의를 그대로 두는 것이 합리적입니다.이 패턴은 모듈화를 용이하게하고 묶음 의존성 그래프를 깨끗하게 유지합니다. – axiopisty

+0

귀하의 의견과 답변을 주셔서 감사합니다, 나는 세 번째 번들을 제거하고 또한 두 번들 사이의 커플을 제거합니다 glassfish에 jms와 함께하기로 결정했습니다 :) – stephanruhl

3

다음과 같은 설정을 가지고 가정. 첫 번째 A와 B는 C.에 대해 해결되어야합니다. C의 목적은 A와 B가 유일한 공유 부분 인 인터페이스를 포함하기 때문에 서로 분리하는 것입니다. 그래서 순수 커플 링 문제로부터 이것은 일반적으로 나쁘지 않고 많은 사람들이 그것을 추천합니다.

그러나이 모델의 문제점은 인터페이스 만 포함하는 조그마한 번들을 많이 얻는다는 것입니다 (미들웨어를 호출하는 것이 스트레칭 인 것 같지만).

따라서 일반적으로 번들 중 하나를 선택하여 서비스 패키지를 내 보내야합니다. 선택한 번들은 공급자이어야합니다. 이것은 일반적으로 서비스 인터페이스 구현 자입니다 (자세한 내용은 OSGi Semantic Versioning Whitepaper을 읽을 필요는 없습니다). 공급자는 서비스 인터페이스 패키지에 정의 된대로 서비스 계약을 이행하는 번들입니다. 서비스 제공 업체는 번들 B 일 가능성이 큽니다.

번들 B는 서비스 인터페이스 패키지를 내 보냅니다. 번들 A가이 패키지를 가져옵니다. 이것은 매우 훌륭한 종속성 모델을 제공합니다 : 번들 A는 서비스 인터페이스의 패키지에 의존하지만 번들 B에는 의존하지 않습니다. 인터페이스 패키지의 다른 공급자도 작동합니다. 동시에 패키지를 내보내는 공급자가 하나 이상있을 때까지 번들 A가 시작되지 않습니다. 그래서 당신은 아주 좋은 의존성 관리 솔루션을 대신 BND (도구) 3.

+-------+        +-------+ 
    | A |---get------|>---register-------| B | 
    +-------+    .     +-------+ 
     !     .     ^
     !   [service package]    ! 
     !     .      ! 
     \----import-----------------------------/ 

이 사소한의 2 번들이 필요, 그냥 BND 다음 복사됩니다 내보내기-Package 헤더에 서비스 패키지를 추가 패키지를 클래스 경로에서 번들 B로 가져옵니다. 가져 오기에 올바른 버전 범위를 사용하도록 패키지의 제공 확인란을 선택했는지 확인하십시오.

+0

당신의 설명이 자세히 설명되어 있지만 번들 C.에 정의 된 서비스 인터페이스에 따라, 나는 혼란 스러워요. 따라서 인터페이스와 구현을 번들 A에 넣은 다음 등록하고 번들 B에서 호출하려면 번들을 가져와야합니다. 그러면 번들이 결합됩니다. 또는 나는 어떤 점을 놓치고 있냐? – stephanruhl