• SpringSource Application Platform Beta Download
• User's Guide
• Programmer's Guide
• SpringSource Enterprise Bundle Repository
  

각 번들에 필요한 기능들을 어떻게 가져오고 노출 시킬 것인가에 대해해, 요즘 고민 중인데, 분석을 하면서 아이디어를 얻어야 할 것 같다.
현재 내가 하고 있는 프로젝트는 공통 모듈들 개발 해야 하는데, 각 공통 모듈을 이용해서 개발해야 할 솔루션의 내부에도 외부로 노출 시켜야 할 서비스 부분이 분명 존재한다. 이를 어떻게 다른 쪽에 인지 시킬 것인지, 그리고 어떻게 가져다 써야 할 것인지에 대한 고민 중이다.



위와 같이 직접 불러다 사용하거나, 아니면 아래와 같이 공통의 라이브러리를 따로 만들고 각 번들에서 직접 호출해서 사용할 수도 있을 것이다.

이미 아는 사람들은 알겠지만, Spring Framework를 만들 "로드 존슨"의 회사명은 "Interface21"에서 "SpringSource"로 사명을 바꿨다. 그리고 더욱 왕성한 활동을 보여주고 있다.

오늘 소개하는 SpringSource Application Platform은 SpringSource의 팀 블러그에 올라온 것으로 beta release를 공개한다는 내용이다.
요즘 사내에서 개발하고 있는 Framwork는 OSGi를 기반으로 설계를 진행중이고 이를 위해서 스프링-DM을 사용하려고 한다. 그래서 관심을 갖을 수 밖에 없다.


Tomcat과 Spring을 통해서 lightweight platform을 구성이 가능하지만, modularaty(모듈화)와 non-web application에 대한 지원에 대한 단점을 안고 있다.
이를 개선하기 위한 노력으로 시작된 것이다.

아래는 Application Platform의 구성을 설명해 주는 그림인데, 여기서 중요한 역할을 하는 것은 SpringSource DMK(Dynamic Module Kernel)이다.

DMK가 동작하기 위해서는 최소한의 번들들이 있어야 된다고 한다. MDK는 구동을 위해서 꼭 Tomcat을 필요로 하지도 않지만, Tomcat는 기본적으로 포함되어 있고, 언제든지 설정을 통해 넣거나 뺄수 있다. 그러나 Tomcat을 제거한다는 것은 Web Module의 Deplroy를 하지 않는 다는 것을 의미하므로 이점은 반드시 유의해야 한다.

다음은 Platform에서 지원하는 3가지 패키징 및 Deploy 방법이다.

Building Applications

• The Platform supports applications packaged in three forms:
  
  1. Java EE WAR
  2. Raw OSGi bundles
  3. Platform Archive (PAR)

먼저,  WAR파일을 통해서 배포가 가능한데, 이는 배포 시점에 OSG번들과 Tomcat에 설치가 된다.
둘째로, OSGi 번들은 직접 Platform에 배포가 가능하며, Import-Package and Require-Bundle를 이용해서 번들간의 deendency의 선확인이 가능하다.
마지막으로 PAR 포맷은 Platform으로 deploy할 때 수동으로 설치가 쉽고, 로드 될때 다른 서비스와 충돌 또는 이중으로 서비스가 동작하는 것을 막아주고, Application에서 사용되는 모듈들에 대해 로직컬하게 Grouping이 가능하게 만들어 주는 잇점을 가지고 있다.
아래는 모듈간의 RAR Application의 전형적인 예이다.

Dependency는 일반적으로 Import-Package & Export-Package를 이용하여 표시한다. 그러나, Third-party 라이브러리를 이용하기 위해서는 이 것말고도 더 많은 라이브러리를 요청하는 경우가 있다. 이를 개선하기 위해서, Platform에서는 Import-Bundle 과 Import-Libary을 이용하여. Import-Bundle 은 추가적으로 다른 third-party 라이브러지를 참조할 수 있게 된다.
 

 

Spring Framework에 대한 관심이 어느때보다 높다.
단지, 유행의 차원을 넘어서서, 개발 효율을 한단계 높일수 있는 계기가 될거라 생각하는 많은 SI업체들이 경쟁적으로 도입하고 있다. 최근 내가 근무하고 있는 회사에서도 일부 도입하여 개발하는 팀도 생기고 있고, 도입을 고려하고 있는 팀도 있다.
내가 속해 있는 팀은 후자에 속한다. 개발의도는 기본적으로는 재활용성을 극대화 하여 모듈간의 의존성을 줄이면서도 중복 개발을 피하려는 의도가 포함되어 있다.

이미 아는 사람들은 알고 있겠지만, Spring Dynamic Module은 기존의 Spring OSGi에서 변경되었다. (Spring Dynamic Modules for OSGi Service Platforms이 Full Name이고 약어로는 Spring-DM으로 사용된다.)
위에서 잠깐 언급하였지만, 현재 진행하고 있는 프로젝트는 Spring Framwork의 여러 부분들과 Spring-DM을 적극 도입하려고 검토하고 있다.

최근에 호주로 간 Toby(일민)이와 채팅을 통해서 어떤 부분들을 공부해야 하는지 의견을 나누었었다.  OSGi에 대한 무지한 내가 어떤식으로 접근해야 하는지 정말 막연했는데, 여러가지 정보들을 얻을수 있었다. 이는 나중에 기회가 되면 따로 정리할 것이다.

Spring-DM은 Java 1.4와 OSGi 4.0이 필요하고 Spring 2.5 또한 필요하다.
OSGi는 일반적으로 Eclipse-equinox가 추천되고 있다. 이미 아는 사람들은 다 알겠지만, Eclipse IDE 3.x는 OSGi를 기반으로 설계되어 개발되었고, 이미 수백만 개발자들이 다운받아 사용하고 검증한 OSGi의 가장 성공한 Case model이다. 그리고, Spring Framework 2.5도 OSGi 번들로 개발되어있다.

이런점에서 Eclipse-Equinox는 OSGi를 분석하고 공부하는데 분명 큰 도움이 될것이다.