애플리케이션 아키텍쳐
- standalone
- 각각의 사용자가 데이터를 공유하려면 파일을 공유해야한다 => 공유 폴더를 둬야한다.
문제점 =< 파일의 동시접근 문제가 있음/ 데이터 변경/ 삭제에서 결함이 발생한다. 접근 권한 제어의 문제 발생, 데이터 중복에 따른 동기화 문제
- client/server 방식
데이터 입출력을 DBMS에게 맡김 DBMS는 Data I/O 대행, 동기화 관리, 사용 권한 관리
DBMS 에게 데이터 I/O요청할 때 sql 문 사용해야한다.DBMS에 연결된 application의 기능 변경을 하게 되면 재설치(uninstall -> install)해야한다.
<= 글로벌 비즈니스 가속화 -> 경쟁 심화 -> 제품 출시 기간이 짧아짐(제품 lifecycle 이 짧아짐) -> 업무 조직의 변경이 잦아짐 -> s/w변경이 잦아짐 -> 재설치가 잦아짐 -> 유지보수가 어렵다.
=> 해결방법? application 쪽으로 DBMS를 적용하는 거임
ClientAPP(UI 제공) ---(작업요청)---> ApplicationServer(업무작업 수행)
이 둘은 통신을 함
Application 실행 = 기능변경 -> 서버 쪽만 변경하면 된다 -> 유지보수가 쉽다(높은 H/W성능요구 => 그리드 컴퓨팅, 분산 컴퓨팅, 등장 => 낮은 성능의 H/W 여러개를 묶어 높은 성능을 내는 컴퓨터로 만드는 기술 => 비용이 낮아짐)
cloud말고 crowd(군집) 컴퓨팅도존재
Web Browser <---(HTTP + XML, JSON)----> Web Server <= 웹 기술적용(1. ClientApp 을 개발할 필요가 없다 => 웹 브라우저 사용 2. 네트워킹 + 멀티 스레드 프로그래밍을 할 필요가 없다 => 웹서버를 사용하기 때문 3. 이기종 플랫폼/ 프로그래밍 언어 간에 연동이 쉽다.
자바 웹 애플리케이션 표준 제작 기술 등장
Web Browser <----(HTTP 요청/응답)----> Web Server(정적자원 로딩(.html, .css .js .gif ....)) ------(실행)----->
JAVA App
****Web Server는 App을 실행하는 기능이 없다. => 해결책!! 웹 서버에 그런 일을 하는 플러그인을 장착하여 수행한다. => 물론 웹 서버를 만드는 개발자들이 플러그인을 장착하여 웹 서버의 기능을 자유롭게 확장할 수 있도록 프로그램을 짰기 떄문에 가능한 것이다. => 웹 서버마다 플러그인을 장착하는 방법이 다르다! (ex) Apache, Nginx 등등)
Web Server에 App 실행 플러그인을 장착하고 Web Server가 실행하는 C/C++APP (웹 애플리케이션) <= 만드는 기술을 Common Gateway Interface(CGI 프로그래밍이라고 부름 : 웹 서버와 애플리케이션 사이에 데이터를 주고받는 표준 기술)
웹 애플리케이션 제작기술 - 서버 스트립팅 엔진(script = C/C++ 보다 좀 더 가벼운 문법을 가진 프로그래밍 언어 ex) javascript, vbscript, php, perl) scripting = script로 프로그램을 짜는 것
ex) Web Browser에 있는 javascript 엔진으로 hello.js 요청 NodeJs 에서 Javascript 엔진 실행 이거는 server scripting 이라고 부름
스크립트 엔진 등장 이후 C/C++ CGI 프로그램 => 문자열을 다루는 문법이 불편하다.(C는 H/w를 제어하기 위해 등장했기 때문=> 메모리 주소를 다루는 데 특화되었다=> 포인터, C++는 좀더 유지보수가 쉬운 코드를 작성하기 위해 등장했기 때문.) => 웹 애플리케이션은 주로 웹페이지를 다룬다(HTML, CSS, JavaScript) => 즉 문자열을 주로 다룬다. -> C/C++ 언어가 불편하다. -> 문자열을 다루기 쉽고 소스 변경 즉시 실행할 수 있는 스크립트 류의 언어를 사용하게 되었다.
자바도 web Server가 직접실행할 수 없다 why? 진짜 기계어가 아니기 때문이다. Bytecode(p-code)이다. 즉 web server 에서 플러그인을 장착해서 [JVM+ (객체생성, 실행) 객체 분리, 웹 애플리케이션 제작에 유용한 도구]을 통해 실행해야한다. => JVM 뿐만아니라 (객체생성, 실행) 객체 분리, 웹 애플리케이션 제작에 유용한 도구 & HTTP 웹 기술을 다룰 도구가 필요하다. => 특정 회사나 특정 개발자에 종속되지 않는 표준 기술이 필요하다. => 그래서 Sevlet/ Jsp 기술이 등장했다!(어떻게 보면 JAVA APP 관리자 와 JAVA APP 제작하는 것을 Servlet/ JSP라고 함)
Servlet API 규칙에 따라 만든 JAVA 프로그램 => Servlet(server에서 실행하는 작은 application ) 자바App(서블릿) 객체를 생성하고 실행, 소멸(lifecycle 을 관리 = container) => Servlet container(engine 이라고 부르지 않음(실행에 초점을 맞출떄는 engine이라고 하고 관리에 초점을 둘 때는 container라고 부름))
서블릿 프로그래밍
Web Browser <-(요청/응답)-> Web Server <-(실행)-> Sevlet container -(객체생성, 호출)-> 서블릿
개발자는 container 를 만들 필요가 없다 why? 이미 잘 만들어진 container(ex) Tomcat, Resin, Jetty, Undertow, Jeus) 가 많이 존재하기 때문 서블릿만 만들면 된다. => Servlet API 를 사용하여 제작 규칙에 따라 웹애플리케이션을 작성한다.
JDBC API를 사용하면 어떤 DBMS와 연결하더라도 상관없듯이 Servlet 도 웹 서버에 상관없이 동일한 웹 애플리케이션을 제작할 수 있게 해주는 기술이다.
서블릿 컨테이너와 서블릿 Servlet container -(호출)-> 서블릿(/servlet interface 규칙에 따라 구현해야한다.)
JVM에서 main() 호출을 통해 Servlet Container를 사용가능함(servlet container 설치가 필요하다.)
