서블릿

자바 APPLET이 웹에서의 자발 구현 부분이라면 서블릿도 마찬가지로 웹 애플리케이션 개발 기술이다. 하지만 애플릿이 실행 클래스가 클라이언트 쪽으로 다운로드되어 클라이언트 브라우저에서 실행되는 형태를 가지고 있다면 서블릿은 서버 측에서 돌아가는 프로그램이므로 애플릿과 다르게 다양한 자바의 부분을 웹에 전환시킬 수 있다.

애플릿 처리 순서는 다음과 같다.

  1. 클라이언트 웹 브라우저에서 웹서버로 애플릿 파일을 요청한다.
  2. 클라이언트의 요청을 받은 웹서버에서는 클라이언트가 요청한 애플릿 파일의 존재여부를 확인하고 존재한다면 클라이언트로 다시 파일을 네트워크 전송한다. 이때 서버측에서 애플릿 파일이 실행되는 것이 아니라 단지 네트워크 전송으로 파일만이 보내지게 되는 것이다.
  3. 서버로부터 전송된 애플릿 파일이 클라이언트 컴퓨터의 저장공간에 저장이 되니 후 프로그램 수행을 위해 메모리 공간으로 로딩된다.
  4. 로딩된 애플릿 파일을 클라이언트 브라우저 내의 자바 가상머신(JVM)이 실행을 하여 브라우저로 결과물이 보이게 된다.

많은 장점도 있지만 보안상의 문제 등 제약을 많이 받게 된다.

서블릿은 애플릿과 다르게 서버 측의 서블릿 엔진에 의해 실행되고 결과만 HTML 형식으로 클라이언트에게 넘어감으로 자바의 다양한 기술을 웹상에서 구현할 수 있다는 장점과 HTML을 기본 GUI로 채택함으로써 프로그램하기 쉬워졌으며 기존 HTTP프로토콜을 이용함으로써 기존의 웹프로그래밍 로직을 그대로 이용할 수 있다는 장점을 가지고 있다.

 

Server Side Script

확장 CGI프로그램인 ASP나 PHP 모두 Server Side Script 프로그램이라 정의할 수 있다. Server Side Script라 함은 HTML문서에 포함되어 있는 스크립트 언어가 어디에서 처리되느냐로 결정된다. 즉 HTML 문서 내의 Script가 클라이언트 사이드, 다시 말해 클라이언트 컴퓨터에서 처리된다면 이를 Client Side Script라고 하고 서버 컴퓨터에서 처리된다면 이를 Server Side Script라고 한다.

이는 웹프로그래밍에 있어 중요한 부분으로 어느 Side에서 로직을 실행시키느냐에 따라서 로드 문제나 보안 그리고 네트워크통신 등에서 큰 차이를 보이고 있다.

대표적인 Client Side Script라고 할 수 있는 것이 많이 쓰이고 있는 자바스크립트일 것이다.

function nullCheck(form) {

var id = document.myform.myid.value;

var password = document.myform.mypw.value;

if(!id || !passwd)

{

alert(‘아이디나 패스워드를 입력하지 않았습니다.”);

}

return;

}

위의 자바스크립트 부분이 화면 구성과 관련이 없는 null 체크를 위한 부분이다. null 체크를 자바스크립트로 했다면 이는 서버와 네트워크 통신없이 null값이 있다는 것을 알아낼 수 있을 것이다. 만약 자바스크립트 null체크를 하지 않았다면 서버로 데이터가 전송될 것이고 다시 서버에서 null값에 대한 오류 로직을 통해 클라이언트로 보내지게 된다.

이렇게 된다면 불필요한 네트워크 통신이 일어나게 된 것이다.

다시 말해 위와 같은 경우 당연히 Client Side에서 프로그램이 실행되는 것이 맞으며 이렇게 서버와 네트워크 전송 없이 어떤 로직을 수행하는 것을 Client Side Script라고 한다.

web server

이러한 Client Side Script들은 당연히 클라이언트 컴퓨터에 의해 실행되므로 클라이언트에서 소스보기 등의 방법으로 프로그램 내용을 확인할 수 있는 것이다.

하지만 만약 위처럼 간단한 로직이 아니라 데이터베이스와 관련된 로직이라면 그 데이터베이스 계정명과 암호등이 프로그램 내에 들어가야 하고 이 계정과 암호가 클라이언트에게 그대로 보인다면 보안상 심각한 문제를 발생시킬 수 있다.

결국 이렇게 어떠한 로직을 수행하는 소스는 보이지 않고 단지 그 결과만이 html형태로 클라이언트에게 보내지는 방법을 Server Side Script라고 한다.

그리고 이 Server Side Script는 클라이언트 컴퓨터가 아닌 서버에서 수행되게 되는 것이다.

만약 클라이언트가 다음과 같은 url로 웹페이지를 요청했다고 하자.

http://localhost:8080/examples/jsp/helloworldjsp.jsp

그러면 웹서버에서 이 요청을 받아들이고 다음과 같은 jsp파일을 수행시킨다.

<html><head></head><body>

<%! String str = new String(“HelloWorld jsp!!”); %>

<h1><center><%=str %>

</center></h1></body></html>

위 예전에서 굵은글씨로 되어 있는 부분은 jsp프로그램이다. 즉 html에서 jsp 스크립트가 있는 파일이다.  하지만 이것의 결과를 보는 클라이언트는 단순히 이 프로그램 결과물인 html파일밖에 볼 수 없다. 즉 서버 측에서 프로그램이 돌아가고 클라이언트에게는 단순히 결과물만 넘어가게 되는 것이다.

클라이언트 측에서는 helloworldjsp.jsp의 실행결과물인 html파일만 볼 수 있는 것이다. 이처럼 Server Side Script와 Client Side Script의 차이를 보이고 있으며 자바에서도 Applet프로그램이 Client Side이고 Servlet이나 jsp가 Server Side이다.

web 프로그램에서 흔히 말하는 스크립트 언어란 컴파일 과정이 없는 언어이다. 즉 소스 프로그램 자체가 컴파일 과정이 없이 해석기에 의해 직접 실행되는 언어들이다. 대표적인 스크립트 언어가 자바스크립트, asp, php등이다. 그러나 자바프로그램은 모든 파일들이 컴파일 과정을 거쳐 생성된 class(중간 기계어)파일에 의해서 서비스를 제공하는 것이다.

 

확장 CGI

기존의 프로세스 기반 CGI의 단점은 매 요청시 독립된 프로세스를 생성하고 요청 결과를 생성하고 나면 프로세스를 보존하지 못하는 문제점을 가지고 있다. 이로 인해 서버에 많은 오버헤드를 발생시키고 서버에서 감당하기 힘든 상태가 발생하게 된다.

그러므로 이런 기존의 CGI 프로그램으로 데이터 연동 프로그램을 짠다는 것은 비효율적인 일이 된 것이다.

이로 인해 확장 CGI에서는 독립 스레드 방식으로 서버의 오버헤드 문제를 해결하고자 하였으며 session 기술을 이용해 클라이언트의 상태를 지속시키는 기술을 제공해주고 있다.

대표적인 확장 CGI 프로그램으로는 ASP, PHP 그리고 자바기술인 servlet, jsp등이 있다.

 

ASP는 Active Server Pages의 약자로 CGI의 단점을 극복하고자 MS 사에서 만들 언어로 MS사의 IIS(Internet Information Server)에서 프로그래밍할 수 있다. asp는 HTML 문장과 스크립트 로직을 함께 포함하고 있는 ASP란 확장자를 가진 파일이다.

asp 프로그래밍을 가능하게 하는 웹서버로는 MS사의 IIS웹서버와 PSW웹서버이다.

IIS 웹서버는 클라이언트에 의해 ASP에 대한 HTTP요청을 받으며, ASP에 의해 수행된 최종적인 결과를 HTML문장에 추가하여 전달되게 된다. 서버 측에는 ASP가 설치되어 있어야 하며, 이는 서버상에 IIS나 PSW가 반드시 실행되고 있어야 한다.

PHP(Personal Home Page Construction Kit)는 Unix와 Linux 그리고 Windows와 NT환경의 HTTP서버에서 사용할 수 있는 웹프로그래밍 언어이다.

ASP와 마찬가지로 CGI의 단점을 극복할 수 있는 확장 CGI로 웹서버에서 요청을 수행하고 다시 서버에 결과를 넘겨주게 된다. ASP와 다르게 대부분의 OS에서의 프르그램이 가능하고 또 대부분의 데이터베이스를 지원해주고 있다.

 

 

AJax

Ajax란 비동기 javaScript와 XML을 말한다.

서버측 Script와 통신하기 위한 XMLHttpRequest객체를 사용하는 것을 말한다. 서버측을 다양한 형식(JSON, XML, HTML 및 일반 텍스트 형식 등)의 정보를 주고 받을 수 있다. Ajax의 강력한 특징은 페이지 전체를 리프레쉬 하지 않고서도 수행되는 “비동기성”이라는 것이다. 이러한 비동기성을 통해 사용자의 Event가 있으면 전체 페이지가 아닌 일부분만을 업데이트할 수 있게 해준다.

페이지 일부분을 업데이트 하기 위한 정보를 서버에 요청할 수 있으며, 서버로부터 받은 데이터로 작업을 할 수 있다.

ajax-fig1

CGI

CGI란 하나의 규약을 의미하며 흔히 마라는 CGI 프로그래밍처럼 특정 프로그래밍 언어를 지칭하는 말이 아니다. CGI(Common Gateway Interface)란 각 클라이언트의 웹브라우저와 서버의 웹서버 그리고 응용 프로그램간의 인터페이스를 지칭한다.

즉 클라이언트의 브라우저로부터 서버로 전달되는 데이터를 어떻게 응용 프로그램에 전달하고 응용 프로그램의 결과 데이터를 어떻게 클라이언트 브라우저에 전달하는가를 정해놓은 하나의 인터페이스이다.

CGI 프로그램이 일반 다른 프로그램과 프로그램의 구조적 차이를 보이는 것이 아니라 단지 HTTP서버와 정보를 교환하는 특성을 가지고 있는 것이다. 그러므로 HTTP 서버로부터 프로그램 수행에 필요한 입력을 전달받는 부분과 프로그램의 출력이 HTTP서버를 통하여 클라이언트에 전달되는 방식을 택하고 있는 것이다.

그러므로 프로그램의 결과가 HTTP 서버에 의해 클라이언트에 전달되므로 가장 많이 사용하듯이 HTML에 의해 전달되며 이는 가장 일반적인 HTTP서버와 클라이언트 사이의 전달 형식이 되기 때문이다.

다시 정리하면 CGI프로그램은 웹서버를 중간 매개로 웹서버에 의해 클라이언트의 요구를 받아들이고 클라이언트으 요구를 받아들인 웹서버에 의해 CGI 프로그램이 돌아가며 CGI 프로그램에 의해 발생한 결과물이 다시 웹서버에 의해 클라이언트 브라우저로 보여지게 된다. 그리고 보여지는 형식을 HTML로 주로 이용하고 있는 것이다.

1085619015217_cgi01

위의 그림처럼 클라이언트 브라우저에서 서버로 요청(request)이 들어온다. 이 요청을 server 측의 web server에서 받아들이고 클라이언트가 요청한 CGI 프로그램을 실행시킨다. 그리고 CGI 프로그램을 수행하면서 클라이언트에게서 전달받은 데이터를 CGI프로그램에 전달하게 된다. CGI 프로그램은 요청에 의해 프로그램을 수행하고 결과를 다시 web server에 전달하게 된다. web server에서는 CGI 프로그램에서 전달된 결과를 다시 클라이언트에게 전달된다.

 

web programming 언어

인터넷은 기본적으로 TCP/IP를 기반으로 하는 네트워크 서비스라 할 수 있다. TCP/IP 기술을 기반으로 하는 TELNET, FTP, SMTP 서비스 등이 제공되다가 대중적 서비스가 가능해진 것이 바로 HTML의 등장부터이다.

HTML은 HTTP 프로토콜을 이용하여 인터넷상에서 문서전달을 기본으로 그래픽, 사운드, 동영상 등의 멀티미디어 기술을 도입 서비스함으로써 인터넷의 폭발적 발전을 이루게 되었다. 하지만, HTML의 정적인 구조는 새로운 방식의 기술을 요구하게 되었고 이로 인해 나온 것이 CGI(Common Gateway Interface)이고, 이 기술을 지원하기 위해 web programming 언어로써 쉘, Perl, C 등이 이용되기 시작했다.

그러나 프로세스 기반의 CGI 서비스는 클라이언트의 요청에 대해 프로세스가 기동되며, 프로세스가 수행이 끝나면 메모리상에서 제거됨으로 응답이 느리고 무거우며 상태의 보전이 되지 않는 문제점을 가지고 있다.

이런 단점을 극복하기 위해 나온 것이 확장 CGI 방식으로 현재 많이 이용되고 있는 ASP, PHP 등의 web programming 언어들이다.

 

SOAP

SOAP는 XML과 HTTP 통신을 기반으로 하여 네트워크 상에 존재하는 각종 컴포넌트간의 호출을 효율적으로 실현하기 위한 방법을 제시하는 규약이다.

네트워크 상에서 Client와 Service Provider간에 메시지를 요청하고 이에 응답해주는 방법을 제공하는 것이다. 이런 방식은 RPC(Remote Procedure Call)라 묶여서 불려오던 것들인데, SOAP가 RPC의 한가지 방법이라 보면 된다.

SOAP은 여러 Application Layer Protocol들 중에 HTTP를 사용함으로써 여러 시스템간의 통신과 통합을 위한 좀더 단순하면서도 가벼운 메카니즘을 제공한다. HTTP를 사용하게 된 중요한 이유는 바로 방어벽에 제한을 받지 않는 범용성 때문이다.

다른 Application Layer Protocol의 경우 그들만의 약정된 TCP 또는 UDP포트를 사용하기 때문에 인터넷상에 설치되어 있는 방어벽에 많은 제약을 받게 된다. SOAP은 HTTP를 채택함으로써 방어벽의 제약을 받지 않고 불특정 다수의 클라이언트 또는 인터넷 상의 특정한 서버와의 RPC를 효율적으로 수행할 수 있도록 해준다.

SOAP은 특정한 HTTP Header를 방어벽의 필터링 부분에 보냄으로써 메시지의 통과여부를 가릴 수 있게 하는 방법으로 보안이라는 문제를 해결한다.

SOAP 4가지 구성

  1. SOAP envelope : Message에 무엇이 있는가, 누가 무엇을 다루는가, 어떤 것이 Optional이고 mandatory인가를 나타내기 위한 전체적인 framework를 제공한다.
  2. SOAP encoding rules : Application에 정의된 data type들의 instance를 교환하는데 사용되는 메카니즘이다.
  3. SOAP RPC 표현 : Remote procedure call과 response들을 나타내는데 사용되는 규약을 정의한다.
  4. SOAP binding : 두 peer간의 전송프로토콜을 사용하여 SOAP envelope 교환에 대한 규약을 정의한다.

SOAP의 전달과정은 먼저 Client에서 특정한 작업을 요청하게 되면 중계자가 받게됩니다. 그리고 자신이 처리할 내용이 있는지 확인 후 다음 중계자에게 전달합니다. 이렇게 중계자를 통해 메시지의 일부를 변경하여 다음 중계자에게 포워딩 하다가 액터를 만나게 되면 해당 작업을 처리하게 됩니다. 이 액터를 Default Actor라고 부르며 SOAP mesage의 최종 수진자라고 말할 수 있습니다.

Client -> 중계자 -> 중계자 -> Default Actor

SOAP Library (C, C++) 와 SAAJ(SOAP with Attachment API for JAVA)를 통해 사용이 가능합니다.
<C나 C++의 경우>
1. gSoap : c++로 작성된 라이브러리고 SOAP 1.1/1.2 명세를 충실히 따르는 안정적인 라이브러리로 클라이언트, 서버를 모두 지원합니다. 또한 linux, window, Mac, Solaris 등 다양한 플랫폼을 지원하며 의존라이브러리가 따로 없기때문에 자체적으로 작동됩니다. 무엇보다 WSDL 문서를 통해 서버/클라이언트 모두 자동으로 스텁코드를 생성해준다는 점이 강력한 점입니다.
2. cSoap : 순수 C언어로 구현한 라이브러리로 클라이언트/서버 모두를 지원하며 SOAP 1.1 명세를 지원합니다. 의존라이브러리는 libxml, libssl, libpthread가 있으며 ANSI C로 구현했기 떄문에 window, Unix, Linux, Mac, OpenVMS, AIX 등의 아키텍처에서 모두 지원합니다.
3. libSoap : GNOME환경을 위한 HTTP 클라이언트/서버 라이브러리입니다. 의존 라이브러리로는 libglib, libgntls, libpthread가 있으며    비동기뿐만 아니라 동기 API도 가지고 있어 Thread 프로그래밍도 사용 가능합니다