<323020C0CCB8EDC8A32DB0E6B7AEC4C1C5D7C0CCB3CA2E687770>

Size: px

Start display at page:

Download "<323020C0CCB8EDC8A32DB0E6B7AEC4C1C5D7C0CCB3CA2E687770>"

상순 신
5 years ago
Views:

1 한국산학기술학회논문지 Vol. 10, No. 3, pp , 2009 이명호 1* 1 세명대학교전자상거래학과 Design and Implementation of Hotel Reservation System Based Spring Framework 2.5 of Lightweight Container Architecture Myeong-Ho Lee 1* 1 Department of ecommerce, Semyung University 요약본논문은스프링프레임워크 2.5와연관된객체지향소프트웨어개발에대한지침과평가지표를제공하는데목적이있다. Non EJB와 EJB 아키텍처가가지고있는문제점을해결하고장점들을지원하기위하여새롭게등장한아키텍처가경량컨테이너아키텍처이다. 이구조는 EJB 아키텍처와같이무겁지않으면서도 EJB 컨테이너의모든가능을제공하는구조이다. 현재까지경량컨테이너아키텍처로현업에서가장많이사용되고잘알려진아키텍처로스프링프레임워크가있다. 따라서본연구에서는 Non EJB와 EJB 아키텍처가가지고있는단점들을해결하고장점들을지원하기위하여개발된최신경량컨테이너아키텍처인스프링프레임워크 2.5를기반으로호텔예약시스템의설계및구현을통하여이전의사양과의객관적인소프트웨어개발생산성지침을제공하고자한다. Abstract This paper proposes an object-oriented software development guidance and an evaluation index for the productivity related to Spring Framework 2.5. Spring Framework is a known successful open source standard model for lightweight container architecture. Non EJB and the EJB architecture to resolve the problem with benefits to support the new architecture is a lightweight container architecture. This architecture, such as the EJB, but not heavy, to provide all of the architecture is possible. The lightweight container architecture is most often used in business spring framework is well-known architecture. Therefore, this research has the Non EJB and the EJB to solve the advantages and disadvantages developed to support the latest spring framework 2.5 lightweight container architecture based on the design and implementation of a hotel reservation system with the objective through the specification of the software previously to provide guidance to development productivity. Key Words : Spring Framework 2.5, Lightweight Container Architecture, Non EJB, EJB 1. 서론 디지털컨버전스시대에서의컴퓨터아키텍처는인터넷의주도아래근본적인거대한변화의시대를맞이하고있다. 또한웹이진화하면서데이터뿐만아니라응용애플리케이션프로그램까지데스크톱에서해방되어외부 데이터센터에저장해놓고사용할수있는클라우드컴퓨팅 (Cloud Computing) 환경의시대를예고하고있다. 따라서운영환경통합은온-디멘드로, 기반구조의통합은그리드나유틸리티로, 개발통합은통합개발환경으로, 데이터베이스통합은데이터허브나 EAI(Enterprise Application Integration) 로, 사용자인터페이스통합은 * 교신저자 : 이명호 (mhlee@semyung.ac.kr) 접수일 09 년 02 월 02 일수정일 09 년 03 월 19 일게재확정일 09 년 03 월 23 일 589

2 한국산학기술학회논문지제 10 권제 3 호, 2009 RIA(Rich Internet Architecture) 로통합화및표준화가진화되고있다 [3][4]. 이러한엔터프라이즈환경에서는이기종컴퓨터들간에프로그램을분산시켜부하를줄여시스템의성능저하와네트워크병목현상을줄일수있는분산객체구조가필요하게되었으며, 이를해결하기위한컴포넌트기반개발 (CBD:Component-Based Development) 방법론까지이르게되었다 [6]. 여기에서컴포넌트는고유한기능을수행하는독립적인소프트웨어의단위를말하며, 인터페이스와구현의분리를통해캡슐화를통하여컴포넌트제공자와사용자사이에서독립성을확보하여소프트웨어의재사용성을높일수있게하는것이다. 컴포넌트모델은컴포넌트설계와구현단계에서표준규약을통하여컴포넌트에대한일관성있는관리를지원하며, 컴포넌트패키징, 분산, 트랜잭션관리, 통신, 보안등의서비스가포함된다. 그러나이러한컴포넌트모델의분산응용프로그램을운영하기위하여 CORBA, DCOM, RMI 등이개발되었지만지속성있는데이터를표현하기위한표준화된방법이없었고, 트랜잭션, 보안, 멀티쓰레딩등의서비스를위하여개발자들이직접코드를작성해야하였다. 이러한문제점들을해결하기위하여현재인정되고있는컴포넌트모델의표준은 MS사의 COM+, OMG의 CCM(CORBA Component Model), SUN 사의 EJB(Enterprise JavaBeans) 등이있지만, 이중에서대용량분산객체의가장성공모델로알려진것이 EJB이다 [1][3][4][9]. EJB는자바프로그램처럼단독으로실행되는것이아니라 EJB 컨테이너라는소프트웨어에설치되어야실행될수있으며, EJB 컨테이너는 EJB 서버에포함되어있다. 그러나 EJB의단점은분산환경을지원하기위하여객체를직렬화 (Serialization) 하는과정때문에실행속도의저하가발생하며, 개발주기가소스수정, 빌드, 배포, 테스트와같은복잡한과정을거치기때문에개발생산성의저하가일어나며, 테스트의어려움으로제품의품질저하, 변형된패턴들로인한객체지향적으로개발하는데제약사항도발생하며, 대형벤더사들의 EJB 컨테이너사이의이식성저하등이발생한다 [8]. Non EJB와 EJB 아키텍처가가지고있는문제점을해결하고장점들을지원하기위하여새롭게등장한아키텍처가경량컨테이너아키텍처 (Lightweight Container Architecture) 이다. 이와같이경량컨테이너아키텍처의가장중요한 6가지기본핵심가치로는아키텍처리팩토링에의해서확장할수있는단순한아키텍처구성, 소프트웨어개발생산성확보, 객체지향중심적, 비즈니스요구사항의중요성, 기술과아키텍처의검증과정의중요성, 그리고테스트가능성등의지향점을추구하기위한결과물로등 장한것이스프링프레임워크 (Spring Framework) 이다. 따라서본연구에서는 Non EJB와 EJB 아키텍처가가지고있는문제점을해결하고장점들을지원하기위하여개발된스프링프레임워크 2.5를기반으로경량컨테이너아키텍처를설계및구현하여이전의사양과의객관적인소프트웨어개발생산성지침을제공하고자한다. 2. 스프링프레임워크의기본개념 2.1 스프링프레임워크의고찰 현재까지경량컨테이너아키텍처의가장잘알려진구조로는스프링프레임워크이며, 첫번째버전은 2002 년 10월 Rod Johnson이 Wrox 출판사에서출간한 Expert One-on-One J2EE Design and Development" 에서처음소개되었으며, 프레임워크는 2003년 6월에 Apache 2.0 라이센스로릴리즈되었다. 2004년 3월에첫번째스프링프레임워크 1.0 마일스톤이릴리즈되었고, 2006년스프링프레임워크 2.0이릴리즈되었다. 2007년 11월에스프링프레임워크 2.5가릴리즈되었으며. 2008년 12월스프링프레임워크 3.0 M1이발표되었고, 2009년 1월스프링프레임워크 3.0 M2가발표되었다. 그러나스프링프레임워크 2.5에서기존 2.0 버전과비교하여새로운특징의변화가있었다. 가장큰특징으로는애노테이션 (Annotation) 을이용한의존성삽입 (DI:Dependency Injection) 의도입이다. 또한현재까지스프링프레임워크 3.0에서도 2.5의기능에애노테이션설정이좀유연하고폭넓게사용할수있도록조금발전한것뿐이다 [2][8]. 따라서본연구에서는가장큰특징과변화를가지고있으며안정된스프링프레임워크 2.5를기반으로파일럿시스템을설계하여구현하도록한다. 2.2 스프링프레임워크 2.5의구성스프링프레임워크 2.5의가장큰특징은애노테이션을이용한의존성삽입이다. 스프링이시작한의존성삽입기술은피코컨테이너, EJB3.0, SEAM, 구글주스 (Google Guice) 등의다양한프레임워크와기술스펙으로발전해왔다 [5]. 의존성삽입기술은스프링 1.0부터 2.0 까지계속발전해오고있는기술이다. 의존성삽입은 Constructor Injection, Setter Injection, Interface Injection 등의크게 3가지유형을가진다 [2][8]. Constructor Injection은생성자를이용해서의존성을설정해주는방법이고, Setter Injection은 Setter 메서드를이용하여의존성을설정해주는방법이다. 스프링은자바빈규칙을이 590

용한 Setter Injection을주로사용한다. 또한 Factory Bean 기능이추가되어빈의생성방식이유연하게만들수있는길을열어주었다. 스프링프레임워크 2.0에서는이러한의존성삽입의범위를스프링이직접관리하지않는객체에게로확대하는기능이추가되었으며, 스프링프레임워크 2.

3 용한 Setter Injection을주로사용한다. 또한 Factory Bean 기능이추가되어빈의생성방식이유연하게만들수있는길을열어주었다. 스프링프레임워크 2.0에서는이러한의존성삽입의범위를스프링이직접관리하지않는객체에게로확대하는기능이추가되었으며, 스프링프레임워크 2.5에서는단지기존의 XML 설정기능을그대로애노테이션으로적용한수준이아니라애노테이션방식의특징을최대한살리면서다른의존성삽입기술에서제공하고있는편리한설정방식을대폭도입하게되었다 [5]. 따라서본연구에서경량컨테이너아키텍처환경에서스프링프레임워크 2.5 사양으로파일럿시스템을구현한구성도를살펴보면그림 1과같다. 3.2 DB 스키마의설계대용량분산객체처리를위한스프링프레임워크 2.5 사양의파일럿시스템은테이블로영속적인정보를저장하기위하여데이터모델이먼저정의되어야한다. 따라서엔티티클래스를기반으로데이터모델을작성한다. 본연구에서파일럿시스템으로제시한데이터모델인데이터베이스스키마구조는그림 2와같이관리자정보, 회원정보, 예약정보, 예약자정보, 그리고객실관리정보등으로설계하여구현한다. [ 그림 2] 데이터베이스스키마구조 [ 그림 1] 스프링프레임워크의구성도 3. 비주얼모델링의분석및설계 3.1 개발환경 본연구에서는대용량분산객체시스템을개발하기위한스프링을기반으로표 1과같은개발환경을이용하여스프링프레임워크 2.5 환경에서의프로그램을분석하고설계한후파일럿시스템을구현하도록한다. [ 표 1] 스프링프레임워크 2.5의개발환경구분항목 OS Windows XP Professional Platform JDK 1.6 WAS JBOSS-4.2.3GA DB Oracle 10g IDE MyEclipse 6.0 CASE Rational Rose 2003 데이터베이스스키마구조에서각엔티티의기능을요약하면표 2와같다. 엔티티명 Admin Member Reservation Reserinfo Roominfo ipcode [ 표 2] 엔티티의기능 설명 시스템을관리하는관리자정보 시스템에가입된회원의정보 회원이예약한예약정보 예약자와실제투숙자구별을위한예약자정보객실의변동사항을관리하는정보전국의우편번호정보 3.3 유스케이스다이어그램 파이럿시스템의기본적인요구사항을기술한문제기술서와유스케이스명세서를기반으로예약관리에대한요구사항정의활동으로모델링한결과인유스케이스다이어그램으로표현해보면그림 3과같은유스케이스모델이된다. 591

한국산학기술학회논문지제 10 권제 3 호, 2009 [ 그림 3] 예약관리의유스케이스다이어그램 [ 그림 5] 예약관리시퀀스다이어그램 3.4 클래스다이어그램비기능적인요구사항과플랫폼을고려한후, 설계활동을통한분석클래스를구체화하여설계클래스를도출한다. 따라서본연구의파일럿시스템에서중요한예약관리의설계객체모델인클래스다이어그램은그림 4 와같다. 4. 스프링프레임워크 2.

4 한국산학기술학회논문지제 10 권제 3 호, 2009 [ 그림 3] 예약관리의유스케이스다이어그램 [ 그림 5] 예약관리시퀀스다이어그램 3.4 클래스다이어그램비기능적인요구사항과플랫폼을고려한후, 설계활동을통한분석클래스를구체화하여설계클래스를도출한다. 따라서본연구의파일럿시스템에서중요한예약관리의설계객체모델인클래스다이어그램은그림 4 와같다. 4. 스프링프레임워크 2.5의평가 4.1 서비스코드의평가 일반적으로소프트웨어개발생산성을평가할때 LOC 평가방법을자주사용한다. 따라서본연구에서도스프링프레임워크 2.5 사양에서의패키지에대한 LOC를평가해보면표 3과같다. 서비스코드설정부분의직접선언은코드의복잡성을야기시킬수있으며, 형으로빈을찾아서설정하는문제도있다. 이것은같은타입의빈이여러개존재할경우 Autowiring 작업의실패원인이되기도한다. Request Mapping을클래스에적용하게되면해당클래스는지정한 URL만을처리하게되기때문에메서드에적용되는 RequestMapping 애노테이션은더이상 URL을명시할수없는단점도존재한다. [ 그림 4] 예약관리클래스다이어그램 3.5 시퀀스다이어그램위의클래스다이어그램은시스템에서어떤클래스들이있고, 각클래스에서는어떤연산을제공하고있는가를표현한다. 그러나객체들사이의상호작용인전달되는메시지의흐름은시퀀스다이어그램으로표현된다. 따라서본연구의파일럿시스템에서중요한예약관리의분석유스케이스실현모델인시퀀스다이어그램은그림 5 와같다. [ 표 3] 인터페이스와클래스파일의평가 Package명 설정사항 LOC Member Component Controller 선언, 243 Reservation Component Controller 선언, 195 ReservInfo Component Controller 선언, 173 Roominfo Component Controller 선언, 68 Admin Component Controller 선언, 192 Total ( 단위 : Line)

5 그러나스프링프레임워크 2.5에서의서비스코드설정시의장점으로는표 4와같이소스코드와함께설정을할수있고, Field, Multi ActionController의메서드등의편리한설정방식을지원한다. 소스코드와함께있기에리팩토링시편리하다. 소스코드의직접설정으로인한 XML의설정의간소화하며, 의존관계의자동설정으로인한편의성이증가한다. 또한 Controller 인터페이스를구현하지않은클래스도애노테이션을이용하여 Controller 로사용이가능하다. [ 표 4] 서비스코드인 Controller의설정내용 Resource설정및 X - Bean 등록 Context Schema Type 8 (2.5) Annotation Config 1 Total( 단위 : Line) servlet.xml 설정방식 servlet.xml 스키마방식은다음과같다. <beans xmlns=" xmlns:context=" xmlns:p=" xmlns:xsi=" xsi:schemalocation=" XML 평가 스프링에서는스프링MVC의 DispatcherServlet에서컨트롤러를사용하여클라이언트의요청을처리한다. 스프링MVC는 1개이상의 DispatcherServlet을설정할수있으며, 이것은기본적으로웹애플리케이션의 /WEB-INF/ 디렉터리에위치한 [ 서블릿이름 ]-servlet.xml 파일로부터스프링의정보를읽어온다. 서로다른 DispatcherServlet 이공통빈을필요로하는경우에는 ContextLoaderListener를사용하여공통으로사용될빈을설정할수있다. ContextLoader Listener는 contextconfiglocation 컨텍스트파리미터를명시하지않으면 /WEB-INF/application- Context.xml을설정파일로사용한다 [7]. 따라서본연구에서스프링프레임워크 2.5에서개발된파일럿시스템의중요한 XML 현황은표 5와같다. XML 항목 Dispatcher Servlet [ 표 5] 스프링프레임워크 2.5 의 XML 현황 설정항목사용여부 LoC Component-Scan 1 Handler Mapping X - Controller Bean 설정 X - Schema Type (2.5) Total( 단위 : Line) 9 Application Component-Scan 5 8 ( 추가확장기능 ) HandlerMapping 설정을살펴보면, BeanNameUrl, SimpleUrl, AbstractUrl, AbstractBeanNameUrl Mapping, DefaultAnnotationHandler Mapping 방식중한가지를설정한다. 스프링프레임워크 2.5는애노테이션선언과컴포넌트스캔을사용하기때문에디폴트애노테이션방식을사용한다. 따라서애노테이션선언과 Component-Scan 을사용하기때문에 DefaultAnnotationHandler Mapping 방식을사용한다. <bean class= org.springframework.web.servlet.mvc.annotation.defaultannotationhandler Mapping p:alwaysusefullpath="true" /> Component-Scan 설정을살펴보면, controller 패키지를스캔범위로지정해줌으로써컴포넌트선언컨트롤러 Bean을자동등록되게한다. <context:component-scan base-package="controller" /> applicationcontext.xml 설정방식 applicationcontext.xml Schema 방식은다음과같다. <beans xmlns=" xmlns:context=" xmlns:p=" xmlns:xsi=" xsi:schemalocation=" 또한 Component-Scan 설정을살펴보면, 서비스패키 593

5에서 이전 버전들 보다 XML 스키마 형(Schema Type)의 변화로 인한 설정 의 간소화와 Component-Scan으로 인한 빈 설정의 편리 성, 그리고 Controller, Service, Resource, Handler-Mapping 등의 선언을 자동으로 등록 가능함에 따라 컴포넌트 추 가 확장 시 효율성이 증가 등의 장점이 있다.

6 한국산학기술학회논문지 제10권 제3호, 2009 지를 스캔 범위로 지정해 줌으로써 컴포넌트 선언 서비 스 빈의 자동 등록 및 Resource 설정을 하도록 한다. <context:component-scan base-package= member /> <context:component-scan base-package= reservation /> 이상과 같이 스프링 프레임워크 2.5에서 이전 버전들 보다 XML 스키마 형(Schema Type)의 변화로 인한 설정 의 간소화와 Component-Scan으로 인한 빈 설정의 편리 성, 그리고 Controller, Service, Resource, Handler-Mapping 등의 선언을 자동으로 등록 가능함에 따라 컴포넌트 추 가 확장 시 효율성이 증가 등의 장점이 있다. 그러나 스 [그림 7] 호텔예약시스템의 메인 화면 키마 형을 확장 할수록 코드의 라인수가 증가하는 단점 도 있다. 호텔예약시스템 중에서 구현된 회원가입을 위한 실행 화면을 살펴보면 다음 그림 8과 같다. 5. 파일럿 시스템의 구현 경량 컨테이너 아키텍처 환경에서 스프링 프레임워크 2.5의 파일럿 시스템은 각 유스케이스에 사용되는 화면 간의 전환을 화면 흐름 모델로 설계함으로써 명시적으로 분석하였다. 다음 그림 6은 회원가입 관련 화면 흐름 모 델과 관련된 사례로써 예약관리 유스케이스의 사용자 인 터페이스를 위하여 사용되는 화면 흐름 관계를 나타낸다. [그림 8] 회원가입의 실행 화면 6. 결 론 스프링 프레임워크에서는 특정한 인터페이스에 종속 되지 않는 Bean과 같은 클래스인 POJO(Plain Old Java [그림 6] 회원가입을 위한 화면 흐름도 Object)를 관리하는 스프링 컨테이너에게 제어 역행화 이상과 같은 개발 환경과 데이터베이스 스키마를 기반 (IoC:Inversion of Control)를 통한 제어권을 넘겨서 EJB 으로 스프링 프레임워크 2.5 환경에서 호텔예약시스템을 컨테이너에서 지원하던 매력적인 기능들을 지원하고 있 구현한 메인 화면은 그림 7과 같다. 다. 그리고 POJO 기반이기 때문에 특정 환경구축을 위한 클래스를 Import하지 않으며, 애노테이션 사용으로 인한 개발 편의성이 증가되는 장점이 있다. 그러나 설정이 바 뀔 때 마다 컴파일이 필요하며, 각 티어간 연결이 인터페 이스를 통해 이루어지기 때문에 인터페이스의 생성이 필 요로 하는 단점도 있다. 그러나 현재까지 경량 컨테이너 594

아키텍처의성공모델로알려진스프링프레임워크 2.5 사양의정량적인성과지표개발및사례의부족으로이전사양으로운영중인실무프로젝트의업그레이드나새로운기술사양의적용이미비하였다. 그이유는기본적인스프링프레임워크의기술변화의속도가빠르고표준사양의복잡도가높음에따라쉽게새로운사양들을현업에적용하지못한것이다.

7 아키텍처의성공모델로알려진스프링프레임워크 2.5 사양의정량적인성과지표개발및사례의부족으로이전사양으로운영중인실무프로젝트의업그레이드나새로운기술사양의적용이미비하였다. 그이유는기본적인스프링프레임워크의기술변화의속도가빠르고표준사양의복잡도가높음에따라쉽게새로운사양들을현업에적용하지못한것이다. 또한스프링프레임워크의소프트웨어개발생산성비교에대한연구도부족한상태이며, 스프링프레임워크의새로운사양이발표됨에도현재까지구체적인분석및설계기반에따른구현지침이부족하여소프트웨어생산성의평가와프로젝트의새로운시도에제한이있었다. 따라서본연구에서는대용량분산객체시스템처리를위하여스프링프레임워크 2.5를기반으로파일럿프로젝트의분석및설계를통하여구현지침을제시하였으며, 또한스프링프레임워크 2.5에대한성능평가기반으로정량적인분석을통하여객관적인소프트웨어개발생산성연구에대한지침을제시하였다. 향후에는 AOP(Aspect Oriented Programming) 나 EJB 기반구조로스프링을사용한연구와동일한데이터스키마를이용하여 EJB 3.0과스프링프레임워크 3.0의소프트웨어생산성분석연구가지속되어야할것이다. technicalarticles/j2ee/intro_ee5/index.html, 이명호 (Myeong-Ho Lee) [ 종신회원 ] 1984 년 2 월 : 아주대학교산업공학과 ( 공학사 ) 1986 년 2 월 : 아주대학교대학원산업공학과 ( 공학석사 ) 2001 년 2 월 : 아주대학교대학원산업공학과 ( 공학박사 ) 2002 년 3 월 ~ 현재 : 세명대학교전자상거래학과부교수 < 관심분야 > 물류정보시스템, WAS 프로그래밍, 모니터링시스템 참고문헌 [1] 김병곤, Enterprise Java Beans 3.0, 가메출판사, pp , [2] 박재성, Spting 프레임워크워크북, 한빛미디어, pp , [3] 이명호, EJB 3.0 표준을기반으로대용량분산객체처리의설계및구현 ", 대한설비관리학회지, 제13권제2호, pp , [4] 이명호, EJB2.0과 EJB3.0의소프트웨어개발생산성비교연구 ", 한국산업경영시스템학회지, 제31권제3호, pp. 1-7, [5] 이일민, 자바기술의미래를비추는거울스프링프레임워크 2.5, 마이크로소프트웨어, pp , [6] 채흥석, 객체지향 CBD 개발 Bible, 한빛미디어, pp , [7] 최범균, 웹개발자를위한스프링 2.5 프로그래밍, 가메출판사, pp , [8] Road Johnson, Expert One-on-One J2EE Design and Development", Wrox, pp , [9] John Steams, Roberto Chinnici, and Sahoo, An Introduction to the Java EE 5 Platform, " 595

<313720C0CCB8EDC8A32DB5BFC0CFC7D120B0E6B7AE20C4C1C5D7C0CCB3CA20B1B8C1B620C8AFB0E62E687770>

<313720C0CCB8EDC8A32DB5BFC0CFC7D120B0E6B7AE20C4C1C5D7C0CCB3CA20B1B8C1B620C8AFB0E62E687770> 한국산학기술학회논문지 Vol. 10, No. 6, pp. 1265-1274, 2009 동일한경량컨테이너구조환경에서스프링프레임워크 2.0 과 2.5 의개발생산성비교연구 이명호 1* 1 세명대학교전자상거래학과 A Study on Comparison of Development Productivity of Spring Framework 2.0 and 2.5 with