# CGI의 문제점
초기 웹 어플리케이션 구현이는 CGI같은 기술이 사용되었다.
하지만 이런 기술들은 성능,확장성,유지보수, 보안등 여러 면에서
문제점이 있었다.
CGI스크립트가 동작하려면 사용자 요청마다 별도의 프로세스가 생성되어야 한다.
이로 인해 메모리 및 시스템 자원의 과도한 사용으로 성능 저하가 발생할 수 있다.
ex)
1, 사용자가 웹 브라우저에서 요청합니다: http://example.com/cgi-bin/script.cgi?name=John
2. 웹 서버는 CGI 프로그램(script.cgi)를 실행합니다.
3. CGI 프로그램은 "John"이라는을 받아 처리하고 동적 인사말 메시지를 생성합니다.
초기 웹 어플리케이션 구현이는 CGI같은 기술이 사용되었다. 하지만 이런 기술들은 성능,확장성,유지보수, 보안등 여러 면에서
문제점이 있었다.
=> 서블릿,JSP 탄생
# 1997년 - 서블릿( Servlet )
Java Servlet은 자바를 사용하여 웹 페이지를 동적으로 생성하는 서버측 프로그램 혹은 사양이다.
1. 멀티 스레딩 : 자바 서블릿은 멀티 스레딩을 사용하여 성능과 확장성을 개선한다. 웹서버가 요청을 받으면,
서블릿 컨테이너는 대신 처리할 스레드를 생성하고 이 스레드는 서블릿 메소드를 호출하여 요청을 처리한다.
스레드는 공용 소스를 적절하게 공유하여 메모리 효율을 향상시킬 수 있다.
2. 서블릿 인스턴스 관리 : 서블릿 컨테이너는 서블릿 클래스의 인스턴스를 관린한다.
처음 호출될때 인스턴스를 생성하고 초기화하며, 이후 들어오는 요청에 대해 동일한 인스턴스를 재사용한다.
이 방식은 생성및 삭제 비용을 절약하여 메모리 효율을 높인다.
3. 웹 어플리케이션 생명주기 관리 : 서블릿 컨테이너는 웹 어플리케이션의 시작 및 종료를 처리하여 필요한 자원을 할당하고 해제한다.
이로써 개발자는 생명주기 걱정없이 서버의 메모리를 효율적으로 활용할 수 있다.
=> Java코드 안에 HTML코드
public Sample extends HttpServlet {
public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
response.setContentType("text/html");
printWriter out = response.getWriter();
String title = "Servlet Sample";
String docType = "<!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.01 Transitional//EN\">\n";
out.println(docType +
"<HTML>\n" +
"<HEAD><TITLE>" + title + "</TITLE></HEAD>\n" +
"<BODY BGCOLOR=\"#FDF5E6\">\n" +
"<H1 ALIGN=\"CENTER\">" + title + "</H1>\n" +
"<UL>\n" +
"<LI><B>param1</B>: " + request.getParameter("param") + "\n" +
"</UL>\n" +
"</BODY></HTML>");
)
}
}=> 기능변경, 화면의 디자인등이 수정된 경우 Java코드를 수정 해야 한다.
=> 배포할때 컴파일 후 배포해야함(자바니깐)
=> HTML과 자바코드가 섞이게 되어 가독성이 떨어짐
# 1999년 - JSP( Java Server Pages )
서블릿의 단점을 해결하고자 1999년에 Sun Microsystems에서 발표한 기술
=> 기존에 동적 html을 구성하기 위해 서블릿이나, 모듈을 사용해서 구성을 했지만 복잡한 화면 구성과 사후 대응이 힘들었다.
=> 동적 HTML을 보다 용이하게 구성할 필요가 생겼고 JSP가 탄생했다.
=> 글을 쓰고있는 현재 2022년에도 아직 JSP를 사용하는 프로젝트가 많다.
=> JSP는 HTML 코드에 Java코드를 넣어 동적 웹페이지를 생성한다.
=> JSP는 화면을 보여주는 역할을 받았고 화면코딩(html), 로직개발(자바), 데이터베이스개발이라는 역할을 나누게 해 주었다.
1. 클라이언트가 hello.jsp 요청
2. JSP 컨테이너가 JSP파일을 읽음
3. JSP컨테이너가 변환(Generate)작업을 통해 Servlet(.Java) 파일 생성
4. .Java파일은 다시 .class파일로 컴파일
5. Excute(실행)을 통해 HTML파일 생성해서 JSP 컨테이너한테 전달
6. HTML페이지를 클라이언트에게 전달
=> JSP는 HTML을 Java코드로 인해 동적으로 작성 할 수 있어 간편하지만 하나의 파일에 HTML,JAVA,JAVASCRIPT가 같이 코딩되어 있어 가독성이 좋지 않다.
=> JSTL등 대안이 있었지만 그래도 HTML코드의 JAVA코드가 들어가는건 개인적으로 불호
=> Java파일은 코딩하면 컴파일해서 .class파일을 배포하고 서버를 내렸다 올려야 했지만(가끔 JSP컨테이너가 JSP를 읽지 못할때 있음)
=> JSP는 이런 과정이 필요 없어서 JSP위주로 코딩을 좋아하던 PM이 많이 있었다.
<!-- hello.jsp 파일 -->
<%@ page contentType="text/html; charset=UTF-8" %>
<!DOCTYPE html<html>
<head>
<title>Hello JSP</title>
</head>
<body>
<%-- 사용자 이름을 URL 파라미터로 받음 --%>
<%
String name = request.getParameter("name");
if (name == null || name.trim().isEmpty()) {
name = "Anonymous";
}
%>
<h1>Hello, <%= name %>!</h1>
</body>
</html># 1998년 - EJB( Enterprise Java Bean )
Java RMI(Remote Method Invocation): 자바의 내장된 기술로, Java 환경에서 컴퓨터, 프로그램간 통신을 할 수 있는 기능
Java Bean : 자바 객체를 재사용 가능하게 컴포넌트화 시킬 수 있는 코딩 방침
EJB(Enterprise Java Bean) : 대규모 분산 객체 시스템을 구축하기 위한 Enterprise환경에서의 자바 표준
=> 옛날에는 H/W 성능이 좋지 않았기 때문에 S/W로 H/W를 커버해야 할 필요가 있었음
=> 비즈니스 객체들을 관리하는 컨테이너를 만들어서 필요할 때마다 컨테이너로부터 객체를 받는 식으로 관리하면 좋겠다는 필요에 의해 탄생
=> CORBA가 벤더 각자의 설계로 상호 운용성을 확보하기 위해 만든 기술이 EJB
=> EJB 컨테이너에 의해 분산된 EJB컴포넌트를 마치 같은서버에 있는것처럼, 분산된 DB의 트랜잭션을 하나의 DB만 있는 것처럼 제어할 수 있는 분산처리를 위해 탄생
=> EJB 스펙으로 구현만 하면 다른 컨테이너의 객체를 갖다 쓸 수 있게 됨
=> 서버 개발 회사들은 EJB 스펙을 구현하여 여러 WAS제품을 출시했다( WebLogic, Jeus등 )
=> EJB 스펙으로 구현된 WAS의 다양한 서비스(보안, 트랙재션,분산 컴퓨팅) 를 제공 받는것으로 개발자는 비즈니스 로직에만 집중 하게 되었다.
=> WAS의 서비스를 제공받기 위해서 EJB로 비즈니스로 로직을 작성했고 어느새 EJB는 웹 어플리케이션의 권장 설계가 되었다.
=> 그러나 문제가 발생했다.
=> WAS의 다양한 서비스(보안, 트랙재션,분산 컴퓨팅)을 사용하기 위해 개발자는 EJB 스펙을 지켜며 EJB 컨테이너를 사용해야 했다.
=> 그 결과 서비스를 구현해야 하는 실제 비즈니스 로직부터 EJB 컨테이너를 사용하기 위한 상투적인 코드가 많아졌다.
=> 또한 개발사마다 EJB컨테이너를 구현한 내용이 다르기 떄문에 다른 개발사의 컨테이너로의 변경에 어려움이 있었고 설정이 너무 복잡했다.
=> 이러한 것을 비즈니스로직에 특정 기술(EJB)이 종속되어 있다는 것( 기술 침투라고 함 )
=> 애초에 EJB는 컨테이너에서 필요할 때마다 다른 컨테이너에서 객체를 받아내는 방식을 통해 객체들간의 의존성을 해결하는것이 목적이였다.(상호 운용성 확보)
=> 그러나 지금은 EJB를 사용하지 않으면 안되는 문제가 발생(기술침투)
=> 로드 존슨은 EJB를 사용하지 않고도 객체간 의존성 해결이 가능한 컨테이너를 개발했는데 이것이 스프링의 시작
=> 특정 기술에 종속되지 않고 ( 기술 비침투적 ) 객체를 관리할 수 있는 컨테이너를 제공하는것이 스프링의 기본 철학
=> WAS의 기능적인 부분을 유지하되 기술 침투적인 부분을 해결,
=> 개발자는 비즈니스 로직에 집중.
=> 스프링의 탄생
# 짜투리 지식
## EJB에서 분산 컴퓨팅과 MSA의 차이?
=> 분산 컴퓨팅은 하드웨어가 소프트웨어보다 성능이 덜어져서 소프트웨어로 하드웨어로 커버하기 위해서 분산 처리를 위한 기술
=> MSA는 소프트웨어가 너무 방대해지다 보니 유지보수, 관리등의 어려움이 있었고 어플리케이션을 쪼개는 기술
# 정리 - 자바 엔터프라이즈의 역사
1. 정적 웹의 시대 : HTML정적콘텐츠
2. 동적 웹의 시대 : HTML + CGI( 1요청 1프로세스 )
3. 서블릿.JSP의 탄생 : CGI의 문제점을 해결,
4. EJB의 탄생 : 분산 시스템 위해 탄생했지만 다양한 벤더사들이 출시한 제품의 기능을 사용하다보니 어느새 웹 권장 설계가 되었다.
5. 스프링의 탄생 : EJB의 문제점을 개선하기 위해 탄생
'Dev > Web History' 카테고리의 다른 글
| 2002년 스프링의 탄생 (0) | 2022.09.04 |
|---|---|
| 1990년대 중반 - 웹 2.0의 탄생 (0) | 2022.08.28 |
| 1980년대 ~1990년대 초 - WEB 시작 (2) | 2022.08.28 |
