cover story3 자바기술의미래를비추는거울 스프링프레임워크 2.5 스프링프레임워크 (SpringFramework) 의세번째메이저업그레이드인스프링 (Spring) 2.5 가지난 11 월말에릴리즈되었다. 스프링의캐치프레이 즈처럼더욱간결해지고더욱강력해진 (simpler

cover story3 자바기술의미래를비추는거울 스프링프레임워크 2.5 스프링프레임워크 (SpringFramework) 의세번째메이저업그레이드인스프링 (Spring) 2.5 가지난 11 월말에릴리즈되었다. 스프링의캐치프레이 즈처럼더욱간결해지고더욱강력해진 (simpler and more powerful) 스프링 2.5 의달라진모습과 2008 년에새롭게등장하는스프링포트폴리오에 대해서살펴보자. 스프링 2.5 가릴리즈되었다. 2.0 버전에도그랬던것처럼 2.5도원래계획에없다가갑작스럽게만들어진경우의하나이다. 재작년에스프링 2.0이릴리즈되고나서원래는일부기능을보강한 2.1버전이준비되고있었다. 하지만그변화의폭이워낙크고중대한마일스톤이라고판단한스프링개발팀은릴리즈일정을 5개월연기하면서 2.0에이은새로운버전을 2.1이아닌 2.5로업그레이드시켰다. 이일민 tobyilee@gmail.com 오픈소스기술을엔터프라이즈시스템에적용할수있는전략과기술연구에많은관심을가지고있다. Spring Framework와 Hibernate등의오픈소스프레임워크의교육, 컨설팅, 기술지원을제공하고있는 Epril의대표컨설턴트로활동하고있다. 한국스프링사용자모임 (KSUG) 의기술고문으로활동하며토비의이프릴 (toby.epril. com) 이라는스프링관련기술정보를제공하는블로그를운영하고있다. 어노테이션을이용한설정스프링 2.5의가장큰특징을꼽으라면단연어노테이션을이용한 DI(Dependency Injection) 의도입이라고할수있겠다. DI 는스프링이시작하고대중화시킨스프링의가장중요한기본개념이다. 스프링의거대한프레임워크모듈과구조가모두스프링 DI 컨테이너위에서동작한다. 따라서스프링 DI는스프링프레임워크의기반을이루는프레임워크라고할수있을것이다. 스프링이시작한 DI 기술은이후에피코콘테이너 (Pico Container), EJB3, 심 (SEAM), 구글주스 (Google Guice) 등의다양한프레임워크와기술스펙으로발전해왔다. 스프링도처음로드존슨이쓴 One-on-one J2EE Design and Development 책에나오는예제부터시작해서 1.0부터 2.0 에이르기까지 DI 기능과방법은계속발전해왔다. 초기에단순한 setter injection을이용한 DI에서피코콘테이너의영향을받 136 m a s o

아서생성자를이용한방식 (constructor injection) 을도입했고, 이어서빈의이름또는타입을이용한자동연결기능 (auto wiring) 과긴라이프사이클을가지는빈에서짧은라이프사이클을가지는빈을사용할때쓸수있는메소드삽입 (method injection) 이추가되었다. 또 FactoryBean 기능이추가되어빈의생성방식을유연하게만들수있는길을열어주었다. 2.0에서는이러한 DI의범위를스프링이직접관리하지않는객체에게로확대하는기능이추가되었다. AOP의 LoadTime Weaving 기능을이용해서애플리케이션이직접생성하는객체또는써드파티 (3-rd party) 의프레임워크가생성하는객체에도 DI가가능해졌다. 동시에기존에 <bean> 태그만존재하던 XML 설정파일에네임스페이스가도입되어서스프링이제공하는다양한인프라스트럭처기능에대한설정은 <bean> 을이용하지않고전용네임스페이스의태그를사용해서명시적인정의가가능해졌다. 스프링이 2.0에이르기까지제공한설정방식은 XML을통한외부설정뿐이었다. 물론그사이 XML 설정방식은단계적으로단순해지기는했다. 어트리뷰트를사용한레퍼런스설정이나, P 네임스페이스도입, 자동연경기능등을통해서 1.x의스프링보다는한결단순해진설정이가능했다. 하지만 XML이가지는근본적인불편함이있었고, 특히자바5 이후에도입된어노테이션을이용한메타데이터설정기능을선호하는개발자들은 XML만을이용한설정을제공하는스프링에대해서불만을호소해왔다. 동시에 EJB3, SEAM, 구글주스와같은경쟁 DI 기술들이어노테이션을대폭사용하는기능을지원하면서스프링의어노테이션을이용한설정에대한요구가점차로늘어나게되었다. 결국스프링은스프링의 XML은충분히간결하고편리하다는기존의주장을접고 2.5에서드디어어노테이션방식의설정기능을도입하게되었다. 스프링 2.5의어노테이션 DI가가지는특징은단지기존 XML 설정기능을그대로어노테이션으로적용한수준이아니다. 어노테이션방식의특징을최대한살리면서다른 DI 기술에서제공하고있는편리한설정방식을대폭도입하게되었다. JSR-250 Common Annotation 스프링 2.5가도입한어노테이션에는기존자바스펙에서정의된어노테이션이있다. JSR-250 Common Annotation은자바 EE5와자바 SE6에도입된어노테이션이다. 스프링은자바 EE/SE에서정의된것과같은의미로 JSR-250 어노테이션을사용한다. 만약 JEE5나 JSE6 환경이아니라면 common-anno tations.jar을직접라이브러리에추가해서사용하면된다. JSR-250 에서정의된어노테이션은다음의세가지다. @Resource @PostConstruct @PreDestory @Resource @Resource는빈의이름이나아이디를이용한 DI 를지원한다. 자바 EE 에서는원래 JNDI를이용한 DI를위해서도입된것이다. 스프링에서도 JNDI 리소스의검색을통한 DI 방식으로도사용할수있다. UserServiceImpl이라는빈이 userdao 라는이름을가진빈에의존적이라고하자. 기존 XML을이용한설정에서는 UserServiceImpl 클래스안에 setter를만들고 XML에프로퍼티를설정해야한다. <bean id= userservice class= user.userserviceimpl > <property name= userdao ref= userdao /> 스프링은기본적으로 setter를이용한 DI를사용하니당연히 userdao 프로퍼티에대한 setter 메소드도만들어야한다. < 리스 < 리스트 1> Setter DI 를이용하는빈의예 class UserService { public void setuserdao(userdao userdao) { this.userdao = userdao; 트 1> 은 setter를사용한서비스빈클래스이다. @Resource를이용하면어노테이션을이용하여 <property> < 리스트 2> @Resource 를이용한 setter DI 의예 class UserService { @Resource public void setuserdao(userdao userdao) { this.userdao = userdao; m a s o 137

cover story 3_ 스프링프레임워크 2.5 태그를이용한의존관계를설정할수있다. @Resource를사용할때명시적으로빈의이름을주지않으면자바빈의규약에따른 setter의프로퍼티이름을사용한다. 즉 setuserdao라면 userdao id 를가진빈을찾게된다. 경우에따라서는명시적으로이름을주는것도가능하다. @Resource(name= hibernateuserdao ) public void setuserdao(userdao userdao) { @Resource를사용하면빈을등록하는것이다음과같이단순해진다. 의존성설정이어노테이션을통해서소스코드안에정의되기때문이다. <bean id= userservice class= user.userserviceimpl /> <bean id= myuserdao class= UserDaoHbernate /> 위와같은경우 userdao라는이름을가진 bean은없지만 UserDao 인터페이스를구현한빈이 myuserdao 하나뿐이라면타입을이용한의존삽입이자동으로일어난다. 타입을이용한삽입을시도하다가같은타입의빈이두개이상이면에러를내며 DI 작업이중지된다. 스프링의어노테이션을이용한 DI 기능은 CommonAnno tationbeanpostprocessor에의한 Post Processing 방식을이용한다. 이를위해서 CommonAnnotationBeanPostProcessor을 <bean> 으로정의하거나새로도입된 context 네임스페이스에서제공하는 <context:annotation-config/> 을 XML에정의해야한다. @Resource는 <property> 태그를대치하는것이상의설정을할수있다. @Resource를이용하면 setter뿐아니라필드에바로의존성을주입할수있다. 이경우 setter 메소드가필요없게된다. 또한필드는 public일필요가없다. @Resource @PostConstructor, @PreDestroy @PostConstructor, @PreDestroy는각각스프링의라이프사이클콜백메소드인 InitializingBean의 afterpropertiesset() 과 DisposableBean의 destory() 에대응된다. 따라서이어노테이션을이용하면인터페이스의구현없이메소드의어노테이션설정만으로라이프사이클관리를위한기능을추가할수있다. @PostConstructor는프로퍼티의삽입이끝나면실행되고, 스프링을사용하는코드의특징이길게나열된 setter 메소드들인것을생각하면필드를이용한 DI 기능은의존객체가많은클래스의코드를간결하게만들수있다. 하지만일반적으로필드를 public으로외부에노출하지않는것이바람직하다는것을생각하면단위테스트시코드에의한직접적인의존성삽입이매우어려워지므로테스트코드작성이불편해진다는단점이있다. 반면에 DAO의경우라면 datasource나 sessionfactory 등을목객체를사용하기보다는인티그레이션테스트를하는것이유리하다. 따라서이런케이스라면코드가간결한필드삽입을사용하는것이좋다. 어쨌든스프링을이용한 DI 방식의선택의조건이많아진것이다. @Resource는여기서한단계더나아가서이름이아닌타입을통한 DI 도지원한다. 기본적으로이름을이용해서빈을찾을수없는경우스프링컨테이너는 bytype방식을이용한빈삽입을시도한다. @Resource < 리스트 3> @PostConstructor, @PreDestroy 적용예 @PostConstuctor pubic void initilaize() { @PreDestroy public void shutdown() { @PreDestroy 는컨텍스트가클로즈된후에호출된다. @Resource를이용한 DI방식은기본적으로빈의이름을이용한방식을기반으로하고있다. 이에반해스프링이새롭게소개하는 는기본적으로타입을이용한 DI를지원한다. AutowireByType과같은기능을한다. 사용방법은 @Resource 와마찬가지로 setter 메소드와필드에적용하면된다. 138 m a s o

public void setuserdao(userdao userdao) { 는생성자를이용한 DI와 setter가아닌일반메소드를이용한 DI를추가로지원한다. 생성자와일반메소드를이용한삽입의특징은한개이상의파라메터를주입하는것이가능하다는점이다. 다음은생성자를이용한삽입의예이다. public UserServieImpl(UserDao userdao) { 다중파라미터를받는메소드를이용한삽입의예이다. 각각의파라메터에대해서타입을이용해서빈을찾아서삽입해준다. public void setup(userdao userdao, GroupDao groupdao) { this.userdao = userdao; this.groupdao = groupdao; 를이용한설정은삽입할빈이반드시존재해야한다. 만약빈을찾을수없는경우에도동작하게하려면 re quired 조건을 false로해야한다. (requred=false) 이를이용하면외부삽입이없는경우에해당하는디폴트설정이가능하다. 예를들면다음과같이하면삽입할빈을찾지못하면기본설정된객체를사용하고외부빈이설정되어있다면그것을이용할수있다. 생한다. Required를 false로했을경우에도마찬가지이다. 이를피하기위해서같은타입의빈중에서하나에 primary를설정하 < 리스트 4> primary 를이용한우선빈설정방식 <bean id="userdaohibernate" class="user.userdaohibernate" primary="true">.. <bean id="userdaoibatis" class="user.userdaoibatis"> 는것이가능하다. < 리스트 4> 에서는같은 UserDao타입의두개의빈이등록되어있다. 이경우 를사용하면두개의빈중에서하나를선택해야만한다. 이때 primary=true로설정되어있는빈이있으면그빈을선택하게된다. 이외에도 @Qualifier를이용해서상세한빈의선택을지정하는것이가능하다. @Qualifier는두가지방식으로빈의선택을지정할수있다는첫째는 @Resource와마찬가지로빈의이름을통한설정이가능하다. 또다른방법으로는 @Qualifer의커스톰어노테이션을만들어서이를적용할수있다. 첫째방법은간단하다. @Qualifer에빈의이름을지정하면된다. @Qualifier( myuserdao ) 두번째방법은커스톰어노테이션을지정하는것이다. 먼저 @Qualifier가지정된어노테이션을하나정의한다. @Qualifier public @interface HibernateDao (required=false) UserPolicy userpolicy = new DefaultUserPocily(); 그리고이어노테이션을 @Qualifier 대신사용한다. 이때는이름을지정할필요가없다. 타입을이용한 DI의장점은구지엄격한네이밍룰을만들어사용하지않아도된다는점이다. 대신단점은같은타입을가진두개이상의빈이있는경우에사용할수없다는것이다. @Auto wired를사용했을때해당타입의빈이두개이상이면에러가발 @HibernateDao m a s o 139

cover story 3_ 스프링프레임워크 2.5 그리고빈의설정에 qualifier를지정해주면된다. <bean id= userdaohibernate calss= user.userdaohibernate > <qualifier type= HibernateDao /> @Qualifier가빈의이름을이용한 DI 를지원한다면 @Auto wired/@qualifier를사용하는것과 @Resource를사용하는것이사실같아진다. 이름을이용한빈의의존관계설정을할때이중에어떤것을선택하는가는개발자의선택에달렸다. @Re quired와 @Autowiried는한클래스안에서혼합해서사용하는것이가능하다. 와 @Resource를이용한설정은기존 XML의 <property> 또는 autowire를이용한설정보다매우상세한제어가가능하다. 선택의폭이넓어진만큼적절한설정에대한전략이필요하다. 스프링 2.5를이용한 DI 적용전략스프링의 DI 설정방식은 XML과어노테이션의두가지가존재한다. 이중에서어떤것을사용할지에대해서생각해보자. 먼저기억할것은 XML과어노테이션방식의설정은혼합해서사용할수있고, 많은경우에혼합해서사용하는것이바람직하다. 어노테이션방식의설정은소스코드와함께설정을할수있고필드, 멀티파라메터메소드등의편리한설정방식을지원한다는장점이있다. 소스코드와함께있기때문에리팩토링하기가편리하다. 하지만설정이바뀔때마다컴파일이필요하다는단점이있다. 애플리케이션의설정은시간이지날수록변화할가능성이적어진다. 따라서애플리케이션배치후에변화할가능성이적은일반콤포넌트의경우에는어노테이션방식의설정이편리할것이다. XML 방식은설정이 XML파일안에모아져있기때문에애플리케이션의전체구성을쉽게파악하고변경하는데유리하다. 대신어노테이션에비해서설정코드가많아지며리팩토링시수동으로설정을다시해야하는단점이있다. 하지만 XML은어노테이션에서는불가능한여러가지추가기능을제공한다. 스프링 DI 컨테이너의모든기능을제공하는것은 XML 설정뿐이다. 예를들면다음과같은것들은 XML에서만설정이가능하다. String이나숫자갈은 value값설정 JNDI, DataSource, Transaction, JMS 등의인프라스트럭처설정스프링 2.5의 Pet Clinic 예제를잘살펴보면 XML과어노테이션을함께사용하는설정방식의좋은예를찾을수있을것이다. Component Scanning 스프링 2.5의새로운 DI 기능은빈의의존관계에대한설정뿐아니라빈의정의자체도어노테이션을이용할수있게해준다. 이를위해서콤포넌트스캐닝이라는방식이새롭게도입되었다. 이는패키지를지정하면해당패키지와그하위패키지에서스프링의콤포넌트를찾아서자동으로빈으로등록해주는방식이다. 어떤클래스를스프링의빈으로등록하려면 @Component 어노테이션을클래스에부여해주면된다. @Component public class UserDao { 그리고이클래스가속한패키지또는그상위패키지를스캐닝대상으로설정하기만하면된다. 스캐닝에관한설정은 XML 에다음과같은부분을삽입하면된다. <context:component-scan base-package= user /> 스캐닝방식의빈의등록과어노테이션 DI 기능을함께사용하면 XML 설정이없이도스프링을이용할수있다. 또는인프라스트럭처설정과같은최소한의 XML만을사용하고애플리케이션콤포넌트들은 @Component를이용해서설정할수있다. @Component를메타어노테이션으로사용해서새로운스테레오타입어노테이션을정의해서적용하는것도가능하다. @Component public @interface Util { 과같이 @Util을설정했다면다음과같이어노테이션을추가한후스캐닝에의해서빈으로자동등록하는것이가능하다. 써드파티가제공한코드의설정 인스턴스단위의설정 @Util public class StringUtil {. 140 m a s o

스프링 2.5는 @Component 외에이미등록된스테레오타입어노테이션이있다. @Repository : DAO와같은 repository @Service : stateless 서비스 @Controller : MVC Controller 이와같이스테레오타입을만들어사용하는것은빈의종류를명시적으로구분한다는것이상의의미가있다. 특정어노테이션이지정된빈들을대상으로특별한설정을한다거나, 추가적인정보를지정할수있다. 예를들면 @Repository의경우는스프링이지원하는 Exception 변환기능을적용할수있다. 스프링의 AspectJ 스타일의 AOP 설정기능을이용하면어노테이션을이용한포인트컷의적용이가능하기때문에특정어노테이션을가진빈들을선택해서특정어드바이스를주입하는것도가능하다. 콤포넌트스캔을적용할때주의할점은불필요하게많은클래스를스캔하는것을막는것이다. 그렇지않으면컨테이너의컨텍스트셋업에많은시간이소요될수있기때문이다. 또필요에따라서특정한빈들만스캐닝대상에적용할수도있다. 이를위해서스프링은 <context:filter> 를지원한다. 이를이용하면특정어노테이션, AspectJ 포인트컷, 정규식 (regex) 을이용한필터를설정할수있다. <context:component-scan base-package= component > <context:include-filter type= assignable expression= user.baz /> <context:include-filter type= aspectj expression= user..*service /> <context:include-filter type= regex expression= user\.b[a-z]+ /> </context:component-scan> <bean id= userdao class= user.dao.userdao /> 만약이름이충돌이나거나다른이름으로빈의등록이필요하다면직접이름을지정하는것도가능하다. @Component( myuserdao ) public class UserDao { XML을이용한빈의등록과마찬가지로 @Component를이용한빈의 scope도기본적으로는싱글톤이다. 이를변경하려면 @Scope 어노테이션을사용한다. @Component @Scope( session ) public class SomeBean { 플랫폼스프링 2.5는자바EE부터 OSGi에이르기까지다양한플랫폼을지원한다. JDK1.6 스프링 2.5는 JDK1.6을공식적으로지원한다. JDK1.6의 JDBC 4.0의 native connection이나 LOB 핸들링기능을지원하며, JMX MBean, ServiceLoader API 를이용한다. 물론스프링은기존 JDK1.5, 1.4버전과도완벽하게호환된다. 다만기존 2.0까지지원하던 JDK1.3은더이상지원하지않는다. SUN이 JDK1.3에대해서 EOL(End of Life) 선언을한만큼이제 JDK1.3은현장에서수명이다했다고볼수있기때문이다. 그럼 @Component나스테레오타입어노테이션이적용된빈의 id 는클래스의 Non-Qualified 이름을이용한다. 즉, 패키지를제외한클래스명을그대로사용한다. package user.dao; @Component public class UserDao { 이렇게정의된클래스라면다음과같이 XML을설정하는것과동일한설정결과를가져온다. 자바 EE 5 스프링은 JavaEE5를완벽하게지원한다. J2EE1.4, J2EE1.3 과도역시호환된다. Servlet2.5, JSP1.2, JSF 1.2등에적용된 JSP-250 annota tion을일관된방식으로사용할수있으며, unified EL과같은기능을사용할수있다. 또 JTA 1.1, JAX-WS 2.0등도지원된다. RAR J2EE 1.4 (JCA 1.5) 에서사용하는 RAR파일형태로스프링을패키징할수있다. 이를이용하면스프링이웹이나유저인터페이스환경없이서비스레벨로배치하는것이가능해진다. 메시 m a s o 141

cover story 3_ 스프링프레임워크 2.5 징처리, 스케줄링기능등의백그라운드프로세싱을담당하는형태로의배포가가능하다. JMX MBeanServer를이용해서액세스하는것도가능하다. JCA 1.5 JCA 1.5에대한완벽한기능을제공한다. JCA Resource Adapter를지원하며, JMS나 CCI 메시지리스너를사용할수있다. OSGi 스프링 2.5는그자체로 OSGi에배포가능한번들로사용할수있다. 스프링다이나믹모듈프로젝트에서제공하는기능을이용하면스프링을이용해서만든빈들을번들로손쉽게작성해서 OSGi에서사용하는것이가능하다. 이를이용하면스프링애플리케이션을자바EE 플랫폼뿐만아니라 OSGi 플랫폼에서도사용하는것이가능하다. AspectJ 지원스프링 2.5에서는 AspectJ와관련된많은기능이추가되었다. 대표적으로 AspectJ의포인트컷에빈의이름을이용한정의가가능해지게되었다. 이를이용하면빈의타입뿐만아니라이름을이용한포인트컷이가능해진다. 다음은클래스이름이 Service로끝나는것이아니라빈의이름이 Service로끌나는모든빈을선택하는포인트컷의예이다. <aop:advisor pointcut= execution(bean(*service)) advice-ref= accesscounter /> 스프링은여전히프록시기반의 AOP와 AspectJ 기반의 AOP 를모두지원한다. 빈단위의 AOP 적용은일반적으로프록시기반을사용한다. 하지만필요에따라서 AspectJ의 AOP를적용할수있다. 이때는클래스의로딩시에바이트코드변환을가져오는 LTW방식과컴파일러방식두가지를모두사용할수있다. 기존에는 AspectJ의라이브러리를직접이용했던것에반해서스프링 2.5는스프링이직접제공하는 LoadTimerWeaver를제공한다. @Configurable 스프링 2.0에서부터지원하던 @Configurable도더욱편리한방식으로사용할수있다., @Resource등을 @Con figurable이적용된클래스에사용할수있다. 또한스프링자체 의LTW를적용할수있다. @Transactional @Transactional을 AspectJ를이용한방식으로사용할수있다. <tx:annotation-driven mode= aspectj transaction-manager= txmanager /> 기타지금까지소개한것이외에도스프링 2.5는많은새로운기능을제공하고있다. JUnit 4.x와 TestNG를어노테이션을기반으로한스프링테스트로만들수있는기능이추가되었다. 이제스프링컨텍스트를사용하는인테그레이션테스트의사용범위가더넓고편리했졌다. WebSphere와 WebLogic과같은대표적인 WAS를위한기능도대폭추가되었다. 이를이용해서스프링의추상화기능을사용하더라도 WAS가제공하는특별한기능을폭넓게이용할수있다. 스프링은스프링핵심프레임워크이외에도다양한서브프로젝트들로구성된스프링포트폴리오로구성되어있다. 이중에서올해주목받을만한것들이몇가지있다. 첫째는지난일년간계속발전해온스프링다이나믹모듈- OSGi 프로젝트이다. 자바EE외의새로운플랫폼으로새롭게주목받고있는 OSGi가스프링을통해서빠르게보급될것으로기대하고있다. 두번째는액센추어와스프링개발팀에의해서공동개발되고있는스프링배치프로젝트이다. 엔터프라이즈개발에빠질수없는배치개발을위해서제공되는스프링기반의안정적인인프라스트럭처이다. 셋째는 2008년에새롭게시작되는스프링인테그레이션프로젝트이다. SOA 환경에서스프링을이용한다양한엔터프라이즈인테그레이션기술을추상화된레벨에서제공할수있는새로운프로젝트이다. 올해초에그모습을공개하기로했으니기대할만하다. 스프링의발전모습은무척이나인상적이다. 때론새로운첨단기술의도입을빠르게주도해가면서도동시에원칙과기본에충실하고더욱단순해지려는모습은스프링이성공한비결이어떤것인지잘말해주는것같다. 2.5버전까지거의 4년을빠르게발전하면서도완벽한구버전호환성을가지고있다는것이그것을증명해주고있다. 로드존슨의말대로스프링은자바서버개발의 142 m a s o

사실상의표준이되어가고있다. 스프링의발전모습을잘살펴본다면그것을통해서앞으로자바기술의흐름에대한전망을얻을수있지않을까기대해본다. 참고자료 1. Spring 2.5 reference manual, http://static.springframework.org/spring/docs/2.5/reference/index.html 2. Configuring Spring with Annotations: Mark Fisher, Rod Johnson 3. Spring Framework 2.5 : Juergen Hoeller 스프링다이나믹모듈프로젝트 스프링포트폴리오는스프링프레임워크를확장해서만든다양한엔터프라이즈기술프로젝트를말한다. 그중에서 2008년에가장주목받는것은바로스프링다이내믹모듈 -OSGi 프로젝트이다. OSGi는차세대자바플랫폼으로가장기대되는기술로자바기반으로완벽한모듈구조의개발이가능하도록만들어진기술이다. OSGi는번들이라고불리는모듈이다음의세가지특징을가지면서서로연동하여동작하도록되어있다. 강력한모듈화번들은하나의블랙박스처럼동작한다. 외부와는하나이상의패키지를노출하는것을통해서연동할수있다. 모듈에서노출된패키지외에는강력한방법으로차단되어있기때문에불필요한커플링을줄이고, 번들간독립적인개발이가능하며, 빠른개발사이클을가질수있다. 동작컨트롤-라이프라이클관리 OSGi의번들은완벽한동작컨트롤이가능하다. 모든모듈에대한상태를조회할수있으며, 와이어링과관련된정보를얻을수있고, 새로운모듈의배치와업데이트, 시작, 중지, 언인스톨등의작업이가능하다. OSGi의가장큰특징은이러한모듈의컨트롤작업이완벽하게런타임시에일어날수있다는것이다. 완벽한버전관리노출된패키지는다른번들에의해서사용될수있는데이때여러버전의같은번들을동시에액세스하는것도가능하다. OSGi 는버전의충돌과의존관계의문제, 업그레이드의문제등을완벽하게제어할수있는방식으로동작한다. OSGi가주목받는이유중의하나는바로기존자바서버플랫폼을대치할수있다는기대때문이다. OSGi 서비스플랫폼위에기존자바엔터프라이즈서버를번들형태로배치할수도있고, 반대로임베디드된 OSGi 플랫폼을자바엔터프라이즈서버위에서동작하게할수도있다. 또는이두가지형태의아키텍처가동시에존재하며서로연동하게만들수도있다. 스프링다이나믹모듈프로젝트는 OSGi환경의번들을스프링프로그래밍모델을그대로유지한채로만들수있도록도와준다. 이미스프링2.5의모든기능은그자체로 OSGi번들로배치될수있도록패키징되어있다. 그위에애플리케이션콘텍스트단위로번들을만들어서스프링애플리케이션이 OSGi에서동작하도록만들수있다. OSGi의특징대로하나의애플리케이션을세부모듈로나누어개발하고별도로배치할수있는데스프링다이내믹모듈프로젝트는이렇게분리된모듈간에스프링의의존관계주입 (Dependency Injection) 이일어나도록만들어준다. 아래와같이등록된스프링빈을외부에노출하려면간단히 <osgi:service> 태그를사용하면된다. <bean id= printservice class= com.springsource. osgi.print.internal.printserviceimpl init-method= init destroymethod= destroy /> <osgi:service ref= printservice interface= com.springsource. osgi.print.printservice /> 이렇게노출된서비스빈은다른번들에서 <osgi:reference> 를통해서참조해서사용할수있다. <bean id= printclient class= com.springsource.osgi. print.client.client init-method= init > <property name= printservice ref= printservice /> <osgi:reference id= printservice interface= com.springsource. osgi.print.printservice /> 이처럼스프링은기존의프로그래밍모델을유지하면서도손쉽게 OSGi번들형태로재구성하는것이가능하도록도와주기때문에 OSGi 기술의확산에큰바람을불러올것으로기대되고있다. m a s o 143