이 주제에서는 서블릿에 대한 나의 이해, 서블릿 컨테이너가 무엇인지, 전부는 아니지만 대부분의 웹 프런트 엔드 프레임워크가 무엇인지 솔직하게 이야기하고 서블릿 컨테이너와 애플리케이션 서버가 어떻게 관련되어 있는지에 대한 주제도 다루고 싶습니다. 서로, 서블릿 및 웹 서버 컨테이너. 대화를 시작하기 전에 토론이 있을 것으로 기대한다는 점을 말씀드리고 싶습니다. 왜냐하면... 여기서는 단 하나의 코드도 제시하고 싶지 않고 언제나 말로 표현할 수 있는 본질만 언급하고 싶습니다. 처음 시작했을 때 명확하지 않았던 모든 사항을 간략하게 설명하려고 노력할 것입니다. Tomcat 서블릿 컨테이너가 WebSphere나 Geronimo와 같은 애플리케이션 서버와 어떻게 다른지에 대한 주제로 다양한 포럼에서 질문을 했을 때 감히 대답한 사람은 "Wikipedia를 보세요" 또는 " 서버 애플리케이션이라고 말하기는 어렵습니다. 이는 기업 애플리케이션을 위한 복잡한 인프라이므로..." 어쩌구 저쩌구. 나는 그런 사람들을 참을 수 없고 여러분 대부분도 그렇지 않을 것이라고 생각합니다. 역사적 불의를 바로잡겠습니다. 가다…
서블릿
누가 뭐래도 서블릿은 자바로 작성된 웹페이지이다. 어떤 사람들은 내가 틀렸다고 말하고 서블릿은 웹 애플리케이션이며 이러한 개념에 차이가 있다고 말하지만 그렇지 않습니다. 이제 아무런 차이가 없으며, PHP로 작성된 사이트를 웹 애플리케이션이라고 안전하게 부를 수도 있습니다. 이제 이것은 완전히 자연스럽습니다. 왜냐면... php는 OOP를 완벽하게 지원하며 Joomla와 같은 CMS는 이를 적극적으로 사용합니다. 코드 수준에서 서블릿이란 무엇입니까? 이는 잠자기 상태를 유지하고 누군가가 GET 또는 POST HTTP 요청을 통해 해당 메소드에 액세스하는지 확인하는 여러 메소드가 있는 클래스입니다. 저것들. 브라우저에 일부 GET 요청을 입력하면 서블릿 클래스의 해당 메소드가 이를 수락한 다음 HTML 페이지 형식으로 이에 대한 응답을 생성합니다. Sun이 고안한 서블릿의 고전적인 의미에서 이 페이지는 <!DOCTYPE htm>> 줄로 시작하여 </html> 줄로 끝나는 한 줄씩 클라이언트에 전송됩니다. 따라서 Java에는 이라는 기본 서블릿 클래스가 있습니다 Servlet. 또한 이 기본 클래스를 상속하여 해당 기능을 확장하는 다른 클래스도 많이 있습니다. 그것이 바로 서블릿입니다. 그 이상은 아닙니다. 이는 서버에서도 실행되는 PHP 코드의 Java 아날로그일 뿐이며, 웹 페이지 형식의 웹 브라우저 요청에 대한 응답만 클라이언트로 전송됩니다. 모두.
웹 프런트엔드 프레임워크
부제가 복잡하고 보통 프론트엔드 프레임워크 나 웹 총구 만 작성 하지만 여기서는 프론트엔드 프레임워크에 대해 이야기할 때 웹 브라우저를 통해 Java로 작업하기 위한 GUI에 대해 이야기한다는 점을 강조하기로 결정했습니다. 저것들. 여기서 다시 우리는 Java로 된 웹사이트에 대해 이야기하고 있습니다. 서블릿에 대해서. Apache Struts와 같은 거의 모든 프런트엔드 프레임워크는 무엇입니까? 이는 단순히 기본 클래스를 확장하는 클래스 집합입니다 Servlet. 더 이상은 없습니다. 저것들. 이는 동일한 일반 서블릿을 생성하는 다른 방법일 뿐입니다. 단지 이 프레임워크의 개발자(즉, 이 기술의 개발자)는 Servlet일부 메서드와 함께 기본 클래스를 추가하는 것이 Sun/Oracle의 클래식 서블릿이 제공하는 빈약한 기능보다 프로그래머에게 더 편리할 것이라고 생각했을 뿐입니다. 가지다.
JSP 페이지
거의 즉시, Java 서블릿 개념 개발자들의 마음속에 또 다른 아이디어가 떠올랐습니다. 우리는 html 페이지를 클라이언트에 보내는 작업인 서블릿을 작성하고 있으므로 이 html 페이지를 즉시 작성하는 것이 더 정확할 수 있으며 Java에서 일종의 논리가 필요한 경우 간단히 직접 삽입하십시오. html로. 더 명확해지지 않으면 jsp 페이지는 php 페이지와 유사하다는 문구가 도움이 될 수 있습니다. 어려운? 그럼 다시 설명하겠습니다. PHP로 페이지를 작성할 때 무엇을 합니까? 우리는 정적 HTML을 가지고 있으며, 루프나 조건과 같은 로직을 PHP에 삽입해야 할 때 이를 태그 본문에 삽입합니다 <?php … ?>. jsp를 사용하면 모든 것이 동일하며 논리만 순수 Java로 작성되며 해당 코드는 태그 본문에 삽입됩니다 <% … %>. 다시 한번 서블릿의 개념으로 돌아가 보겠습니다. 본질적으로 JSP 페이지는 서블릿이지만 약간 다르게 작성되었습니다. 일반 서블릿에서는 일부 논리를 수행하고 그 결과에 따라 클라이언트용 HTML 페이지를 생성하는 메서드를 작성합니다. 얼마 후 서블릿 개발자는 다음과 같이 생각하기 시작했습니다. 메소드에 로직이 거의 없고 html 페이지의 형성만 거의 발생한다면 html 페이지를 즉시 작성하는 것이 더 쉽지 않을까요? 최소한의 Java 삽입을 만드는 방법은 무엇입니까? 음, jsp 페이지에 대한 마지막 사항입니다. 이러한 페이지에 처음 액세스하면 서블릿으로 컴파일된 후 실행됩니다. 이 jsp 페이지에 대한 후속 요청은 더 빨라질 것입니다. 이미 컴파일되어 있으므로 실행만 하면 됩니다.
서블릿 컨테이너
그래서 우리는 서블릿 클래스나 JSP 페이지를 작성했습니다. 무엇 향후 계획? 사용자의 웹 브라우저로 보낼 수 있도록 웹 서버(예: apache)에 푸시하는 방법은 무엇입니까? 웹 서버는 html만 보낼 수 있으며 페이지에 php 코드가 있는 경우 웹 서버는 먼저 php를 html로 변환하는 인터프리터를 통해 페이지를 전달한 다음 결과를 클라이언트에 보냅니다. 서블릿에서도 거의 같은 일이 발생합니다. 보내기 전에 HTML 페이지가 생성되도록 서블릿을 실행해야 하며, 서블릿 컨테이너는 서블릿과 JSP 페이지 코드 실행을 담당하는 것입니다. 저것들. Java용 서블릿 컨테이너는 웹 서버의 PHP 인터프리터 모듈과 유사합니다. 따라서 사용자가 웹 브라우저에 주소를 입력하면 요청이 웹 서버로 전송되고 웹 서버는 서블릿이 요청되고 있음을 이해하고 요청을 서블릿 컨테이너에 전달합니다. 그런 다음 서블릿 컨테이너는 서블릿을 실행하고 결과 HTML 페이지를 웹 서버로 보내고 웹 서버는 이를 클라이언트에 반환합니다. 서블릿 컨테이너가 자체적으로 실행될 수 있습니까? 웹 서버 없이? Tomcat과 같은 것은 확실히 가능합니다. 그리고 서블릿 기반 페이지를 제외하고 다른 HTML 페이지가 없는 사이트를 만들고 싶다면 서블릿 컨테이너만으로도 충분합니다. 그러나 서블릿의 사이트와 PHP 페이지를 결합하려면 웹 서버를 설치해야 합니다. 또한 모든 웹 서버에 기본적으로 서블릿 컨테이너가 포함되어 있는 것은 아니지만 거의 모든 웹 서버에서 이를 플러그인으로 설치할 수 있습니다. 따라서 Apache가 실행될 가능성이 가장 높은 인터넷의 일부 호스팅에서 웹 사이트를 시작하려면 공급자에게 서블릿 컨테이너가 연결되어 있는지 물어봐야 합니다.
자바 EE
소위 JavaSE(Java Standard Edition)가 있습니다. 이 개념에는 모든 클래스가 포함됩니다 java. 사용하기 위해 가져오기만 하면 되거나(예: java.util.Date) 이를 수행할 필요가 없습니다(예: String패키지에 있기 때문에 java.lang). 그리고 Java EE(Java Enterprise Edition)가 있습니다. 이 클래스도 Sun/Oracle에 속하지만 유일한 차이점은 프로젝트에서 사용하기가 더 어렵다는 것입니다. 단순한 선만으로는 import…충분하지 않습니다. 왜냐하면... 프로젝트가 컴파일되지 않습니다. 이러한 상황을 해결하려면 javaee.jar 라이브러리 파일을 찾아서 프로젝트에 포함시켜야 합니다. 이는 개발 환경의 프로젝트 속성을 통해 수행할 수 있습니다. 이 연결 프로세스를 프로젝트의 빌드 경로 나 클래스 경로 에 jar 별명을 등록한다고 흔히 말합니다 .
애플리케이션 서버
이제 Java EE를 사용하는 서블릿 프로젝트를 컴파일했다고 상상해 보세요. 모든 것이 훌륭하지만 이제 컴파일된 클래스를 서블릿 컨테이너에 배치해야 합니다. 그들이 해냈다고 가정해 봅시다. 우리 애플리케이션이 작동할까요? 내 대답은 아니오 야. 서블릿에 액세스할 때 일부 클래스를 찾을 수 없음을 나타내는 예외가 발생합니다. 왜? 왜냐하면 우리는 슬리핑을 통해 컴파일러를 "기만"했기 때문 javaee.jar в classpath입니다. 컴파일러는 Java EE의 클래스가 제자리에 있고 진정되었음을 확인했지만 서블릿 컨테이너는 이러한 클래스를 볼 수 없지만 서블릿에서 해당 클래스에 대한 링크를 볼 수 있습니다. 이 상황을 서블릿 컨테이너 내에서 해결할 수 있습니까? 물론 그렇습니다. 서블릿 컨테이너의 서블릿이 있는 폴더에 javaee.jar 라이브러리 파일을 추가하기만 하면 됩니다 . 이제 그러한 프로젝트가 많이 있을 것이고 모두 하나의 Tomcat 서블릿 컨테이너에서 실행되고 있다고 상상해 보십시오. 이는 이 jar 파일을 각 서블릿의 폴더에 복사해야 함을 의미합니다. 이것은 불편하고 잘못된 것입니다. 이 파일은 오랫동안 단일 사본에 있었고 모든 서블릿이 이에 액세스할 수 있지만 자체 사본은 갖지 않는 애플리케이션 서버의 개념을 도입함으로써 상황이 해결되었습니다. 제 생각에는 매우 편리하고 논리적입니다. 당연히 모든 소란은 하나의 jar 파일로 인한 것이 아닙니다 (예를 들어 설명했습니다). 그러한 파일이 많이 있습니다. 그러나 그것이 애플리케이션 서버가 우리에게 제공하는 전부는 아닙니다. 애플리케이션 서버 자체는 데이터베이스와 같은 많은 리소스에 대한 연결을 유지할 수 있습니다. 동시에, 우리 서블릿은 그러한 연결 자체를 열지 않고 단순히 애플리케이션 서버에서 이를 가져올 수 있습니다. 서블릿 컨테이너에서는 이것이 불가능합니다. 왜냐하면... 컨테이너는 어느 정도 단순한 애플리케이션 서버입니다. 컨테이너에서 서블릿은 항상 데이터베이스 자체에 대한 연결을 생성해야 합니다. 이런게... 전쟁아카이브 전쟁아카이브란? WAR은 웹 아카이브입니다. 실제로 이는 다른 병과 마찬가지로 zip 파일일 뿐입니다. 기본적으로 이는 많은 웹 페이지, jsp 페이지 및 서블릿 클래스로 구성된 웹 사이트를 하나의 zip 파일에 집어넣는 방법일 뿐입니다. web.xml web.xml은 소위 배포 설명자입니다. 이것은 처리를 위해 어떤 웹 브라우저 라인 요청을 어떤 서블릿 클래스에 보낼지 어리석게 설명하여 서블릿 컨테이너가 어떤 서블릿이 무엇을 담당하는지 혼동하지 않도록 하는 파일입니다. 일반적으로 Java에서는 모든 종류의 xml 파일에 설정을 설명하는 것이 매우 유행하지만 최근에는 이러한 전통에서 벗어나는 경향이 있습니다. 어떻게 물어보나요? 그리고 주석을 통해. 주석 클래스 자체는 아무 작업도 수행하지 않으며 별도의 XML 파일이 아닌 코드에서 직접 모든 종류의 설정(메타데이터)을 설명하기 위해 만들어졌습니다. 매우 편안합니다. 그러나 이제 일부 설정은 주석으로 지정되고 일부는 xml로 지정되는 특정 중간 단계가 있으며 이는 혼란스러울 수 있습니다. XML을 보면 하나의 설정이 표시되지만 주석에 따르면 다른 설정이 있습니다. 어느 것이 가장 우선순위가 높나요? 누가 알아…
결론
이 글을 쓰면서 이렇게 빠른 리뷰는 누구에게도 도움이 되지 않을 것이라고 생각했습니다. 왜냐하면... 구체적인 내용이나 예가 포함되어 있지 않지만 작성된 내용을 지우지 말고 그대로 두십시오.
GO TO FULL VERSION