보통의 스프링 애플리케이션들은 단일 Application Context를 사용하거나, 서비스 계층, 데이터 계층 그리고 도메인 객체를 가지고 있는 부모 Context와 웹 계층 컴포넌트들을 가지고 있는 자식 Context로 나눠서 사용했을 것이다. Application Context는 여러 설정 파일들을 뭉쳐서 생성할 수 있었다.

애플리케이션을 OSGi에 배포할 때 자연스러운 방법은 애플리케이션을 OSGi 서비스 레지스트리를 사용하여 상호 작용하는 번들 집합체로 패키징 하는 것이다. 독립적인 하위 시스템은 독립적인 번들 또는 번들들의 집합체로 패키징해야 한다.(수직 파티셔닝) 하위 시스템은 단일 번들로 묶을 수도 있고, 레이어별로 번들을 구성할 수도 있다.(수평 파티셔닝) 예를 들어, 웹 애플리케이션은 간단하게 네 조각으로 나눌 수가 있다. 웹 번들, 서비스 계층 번들, 데이터 계층 번들, 도메인 모델 번들.
사용자 삽입 이미지
이 예제에서 데이터 계층 번들( 분홍색 Application bundles의 첫 번째 녹색 네모)은 데이터 계층 Application Context에 여러 내부 컴포넌트(bean들)들을 가지고 있으며 그 들 중에서 두 개의 빈을 공개적으로 외부에서 접근 가능하도록 그들을 OSGi 서비스 레지스트리에 등록했다.

서비스 계층 번들(Application bundles의 두 번째 녹색 네모)은 역시 여러 개의 내부 커포넌트를 가진 Application Context를 가지고 있고, 그 중 몇개가 데이터 계층 서비스들을 사용하려고 import 하고 있다. 서비스 계층 컴포넌트 중에 두 개를 외부에서 이용할 수 있도록 OSGi 서비스 레지스트리에 등록했다.(레지스트리 그림은 빠져있어서 2% 아쉽..아니면 서비스로 노출시킨 bean은 다른 색으로 그려주던지...)

웹 컴포넌트 번들(Application bundles의 세 번째 녹색 네모)은 Web application context에 여러 컴포넌트들을 가지고 있고 그 중 몇 개는 서비스를 OSGi 서비스 레지스트리로부터 참조해 온다.

도메인 모델 번들(Application bundles의 네 번째 녹색 네모)은 오직 도메인 모델 타입은 컴포넌트(걍 빈이라고 하지..)가 될 필요가 없기 떄문에 이 번들에는 Application context가 없다.

==============================

애플리케이션을 여러 번들로 쪼갤 때 가장 기본적으로 생각해 볼 수 있는 단서를 제공해 줍니다. 스프링 레퍼런스는 정말 잘 만드는 것 같습니다. 수평으로 쪼개기와 수직으로 쪼개기라.. 멋져부러...