Lightweight Architecture In Web Application (kingori@gmail.com)
Executive Summary 현대기업환경에서효과적인 web service와 web application 구축은기업의비즈니스적인목표를달성하는데매우중요한위치를차지하고있다. 그러나기존의 3-Tier 형태의 framework를도입할경우, 개발과유지보수, 그리고장비도입에투입되는높은비용으로인해이러한비즈니스목표의달성에어려움이있었다. 이러한문제점의해결방안의하나로복수의저가장비의 clustering을이용한 2-Tier 형태의 lightweight architecture가제안되었고, 이를통해기업은효과적으로자신의 business 역량을증진시킬수있다.
목차 1. 기술상황분석...5 2. Scope...5 3. 용어설명...5 4. 자료조사...6 5. Technical Findings...7 5.1. Lightweight Architecture의정의...7 5.2. Lightweight Architecture 관련기술및제품... 10 5.2.1. LAMP... 11 5.2.2. Spring... 12 5.2.3. Hibernate... 13 5.2.4. Tomcat... 14 5.2.5. Ruby on rails... 15 6. Lightweight Architecture 적용사례분석... 16 6.1. WEB 2.0 시대의신생기업들... 16 6.2. Reuters 거대뉴스, 정보제공사업자... 18 7. 결론... 19 8. 참고문헌... 20 9. 참고자료... 21 9.1. 기타 lightweight J2EE application... 21 9.2. Dependency Injection 추가설명... 21
그림목차 그림 1 Lightweight Architecture Overview...7 그림 2 3-Tier layout...7 그림 3 2-Tier layout...8 그림 4 WEB 2.0 환경의성공적인시스템개요... 10 그림 6 Local EJB architecture presenting... 12 그림 7 Lightweight J2EE architecture... 13 그림 8 Hibernate Architecture... 14 그림 9 Rails process flow... 16 그림 10 FlickR system architecture... 17 그림 11 Reuters 시스템의분산노드구조... 18
1. 기술상황분석 Web 환경의도입으로기업들은기존의 Client/Server 환경에서의 client 환경종속성과배포의어려움, 그리고유지보수에들어가는높은비용등의많은문제점들을해결할수있었다. Web application/web service 기술은이러한 web 환경의장점을극대화하여더욱기민하고효율적인, 그리고강력한 business enabler로서역할을수행하기위해발전되어왔다. 그결과로 J2EE, CORBA, SOAP,.NET, SOA, AOP 와같은다양한표준안, platform, 기술및각종 vendor들의제품이등장하게되었다. 시장과기술이점차로성숙됨에따라이러한다양한기술에대해검토및비판, 개선이이루어지고있다. 이중많은시스템의근간을이루고있는 3- Tier architecture의단점에대한개선책으로 lightweight architecture가제안되었고, 이에대한활발한논의및기술개발이이루어지고있다. 2. Scope 먼저 lightweight architecture 의개념을 hardware 적측면과 software 적 측면에서대해서알아본다. 이후 lightweight architecture 를이루는대표적 인 framework 들을기술적인측면에서소개한다. 마지막으로기업에서의적 용사례를통해실제적용형태에대해알아본다. 3. 용어설명 Mash ash-up: 하나이상의 source를통해새로운콘텐트를생산해내는 web site 혹은 web application Scale-up: Vertical Scaling이라고도불린다. 단일의높은성능의 server를통해연산을수행하는환경에서, 높은처리용량을확보하기위해 server 자체의기능을확장함을의미한다. 주로고가의서버가투입되므로높은비용이소요되며, 개별시스템의한계로인한기능확장의제한이있다 [1]. Scale-out: Horizontal Scaling이라고도불린다. 연산과 data의 workload 를 load balancing을통해복수의저가장비로분산처리를한다. 투입장비의수를조절하여수행능력을늘이거나줄이는것이가능하다 [1]. LAMP: Linux OS, Apache web server, MySQL DBMS 와함께 PHP/Perl/Python등의 script 언어를통해구현한 web application system 을뜻한다. POJO: Pure Old Java Object. 일반적인 java object를뜻하고, J2EE 환경에서는주로 EJB의대응개념으로쓰인다. EJB가 EJB Container와같은특수 -5/22-
환경에서의동작을고려하여작성된다면, POJO는일반적인 java object로서범용적인용도로서의사용을고려하여작성된다. 그러나 container의 transaction, security 와같은기능을사용하기위해서는 AOP 혹은 container가제공하는 class의상속과같은부가적인지원이필요하다. IoC (Inversion of Control): 객체의 lifecycle 및구동을 container level에서담당하는것을뜻한다. 이를통해 source code에서 container 종속적인 code를분리해낼수있다. 이를구현하는방법에는 Dependency Injection 과 Dependency Lookup이있다 [2]. Dependency Injection: 개별 object이자신이의존하는 resource와 collaborator에대한 lookup을외부 container를통해얻어온다. 대상 object는특별한 interface나 class의상속이필요하지않기때문에 framework과관계없이동작할수있다 [2]. O/R Mapping: OO language의객체와 RDBMS로대표되는 persistent layer간의 mapping을의미한다. 주로 table 이 class, 각 row가 instance로 mapping된다. O/R mapping을통해 RDB와 application 간의자료교환의용이성및향상된 transaction 관리, 성능향상을기대할수있다. AJAX: Asynchronous Java Script and Xml. Web page 상에서 java script와 XML을통해 server와동적으로비동기방식메시지교환을하는작업을의미한다. MVC: Model / View / Controller. AOP: Aspect Oriented Programming. 4. 자료조사 Lightweight architecture 개념및사례조사를위해 ZDNet, InfoWorld, Linux World 등의대형커뮤니티, 뉴스사이트의문헌을조사하였다. 기술자료를위해 J2EE without EJB등의관련도서와 Spring Framework, PHP등의각각의기술커뮤니티사이트의문헌을조사하였다. 각각의기술과관련된기업의사이트를통해시장동향정보를수집하였다. -6/22-
5. Technical Findings 5.1. Lightweight Architecture 의정의 그림 1 Lightweight Architecture Overview (http://www.activegrid.com http://www.activegrid.com) [ 그림1] 은개괄적인 lightweight architecture의특징을보여주고있다. 고가의장비로이루어진소수의서버에서다양한업무를수행하는 3-Tier 개념에서, 저가의일반적인 PC장비를통해비교적간단한업무를수행하는 2- Tier 개념을도입하되, 이를 cluster화하여충분한부하를견딜수있도록한다 [3]. 이를좀더자세히살펴보기위해 hardware적인측면과 software 적인측면으로나누어생각할수있다. 그러나두부분은서로구분되는것이아닌, 상호적인연관관계를가지고있다. - Hardware 적측면에서의 Lightweight Architecture 기존의전형적인 web application /service 시스템은 [ 그림 2] 와같은 3- Tier 구조를가지고있었다. 그림 2 3-Tier layout -7/22-
Web Server Tier는 html, image와같은 static content를저장하고, 사용자에게 content를전송한다. 일반적으로저가 server들의 cluster로구성하고, Apache와같은 web(http) server application으로구동된다. Application Server Tier는 JSP등을통해 dynamic content를생성하고, 이를 Web Server Tier로전송한다. IBM, SUN과같은대형 vendor들의고가장비에, WebLogic 과같은중-고가의 server application으로구동된다. Data Tier는주로 RDBMS가해당되고, content를생성하기위한 data를제공한다. Application Server Tier와마찬가지로대부분고가의장비를사용한다. 3-Tier 구조의경우 Application Tier에도입되는대당장비의비용이높기때문에, 주로 scale-up 전략이도입된다. 아울러높은 server application license 비용도 scale-up 전략을도입하게하는요소이다. 그러나 scale-up 전략도입시정확한부하예측을통한장비도입계획을수립하지못할경우, 과잉장비는기업의추가지출로연결되고, 부족장비는서비스품질저하로이어질수있다. 이러한정교한예측은매우어렵기때문에, 기업으로서는장비구매에대한위험성을동반하게된다. 그림 3 2-Tier layout 이러한문제를극복하기위해위의 [ 그림3] 과같은형태의 Web Server Tier와 Application Server Tier를통합한 2-Tier 구조가대안으로제시되었다. 중저가 PC의성능향상및 2-Tier 구조에적절한 application 및 framework의등장으로이러한 2-Tier 구조가가능하게되었다. 이를통해기업은고가서버도입에따른구매비용에대한부담을덜수있고, 부하집중시 scale-out 전략에의해신속하게지원서버를확충할수있다. 또한좀더가볍고단순한 framework의도입으로개발의생산성및관리비용을줄일수있다. -8/22-
- Software적측면에서의 Lightweight Architecture 비즈니스환경이점차복잡화함에따라, 비즈니스로직도복잡하게되었고, 이것은개발비용의증가와직접적으로연결되었다. 따라서 Amazon.com과같은기업들은복잡한비즈니스로직을분산하여처리함으로써복잡도를낮추기위한노력을했고, SOA 및 web service와같은개념및기술이도입되었다. 이러한노력에힘입어, 개별서버는각각의 service로분산된업무의처리에만집중할수있게되었고, 이것은더이상하나의서버가전체비즈니스로직을일괄적으로처리할능력을가지지않아도됨을의미한다. 이것은자연스럽게 3-Tier의거대한중앙 Application server가독립된 service를수행하는작은 server로분산되는상황으로연결되었다. 각각의 server의 application은 J2EE + EJB와같은복잡한 framework 에서높은개발생산성과낮은소유비용을가지는 PHP, ruby on rails, 혹은 Struts, Spring등의보다가벼운 J2EE framework으로이전할수있게되었다. 또한개별 service에가장알맞은 framework를선택하여적용할수있으므로, 이를통해전체적인개발생산성을더욱높일수있다. 위에서살펴본바와같이, lightweight architecture는전통적인 3-Tier 에비해많은장점을가지고있다. 현재이슈가되고있는 Web 2.0 환경에서는이러한 lightweight architecture의장점을더욱극대화할수있다. [ 그림4] 는 Web 2.0 환경에서의효과적인서비스제공을위한시스템을보여주고있다. Web 2.0 환경에서는기존거대 portal 위주의 web application 에서고품질의특징적인 service로 application의경향이바뀌었다. 또한 Mash-up을통해다른 service들과의연결에따른높은 traffic 부하를처리하기위해높은확장성이필요하게되었다. 특정화된 business logic을안정적으로제공하고, time-to-market을달성하는것이야말로대다수의 Web service 기업들이 lightweight architecture를선택하는이유이다. -9/22-
그림 4 WEB 2.0 환경의성공적인시스템개요 (http://blogs.zdnet.com/hinchcliffe/?p=54 http://blogs.zdnet.com/hinchcliffe/?p=54) lightweight architecture 가도입을통해 business goal 달성 5.2. Lightweight Architecture 관련기술및제품 실제적인 Lightweight Architecture 와관련된대표적인 platform 들은다음 과같다 [4]. 1. LAMP: Friendster, Facebook, Flickr 등의많은 Web 2.0 기업들이적용하고있는대표적인 open source framework 이다. 이미형성된넓은사용자층과함께 IBM, Oracle 과같은 vendor의지원으로앞으로도계속적인성장이예측된다. 2. Open Source Java: 기존 EJB 기반의 J2EE 환경에대한대안으로제시된, lightweight한 J2EE 환경을이야기한다. Tomcat WAS 와 Spring, 그리고 Hibernate와같은 open source project를통해 web application을구성한다. E*TRADE와 EBay와같은서비스업체, CERN과같은기관, 금융권들이 open source java를통해구동되고있다. 3. Ruby on Rails: 빠르게확산되고있는 framework이고, 손쉽게 AJAX application을만들수있다. 그러나아직대규모 site에서의안정성이검증되지않았기때문에, enterprise 환경에서적용하기는시기상조로 -10/22-
판단된다. 그러나현재많은관심을받고있고, 기능도빠르게추가되고있으므로조만간 enterprise 환경에도입될것으로기대된다. 4. Skinny.Net: Schwab, JetBlue과같은회사들은.Net framework의특정요소들을선별적용하여 lightweight한 framework으로사용하고있다..net framework는훌륭한 IDE와 XML 환경및높은생산성을갖추고있다. 그러나비록 Windows OS가저가 machine에서가동이가능하지만, 대형 cluster나 grid에적용하는문제에대해서는아직논란의여지가있는실정이다. 위의 platform 중대표적인 LAMP 와 open source java, Ruby on Rails 에대 해자세히알아본다 5.2.1. LAMP LAMP는대표적인 open source product의조합을일컫는용어이다. OS로는 Linux를사용하고, web server로 Apache를, application script로 PHP/Perl/Python을사용하고, DBMS로는 MySQL를사용한다. 위의 4가지서로다른 application의조합으로전체적인하나의서비스를구현할수있다. LAMP는모두 open source이므로, 구현에따르는 license 비용이전혀, 혹은아주적게든다. Linux는이미기업용시장에널리사용되고있고, 빠르게 Unix를대체하고있다. Redhat과같이기업용으로특화된 Linux뿐아니라일반적인 Linux 배포판도이미수많은기업에도입된상태이다. Apache는대표적인 HTTP server이다. 이미오랜시간동안기업용 HTTP server로사용되어왔다. 2005년도의 Netcraft 의통계결과를통해전체가동중인 Web Server의 70% 이상이 Apache를사용하고있다는것을알수있다. 이러한결과를통해우리는 Apache HTTP server가뛰어난안정성및성능을가지고있음을알수있다. MySQL은계속적인버전업을통한기능및안정성향상과, 저렴한 license 를통한 scale-out 환경에서의유리함을통해기업용 Database 시장에서큰비중을차지하고있다. 2005년 Evans Data의 survey를통해 MySQL이현재사용중인 DBMS 중 33.7% 를차지하고있음을알수있다. Dynamic content를생성하는부분은 Perl, Python, PHP의 script 언어들이다. 이들중가장 web 개발에적합하고많이사용되는언어는 PHP이다. PHP는개발생산성이높고, stateless한특징을통해 scale-out에용이하다. 비록 Object orient적인특성이없고, 소스코드의가독성과유지보수의문제가지적되었으나, PHP 5 버전의도입과함께 OOP로변화하였고계속적인 -11/22-
성능및언어개선으로이러한문제는점차해결될것이다. 5.2.2. Spring Dependency Injection을통한 IoC, AOP등의최신 programming 경향을반영하여 EJB가제공하는다양한기능을제공하고있어, J2EE환경에서 EJB의대안으로가장주목되는 framework이다 그림 5 Local EJB architecture[5] [ 그림6] 은 local EJB architecture를보여주고있다. EJB container와그내부의 Session EJB, Entity EJB 를통해 business logic을수행한다. 이에반해 [ 그림7] 의 lightweight J2EE architecture는 DBMS와 O/R mapping 을통해자료를교환하고, 일반 business logic은 POJO를통해구현한다. 이러한 POJO object의 lookup 및실행은 container가수행하고, 이과정에서 IoC, AOP의 container 특징적인기능이추가된다. [ 그림7] 을 Spring에적용한다면, Hibernate 또는 JDO와의 integration이 O/R Mapping layer에해당한다. POJO를 business object로사용하고, 이를가능케하기위해 IoC를이용한다. UI Tier에서는일반적인 JSP를사용하고있다. -12/22-
그림 6 Lightweight J2EE architecture[5] Spring의다른장점은 proxy-based AOP를통한 AOP 지원이다 [6]. Target object에대한 proxy를통해대상 aspect를찾아내어이를수행한다. 이를통해 transaction, security등의공통적인 issue를 source code에서분리하여일괄적으로관리할수있고, source code는 business logic 자체에집중할수있다. EJB 대체제적인성격을통해 Spring은 Bank of America, 프랑스의 web 기반세무신고 system 같은 mission critical 한 system에적용될수있었고, 앞으로도많은부분에서 EJB를대체할수있을것으로전망된다. 5.2.3. Hibernate Hibernate는 JBoss가지원하는 open source project로서, Java의 O/R mapping의대표적인 application이다. 기존 JDBC를통한 RDB와 application 사이의 data 전송시, 서로간의 data type이다르기때문에많은작업이필요하였으나, O/R mapping tool을이용함으로써이러한반복작업을줄일수있다. 이를통해생산성을향상시키고, DB vendor에독립적인 application 개발이가능하다. Hibernate는기존 J2EE architecture와의 integration이가능하고, 새로발표된 EJB 3.0을지원한다. 또한, web 기반환경이아닌일반적인 JDBC 관련 application에범용적으로적용할수있다. -13/22-
그림 7 Hibernate Architecture[7] [ 그림8] 은 Database를사용하는일반적인 Application Architecture 중에 Hibernate Architecture의 diagram을보여준다. Application의객체들은그 lifecycle에따라 transient object와 persistent object로나뉘고, 이들중 persistent object는외부 DBMS나 file system을통해저장되고불려질수있어야한다. 이를위해 Hibernate는 RDB와의 connection은 JTA, JNDI, JDBC 를사용하고, 객체와의 mapping 및 session 관리를수행한다. Session 관리를위해 JDBC, JTA등의기본적인 transaction을추상화한연관작업의최소단위를나타내는 transaction과, 좀더긴작업단위인 session을가지고있다. Hibernate는 XML을통해 OR mapping table을정의한다. 이런 XML문서는수동, 혹은 third party에서제공하는 XDoclet등의도구를이용하여보다효율적으로작성할수있다. 5.2.4. Tomcat Tomcat은 Apache software foundation에서만든 java servlet container이다. Tomcat은최신의 JSP와 Servlet spec을준수하고있고, 현재는 Servlet 2.4, JSP 2.0을지원하는 5.5 버전이배포되고있다. Open source servlet container의 de facto 표준이라고할수있다. Version 5 의 tomcat은자체적으로 clustering과 load balancing 지원기능 -14/22-
을포함하고있으므로, tomcat을이용한 clustering을더욱손쉽게구현할수있다. Cluster간상호통신은 IP multicast를이용한다. 또한 farming을통해 Cluster 내부의 application deploy를지원한다. Load balancing은 Apache를이용하거나, 자체적인 balancer web application을통해수행한다. 5.2.5. Ruby on Rails Ruby는 OOP를지원하는 scripting 언어이다. 대부분의 OS 상에서구동이가능하고, 높은생산성으로인해빠르게사용자층을확대해가고있다. Ruby 가장점으로내세우는점은다음과같다. - Eiffel과 Ada에부분적으로영향을받은단순한문법 - Java, Python과같은 exception handling - Full, pure OOL. - Closure 개념 Rails는 Ruby를기반으로만들어진 web application framework 이다. MVC model에기반을두고있고, Ruby의언어적특성을이용하여빠른 web application 개발에중점을두고있다. 자동화된 template을이용하여 code generation을해주므로, 실제개발자가작성해야할 code의많은부분을줄여준다. Rails의주요디자인개념은 DRY와 convention over configuration이다. DRY는 Don t repeat yourself를의미하고, code의중복을최소화하라는의미이다. Convention over configuration은프로그래머는일반적이지않은부분에대해서만 configuration 처리를하고, 그렇지않은부분에대해서는굳이 configuration을설정하지않아도된다는의미이다. Rails를구성하는요소는다음과같다 [8]. - Active Record: Model을담당함과동시에, Rails의 O/R Mapping layer 로동작한다. DB Table에대응되는 class를생성하고, DB row에해당하는 instance를만든다 - Action Pack: MVC모델의 view 와 controller를담당한다. View는 static HTML과 ERb(Embedded ruby) 로이루어진 ruby snippet으로작성하거나, builder-style view로작성할수있다. Controller는특정 request를내부의 action에 mapping한다. 부가적으로 caching, session 관리및 helper module 제공을통해 view template의기능을확장시킨다. - Prototype: web page상에서의다양한동적효과를위한 DHTML -15/22-
component이다. - Action Mailer: e-mail 처리를위한 component이다. - Action Web Service: SOAP, XML-RPC, WSDL등의 web service를지원하기위한 component이다. [ 그림 9] 는 Rails 에 request 가요청되었을때의처리 flow 를보여준다. 그림 8 Rails process flow [8] HTTP request가 Rails에요청되었을경우, 이를 Store Controller가해석하여해당로직을수행한다. 이는 Rails의 Action Pack이담당한다. 이과정에서, RDB를통해정보를가져와야할경우, Active Record를통해 O/R mapping을수행한다. 작업후화면표시를위해다시 Store가 View에연결을하고, 화면을구성하여사용자의 browser에이를표시하게된다. E-mail 처리가필요할경우 Action Mailer, web service interface 제공이필요할경우 Action Web Service를적용하여원하는작업을처리할수있다. Rails는 Apache나 lighthttpd 상에서 fast cgi로동작한다. 6. Lightweight Architecture 적용사례분석 6.1. WEB 2.0 시대의신생기업들 2005년에나타난 WEB 2.0은 web service 업계에서의중요한화두가되어왔다. WEB 2.0이가져온새로운경향들중, mash-up service 제공기업들은 lightweight architecture를도입하여빠른고객대응및관리비용절감에성공했다. 또한 lightweight architecture를통한적은 starting cost는이러한회사들이탄생하는토대가되었다. 이러한점에서 lightweight architecture는그들의비즈니스에서중요한부분을차지하고있다고할수있다. - FlickR ( http://www.flickr.com ) -16/22-
FlickR은가장성공적인사진공유사이트이다. 2005년 2월의통계에서당시 270,000명의등록사용자와 4백만장의사진을보유하고있었고, 이후로도가파른성장을하였고, yahoo에 M&A 되었다. FlickR의서비스에서가장큰문제는 scaling이다. 그래서 FlickR은 PHP, MySQL을사용한 scale-out 전략을사용하였다. PHP의 stateless한특징을이용하고, 모든정보를 DB에저장함으로써효과적인 scale-out 전략을도입할수있었다. [ 그림10] 의 FlickR architecture 에서 PHP가 FlickR의전체 architecture의많은부분에사용되고있음을알수있다. 그림 9 FlickR system architecture - 검은박스가 PHP 가사용된부분 [9] - Friendster( http://www.friendster.com ) Friendster는 2003년 3월에운영되기시작한커뮤니티사이트이다. 3천만명이넘는회원을보유하고, 2005년일당 page view가 6천만에이르는거대사이트가되었다. 그러나규모의급성장에따른속도문제로인해서비스의질이떨어지게되었다. 그래서이를해결하기위해기존의 Java 환경을대체하여 LAMP 기반으로이전을하기로결정했다. PHP를선택한가장큰이유는 scale-out의용이성때문이었다. 기존의 system은 Tomcat 서버기반의 Java 시스템이었고, 보다큰문제는내부적인 architecture의문제에기반하고있었다. 그들은 architecture를변경을통해 LAMP 기반의새로운 system으로이전함으로써고객에게보다안정적인서비스를할수있었다 [10]. 위의두기업의예를통해, lightweight architecture 를통한 scale-out 전략이높은 traffic 의사이트에효과적으로적용될수있음을알수있 다. -17/22-
6.2. Reuters 거대뉴스, 정보제공사업자 Reuters는 1851년설립된뉴스, 기술적인솔루션, 경제정보등을전세계적으로제공하는정보제공사업자이다. 비록 Reuters가일반대중에게뉴스제공업체로알려져있지만, 실제로그들의수익의 90% 이상은금융서비스업체들로부터들어오고있다. 따라서 Reuters가그들의수익을증가시키기위해서는전세계 445,000명에이르는금융전문가들에게어떻게그들의정보를신속하고정확하게전달하는가에달려있다. 이러한그들의목표를위해, Reuters는 Microsoft사의 Windows 2003 와. NET framework 기반의 lightweight architecture를도입하였다 [11]. [ 그림 11] 에서각분산노드는 data의전달및외부서비스와의 integration을수행할수있다. 이때의 integration은 web service를통하여수행하고, 각각의분산노드는 Windows Server 와 IIS로운영된다. IIS 6.0 Input Any Distribution Node Value Added Service Cache Manager ROSI API Microsoft.NET Framework Web Service Output Windows Server 2003 Presentation 그림 10 Reuters 시스템의분산노드구조 [11 11] 기존의대형 UNIX 시스템에서 Windows Server의분산노드구조로이행함으로써, Reuters는유지보수비용, 개발및서비스 integration에서의이득을확보할수있었고, 이러한구조변경을통해더좋은사업기회를얻을수있었다. -18/22-
7. 결론 Lightweight architecture를통해고가의 server machine이아닌저가의일반컴퓨터의 clustering을통해 enterprise급의서비스를제공할수있다. 각각의 node PC에 LAMP나 open source Java등의 framework를적용하여이들을 cluster로연결하여전체적인서비스를구성한다. 이렇게저가컴퓨터를이용하여 cluster를구성함으로써, 기업은서버의부하에신속하게대처할수있고, 대형서버의구입비및유지비, 그리고고가의 server application에대한 license 비용을줄일수있다. 이러한 architecture는그우수성이나성능은입증되었지만, 선뜻기업환경에적용하기에는환경적인어려움이따르는것이사실이다. 그러나최근의성공사례나, 대형 vendor들의적극적인 Support(BEA의 Spring 지원, IBM 의 PHP 지원, Accenture의 Spring 컨설팅 ) 를통해, 이들이 enterprise규모의업무수행에있어서충분히경쟁력이있음을알수있다. 기존대형시스템의존적인환경에서는하나의 application server에모든 service를갖추고있었다. 이에따른 application 자체의복잡성및개발의어려움은 service 자체가점차로고도화하고있는현재의기업시스템에서의가장큰문제점으로지목할수있다. 이러한문제를해결하기위해 SOA 등의개념을통해집중적인서비스를분산시키는것이기업시스템의화두이고, 이러한분산적인 service 환경에서 lightweight architecture의도입이더큰설득력을갖고있음은명확한사실이다. -19/22-
8. 참고문헌 [1] MySQL, Guide to Cost-effective Database Scale-Out using MySQL, http://www.mysql.com/why-mysql/mysql_power.html [2] Johnson R, Hoeller J, Expert One-on-One J2EE Development without EJB. 2004, Indianapolis: Wiley Publishing Inc [3]Peter Yared, Lightweight architecture, ZDNet http://news.zdnet.com/2036-2_22-6048210.html [4] InfoWorld, Google, Amazon, and Yahoo! point enterprise developers towards "lightweight" architecture, http://weblog.infoworld.com/openresource/archives/2006/01/google_ama zon_a.html [5] John Arthur, Shiva Azadegan, Spring Framework for rapid open source J2EE Web Application Development: A case study, IEEE Computer Society [6] Rod Johnson, Juergen Hoeller, The Spring Framework: Introduction to Lightweight J2EE Architecture, JavaOne conference [7] Hibernate Reference, http://www.hibernate.org/hib_docs/v3/reference/ko/html_single/ [8] Dave Thomas, David Heinemeier Hansson, Agile Web Development With Rails, The Pragmatic Programmers, 2005 [9] Cal Henderson, Flickr and PHP, http://www.niallkennedy.com/blog/uploads/flickr_php.pdf [10]Cathleen Moore, Friendster adopts open source, LinuxWorld http://www.linuxworld.com.au/index.php/id;1007522249;fp;4;fpid;4 [11] Microsoft, Reuters Lightweight Architecture Improves Manageability and Expands Market Reach, http://download.microsoft.com/download/5/d/1/5d14fee4-1b42-4e7fb72d-749ea396e38d/cs_reuters_en.pdf [12]IBM, Secrets of lightweight development success http://www- 128.ibm.com/developerworks/views/opensource/libraryview.jsp?search_b y=secrets+of+lightweight+development+success -20/22-
9. 참고자료 9.1. 기타 lightweight J2EE application 본문에서다루지않은대표적인 lightweight J2EE application/framework는아래와같다. - JDO 구현체 : Hibernate와같은 O/R mapping을위한 JDO spec의구현체로, 대표적으로 Kodo JDO를이야기할수있다. BEA로합병되어 WebLogic 9.5의일부분으로서제공된다. - PicoContainer: Spring과같은 IoC 구현 container이다. DI를통해객체생성및연관성관리를수행한다. - HiveMind: Spring과같은 IoC 구현 container이다. Microkernel과이를통해 POJO를이용하여 logic을수행하는 Servce로구성되어있다. - Struts: web application에 MVC를구현하기위한 framework. 현재가장널리쓰이는경량형 framework이나, Spring으로빠르게대체되고있는추세이다. 9.2. Dependency Injection 추가설명 Spring, HiveMind 와같은, 최신 container의장점으로부각되는 dependency injection에대한추가설명을 theserverside.com 의 A beginners guide to Dependency Injection에서발췌, 해석하였다. 원문은 http://www.theserverside.com/tt/articles/article.tss?l=iocbeginners 에서읽을수있다. Software components (Clients) 는그들의목표달성을위해, 종종연관 component (Services) 묶음의일부로동작하기도한다. 많은경우, 이러한 component들은 어떤 component와통신하고, 어디에 이러한 component 를위치시키고, 어떻게 그들과통신할지알아야한다. 이러한 Service가변화될때, 이러한변경들은많은 client들의 source code 단의변경을요구하기도한다. Code를구조화하는방법중하나는 client들이그들의 logic의일부로서이러한 service를위치시키고, service를생성하는 logic을포함하는것이다. 다른방법으로는 client들은자신의 service 의존성만을선언한후, 다른 외부 code로하여금 service를위치시키고생성하는로직을선언하고, client 가필요로할때적절한service를제공하도록하는것이다. 후자의방법에서 -21/22-
는, 일반적으로외부의존요인을위치시키는방법이바뀌어도 client code 가바뀔필요가없다. 이런종류의구현을 Dependency Injection이라고하며, 이때필요한 외부 코드는수동으로작성되거나 DI 지원 framework를통해서지원된다. 수년전부터 interface와 implementation을분리시키려는움직임이있었다. 비록 Factory pattern을통해객체생성에대한복잡성은감출수있었지만, service를 위치 시키는내용은 client에남아있었다. 더욱이어떤경우에는다양한 service 간의의존관계에대해고려해야했고, 이는 component들의생성순서와 life cycle 관리에어려움을초래했다. Dependency Injection은우리가작성하는 software가의존관계를정의하고, container 혹은 framework를통해 service 생성, 순차적배열, 에따르는복잡성을없애게했으며, 필요한경우에 client에 service를제공하도록했다. -22/22-