IT/모바일
저자: 이아스님 (http://iasandcb.hihome.com)
jEdit는 순수 자바 에디터 애플리케이션입니다. SciTE는 Win32와 X용 에디터지요. 따라서 둘 다 무척 다양한 플램폼에서 쓸 수 있다는 공통점이 있지만, 그것보다 더 눈에 띄는 것은,
사실 클래스를 짜다 보면 이렇게 저렇게 블럭이 많이 생기게 되고(반복문, 조건문등), 그게 나 늘어져 있는 상태에서 소스의 여기 저기를 이동하려다 보면 스크롤 양이 참 많아지죠. 그런데 이 폴딩 기능을 활용하면 잘 안보는 블럭은 접어둘 수가 있어 훨씬 소스의 특정 부분의 접근이 빨라집니다.
jEdit는 J2SE 1.4 RE(Runtime Environment)를 권하는데, 다양한 플러긴으로 휠마우스 지원, 톰켓 연동등의 강력함도 선사합니다. 또한 편리하게 울트라에디트나 에디트 플러스처럼 오른쪽 버튼 바로 열기 기능을 지원하구요. 다만 초기에 뜨는 시간이 좀 걸리죠.
SciTE는 반면 상당히 가벼우면서도 간편함이 돋보입니다. 굳이 JRE을 쓰지 않으시는 분들이라면 딱이 아닐까 싶네요.
친구 히따꿍(sgwcs)가 만든 Tree자료구조체 구현 클래스~
어느 게시판에선가도 본 듯한 기억이 나는데, 왜 자바에는 트리(tree) 자료구조를 구현한 것이 없으냐는 의문에 부응하듯이, kr.pe.sgwcs 패키지에 트리 구조 인터페이스와 임플리멘테이션이 있어 소개합니다. 자바 콜렉션 프레임웍에는 배열(가변), 연결 리스트, 집합(Set), 해시 등은 구현되어 있는데, 묘하게도 트리만은 스윙에서 JTree의 데이터모델로서 TreeModel과 SortedMap을 구현하기 위한 Red-Black(RB) 트리(재밌는 설명 사이트가 있더군요.) 도입이 있을 뿐이죠.
조만간 이 트리 패키지에 형총칭성(Generics)를 적용하여 더욱 편리한 콜렉션 프레임웍으로 선보일 협의에 들어갈 예정입니다. kr.pe.sgwcs 패키지에 많은 관심 바랍니다.
첨부 파일 전송의 현재와 미래
지난 토요일 공개 세미나에서 받은 한 참가하신 분께서 클라이언트(애플릿)이 서버(아마도 서블릿)로 POST multipart/form-data 방식으로 자료를 보내는 방법에 대해 문의해주셨는데요, 마침 거기에 대한 글들을 제가 이미 자바 스터디에 답변으로 써서 여기 링크를 달아보았습니다. 역시 애플릿이 소켓이 아닌 HTTP로 이러한 방식을 취해야하는 이유는, 그만큼 HTTP가 방화벽 친화적(firewall-friendly)이라는 뜻이기도 하겠지요. 최근의 웹서비스도 이런 HTTP를 기반으로 삼고 있다는 것도 이런 사실을 반증합니다.
그런데, 사실 위에 소개한 방식은 무척 까다롭고 구현하기도 힘듭니다. 특히 multipart의 MIME 특성상 첨부파일격의 바이너리 데이터를 전체 네트웍 정보에서 유의미하게 뽑아낸다는 것은 더욱 그렇지요. 그래서 JavaMail도 Java Activation Framework이라는 거창한 API로 이런 데이터를 다루는데요, SOAP에서도 이 API들을 쓰면 편리합니다.
이러한 현실적인 필요에서 XML, 특히 SOAP("솝"이라 발음합니다.)는 무척 유용한데요. 간단히 아파치 SOAP로 구현해볼 수도 있구요, XML 팩에 들어있는 JAXM으로도 가능합니다. 기본적인 아이디어는 클라이언트가 서버에 던지는 SOAP메시지에 첨부파일을 붙여 보내는 식인데요, 제가 현재 번역하고 있는 "자바 웹 서비스(오라일리)"의 3장, 7장에 각각 나와있습니다. 급하신 분은 원서를 보셔도 되겠구요. (이 주제를 가지고 공개 세미나에서 자세히 언급할 생각도 가지고 있습니다. 웹서비스에 대한 공개 세미나는 6월말 책 출간과 더불어 열릴 예정입니다.)
이러한 웹서비스 방식의 장점은 역시 HTTP를 타므로 방화벽 걱정이 없고 XML 메시징이므로 다루는 입장에서도 무척 선명하다는 것입니다. POST multipart와 같은 저수준(low-level) 프로토콜을 직접 구현할 필요도 없어 더욱 편리하죠. 다만 서버가 웹서비스를 지원하도록 구비되어 있어야하는데, 이또한 결코 어려운 일은 아니니 걱정하지 않으셔도 되겠습니다.
생각보다 웹서비스는 우리 가까히 있다는 생각이 들었습니다.
SRV(Servlet) 2.4와 JSP 1.3
현재 JCP에서 논의중인 서블릿 2.4[JSR154]와 JSP 1.3[JSR152]을 잠깐 소개하려 합니다.
올 하반기 출시 예정인 J2EE 1.4[JSR151]에 포함할 예정인 이 핵심 기술들은 웹서비스와의 연동, 더 쉬운 페이지 제작을 모토로 전개되고 있습니다.
오늘은 간단하게 각 기술들의 새로운 모습을 개요적으로 살펴보고, 다음주부터 그 면면을 자세히 살펴보겠습니다.
우선 서블릿 2.4에서는
JSP 1.3의 모토는 "스크립트없는(script-less) JSP 작성"입니다. 그것의 첫번째 시도는 이미 JSP 1.1때부터 실험적이라는 평을 받았던 커스텀 태그 개념이었는데, 안타깝게도 너무나 고상한 이론과 더 거룩한 실제 덕분에 MVC모델 구현의 저높은 이상(ideal)로 남아버렸습니다. 그래서 덩달아 불어나는 JSP속의 자바 코드-스크립틀릿(scriptlet, <% ~ %>), 표현식(expression, <%= ~ %>)등-을 지양하기 위해 자바보다 훨씬 직관적이고 쉬운 스크립트 언어로 자바 코드가 해왔던 역할을 대체하고자 하는 시도가 이번에 선보입니다.
현재 이 EL의 스크립트 언어적인 기반으로는 ECMAScript와 XPath가 채택되어 JSP에 적합한 요소들만을 취합할 것으로 알려졌습니다.
점점 분화하는 웹 개발 현장, 과연 그 이동(shift)을 JSP 1.3이 열지, 아니면 이동을 한 후 JSP 1.3을 요구할지 사뭇 기대가 됩니다.
CLDC 1.1과 MIDP 2.0
CLDC 1.1[JSR139]과 MIDP 2.0[JSR118]가 현재 명세 공개된 상태입니다. CLDC는 1.0에서 마이너 업그레이드한 반면, MIDP는 1.0에서 화끈하게 2.0으로 뛰었습니다. 이는 그만큼 MIDP의 API적인 요구가 많았다는 것이겠죠.
CLDC 1.1 진화의 면면을 한마디로 요약하면 "더욱 강력한 CLDC"입니다. 그간 부동 소수점, 레퍼런스 개념등의 결핍, 그리고 Calendar, Date, TimeZone과 같은 핵심 클래스의 J2SE와의 위화감을 해결하여, 비표준적인 부가 지원이 없도록 하였습니다.
MIDP 2.0의 변신은 한마디로 "대규모 성형수술 공사"수준입니다. MIDP가 가장 많이 쓰이는 분야인 "게임"에 대한 현실적인 요구 수용과 더불어 앞으로 각광받으리라 예상하는 "법인대상" 씬 클라이언트(thin client) 수요에 대비한 보안 능력 강화가 가장 눈에 띄입니다.
MIDP 2.0은 1.0의 미약한 점들을 보강하고자 각 기술사가 재빠르게 나름대로의 부가 프로파일을 개발해오던 것을 이왕이면 표준화하여 차세대 모바일 개발 시장에서 유리한 고지를 점령코자 마련된 것이라고 볼 수 있습니다. 애니메이션쪽만 봐도 이미 제이폰(J-Phone)의 자바 서비스에서 반다이(BANDAI)가 3D쪽을, 세가(SEGA)가 2D쪽을 강화한 별도의 프로파일을 제공했는데, 스프라이트 개념은 세가의 그것에서 온 것이나 다름 없습니다. (3D쪽은 Mobile 3D API라고 해서 따로 진행중입니다.)
SKT, LGT의 경우에는 일본이 HTTP만을 지원하는데 반해, 시작부터 소켓을 지원했고, 미디어 지원도 확실했습니다. 거기에 부동 소수점, 3D, SMS(이것은 현재 Wireless Messaging API로 연구중)까지 선구적으로 지원한 셈이죠.
SKT측의 자바 기술 담당사인 XCE는 이미 SSL구현을 마쳤다고 하는데, 이번 MIDP 2.0에 어떠한 모습을 보여줄 지 기대가 됩니다.
앞으로도 MIDP 2.0을 비롯한 J2ME관련 기술-API의 소개는 계속됩니다.
스트럿츠(Struts) 책 소식
오라일리에서 올 3사분기에 낼 스트럿츠 책의 원고가 더 서버 사이드 닷 컴에서 사전 공개중입니다. 스트럿츠는 MVC모델 구현을 돕는 프레임웍으로 유명한데, 이 분야에 있어서 거의 표준으로 자리잡을 전망입니다.
스트럿츠는 Model-View-Controller 컴포넌트 구현을 위한 편리한 도구를 제공하는데, 특히 View쪽의 커스텀 태그는 현재 연구중인 JavaServer Faces(JSF)의 발안에 지대한 영향을 준 것으로 알려져 있으며, 실제로 스트럿츠의 뷰 커스텀 태그가 상당량 반영되지 않겠냐는 예상도 나오고 있습니다.
Model쪽은 워낙 자바빈즈 구조를 기반하고 있어서 달리 웹 기술에 영향을 줄 것은 없지만, 이쪽은 오히려 JDO(Java Data Object)와 가까와서, DB-대응(mapping)과 관련하여서는 JDO와의 연동도 고려해볼 만합니다.
Controller쪽이 매우 근본적으로 강력한데, 일명 Mediator-Command패턴을 스스로 밑바닥부터 구현할 필요없이 기본적인 구성의 틀을 제공하고 있어 콘트롤러에 대한 개발자의 고민도 사라집니다.
MVC모델의 놀라운 점은 웹애플리케이션을 마치 GUI애플리케이션처럼 컴포넌트-이벤트 핸들링 스타일로 짤 수 있다는 것입니다. 콘트롤러는 뷰와 모델의 중개자(mediator)로서 자료의 변경과 화면의 갱신을 지시합니다.
그런데, 지금까지의 웹 이벤트는 이른바 GET-POST메소드 방식의 요청 송신으로 촉발되는 것이 대부분이었습니다. 즉 사용자의 웹브라우저 조작에 따른 요청이 발생하였을 때 콘트롤러가 그 요청을 분석하여 이런저런 처리를 중재한다는 뜻이죠.
여기서 바로 웹 애플리케이션 모델2(MVC모델)의 콘트롤러(서블릿) 중심 설계(servlet-centric design)이 대두하는 것입니다.
다수의 JSP-하나의 서블릿(중앙 본부-headquarter)-다수의 빈
따라서 JSP의 코딩을 담당하는 JSPer(제이에스피어)는
빈 코딩(DB쪽을 포함하여)을 담당하는 Beaner(비너)는
MVC모델은 단순히 애플리케이션의 구조적인 관점뿐만 아니라 제작(production) 구조에도 영향을 미치고 있습니다. JSTL와 JSF를 통해 빠르고 쉬운 페이지 작업을 열망하는 JSPer, 재사용 가능하며 역동적인 비즈니스 로직을 유연하게 수용하는 빈 제작을 꿈꾸는 Beaner, 그리고 이런 동상이몽의 사이에서 전체적인 조율을 담당할 Servleter... 모델 2가 나온지 어언 2년이 넘어가는 시점에서 스트럿츠와 같은 프레임웍이 나오며 자바 웹 개발자들의 시선을 모으며 무척 "당연하게" 여기듯이, JSPer-Servleter-Beaner의 삼위일체 삼자분업의 일도 어쩌면 MVC모델의 대중화에 걸린 시간보다 훨씬 빠르게 정착할 지도 모르겠습니다.
그 일례가 바로 스트럿츠와 XML로 구현한 MVC 게시판을 연구, 제작, 그리고 공개 배포까지 하고 있는 자바지기 사이트입니다. XML이 가져다주는 "배치성"까지 어울어진다면 JSPer-Servleter-Beaner + Deployer까지, 꿈이라고 하기엔 이미 되어버렸다는 생각마저 드는군요.
- 블럭 폴딩을 지원하는 에디터들 - jEdit와 SciTE
- 친구 히따꿍(sgwcs)가 만든 Tree자료구조체 구현 클래스~
- 첨부 파일 전송의 현재와 미래
- SRV(Servlet) 2.4와 JSP 1.3
- CLDC 1.1과 MIDP 2.0
- 스트럿츠(Struts) 책 소식
jEdit는 순수 자바 에디터 애플리케이션입니다. SciTE는 Win32와 X용 에디터지요. 따라서 둘 다 무척 다양한 플램폼에서 쓸 수 있다는 공통점이 있지만, 그것보다 더 눈에 띄는 것은,
폴딩 - 즉, 중괄호({})로 묶이는 블럭(클래스, 초기화, 메소드)을 접었다 폈다 할 수 있는 기능입니다. 말로 설명하는 것보다는 받아서 깔아 자바 소스를 열어보는 것이 훨씬 폴딩의 묘미를 이해하는 데 빠릅니다.
사실 클래스를 짜다 보면 이렇게 저렇게 블럭이 많이 생기게 되고(반복문, 조건문등), 그게 나 늘어져 있는 상태에서 소스의 여기 저기를 이동하려다 보면 스크롤 양이 참 많아지죠. 그런데 이 폴딩 기능을 활용하면 잘 안보는 블럭은 접어둘 수가 있어 훨씬 소스의 특정 부분의 접근이 빨라집니다.
jEdit는 J2SE 1.4 RE(Runtime Environment)를 권하는데, 다양한 플러긴으로 휠마우스 지원, 톰켓 연동등의 강력함도 선사합니다. 또한 편리하게 울트라에디트나 에디트 플러스처럼 오른쪽 버튼 바로 열기 기능을 지원하구요. 다만 초기에 뜨는 시간이 좀 걸리죠.
SciTE는 반면 상당히 가벼우면서도 간편함이 돋보입니다. 굳이 JRE을 쓰지 않으시는 분들이라면 딱이 아닐까 싶네요.
친구 히따꿍(sgwcs)가 만든 Tree자료구조체 구현 클래스~
어느 게시판에선가도 본 듯한 기억이 나는데, 왜 자바에는 트리(tree) 자료구조를 구현한 것이 없으냐는 의문에 부응하듯이, kr.pe.sgwcs 패키지에 트리 구조 인터페이스와 임플리멘테이션이 있어 소개합니다. 자바 콜렉션 프레임웍에는 배열(가변), 연결 리스트, 집합(Set), 해시 등은 구현되어 있는데, 묘하게도 트리만은 스윙에서 JTree의 데이터모델로서 TreeModel과 SortedMap을 구현하기 위한 Red-Black(RB) 트리(재밌는 설명 사이트가 있더군요.) 도입이 있을 뿐이죠.
조만간 이 트리 패키지에 형총칭성(Generics)를 적용하여 더욱 편리한 콜렉션 프레임웍으로 선보일 협의에 들어갈 예정입니다. kr.pe.sgwcs 패키지에 많은 관심 바랍니다.
첨부 파일 전송의 현재와 미래
지난 토요일 공개 세미나에서 받은 한 참가하신 분께서 클라이언트(애플릿)이 서버(아마도 서블릿)로 POST multipart/form-data 방식으로 자료를 보내는 방법에 대해 문의해주셨는데요, 마침 거기에 대한 글들을 제가 이미 자바 스터디에 답변으로 써서 여기 링크를 달아보았습니다. 역시 애플릿이 소켓이 아닌 HTTP로 이러한 방식을 취해야하는 이유는, 그만큼 HTTP가 방화벽 친화적(firewall-friendly)이라는 뜻이기도 하겠지요. 최근의 웹서비스도 이런 HTTP를 기반으로 삼고 있다는 것도 이런 사실을 반증합니다.
그런데, 사실 위에 소개한 방식은 무척 까다롭고 구현하기도 힘듭니다. 특히 multipart의 MIME 특성상 첨부파일격의 바이너리 데이터를 전체 네트웍 정보에서 유의미하게 뽑아낸다는 것은 더욱 그렇지요. 그래서 JavaMail도 Java Activation Framework이라는 거창한 API로 이런 데이터를 다루는데요, SOAP에서도 이 API들을 쓰면 편리합니다.
이러한 현실적인 필요에서 XML, 특히 SOAP("솝"이라 발음합니다.)는 무척 유용한데요. 간단히 아파치 SOAP로 구현해볼 수도 있구요, XML 팩에 들어있는 JAXM으로도 가능합니다. 기본적인 아이디어는 클라이언트가 서버에 던지는 SOAP메시지에 첨부파일을 붙여 보내는 식인데요, 제가 현재 번역하고 있는 "자바 웹 서비스(오라일리)"의 3장, 7장에 각각 나와있습니다. 급하신 분은 원서를 보셔도 되겠구요. (이 주제를 가지고 공개 세미나에서 자세히 언급할 생각도 가지고 있습니다. 웹서비스에 대한 공개 세미나는 6월말 책 출간과 더불어 열릴 예정입니다.)
이러한 웹서비스 방식의 장점은 역시 HTTP를 타므로 방화벽 걱정이 없고 XML 메시징이므로 다루는 입장에서도 무척 선명하다는 것입니다. POST multipart와 같은 저수준(low-level) 프로토콜을 직접 구현할 필요도 없어 더욱 편리하죠. 다만 서버가 웹서비스를 지원하도록 구비되어 있어야하는데, 이또한 결코 어려운 일은 아니니 걱정하지 않으셔도 되겠습니다.
생각보다 웹서비스는 우리 가까히 있다는 생각이 들었습니다.
SRV(Servlet) 2.4와 JSP 1.3
현재 JCP에서 논의중인 서블릿 2.4[JSR154]와 JSP 1.3[JSR152]을 잠깐 소개하려 합니다.
올 하반기 출시 예정인 J2EE 1.4[JSR151]에 포함할 예정인 이 핵심 기술들은 웹서비스와의 연동, 더 쉬운 페이지 제작을 모토로 전개되고 있습니다.
오늘은 간단하게 각 기술들의 새로운 모습을 개요적으로 살펴보고, 다음주부터 그 면면을 자세히 살펴보겠습니다.
우선 서블릿 2.4에서는
- 배치 형식의 모듈화 : 현재의 DTD기반 배치 설명서(deployment descriptor, 보통은 web.xml이죠)의 한계를 극복
- 보안 모델 강화 : 로깅, 세션과 인증 정보 연동
- 필더 보완, 요청-응답 관련 이벤트 처리 리스너 개설
- J2SE 1.4의 NIO를 활용한 성능 향상
- JSP로 커스텀 태그 저작 : 그간 커스텀 태그 제작에 자바가 간여하여 스크립트-페이지 개발자에게는 난해하였다는 지적에 대한 응답
- 표현 언어(Expression Language) 지원 : 이미 JSTL(Java Standard Tag Library)에서 지원하고 있지만, 이것을 JSP전체에 적용할 수 있어 JSP안에 자바 표현식(Java expression) 배제
JSP 1.3의 모토는 "스크립트없는(script-less) JSP 작성"입니다. 그것의 첫번째 시도는 이미 JSP 1.1때부터 실험적이라는 평을 받았던 커스텀 태그 개념이었는데, 안타깝게도 너무나 고상한 이론과 더 거룩한 실제 덕분에 MVC모델 구현의 저높은 이상(ideal)로 남아버렸습니다. 그래서 덩달아 불어나는 JSP속의 자바 코드-스크립틀릿(scriptlet, <% ~ %>), 표현식(expression, <%= ~ %>)등-을 지양하기 위해 자바보다 훨씬 직관적이고 쉬운 스크립트 언어로 자바 코드가 해왔던 역할을 대체하고자 하는 시도가 이번에 선보입니다.
현재 이 EL의 스크립트 언어적인 기반으로는 ECMAScript와 XPath가 채택되어 JSP에 적합한 요소들만을 취합할 것으로 알려졌습니다.
점점 분화하는 웹 개발 현장, 과연 그 이동(shift)을 JSP 1.3이 열지, 아니면 이동을 한 후 JSP 1.3을 요구할지 사뭇 기대가 됩니다.
CLDC 1.1과 MIDP 2.0
CLDC 1.1[JSR139]과 MIDP 2.0[JSR118]가 현재 명세 공개된 상태입니다. CLDC는 1.0에서 마이너 업그레이드한 반면, MIDP는 1.0에서 화끈하게 2.0으로 뛰었습니다. 이는 그만큼 MIDP의 API적인 요구가 많았다는 것이겠죠.
CLDC 1.1 진화의 면면을 한마디로 요약하면 "더욱 강력한 CLDC"입니다. 그간 부동 소수점, 레퍼런스 개념등의 결핍, 그리고 Calendar, Date, TimeZone과 같은 핵심 클래스의 J2SE와의 위화감을 해결하여, 비표준적인 부가 지원이 없도록 하였습니다.
- 부동 소수점 지원 : float, double 기본형과 Float, Double 포장 클래스 추가
- 약한 참조(Weak Reference) 지원 : J2SE의 참조 개념을 여기를 참고하세요.
- NoClassDefFoundError 추가 : 너무도 당연한 에러였음에도 참 속을 많이 썩였죠.
MIDP 2.0의 변신은 한마디로 "대규모 성형수술 공사"수준입니다. MIDP가 가장 많이 쓰이는 분야인 "게임"에 대한 현실적인 요구 수용과 더불어 앞으로 각광받으리라 예상하는 "법인대상" 씬 클라이언트(thin client) 수요에 대비한 보안 능력 강화가 가장 눈에 띄입니다.
- 애니메이션 기능 대폭 강화 : 게임을 위해서라고밖에는 볼 수 없는 Sprite클래스는 더이상 모바일 게임을 짜기 위해 이리저리 머리를 굴릴 필요가 없을 정도로 강력한 애니메이션 기능을 제공합니다. Layer기반으로 TiledLayer, LayerManager, 거기에 GameCanvas까지, 편리한 처리와 가속화의 양면을 지원하고 나섰습니다.
- 멀티 미디어 보강 : MIDP 1.0에는 음악을 제어하는 인터페이스가 표준으로 제공되지 않았었습니다. 워낙 미디어 계열이 단말기에 밀착된 영역이어서 구현사별로 부가 프로파일로 처리하라는 방침이었는데, 이것이 결국 MIDP 애플리케이션이식성의 발목을 잡고 말았습니다. 현재도 같은 MIDP 기반이지만 SKT의 미들릿을 LGT에 그대로 돌린다는 것은 사운드를 사용할 경우라면 100%불가능, 약간이라도 손을 봐야하는 상황이죠. 여기에 대해서는 다음주에 Mobile Media API에서 더욱 자세히 소개하겠습니다.
- 보안 기능 : SocketConnection이 기본 표준으로 들어가면서, SSL과 TLS를 지원하기 위한 SecureConnection, 또한 HTTPS를 위한 HttpsConection, 그리고 그와 관련된 Certificate, SecurityInfo등의 인터페이스도 추가되었습니다. 이 또한 각사에서 개별적으루 구현하던 것을 통합한 결과입니다.
MIDP 2.0은 1.0의 미약한 점들을 보강하고자 각 기술사가 재빠르게 나름대로의 부가 프로파일을 개발해오던 것을 이왕이면 표준화하여 차세대 모바일 개발 시장에서 유리한 고지를 점령코자 마련된 것이라고 볼 수 있습니다. 애니메이션쪽만 봐도 이미 제이폰(J-Phone)의 자바 서비스에서 반다이(BANDAI)가 3D쪽을, 세가(SEGA)가 2D쪽을 강화한 별도의 프로파일을 제공했는데, 스프라이트 개념은 세가의 그것에서 온 것이나 다름 없습니다. (3D쪽은 Mobile 3D API라고 해서 따로 진행중입니다.)
SKT, LGT의 경우에는 일본이 HTTP만을 지원하는데 반해, 시작부터 소켓을 지원했고, 미디어 지원도 확실했습니다. 거기에 부동 소수점, 3D, SMS(이것은 현재 Wireless Messaging API로 연구중)까지 선구적으로 지원한 셈이죠.
SKT측의 자바 기술 담당사인 XCE는 이미 SSL구현을 마쳤다고 하는데, 이번 MIDP 2.0에 어떠한 모습을 보여줄 지 기대가 됩니다.
앞으로도 MIDP 2.0을 비롯한 J2ME관련 기술-API의 소개는 계속됩니다.
스트럿츠(Struts) 책 소식
오라일리에서 올 3사분기에 낼 스트럿츠 책의 원고가 더 서버 사이드 닷 컴에서 사전 공개중입니다. 스트럿츠는 MVC모델 구현을 돕는 프레임웍으로 유명한데, 이 분야에 있어서 거의 표준으로 자리잡을 전망입니다.
스트럿츠는 Model-View-Controller 컴포넌트 구현을 위한 편리한 도구를 제공하는데, 특히 View쪽의 커스텀 태그는 현재 연구중인 JavaServer Faces(JSF)의 발안에 지대한 영향을 준 것으로 알려져 있으며, 실제로 스트럿츠의 뷰 커스텀 태그가 상당량 반영되지 않겠냐는 예상도 나오고 있습니다.
Model쪽은 워낙 자바빈즈 구조를 기반하고 있어서 달리 웹 기술에 영향을 줄 것은 없지만, 이쪽은 오히려 JDO(Java Data Object)와 가까와서, DB-대응(mapping)과 관련하여서는 JDO와의 연동도 고려해볼 만합니다.
Controller쪽이 매우 근본적으로 강력한데, 일명 Mediator-Command패턴을 스스로 밑바닥부터 구현할 필요없이 기본적인 구성의 틀을 제공하고 있어 콘트롤러에 대한 개발자의 고민도 사라집니다.
MVC모델의 놀라운 점은 웹애플리케이션을 마치 GUI애플리케이션처럼 컴포넌트-이벤트 핸들링 스타일로 짤 수 있다는 것입니다. 콘트롤러는 뷰와 모델의 중개자(mediator)로서 자료의 변경과 화면의 갱신을 지시합니다.
그런데, 지금까지의 웹 이벤트는 이른바 GET-POST메소드 방식의 요청 송신으로 촉발되는 것이 대부분이었습니다. 즉 사용자의 웹브라우저 조작에 따른 요청이 발생하였을 때 콘트롤러가 그 요청을 분석하여 이런저런 처리를 중재한다는 뜻이죠.
여기서 바로 웹 애플리케이션 모델2(MVC모델)의 콘트롤러(서블릿) 중심 설계(servlet-centric design)이 대두하는 것입니다.
다수의 JSP-하나의 서블릿(중앙 본부-headquarter)-다수의 빈
따라서 JSP의 코딩을 담당하는 JSPer(제이에스피어)는
"어떠한 폼에서 어떠한 정보를 본부에 넘긴다."와라는 인터페이스(interface)만을 가지고 작업을 할 수 있으며,
"본부는 그 정보의 처리후 어떠한 결과를 돌려준다."
빈 코딩(DB쪽을 포함하여)을 담당하는 Beaner(비너)는
"폼에서 받은 정보를 받아 비즈니스 로직을 처리한다."와라는 인터페이스만으로 구현할 수 있는 셈이죠.
"이 때 필요한 DB작업을 수행한다."
MVC모델은 단순히 애플리케이션의 구조적인 관점뿐만 아니라 제작(production) 구조에도 영향을 미치고 있습니다. JSTL와 JSF를 통해 빠르고 쉬운 페이지 작업을 열망하는 JSPer, 재사용 가능하며 역동적인 비즈니스 로직을 유연하게 수용하는 빈 제작을 꿈꾸는 Beaner, 그리고 이런 동상이몽의 사이에서 전체적인 조율을 담당할 Servleter... 모델 2가 나온지 어언 2년이 넘어가는 시점에서 스트럿츠와 같은 프레임웍이 나오며 자바 웹 개발자들의 시선을 모으며 무척 "당연하게" 여기듯이, JSPer-Servleter-Beaner의 삼위일체 삼자분업의 일도 어쩌면 MVC모델의 대중화에 걸린 시간보다 훨씬 빠르게 정착할 지도 모르겠습니다.
그 일례가 바로 스트럿츠와 XML로 구현한 MVC 게시판을 연구, 제작, 그리고 공개 배포까지 하고 있는 자바지기 사이트입니다. XML이 가져다주는 "배치성"까지 어울어진다면 JSPer-Servleter-Beaner + Deployer까지, 꿈이라고 하기엔 이미 되어버렸다는 생각마저 드는군요.
TAG :
이전 글 : Shared Source CLI 컴파일하기
다음 글 : 녹색 나무 파이썬
최신 콘텐츠