서블릿

Savor Success with Java on the Front End  -  2002 / 08 / 08

sss 설계자와 관리자는 애플리케이션의 프론트 엔드를 Swing 기반, HTML 기반, XML 기반 중 어느 것으로 할 것인지를 선택해야 하는 상황에 놓이곤 한다. 이 글에서 Alex Kalinovsky 는 이 세가지 기술에 대해 자신의 경험을 공유하고, 여러분의 Java™ 개발 시 선택하기 위한 기준과 도움될 만한 사항들을 알려줄 것이다. 그리고 여러분은 최소한의 노력으로 Swing 과 HTML 의 격차를 줄이는 혁신적 방식에 대해 배울 것이다.

각 회사의 영업 부서와 마케팅 부서에서 자사의 기술을 더 강조하기 위해 조장하는 과대 광고나 홍보에 신물이 났는가? 자바 기술은 언론에서 긍정적으로 평가받기도 하고 부정적으로 평가받기도 했다. 언론은 이 기술에 대해 상반되는 정보를 제공하여 사람들을 혼란스럽게 만들었다. 이 글에서는 자바를 현실적으로 평가하고 "자바를 사용할 때 front end와 관련해서 우리에게는 어떤 옵션이 있는가?" 란 질문에 답을 제공해 볼 생각이다.

서버단 개발에서 자바를 사용할 때 기존의 다른 기술에 비해 자바가 훨씬 많은 이점을 제공하기 때문에 이 부분에 있어서는 확실한 입지를 굳히고 있긴 하다. 그러나, 실질적으로 모든 애플리케이션이 유저 인터페이스와 front-end 프리젠테이션을 어떤 형태로든 가진다. 우리 대부분은 클라이언트단에서의 자바 사용을 언론에서 맹공격하고 있는 것에 대해 익숙하다. (remember how many times we've heard about "nails in the coffin of Java"?) 언론에서는 HTML 기반 front end 를 제외한 그 밖의 다른 기술을 사용하는 것이 제 무덤을 파는 것과 같다고 말하고 있다.

그러나 사실은 기존의 HTML 클라이언트를 사용하는 것 외에도 다른 옵션들이 있다. 필자는 Java 기반 애플리케이션에서 유저 인터페이스를 개발하기 위해 사용할 수 있는 세 가지 주요 솔루션에 대해 설명할 것이다. 우선 JavaServer Pages™ 과 서블릿에서 HTML 을 사용하는 것에 대한 장단점을 살펴볼 것이다. 다음으로, 약간 놀랍게 들릴 수도 있겠지만, 초기 약속 중 하나인 "GUI 애플릿을 통한 인터렉티브 Web"이 가능하다는 점을 증명할 것이다. 끝으로, XML과 이 언어와 함께 출시된 그 밖의 고급 기술들에 대해 설명할 것이다. 이제 여러분이 정말로 알고자 하는 문제로 넘어가자 - 기술적 사실들.

HTML Client with JSP/Servlets

독자들 대부분이 지금쯤이면 몇몇 종류의 서블릿과 JSP 를 개발해 보았을 것이며, HTML 기반 유저 인터페이스의 장단점을 실제로 느껴보았을 것이다. HTML 을 선택해야 하는 가장 중요한 이유중의 하나는 HTML 이 어떠한 플랫폼에서도 다 실행될 수 있다는 점이다. (모든 브라우저가 Java 를 지원한다고 말할 수 있다면 얼마나 좋겠는가?) 기본 HTML 은 손쉽게 표준화되고 너무 복잡해지지 않으면서도 긍정적인 효과를 얻을 수 있다.

또한 HTTP/HTTPS 프로토콜의 단순함을 고려하면 다양한 네트워크 설정이나 방화벽에서 프로그램 했을 때 어떤 일이 일어날 지를 예측할 수 있는 장점이 있다. 그러나 이 지구상의 모든 것이 그러하듯이 이런 장점이 공짜로 얻어지는 것은 아니다. HTML 의 단점은 사용자와의 상호작용이 없으며, 사용자의 리퀘스트에 대한 리스펀스를 보낼 때 마다 서버를 거쳐야 한다는 것이다.

물론 JavaScript도 존재한다. 그러나 여러분이 프로그래머로써 일하면서 강제적인 필드를 enforce 하고 간단한 프롬프트를 생성하며, 또한 이 둘을 모든 브라우저에서 동일한 방식으로 실행되게 하는 것 보다 더 어려운 작업을 해 본 경험이 있는가? 단순함이 늘 좋은 것은 아니다. 간단히 말해서 JavaScript 는 꼬이지 않은 인터렉티브 로직을 static 한HTML 에 추가하기에 적절한 언어이지만 사용자가 놀랄정도로 잘 구성된 고차원의 유저 인터페이스를 만들 능력은 없다.

여러분 스스로가 디지털화되어 사이버공간에서 살고 있지 않는 한, 혹은 집에 T-1 전용선이 설치되어 있지 않는 한, 웹페이지가 로드되기를 기다리거나 서버가 쓸데없는 페이지를 거치게 만드는 답답함을 느껴보았을 것이다. thin 클라이언트가 다수의 인터렉티브 하지 않은 유저 인터페이스의 프리젠테이션을 멋지게 소화할 수 있는 방안을 제시하기 하지만, 기존의 fat 클라이언트가 똑똑함(intelligence)이란 측면에서는 thin 클라이언트를 능가한다. 예를 들어 온라인 브로커는 HTML 클라이언트보다 훨씬 잘 실행되는 애플리케이션 클라이언트를 active trader 에게 제공한다. Netscape™ Communicator 와 MS Outlook 등의 이메일 클라이언트는 웹 기반 이메일 포털에 비해 훨씬 더 사용자 친화적이다.

HTML 프론트 엔드를 개발하기 위해 Java 를 사용하는 것은 현명한 일이다. 왜냐하면 HTML 이 플랫폼에 구애 받지 않으면서 컨텐트를 전달하고 보여줄 수 있듯이 Java 서블릿과 JSP를 사용하면 거의 모든 환경의 운영 체제에서 실행될 수 있는 서버 단 로직을 개발할 수 있다. 풍부한 Java API와 웹 서버 및 애플리케이션 서버 벤더들이 Java 를 지원하고 있다는 점을 고려할 때 Java 는 확장성 있는 (scalable) 웹 싸이트를 구축하기 위한 최상의 선택이다.

요약하자면, 서브릿을 사용하는 HTML 프론트 엔트는 static 컨텐트를 개발하기 위한 아주 좋은 방법이다 (그리고 당부하건데, 페이지 디자인은 제발 전문 디자이너에 맡기도록 하자). 그러나 이 thin 클라이언트는 유저의 액션에 재빨리 리스펀스를 보내야 한다거나 데이터를 빠르게 조작하는 복잡한 로직을 사용할 때는 그리 좋은 성능을 제공하지 못한다.

Swing GUI Client

여러분 중 Java 애플릿을 여러분의 클라이언트로 사용할 자신이 있는 사람이 몇몇이나 되는가? 물론 HTML 기반 유저 인터페이스를 사용하는 것이 확실히 안전하긴 하지만, 그렇다고 이것이 최상의 선택인가?

AT&T 의 자회사인 Telecorp PCS 사는 자사의 점포와 키오스크에서 휴대폰을 구매하고자 하는 고객들이 제공한 정보를 저장하고 이들의 신용 정보를 조회하며, 그 자리에서 휴대폰을 개통해 줄 수 있는 애플리케이션을 개발해야 했다. 이 클라이언트 애플리케이션은 유저 인풋이 정확한지를 검증하는 작업 외에도 분류, 필터링 및 그 밖의 표준 테이블 기능을 가진 인터렉티브 보고서를 만들어 낼 수 있어야 했다. 거기다 고객에게 휴대전화가 개통되었다는 사실을 인스턴트 메시지로 통보하고 이를 디스플레이 해야 했다.

이를 HTML 로 구현할 수 있을까? 가능하긴 하지만, 구현하기가 까다롭고 늘 네트워크를 사용해야 하기 때문에 개발 속도가 느려진다. 그래서 개발 팀은 자바를 사용하여 자바가 원래 의도했던 것 - 인터렉티브 애플릿 - 을 구현해 보기로 했다. 결과는 대성공이었다. 이 애플릿은 Swing 을 사용하여 개발되었고 Java Plugin을 사용해 배포되었다. Swing UI 클래스를 사용하여 유효하지 않은 인풋이 들어오면 그 자리에서 이를 점검하고 사용자가 계속 진행할 수 있거나 진행할 수 없을 때 활성화되고 비활성화 되는 버튼과, 칼럼의 헤더를 클릭하기만 하면 자동으로 분류되는 표(테이블)를 손쉽게 만들 수 있었다. 그리고 인스턴트 메시지는 다이얼로그 창을 생성하는 RMI callback 으로 처리했다. 물론 사용자들은 대단히 만족스러워 했다.

여러분 대부분이 Java 를 처음 배울 당시 애플릿을 사용해 본 경험이 있을 것이다. 우리는 브라우저마다 나타나는 차이와 애플릿 다운로드 시간, 성능 그리고 그 밖의 모든 문제들을 해결하느라 많은 시간과 노력을 허비했었다. 클라이언트 단 자바에 대한 비판은 거의대부분 객관적인 의견들이다. 그렇지만, 확실히 많은 것이 변화했다. 썬 마이크로 시스템즈 사는 자바의 코드와, 더불어 우리의 삶을 향상시키기 위해 많은 노력을 기울였다. 이제부터 Swing UI 를 사용하는 것이 왜 고려해 볼만한 옵션인지 설명하겠다.

Swing and its Deployment Models

Swing 의 내부 아키텍쳐와 Swing 클래스 및 인터페이스를 설계하고 그 디자인 패턴을 구현하는 데 들인 공을 필자가 굳이 칭찬할 필요도 없다. Swing 은 아마도 필자가 본 것 중 가장 깨끗한 (cleanest) 윈도우잉 시스템의 구현이다. Swing 은 컨테이너간, 컴퍼넌트간, 그리고 UI 요소들 간의 관계를 잘 정의된 놓았다. Swing 의 아키텍쳐는 데이터를 프리젠테이션과 그 데이터의 조작에서 분리하는 방식인 Model-View-Controller (MVC) 디자인 패턴에 기반을 두고 설계되었다.

대부분의 Swing 모델은 다양한 UI 요소들에 의해 공유된다; 가령, JTable 은 JList 와 JTree 가 사용하는 것과 동일한 selection 모델을 사용한다. 이런 점 때문에 Swing 은 배우고 사용하기가 쉽다. Command, Observable, Listener 등의 패턴은 유연성과 바람직한 객체 지향 디자인을 제공한다. 아마도 Swing의 유일한 구조상의 단점이라면 모든 이벤트가 하나의 EventDispatch 스레드에 전달되기 때문에 전체 GUI 클라이언트가 단일 스레드로 실행되게 만든다는 점일 것이다. 그렇지만 EventDispatchThread 대신에 다른 스레드를 사용해 유저 명령에 리스펀드하게 만들면 이런 단점도 쉽게 극복할 수 있다.

모든 출시된 JDK 는 Java 와 Swing 을 향상시킨다. JDK 1.3에서 Swing 과 관련해서 의 가장 중요한 개선점은 성능과 메모리 점유 및 인풋 유효성 점검 프레임워크 (input validity framework) 이다. 성능과 메모리의 향상은 놀라울 정도이다. 필자의 회사에서 사용하는 클라이언트를 JDK 1.2.2 에서 1.3으로 변경하고 나서 메모리의 사용이 적어도 30% 이상 감소했다; 몇몇 애플리케이션은 훨씬 더 많은 메모리 절감 효과를 볼 수 있었다. Swing 의 내부 초기화가 최적화되기 때문에 우리가 사용하는 클라이언트가 훨씬 더 빠르게 실행되고 반응할 수 있다. 간략하게 말하자면, anonymous 인터페이스 구현에서 생성한 너무 많은 수의 클래스를 자동으로 로딩하는 것이 속도에 지장을 주는 가장 큰 요소였다. 이에 대한 해결책은 reflection 메커니즘에 의존하는 한 클래스가 적절한 구현 프록시를 생성하도록 만드는 것이었다. 또 한가지 주목할 만한 변화는 GUI drawing 과 클라이언트 단 실행에 최적화되어 있는 HotSpot Client VM이 디폴트 VM 으로 사용된다는 것이다. 명령 프롬프트에서 java -version 을 실행하면 디폴트 JVM 에 대한 정보를 얻을 수 있다.

input validity framework 를 사용하면 mandatory 필드 또는 엔트리 validation 을 손쉽게 프로그램할 수 있다. 과거에는 사용자가 다음 필드로 넘어가기 전에 제대로 값을 입력했는지 확인하기 위해 해당 컴퍼넌트에 listener 를 달아야 했고, and every time that component lost focus you would validate and possibly restore the focus. 처리하기가 번거롭고 따분한 일이었다. 새로이 InputVerifier 클래스가 추가된 덕분으로 이제는 InputVerifier 서브클래스의 인스턴스를 생성하고 validate 가 필요한 JComponent 에 이 인스턴스를 설정함으로써 똑같은 효과를 얻을 수 있다. 이 컴퍼넌트는 focus 가 이동하도록 허가하기 전에 verify() 메서드를 자동으로 호출할 것이다.

Swing은 초기부터 배포시의 속도와 호환 불가능성의 문제를 안고 있었다. 그러나 그간의 현격한 발전 덕분에 이런 문제를 충분히 해결했고 Java 클라이언트는 효과적인 방법으로 다시금 부상했다. CPU 속도가 지난 2~3년간 거의 두 배 이상 증가했다. JDK 1.3 에서 Swing 애플리케이션은 훨씬 더 빨리 실행되고 더 작은 양의 메모리를 소모한다. 그래도 아직 남아 있는 문제가 있는데 이는 바로 배포이다. 배포에 관해서는 세 가지 옵션이 있다.

Java Plugin

<HTML>
<HEAD>
<TITLE>My traditional applet page</TITLE>
</HEAD>
<BODY>
<APPLET CODE=HelloWorld.class ARCHIVE=
HelloWorld.jar>
Sorry, looks like I bumped into another browser that 
doesn't support Java applets
</APPLET>
</BODY>

이 방식은 HelloWorld 클래스를 로드하고 실행하기 위해 브라우저 JVM 에 의존해야 한다는 문제점이 있다. 시중에 다양한 브라우저가 출시되어 있고 이들이 각기 다른 방식으로 Java 를 구현하기 때문에 애플릿 배포가 매우 까다롭다. 그렇다면 쉬운 해결책은 뭐가 있을까? 우선, 반드시 여러분이 테스트를 해 본 JVM 에서 실행해야 한다. 브라우저가 Java 를 실행하도록 요구하는 대신, 애플릿을 실행할 JVM 을 설치하고 실행하도록 요구해야 한다. Internet Explorer (IE) 에서는 <OBJECT> 태그를 사용하면 되고 그 밖의 브라우저에서는 각기 다양한 태그를 사용하는데, Netscape Navigator의 경우에는 <EMBED> 태그를 사용하면 된다. 이제 수정된 페이지를 살펴보자 :

<HTML>
<HEAD>
<TITLE>My new applet page</TITLE>
</HEAD>
<BODY>
<OBJECT classid="clsid:8AD9C840-044E-11D1-
B3E9-00805F499D93" 
 width=100% height=100
 codebase=
"./j2re-1_3_0_02-win.exe#Version=1,3,0,2">
   <param name=
"code" value="HelloWorld.class">
   <param name=
"archive" value="HelloWorld.jar">
   <param name=
"cache_archive" value="HelloWorld.jar">
   <param name=
"cache_option" value="Plugin">
</OBJECT>
</BODY>

위에 나온 페이지는 IE 에게 주어진 클래스 ID 를 가진 객체가 이미 설치되어 있는지의 여부를 확인하도록 지시한다. 설치되어 있지 않다면 주어진 URL 로부터 JVM 을 다운로드 하고 이를 설치한다 (이 JVM은 IE 의 플러그인으로 등록된다). 다음으로 이 플러그인을 실행하면, 이 플러그인이 애플릿을 로드하고 디스플레이한다. 실제로 어떻게 되는지는 http://192.9.48.9/products/plugin/1.3/d ··· le1.html의 예제를 통해 확인할 수 있을 것이다. 또한 Java 플러그인에 대해 더 자세한 정보는 Sun의 웹싸이트에서 찾아볼 수 있다.

플러그인은 모든 플랫폼에서 모든 브라우저를 지원해야 하는 부담을 덜어준다는 매력이 있다. 거기다 보장된 실행 환경을 얻을 수도 있다. 플러그인은 한번만 설치하면 되고 모든 애플릿을 cache 하기 때문에 재실행 시에 많은 자원을 소모하지 않는다. 이 방식의 가장 큰 담점은 사용자들이 애플릿을 실행하기 전에 5MB 크기의 플러그인을 다운받아야 한다는 것이다. 회선이 느린 사용자들에게는 부담스러울 수도 있다. 여러분이 만든 애플릿이 5KB 크기의 웹페이지 상에 조그맣게 나타나는 시계인데, 그것을 실행하기 위해 5MB 의 플러그인을 다운받는 것이 비합리적으로 느껴질 수도 있기 때문이다.

Java Web Start

Java 애플리케이션을 개발하는 방법 중 최근 부각되는 또 다른 방법으로 썬 사의 Java Web Start 가 있다. 본질적으로 Java Plugin 과 유사하나 첫단계에서 큰 차이점을 보인다. Java WEb Start 는 각 데스크탑 장비에 손수 인스톨해야 할 것을 요구하기 때문에 플러그인이 자동으로 설치되는 것에 비하면 좀 귀찮을 수도 있다. Java Web Start 는 JRE 를 제공하며, 설정하기가 비교적 쉽다. 일단 설정되고 나면 Web Start에 의존하는 애플리케이션이 다운로드되고 설치될 수 있다. 플러그인과 마찬가지로, the application is jarred and published on the Web. HTML페이지는 사용자가 다운로드된 애플리케이션이 아직 사용가능하지 않으면, 이를 사용자 장비에서 launch 할 수 있게 한다. 다운로드된 애플리케이션은 cache 되고 Java Web Start Application Manager를 통해 독립적으로 launch 된다. 이 Manager는 Windows 3.1에서 본 프로그램 관리자와 매우 유사한 모습을 지닌다. 이 기술에 대한 더 자세한 정보는 Resources. 를 참고하기 바란다.

필자의 경험에 의하면 Java Plugin 이 관리자나 사용자를 덜 귀찮게 하기 때문에 Java Web Start 에 비해 설정하기가 더 간단하고 더 사용자 친화적이다. 몇몇 회사에서는 이와 비슷한 일을 하는 (어떤 경우에는 Java Web Start 보다 뛰어난 성능을 제공하는) 배포 툴을 자체적으로 개발하고 있다. 가령, Sitraka의 DeployDirector 는 Java Web Start의 성능을 향상시켜 설치를 보다 간편화했다.

요약하자면 Java Plugin 과 Java Web Start를 사용하면 Swing 애플릿의 배포가 예전보다 훨씬 더 간편하고 안전하게 진행될 수 있지만 JavaScript 가 포함된 HTML 을 클릭하는 것 보다는 더 많이 관여한다. 어떤 사용자들은 컴퓨터에 JVM 을 설피하는데 필요한 과정을 거치는 것이 두려워서 Swing이 제공하는 이점들을 경험하지 못할 수도 있다. 그렇지만 여러분이 사용자에게 유연성을 제공하는 동적 GUI 인터페이스를 만들어야 한다면 Swing 애플릿을사용하는 것 이상의 좋은 방법은 없다.

또한, 전체 배포가 Java 로 되어 있다면 HTML 리퀘스트 데이터와 여러분의 내부 스트럭쳐 관에 mapping이 존재하지 않는다. RMI 는 네이티브 데이터를 옮길 수 있는 빠른 속도의 round-trip 네트워크 call 을 제공한다. 또한 클라이언트에 callback 을 구현하여 서버의 리퀘스트가 있을 때 사용자에게 이를 통보하거나(prompt?) 스크린을 업데이트할 수 있다.

Deploying Swing as Pure HTML

HTML 프론트 엔드와 Swing 클라이언트가 각기 장단점을 가지고 있지만 이상적인 솔루션을 이 둘 모두를 지원하는 것일 것이다. 그렇지만 이 기술이 본질적으로 너무 다르기 때문에 일반적으로 이 둘 중 오직 하나만이 완성된 애플리케이션에서 구현될 수 있다. 대다수의 사용자가 Swing에 기반을 둔 빠른 인터렉티브 클라이언트를 선호할 수도 있겠지만 클라이언트의 장비에 JRE를 설치하는 것이 항상 옵션이 될 수는 없다. 때로는 보안 및 방화벽에서 RMI 를 네트워크 상으로 실행하는 것을 막을 수도 있다. 이런 경우에는 어떤 시스템에서도 실행될 수 있는 인터렉티브 소프트웨어가 필요하다. 비록 의존할 만한 클라이언트 소프트웨어가 웹 브라우저 밖에 없더라도 말이다. CreamTec 의 WebCream - 세번째 배포 옵션 - 은 Swing과 HTML 간의 다리 역할을 한다.

WebCream 은 Java 툴로써 GUI 기반 Java 애플리케이션 및 애플릿에 자동화된 Web-enabling을 제공한다. WebCream 은 AWT와 Swing을 사용하는 GUI front end를 구현하는 동시에 그 애플리케이션으로의 HTML 액세스를 자동으로 얻을 수 있게 해 준다. 어떤 면에서 WebCream 은 Java 플레임과 다이얼로그를 그 즉시 HTML로 변환하는 동적 Java-to-HTML 변환기라고 볼 수도 있다. 다음으로 WebCream 은 애프리케이션의 본래 로직을 유지하기 위해 Webpage 액션을 GUI 이벤트로 emulate 한다. WebCream은 기존의 형식과 비즈니스 로직에 어떠헌 수정도 필요로 하지 않으며 여러분이 새로운 API 를 배워야 할 필요가 전혀 없다. WebCream은 기존의 애플리케이션과 애플릿을 publish할 목적으로 설계되었다; 즉, 여러분이 사용하는 웹 서버와 해당 애플리케이션을 설명하는 프로퍼티 파일을 설정하기만 하면 된다. 나머지는 WebCream이 다 처리한다. 스탠다드 에디션이 모든 기능을 제공하며, 무료로 다운로드 받을 수 있다. WebCream은 클라이언트 장비에 설치할 필요가 없다; 사실 Java 를 지원하기 위한 브라우저 조차도 필요없다. 왜냐하면 브라우저에게는 HTML 밖에 보이지 않기 때문이다.

WebCream 기능은 꽤 독특하다 - 필자가 아는 바에 의하면 아무도 WebCream과 같은 솔루션을 제공하지 않는다. 그렇지만 몇 가지 제품들이 다른 방식을 사용해서 Web 용으로 개발되지 않은 Web-enabling 애플리케이션들에 WebCream 유사한 기능을 제공하기는 한다. Windows 2000 에는 Terminal Server 서비스가 있는데, 이 서비스는 사용자가 마치 로컬에서 로그인 한 것처럼 원격으로 서버에 액세스하도록 해 준다. Citrix Systems' MetaFrame과 마찬가지로 Terminal Server는 원격 터미널에 비디오 스트림을 전송하고 서버에서 실행중인 애플리케이션들에 사용자 액션을 emulate 한다. 상대적으로 빠른 네트워크 상에서 매우 잘 실행되지만 네트워크의 속도가 느리다면 좀 까다로워질 수도 있다. 또한 네이티브 drawing 과 scrolling 루틴을 사용하지 않기 때문에 Java 애플리케이션에서 문제를 야기하기도 한다. 그리고 Terminal Server 는 각 사용자에게 개별 복사본을 제공하는 형태이기 때문에 확장성에서 떨어진다.(Terminal Server is also not very scalable because each user is essentially given an individual copy of the application). WebCream에서 제공하는 애플리케이션은 로컬 장비에서 실행되는 애플리케이션과 형식상 다르지만 사용자가 어떤 페이지를 submit할 때만 서버에 액세스 하기 때문에 훨씬 더 나은 성능을 제공한다. WebCream-enabled 애플리케이션을 사용하는 모든 사용자들은 JVM을 공유할 수 있고 이는 자원의 소비를 크게 줄일 수 있다.

WebCream이 어떻게 실행되는지 보여주기 위해 아래에 나온 도표들은 WebCream이 사용되었을 때 샘픔 GUI 애플리케이션이 HTML 내에서 어떤 모습을 보이는 지를 제시하고 있다. 왼쪽 도표는 실행중인 GUI 애？리케이션 (소스) 를 보여주고, 오른쪽 도표는 WebCream이 똑 같은 애플리케이션을 관리하는 모습을 보여준다. 여기서 각 윈도우는 브라우저 상의 페이지로 나타난다.

도표 1. 샘플 GUI 애플리케이션	도표 2. WebCream과 함께 사용된 샘플 GUI

이 Swing-HTML bridge 가 모든 클라이언트에게 다 적용되지 않을 수도 있지만, WebCream은 HTML을 통한 액세스를 Swing 기반 프론트 엔드에 제공함으로써 그 가치를 높여준다. 일반적으로 애플리케이션 중 95퍼센트 정도가 HTML로 아무 문제없이 변환되고, 나머지 5퍼센트에 대해서는 데이터가 보여지는 방식이나 처리되는 방식을 수정해야 할 수도 있다. WebCream에 대한 더 자세한 정보는 Resources 를 참고하기 바란다.

Emerging Choice : XML/XSLT-Based Client

여러분이 XML에 대한 기초 지식을 가지고 있다는 가정 하에 XML 애플리케이션의 프론트 엔드 개발 대해서 집중적으로 설명할 것이다. 유저 인터페이스 개발시 XML 관련해서 가장 큰 차이점은 컨텐트를 프리젠테이션으로부터 완전히 분리한다는 것이다. 더 간단히 말하며면 데이터를 XML 문서의 형태로 보관되며 그 데이터가 어떻게 사용될지 그리고 어떻게 디스플레이 될 지에 대해서는 그 어떤 가정도 하지 않는다는 것이다. 각 프리젠테이션 타입 - HTML, WML, XHTML 및 기타 - 은 "스타일쉬트" (XSLT) 를 적용하므로써 가능해 지는데, XSLT 는 데이터가 어떤 식으로 포맷되고 페이지 상에서 어떤 식으로 레이 아웃되는지를 결정한다. 이 방식은 레이어를 서로 독립적으로 유지하여 각 레이어가 맡은 임무를 수행하도록 하게 해 주는 이점이 있다.

XML 이 데이터를 publish하고 서로 다른 프리젠테이션 모델을 생성하는 깔끔한 모델을 여러분에게 제공하기는 하지만 그렇다고 해서 XML 이 만병통치약은 아니다. XML은 디자이너와 아티스트가 프리젠테이션을 처리하는 동안 개발자가 데이터에만 신경을 쓸 수 있도록 해 준면에서는 극찬을 받을 만 하다. 애플리케이션은 메모리에 저장되거나 디스크에 저장되는 XML 데이터 파일을 생성한다. 가령 HTML 과 같은 특정 타입의 프리젠테이션을 제공하기 위해서 적절한 XSLT 스타일쉬트를 사용해 컨텐트를 변형(transform)한다. 스타일쉬트는 XML문서에 적용되어 HTML 문서를 만들어 낸다. 스타일쉬트는 문서로부터 어떤 데이터가 나와서 페이지상에서 어디에 디스플레이 되는 지를 결정한는 템플릿과 유사하다. 스타일쉬트와 템플릿 둘 다 데이터를 변형하고 조건 문을 실행하며 데이터를 manipulate하기 위해 루프를 실행하고 결정을 내린다. 처리하기가 매우 복잡해 질 수도 있다.

만약 동일한 애플리케이션에 휴대폰으로부터의 액세스를 제공해야 할 경우에 여러분은 단지 새로운 WML 스타일쉬트만 만들면 되는 장점이 있다. 이론상으로는 애플리케이션의 그 밖의 다른 부분이 수정될 필요가 없기 때문에 서버단 프로그래밍이 매우 효율적으로 진행될 수 있다. XML을 사용하는 프론트 엔드를 구현하는 것은 branding, personalization 및 customization 등의 작업을 매우 간편하게 만든다. 왜냐하면 디스플레이될 데이터와 이를 처리하는 코드가 수정될 필요가 없기 때문이다. 개발팀의 구성원이 독립적으로 각자 맡은 일에 매달리면 되기 때문에 개발의 속도를 향상시킨다.

그러나 필자는 몇 가지 문제점을 경험한 바 있으며, 이 때문에 XML 기반 클라이언트의 새 버전이 출시되었지만 이를 사용하지 않게 되었다. 두 가지 간과할 수 없는 단점으로는 XML 생성과 스타일쉬트 개발을 돕기 위한 툴이 부족하다는 것과 프로세싱 스피드가 느리다는 것이다. 첫번째 단점은 특히 DreamWeaver 와 FrontPage 등의 visual HTML 툴을 사용하여 HTML 페이지를 디자인하는데 익숙한 이들에게는 큰 문제가 된다. 개인적으로 필자는 아직도 때때로 DreamWeaver로 생성된 코드를 browse through하고 수정하길 좋아한다. (FrontPage는 잘 사용하지 않는다). 그렇지만 필자는 HTML을 텍스트 편집기로 처음부터 코딩하는 것에는 별반 재미를 느낄 수 없다; 어쨌든 지금은 21세기가 아닌가. 이제 간단한 XML 문서를 HTML로 변형하기 위해 사용되는 매우 간단한 XSLT 스타일쉬트를 보여주겠다 :

<xml version="1.0">
<xsl:stylesheet version="1.0" xmlns:xsl=
"http://www.w3.org/1999/XSL/Transform">

<xsl:template match="page">
<html>

<head>
<title><xsl:value-of select=
"title"/></title>
</head>

<body>
<xsl:apply-templates/>
</body>
</html>
</xsl:template>

<xsl:template match="title">
<h1><xsl
:apply-templates/></h1>
</xsl:template>

</xsl:stylesheet>

제대로 된 XSLT 스타일쉬트를 사용했다면 위의 코드는 아래와 같은 HTML 페이지를 생성할 것이다 :

<html>
<head>
<title>My first page</title>
</head>

<body>
  <h1>Hello, world</h1>
</body>
</html>

여러분도 볼 수 있듯이 이 코드는 그다지 정교하지 않으며, 흔히 볼 수 있는 HTML 페이지와는 매우 다른 모습을 보여준다. 안타깝게도 이를 수정하기 위해서는 직접 손으로 편집하고 HTML을 생성하는 툴에서 이를 실행한 다음에 그 문서를 브라우저에서 열어야 한다. 폰트 크기를 수정하려고 하는 경우에 이 모든 과정을 다 거치는 것은 너무 낭비가 크다.

두번째문제는 모든 단계를 런타임에 수행하는 데 시간이 많이 걸린다는 것이다. XML 외의 다른 저장방식 (storage) 을 사용한다면 여러분은 우선 XML 문서를 생성하는 것에서부터 시작할 것이다. 그러면 적절한 스타일쉬트가 적용되어 여러분이 실제 결과물인 HTML 페이지를 생성하기 전에 필요한 모든 변형을 처리할 것이다. 이를 서블릿이나 JSP 내의 메모리 버퍼에 최적화된 방식으로 저장하는 것과 비교해 보면 필자가 무슨 말을 하고자 하는지를 금방 알 수 있을 것이다. 속도와 단순성은 오늘날의 기술의 관점에서 XML 기반 프론트 엔드가 제공할 수 있는 장점이 되지 못한다.

요약하자면 다양한 레이아웃과 form을 사용하는 프리젠테이션을 동적으로 생성하고자 할 때는 XML을 사용하라. 프리테이션 포맷이 자주 변경되거나 또는 유연성을 제공해야 한다면 프리젠테이션 디자이너가 새로운 스타일쉬트를 만들도록 하는 것이 더 쉬울 수 있다; 디자이너는 오직 XML 와 XSLT에 대해서만 알고 있으면 된다는 사실을 기억하자.

여러분의 데이터가 네이티브 Java 타입과 객체, 또는 관계형 데이터베이스의 형태로 오는 것이 아니라 XML의 형태로 오는 경우에도 XML 기반 UI를 잘 활용할 수 있다. XML은 향후의 Web 에서 확실한 자리매김을 할 수 있는 가능성이 큰 신규 기술이다. 그러나 오늘날 프리젠테이션을 위해서는 JSP를 사용하는 HTML을 개발하는 것이 훨씬 간편하다. 특히 여러분이 사용할 수 있는 프론트 엔드가 HTML 밖에 없을 경우에는 더욱 그러하다. JavaBeans 와 JSP 용 태그 라이브러리 등의 잘 알려진 디자인 패턴을 사용하면 컨텐트와 프리젠테이션을 XML/XSLT가 하는 것과 거의 동일한 수준으로 분리해 낼 수 있다. 그리고 훨씬 더 빨리 실행될 수 있다. XML/XSLT 편집을 자동으로 처리하는 기술이 출시되면서 이 기술도 사용하기에 훨씬 더 간편해 질 것이다.

Conclusion

프론트 엔드 기술 각각은 Java 애플리케이션의 인터페이스를 개발할 시에 장단점을 가지고 있다. 이 기술 중 어떤 것도 모든 변에서 다른 기술을 능가하지는 않는다. 각각의 애플리케이션을 개발할 때마다 이 기술을 평가하고 요구사항과 사용자의 기대치를 분석해야 할 것이다. 아래에 일반적으로 사용할 수 있는 규칙을 제시해 놓았다 :

HTML/JSP 를 사용하라 :

- 그래픽과 예술적인 내용이 많이 들어간 상대적으로 정적인 컨텐트일 때 .

- 인터페이스가 서로 다른 소프트웨어를 실행하는 모든 유저 타입을 지원해야 할 때

- 사용자의 네트워크 속도가 느릴 때

- 그다지 정교하지 않은 애플리케이션을 빠르게 개발해야 할 때

Swing을 사용하라 :

- built-in, 인터페이스 관련 로직을 가진 매우 인터렉티브한 GUI 일 때

- 네트워크 체증을 줄이고 가능할 때 즉각적인 리스펀스를 제공하고자 할 때

- 사용자가 인터페이스의 품질과 기능에 대한 기대치가 높을 때

- UI의 기능이 보여지는 아름다움(aesthetics) 보다 더 중요할 때

XML/XSLT를 사용하라 :

- 프리젠테이션에서 여러가지 다양한 형태의 자주 변경되는 form을 지원해야 할 때

- 데이터가 XML 내에서 네이티브하게 저장되고 조회될 때 (obtained)

- branding과 정교한 personalization을 지원해야 할 때

- 무선 액세스 등, 다른 방식의 UI 를 제공하려는 계획이 있다면

About the Author

Alex Kalinovsky는 9년 이상 IT 산업에 종사하고 있으며 Windows 상의 C 와 C++ 에서부터 Unix 상의 Java에 이르기 까지 다양한 개발 경험을 보유하고 있다. 1997년부터는 Java로만 작업했으며 자바의 보급에 일익을 담당하였고 이 분야의 전문가 중 한 사람이다. EJB, CORBA, Servlets/JSP, XML. Swing 및 그 밖의 기술을 포함하는 엔터프라이즈 수준의 다양한 프로젝트에서 architect이자 기술부분 리더로 참여했다. 엔터프라이즈 Java 기술에 대해 15개의 다른 수업을 진행했으며 많은 개발 팀에서 지도자로써 역할을 담당했다. Information Week 와 Washington Post 지 등에 글을 기고해 왔다.

Resources

- Java Plugin 에 대한 정보는 : http://java.sun.com/products/plugin

- Java Web Start Application Manager에 대한 정보는 : http://java.sun.com/products/javawebsta ··· ure.html

- WebCream과 그 기능에 대한 자세한 정보는 : http://www.creamtec.com/webcream

- Citrix Systems의 MetaFrame에 대한 정보는 : http://www.citrix.com/

JavaWorld에 최근 개재된 기사들도 흥미로울 것이다 :

- "The Magic of Merlin": Find out how the new JDK 1.4 -- code-named Merlin -- levitates its functionality, Vinay Aggarwal (March 16, 2001)

- "Jato: The New Kid on the Open Source Block, Part 1": Discover a new library for converting between Java and XML, Andy Krumel (March 16, 2001)

- "Jato: The New Kid on the Open Source Block, Part 2": Look in-depth at Java-to-XML translation, Andy Krumel (April 13, 2001)

- "Java Tip 109: Display Images Using JEditorPane": Modify the JEditorPane component to display images without a document base, Rob Kenworthy (March 16, 2001)

- "Dodge the Traps Hiding in the URLConnection Class": Alleviate snags caused by the URLConnection class design, Michael C. Daconta (March 23, 2001)

- JavaWorld를 주제별로 보려면 :

http://www.javaworld.com/javaworld/topi ··· dex.html

- ITworld.com의 자바 포럼에 의견을 개진하려면 :

http://www.itworld.com/jump/jw-0420-swi ··· .ee6b802

- JavaWorld This Week 및 그 밖의 무료 Java 뉴스레터를 구독하려면 :

http://reg.itworld.com/cgi-bin/subcontent12.cgi