Posted by 김덕태 on March 21, 1997 at 15:35:32:
누군가 자바의 장점에 대한 반론을 mailing list에
오렸기에 이에 대한 반론을 이곳에도 올립니다.
모든 것을 무조건 자바로 해결하기보다는
어떤 응용 영역이 자바에 적당한 것인가에 대해
생각해 볼 좋은 기회라고 생각됩니다.
------------------------------------
> cgi는 정적이고 java는 동적이라는생각에는 좀 문제가 있지 않을까 생각됨.
> 단지 움직이는 문서나 이미지가 움직이기에 동적이라고 한가면 cgi도 가능하며
> gif-animation또한 가능하기 때문임.
저는 자바 applet이 동적이라고 말 하는 것을 단지 `움직임'을 의미하는 것으로
보지 않습니다. 최근의 web browser는 말씀하신바와 같이 gif-animation이나
Javascript, CGI를 사용한 user interaction, plug-in S/W를 사용한 동영상등등이
제공되기 때문에 그러한 관점에서 보신다면 차이점을 알 수 없을 것입니다.
따라서, `움직임'보다는 `비정형성' 및 `계속성'으로 이해하고,
몇가지 관점에서 비교해 보면 그 차이점이 보다 명백해집니다.
1. 동적 사용자 대화 (Dynamic User Interaction)
CGI나 plug-in S/W, script언어들이 갖는 문제점들은
유저가 이들 기능을 이용할 수 있는 방법이 미리 정해져 있거나,
그 기능이 매우 제한되어 있다는 의미에서 정적이지만,
자바 applet은 프로그램이 수행되는 것이므로
임의의 user interface를 제공할 수 있으며, server와는
필요할 때만 통신함으로써 보다 즉각적이고 동적인
user interaction이 가능합니다.
gif-animation의 경우에도 user의 입력을 받아
animation의 속도를 조절하거나 다른 animation 혹은
변형된 animation을 보여주지 못한다는 의미에서
그 animation은 정적입니다.
자바의 applet은 사용자의 입력을 받아 즉각
animation을 제어할 수 있다는 의미에서 동적입니다.
또한, gif 화일을 받아오지 않고 자바의 graphics 기능을
이용하여 동적으로 그려주는 것이 가능합니다.
plug-in S/W의 경우도 plug-in S/W가
정해놓은 user interface를 사용하여 사용자가 동영상을
제어해 줄 수 있을 뿐 보다 응용 영역에 맞도록
다양한 방법으로 그 동영상을 제어하지는 못합니다.
2. 동적 네트워킹 (Dynamic Networking)
CGI가 제공하는 네트워킹 기능은 제한된 방식으로
정해진 규격의 문서만을 웹 서버로부터 가져와서 사용자에게 보여주는
데에 적당할 뿐 그 이상은 곤란하므로 정적이라 할 수 있습니다.
그러나, Java의 네트워킹 기능 (네트워킹 패키지에 의해 제공)을 사용하여,
임의의 써버 (httpd, ftpd, telnetd, talkd, ...) 및 프로그래머가
독자적으로 만든 써버등 다양한서버와 통신할 수 있으며,
이러한 통신은 CGI와는 달리 1회성으로 그치는 것이 아니라,
계속적인 통신이 가능하며 (chatting applet을 CGI로 만들 수 있을까요?)
그 data 형식 또한 임의의 형식이 가능합니다.
3. 분산 컴퓨팅 (Distributed Computing)
클라이언트-써버 모델에서 사용자 (클라이언트쪽)가 늘어날 수록
써버의 부담은 증가하게 되고, 전체 시스템의 성능저하를 야기하는
것이 문제가 되나, Java applet은 일종의 프로그램이므로
써버측에서 계산할 필요가 없는 것은 모두 클라이언트 측 (applet)에서
처리하도록 하면 써버의 부담을 줄일 수 있으며, 이때 써버와 클라이언트
사이에 교환되는 데이타를 최소화시키거나 교환 회수를 최소화시킴으로써
네트워킹 지연을 줄 일수 있습니다.
즉, 사용자 인터페이스는 모두 applet이 처리하고 기타 필요한
계산을 처리한 후, 혼자서 처리할 수 없는 부분만 서버에 요청하여
데이타를 가져와서 처리하는 것입니다.
> 요구를 즉석에서 처리의 표현 또한 문제가....
> 예를 들어 엄청나게 큰 프로그램(WWW검색엔진) 을 WWW상에서 실행할 경우 java
> script 와 java applet로는 즉석 처리는 물론,실행 자체가 붕가능.이유는 설명할
> 필요도 없겠지만 ....
> 단 java 애프리케이션이라면 가능함.
applet은 그 code가 네트워크로부터 download되어야 하는 특성과
일반적으로 Security 제한을 받기때문에
커다란 application (WWW검색엔진등)을 대신하기는 곤란하고, 만약 이러한 기능을
사용자에게 제공할 때는 동적 사용자 인터페이스 처리 부분만을 applet으로 만들고
나머지 부분 (WWW 검색 엔진 본체)은 서버로 만들어야 합니다.
WWW 검색 엔진의 경우에는 applet으로 만들 경우 특별한 잇점이 보이지는
않는다고 생각하지만, 굳이 applet의 잇점을 살려서 만들어보고자 한다면,
검색 엔진에서 검색 분야를 선택하는 부분을 tree view를 사용하여 선택하도록
만들수 있을 것입니다.
> 문제점.
> 개발당시는 OS에 의존하지 않는,즉 windows,mac,unix에서 실행가능한 java
> 프로그램의 개발이 가능하였지만 microsoft가 vJ++에 의한 독자적 버전jdk1.5에
> 의해 일부 기능에 제한(?)이 생김.
무슨 말씀이신지 말 모르겠습니다. 자바 기술은 썬이 Microsoft같은 licensee들에게
자바 기술을 제공할 때, 자바의 표준화를 해치지 못하도록 엄격한
협약을 맺은 것으로 알고 있습니다. (직접 문서를 보지는 못했음)
따라서, VJ++에서 부가적으로 제공하는 독특한 기능을 사용하지만 않는다면,
(그리고, bug의 경우를 제외하고는) OS에 의존하지 않을 것입니다.
또한, Java의 효율성 및 기능성을 확장하기 위해서 많은 package들이
표준화되고 있는 중이므로 비 표준화된 package를 사용함으로써 야기되는
의존성 문제 또한 줄어들 것입니다.
> applet와 애플리케이션의 가장 큰 차이점은 데이타를 화일에 입출력이
> 가능하다는 점에 있음.
> 프로그램 개발 목적에 맞게 선택할 필요가 있음.
applet과 application의 근본적인 차이점은 없습니다.
단지, browser가 applet은 일반적으로 화일 입출력을 하지 못하도록 제한시키기
때문일 뿐입니다.
이러한 제한은 여러가지로 해결 될 수 있습니다.
가령, browser내에 애플릿 보안을 담당하는 클래스 (AppletSecurity)가 있는 데,
이 클래스만 다른 내용이 되도록 간단히 바꾸어주면, applet의 제한을 없애거나
자기가 정해준 제한을 받도록 해 줄수 있습니다.
browser에 따라서는 사용자가 애플릿 제한을 조정할 수도 있습니다.
이러한 방법은 Internet에 제공될 애플릿에는 사용할 수 없으나,
만약 그 애플릿이 Intranet용이라면 유용하게 사용될 수 있습니다.
(그 회사내의 browser의 AppletSecurity를 모조리 바꾸어 줌으로써)
그러나, 이러한 방법은 불편하고 완전한 방법은 아니므로
Signed Applet 기법이 나왔습니다. 이러한 applet은
보안상 아무런 해악이 없다고 보증되어 있으므로 화일 입출력, 임의의
컴퓨터와의 통신등이 가능해집니다.
물론, signed applet을 지원하는 web browser를 사용해야 하며,
조만간 major web browser들이 모두 이들을 제대로 지원해 줄 것이라
생각합니다.
--
Deogtae Kim (김덕태)
CA Lab. CS Dept. KAIST
E-Mail : dtkim@camars.kaist.ac.kr
Phone : +82-42-869-3569