2011-12-23 3 views
3

OSGi와 그와 관련된 모든 것들에 대해 상당히 익숙하다.OSGi 서비스로 기존 애플리케이션을 수정하는 Java/OSGi

점프 : 리스너 목록을 유지하는 서버 클래스가 있는데 리스너는 위에서 언급 한 목록에 리스너를 넣는 메서드 (register(this))를 통해 자신을 등록 할 수 있습니다. 모든 수신기는 서버 클래스 물론 리스너 인터페이스) :

public void register(ServerListener listener) { 
    if(theListeners == null) 
     theListeners = new ArrayList<ServerListener>(); 

    theListeners.add(listener); 
} 

ServerListener 인터페이스입니다 :

public interface ServerListener { 
    public void update(JsonObject data); 
} 

이제 서버 클래스가통해 수시로 새 데이터로 청취자를 제공합니다방법.

public void updateListeners() { 
    new Thread() { 
     public void run() { 
      for(ServerListener l : theListeners) { 
       l.update(jsonObject); 
      } 
     } 
    }.start(); 
} 

지금, 나는 OSGi 프레임 워크 (Knopflerfish)에서 서비스 번들로 서버 클래스를 수정하려는. 나는 그것에 익숙하지 않다. 저는 재미있게 놀고 싶지만, 지금하고있는 방식대로 작동하지 않습니다. 청취자는 실제로 ServerListener 인터페이스를 구현해야한다는 것을 모릅니다. 따라서 서버는 인터페이스를 통해 등록 할 수 없습니다.

문제는 데이터를 푸시하는 것이지 클라이언트를 당겨서 푸시하지 않는 것입니다 (이해하기 쉽습니다). 누가 내 가난한 설명을 이해하는 사람이 올바른 방향으로 나를 가리킬 수 있습니까? 여기

+0

"청취자 ServerListener 인터페이스를 구현해야한다는 것을 모릅니다. " 그걸 어떻게 부르죠? 현재 구현에서 – Thilo

+0

은 인터페이스를 구현하는 리스너가 작동합니다. 클라이언트 구현을 가진 다른 개발자가 서버에서 데이터를 가져 오려면 어떻게 든 serverlistener 인터페이스를 구현해야합니다 (맞습니까?).하지만 해당 인터페이스를 어디에 지정해야합니까? 서버 번들에서 올바른 위치가 아닐 수도 있습니다. 이런 종류의 일반 인터페이스와 클래스가 지정되어있는 코어 번들과 같은 것이 필요합니까? 하지만 어쨌든 새 클라이언트는 다른 번들에 지정된 인터페이스에도 액세스하지 못합니다. 맞습니까? – nyyrikki

답변

6

'OSGi 중심'방식은 일반 Java에서와 같이 수신기 패턴보다는 화이트 보드 패턴이라는 패턴을 사용하는 것입니다. 서버 클래스에 등록하는 대신 리스너는 OSGi 서비스 레지스트리에 서비스로 등록합니다. 즉, 프레임 워크가 등록, 등록 취소 및 사라지는 청취자를 처리하는 것을 의미합니다. http://www.osgi.org/wiki/uploads/Links/whiteboard.pdf, 우리는 또한 액션 (http://www.manning.com/cummins)에서 기업은 OSGi의 5 장에서의 토론을 가지고 :

가 여기에 화이트 보드 패턴에 무료 백서입니다.

서비스를 제공하는 리스너이기 때문에 청중 패턴을 감싸는 데 시간이 걸릴 수 있습니다. 서비스를 사용하는 '서버'는 처음에는 거꾸로 느껴집니다. 일단 익숙해지면 실제로 잘 작동합니다. 서버는 ServiceListener 인터페이스를 구현하는 모든 서비스를 사용하고 필요할 때마다 데이터를 푸시합니다.

서비스를 등록하고 소비하는 데 OSGi API를 직접 사용하지 않는 것이 가장 좋습니다. OSGi 서비스의 종속성 주입을 위해 선언적 서비스 (SCR) 또는 청사진을 사용하십시오. 이를 통해 XML 메타 데이터 파일이나 주석으로 서비스를 등록하고 사용할 수 있습니다.

는 는

(다른 제안으로, ServerListener 인터페이스 패키지 수준의 종속성을 사용하여이 모두 서버와 청취자 번들 수입 할 수 있도록해야한다 상관없이 어떤 번들 패키지를 수출하지 않습니다.) 실제로

4

가지고있어 여러 문제 : 당신은

  • 관심 객체에 등록을 다른 개체에 대한 서비스 (서버 클래스)를 노출 할 필요가

    1. 은 자신을 등록하기 위해 서비스를 찾을 필요 이것은 일반적으로

    을 작동하려면

  • 다른 객체를 사용하면 않는 한 고통 스러울 수은 OSGi에 기존 코드를 개조하려고 특정 인터페이스를 구현해야 이미 모듈 형 아키텍처를 갖추고 있습니다.

    리스너 인터페이스는 서버 번들에 살거나 별도의 API/계약 번들에 둘 수 있습니다. 둘 다 유효한 디자인입니다.

    OSGi에서 가질 수있는 다양한 종속성 유형을 알지 못하는 것처럼 문제를 설명하는 방법부터 설명합니다.

    전통적인 Java 개발에서 나온 대부분의 개발자는 '내 종속성은 JAR을 기반으로합니다'로 시작합니다. 이는 최고의 모델이 아닙니다.

    OSGi는 패키지 수준의 종속성을 제공합니다. 이런 방식으로, 어떤 번들이 필요한 패키지를 제공하는 한 번들은 어떤 번들/JAR이 종속성을 제공하는지 신경 쓰지 않습니다.

    따라서 리스너 인터페이스에 패키지 레벨 종속성을 사용하면 구현시 서버 번들 또는 계약/API 번들에서 오는 것인지 고려할 필요가 없습니다.

    마지막으로 디자인은 서버를 청취자와 단단히 연결합니다. 청취자가 실패하면 어떻게됩니까? 아니면 걸려? Pub/sub는 이러한 유형의 통신을위한 더 나은 모델입니다.

    * 편집 *

    그리고 홀리의 대답은 화이트 보드 패턴을 다시 생각 나게 - 확실히 좋은 생각.

  • 관련 문제