원본 출처 :


http://www.terms.co.kr/


비즈니스 로직이란 업무에 필요한 데이터 처리를 수행하는 응용프로그램의 일부를 말한다. 이것은 데이터 입력, 수정, 조회 및 보고서 처리 등을 수행하는 루틴, 좀더 엄밀히 말하면 보이는 것의 그 뒤에서 일어나는 각종 처리를 의미한다. 대개 클라이언트 프로그램은 사용자 인터페이스와 비즈니스 로직으로 구성되며, 서버 프로그램은 대부분 비즈니스 로직만으로 되어 있다. 특히, 클라이언트/서버 모델인 경우에는 이외에도 통신링크가 추가되지만, 통신과 관련된 인프라스트럭처는 사용자 인터페이스처럼 비즈니스 로직의 일부는 아니다.


http://zetawiki.com/wiki/%EB%B9%84%EC%A6%88%EB%8B%88%EC%8A%A4_%EB%A1%9C%EC%A7%81


비즈니스 로직


business logic, business logic layer, business tier, logic tier

비즈니스 로직, 비즈니스 로직 계층, 비즈니스 티어, 비즈니스 계층, 논리 계층


업무절차를 정보시스템으로 구현하기 위한 자료구조와 알고리즘

데이터베이스와 UI간 정보교환을 제어하는 알고리즘

기술적인 표현이 아니라 개념적 표현임

3계층 소프트웨어 아키텍처에서 가운데 논리 계층













http://okky.kr/article/139274


보통 코딩시

 

action -> manager-> dao

 

방식으로 많이 쓰던데요

 

액션단 매니저단 dao단에서 각각 무엇을하는지

명확하게 좀 가르쳐 주실분 계신지요

 

제 생각으로는

 

액션에서는 파라미터 셋팅하고

매니저 에서는 비지니스 로직?

dao단에서는 당연히.. 쿼리를 날리는걸로 알고있는데

 

 

액션단에서 비지니스 로직도 하고 dao를 바로 콜하면 안되는건가요?

보통 비지니스 로직이 매우 간단하여..

액션단에다 대충 기술하고.. 구지 매니저 클래스에서

다시 dao를 호출할 필요가 없는 경우가 만터라구요

'(매니저 클래스에서 하는일은 그냥dao 호출뿐인데

클래스도 인터페이스까지 2개를 만들어야하구요...)

 

아무튼 위문제에 대해서

다들 어떻게 하시는지

그냥 패턴에 따라 코딩하시는지

아니면 저런 경우에는 액션에서 dao를 바로 콜하시는지

궁금합니다...



Action (controller 역할을 합니다. req의 유입, 분기, res 를 전달합니다)
Service (비즈니스 로직을 구현합니다,)
Dao (DB 자원을 억세스합니다.)



보통 클래스를 분리하는 이유는, 하나의 파일이 너무 많은 책임과 권한을 갖게 되면 당연히 스파게티 소스가 되고, 길어지기 마련이며, 유지보수하기 어렵기 때문입니다.

작은 단위의 unit 테스트나, 디버깅을 쉽게 가져가려는 부분, 서비스 영역의 비즈니스로직만 다이렉트 콜 해야 할 경우, 개발자가 여럿이 한 업무를 개발할 경우, MVC에 충실한 디자인을 고려해야 할 경우, 적절한 추상화를 해야 할 경우 등등등 파일의 영역을 역할에 맞게 분리하는것에 대해서는 oop적인 측면에서 장점이 많기 때문에 영역을 나누는것이죠.

그러면 어떻게 나누어야 하나?, 어떤 정도 레벨까지 추상화를 할것인가?
이건 정답이 없습니다. 각 상황에 맞게, 각 인력의 역량에 맞게 '잘' 하면 되는거죠

  • 퀵님 그렇다면...

    만약 비지니스 로직이 없거나 매우 간단하다면
    Service 단 호출 없이 바로 DAO를 호출해도 되는건지요?

    몇개 클래스만 DB처리후 소켓통신을 하고 나머지 클래스느 죄다 
    서비스단 없이 액션단에서 DAO를 호출해도 될것같아서 말입니다.

    이렇게 해도 되는걸까요 ^^
  • 비지님 struts - ibatis 로 구성된 소스 한번 보시구요..

    각 struts - ibatis의 jar까서 디랙토리 구조와 호출 구조보면 답이 나옵니다.
    왜 디렉토리를 그렇게 이름지었을까 ? 이고민만 하시면 해결됩니다. 

    바로 DAO를 호출해도 되는데요 만약 비지니스 로직이 추가되면?
    그래서 프레임워크 사상을 따르는것이 좋습니다. 악간의 반복코딩이 되더라도
    이미 통상적인 Layer는 존중을 하는게 최고입니다



 



정보를 좀 더 수집해야할 듯하다.





'프로그래밍 > 웹 프로그래밍' 카테고리의 다른 글

html 중급?  (0) 2016.02.21
HTML 기초  (0) 2016.02.21
비즈니스 로직(Business logic)?  (0) 2016.02.14
웹서버(Web Server) / 웹 서버 어플리케이션(WSA)  (0) 2016.02.14
웹 프로그래밍 기초  (0) 2016.02.14
ASP(Active Server Page)  (0) 2016.01.28
Posted by GENESIS8

댓글을 달아 주세요


출처 : http://round1tko.tistory.com/64




웹 서버와 WAS(Web Application Server)의 정의 ]

웹서버와 WAS는 비슷한 개념이기 때문에 같이 또는 다르게 사용되는 단어 가운데 하나이다. 인터넷 확산 초기에는 웹서버라는 개념으로 통칭해서 사용했지만, 시간이 지남에 따라 WAS를 더 많이 사용하고 있다. 인터넷 사용자가 증가함에 따라, 각 웹 사이트는 보다 많은 사용자에게 원활한 서비스를 제공하기 위해 기능적인 layer를 나누게 되었고 여기서 웹서버와 WAS의 구분점이 생기게 된 것이다.

기능적으로만 본다면, 거의 대부분의 웹 서버가 웹 애플리케이션을 동작시킬 수 있겠지만 모두 웹 서버 혹은 WAS라고 부르는 것보다는 어떤 기능을 수행하는지에 따라, 즉 기능상의 분류를 통해 구분지어 사용해야 할 것이다.

 

구분

웹서버

WAS

설명

1. 웹브라우저(Web Client)에게 컨텐츠를 제공하는 서버이다.  정적인 HTML이나 jpeg, gif같은 이미지를 HTTP 프로토콜을 통해 웹 브라우저에 제공한다.


2. 
최근에는 웹서버에서도 내부 애플리케이션을 동작시킬 수 있는 컨테이너를 내장하고 있다.

서버단에서 애플리케이션을 동작할 수 있도록 지원한다. 일반적으로 컨테이너라는 용어로 쓰인다. 초창기에는 CGI, 그 이 후에는 Servlet, ASP, JSP, ASP, PHP등의 프로그램으로 사용되고 있다.

 

 

[ 웹 서버와 WAS(Web Application Server)의 구성에 따른 분류 ]

 

1.     기본적인 웹 사이트 구성

  

<그림 1> 웹 사이트의 가장 기본적인 구성 환경이다. 모든 콘텐츠를 한 곳에 집중시켜 웹 서버와 WAS의 역할을 동시에 수행한다. 사용자가 많지 않거나 트래픽이 적을 때 효율적이며 간단한 구조로 개발 및 테스트 시스템 구성시 활용의 가치가 높다.

 

장점 : 사용자 증가에 따라 스위치 장비를 통해 로드 밸런싱을 수행하고, 여러대의 WAS를 통해 지원이 가능하다. 필요시에 추가로 WAS를 증설하는 구조라고 볼 수 있다.

단점 : WAS가 정적인 데이터(HTML/Image)의 처리와 동적인 데이터(웹 애플리케이션)의 처리를 동시에 수행하기 때문에 최적화 측면에선 바람직하지 않다. 또한 정적데이터의 입출력 처리를 위해 웹 애플리케이션의 수행을 방해할 수 있고, 그 반대의 경우도 있다.

 

2.     웹 서버와 WAS로 구성된 환경

 


 
<그림 2>는 웹 서버와 WAS의 기능적 분류를 통해 효과적인 분산을 유도한 형태이다. 정적인 데이터는 구조적으로 앞에 존재하는 웹 서버에서 처리하고, 동적인 데이터는 뒷단의 WAS가 처리한다.

사용자의 요청에 대해서 정적 데이터인 HTML과 자바스크립트 파일, CSS, Image 등을 앞단의 웹 서버에 위치시켜 처리함으로써 WAS로 서비스 요청이 넘어가지 않게 한다.

또한 웹 애플리케이션 서비스를 위치적으로 뒤편에 존재하는 WAS에 넘겨줌으로써 WAS는 웹 애플이케이션의 수행이 집중할 수 있다.

웹 서버 단에서 처리할 것과 WAS에게 넘겨질 것을 처리하는 방식은 웹 서버 단의 Configuration을 통해 처리할 수 있다. 특정 확장자나 디렉토리 업무를 WAS로 넘길지 여부는 웹 서버 단에서 처리한다.


 

3.     특정기능에 대한 서버를 별도로 두고 있는 환경


 

점점 화려해지는 UI를 자랑하는 페이지들이 많아짐에 따라 이미지의 비중이 증가하고, 이런 이미지들이 전체 네트워크 비중의 상당부분을 차지한다. 따라서 이미지 서버를 따로 구성해 네트워크 비중도 줄이면서 웹 서버와 WAS를 좀 더 효과적으로 사용할 수 있는 구조라 할 수 있다.

또는 특정 콘텐츠에만 집중적인 요청을 받는 경우도 있다. 예를 들어, 대학 입시 때 경쟁률 조회는 상당히 많은 사용자에 의해 조회가 되고, Reload 또한 빈번하게 일어나므로 특정시간 간격으로 HTML을 생성하고, 페이지를 특정 서버에 위치시켜 적절하게 부하를 분산시켜 해결이 가능하다.

 

장점 : 다양한 환경에 대한 대처가 빠름

 

단점 : 구조를 정확하게 이해하지 않았을 경우에는 개발 및 테스트에 많은 시간이 쓰임

  

 

4.     WAS단을 Logic으로 구분하여 구성

 

      

 

        <그림 4> <그림 2>의 변경된 형태이다. WAS단의 프로그램이 많은 비중을 차지하는 경우, Presentation Logic을 담당하는 프로그램과 Business Logic을 담당하는 프로그램을 구분하는 구성이다.이런 구성은 특정 로직 부분의 부하에 따라 적절한 대응을 할 수 있으나 구조가 복잡해지는 단점이 있다.

  

 

[ WAS 관련 용어 정의 ]

 

1.     자바 서블릿(Java Servlet)

자바를 사용하여 웹페이지를 동적으로 생성하는 서버측 프로그램 혹은 그 사양을 말하며, 흔히서블릿이라고 한다.

        자바 서블릿은 Java EE사양의 일부분으로, 주로 이 기능을 이용하여 쇼핑몰이나 온라인 뱅킹 등의 다양한 웹 시스템이 구현되고 있다.

        비슷한 기술로는 펄 등을 이용한 CGI, PHP를 아파치 웹 서버 프로세스에서 동작하게 하는 mod_php, 마이크로소프트사의 IIS에서 동작하는 ASP 등이 있다. CGI는 요청이 있을 때마다 새로운 프로세스가 생성되어 응답하는 데 비해, 자바 서블릿은 외부 요청마다 프로세스보다 가벼운 쓰레드로써 응답하므로 보다 가볍다. 또한 자바 서블릿은 자바로 구현되므로 다양한 플랫폼에서 동작한다.

 

2.     엔터프라이즈 자바빈즈(Enterprise JavaBeans, EJB)

EJB는 기업환경의 시스템을 구현하기 위한 서버측 컴포넌트 모델이다. , EJB는 애플리케이션의 업무 로직을 가지고 있는 서버 애플리케이션이다. EJB사양은 Java EE의 자바 API중 하나로, 주로 웹 시스템에서 JSP는 화면 로직을 처리하고, EJB는 업무 로직을 처리한다.

EJB의 종류는 세션 빈(Session Bean), 엔티티 빈(Entity Bean), 메시지 구동 빈(Message-driven Bean)이 있다.

 

3.     자바 메시지 서비스(Java Message Service, JMS)

JMS는 자바 프로그램이 네트워크를 통해 데이터를 송수신하는 자바 API이다.

 

4.     자바 가상 머신(Java Virtual Machine, JVM)

JVM 자바 바이트코드를 수행할 수 있는 환경이다. 자바 바이트코드는 주로 자바를 컴파일하여 생성하지만, 다른 언어의 컴파일러에서도 생성할 수 있다. 자바 가상 머신은 자바 플랫폼의 기반을 이루며 다양한 하드웨어 기반 플랫폼에 포팅된다. JVM 자바 플랫폼의 주요한 부분이며 마이크로소프트 윈도(95/98/NT), 리눅스, 유닉스,  오에스  등 대부분의 운영체제는 물론, 인터넷 익스플로러와 넷스케이프 등과 같은 웹 브라우저 등 여러 가지 플랫폼에 설치되어 사용될 수 있으며, 휴대전화나 가전기기에도 설치할 수 있다. 따라서 자바 플랫폼은 여러 플랫폼을 지원하여 미들웨어로서의 역할과 플랫폼 스스로의 역할을 동시에 수행할 수 있다. 사용자는 자바 바이트코드로 컴파일된 자바 프로그램을 실행시키기 위해서 이 자바 가상머신을 이용하면 된다.

원 개발사인 썬 마이크로시스템즈에서 자바 가상 머신의 기준이 되는 표준판(Java SE) 과 표준판을 핸드폰이나 PDA 등 임베디드 기기용인 축소판(Java ME) 으로 구분하여 가상 머신을 배포하고 있다. 기업판(Java EE)의 경우에는 표준판의 자바 가상 머신을 기반으로 확장된 라이브러리 집합을 정의한 것이기 때문에 자바 가상 머신의 종류로 분류하기 애매하다.  마이크로시스템즈에서 제공하는 자바 가상 머신 말고도 각 운영체제 개발사가 제공하는 자바 가상 머신이 있으며, GNUGCJ 아파치 소프트웨어 재단(ASF: Apache Software Foundation) 하모니(Harmony)와 같은 오픈 소스 자바 가상 머신도 존재한다. 이러한 공개 소프트웨어 단체의 움직임에 따라 썬 마이크로시스템즈에서도 자사의 자바 가상 머신 및 개발 도구 킷을 오픈 소스 정책에 맞추어 공개한 상황이다.

 

5.     힙 메모리(heap memory)

프로그램을 사용할 수 있는 자유 메모리. 프로그램 실행 시에 함수로 보내는 데이터 등을 일시적으로 보관해 두는 소량의 메모리와 필요시 언제나 사용할 수 있는 대량의 메모리가 있다. 이때, 소량의 메모리를 스택이라 하고 대량의 메모리를 이라 한다.  이 없어지면 메모리 부족으로 이상 종료하게 된다.

 

6.     자바 서버 페이지(JavaServer Pages, JSP)

HTML내에 자바 코드를 삽입하여  서버에서 동적으로 웹 페이지를 생성하여  브라우저에 돌려주는 언어이다. Java EE 스펙 중 일부로  애플리케이션 서버에서 동작한다. 자바 서버 페이지는 실행시에는 자바 서블릿으로 변환된 후 실행되므로 서블릿과 거의 유사하다고 볼 수 있다. 하지만, 서블릿과는 HTML 표준에 따라 작성되므로 웹 디자인하기에 편리하다. 이와 비슷한 구조인 것인 PHP, ASP, ASP.NET 등도 있다. 아파치 스트럿츠 자카르타 프로젝트 JSTL 등의 JSP 태그 라이브러리를 사용하는 경우에는 자바 코딩없이 태그만으로 간략히 기술이 가능하므로 생산성을 높일 수 있다.

클라이언트에서 서비스가 요청되면, JSP의 실행을 요구하고, JSP  애플리케이션 서버의 서블릿 컨테이너에서 서블릿 원시코드로 변환된다. 그 후에 서블릿 원시코드는 바로 컴파일된 후 실행되어 결과를 HTML 형태로 클라이언트에 돌려준다.

 

7.     Java Database Connectivity(JDBC)

자바에서 데이터베이스에 접속할 수 있도록 하는 자바 API이다. JDBC는 데이터베이스에서 자료를 쿼리하거나 업데이트하는 방법을 제공한다. JDBC Java로 작성된 프로그램을, 일반 데이터베이스에 연결하기 위한 응용프로그램 인터페이스 규격입니다. 이 응용프로그램 인터페이스는 데이터베이스 관리 시스템에 넘겨질 SQL 형태의 데이터베이스 접근요구 문장을, 각 시스템에 맞도록 바꾸어준다. API는 동적으로 올바른 Java 패키지를 로드하고, JDBC 드라이버 매니저에 등록하기 위한 메커니즘을 제공합니다. 드라이버 매니저가, JDBC connection을 생성하기 위한 connection factory로서 사용됩니다.

 

8.     Java Management eXtensions(JMX)

응용 프로그램 소프트웨어/객체/장치 (프린터 등) 및 서비스 지향 네트워크 등을 감시 관리를 위한 도구를 제공하기 위한 자바 API이다. 이러한 리소스는 MBean(Managed Bean)이라는 객체로 표현된다.

 

9.     Java Naming and Directory Interface(JNDI)

디렉터리 서비스에서 제공하는 데이터 및 객체를 발견(discover)하고 참고(lookup)하기 위한 자바API이다.



'프로그래밍 > 웹 프로그래밍' 카테고리의 다른 글

HTML 기초  (0) 2016.02.21
비즈니스 로직(Business logic)?  (0) 2016.02.14
웹서버(Web Server) / 웹 서버 어플리케이션(WSA)  (0) 2016.02.14
웹 프로그래밍 기초  (0) 2016.02.14
ASP(Active Server Page)  (0) 2016.01.28
IIS란?  (0) 2016.01.25
Posted by GENESIS8

댓글을 달아 주세요


출처 : 

http://webcache.googleusercontent.com/search?q=cache:http://kbp.kongju.ac.kr/cg_edu/cnu/web_server_basic.htm&gws_rd=cr&ei=7fK_Vu-JJqiHmgWGq43oAg


http://j2enty.tistory.com/entry/JSP-Chapter1-%EC%9B%B9-%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D-%EA%B8%B0%EC%B4%88-2



 웹 서 버   구 축 을   위 한   기 초


웹서버(web Server)란 : 웹서버 간단히 웹을 서비스하는 컴퓨터라고 할 수 있다. 웹페이지는 HTML이므로 웹서버는 "HTML파일들을 모아놓고 서비스하는 컴퓨터"라고 할 수도 있다.  모든 컴퓨터는 서버가 될 수 있으므로 웹 서버가 될 수도 있지만, 어떤 컴퓨터를 웹 서버로 만드려면 먼저 웹 서버 프로그램을 설치해야 한다. 웹 서버 프로그램으로는 PWS, IIS, 아파치 등이 있다.


웹 클라이언트(Web Client)란 : 서버와는 상대되는 개념으로 클라이언트는 어떤 서비스를 요청하는 역할을 하게 된다. 그러므로 웹 클라이언트는 "웹 서버에 자료를 요청하기 위해 "HTTP"를 사용하는 클라이언트 프로그램"이라고 할 수 있다.  웹 페이지를 요청하는 것도 클라이언트라고 할 수 있다. 그런데 웹 페이지 요청은 대부분 웹 브라우저가 하게 된다. 그러므로 일반적으로 웹 클라이언트를 웹 브라우저라고 일컫기도 한다.  


서버 사이드(server Side)란 : 서버사이드(Sever-Side)란 간단히 "웹 서버측에서 하는 작업들"이라고 말할 수 있다.  여기서 말하는 작업이란 구체적으로 웹 브라우저(클라이언트)에서 넘어온 자료를 데이터베이스에 저장 한다든지, 어떤 수학적인 계산을 하여 결과를 만들어 낸다든지 하는 것을 말한다. 이런 작업을 담당하는 것이 웹 프로그램이다. 웹 프로그램의 종류는 PHP, ASP, Perl, Python등이 많이 쓰인다.


클라이언트 사이드(Client Side)란 : 웹 브라우저(클라이언트 사이드)를 사용하면 서버의 작업량을 줄일 수 있다. 서버가 작업해야 할 부분중에서 클라이언트가 할 수 있는 작업을 스스로 처리하기 때문에 서버의 작업량을 줄여줄 수 있어 효율적이다. 이렇게 "클라이언트 스스로 일을 처리할 수 있도록 하여 서버의 효율성을 높일 수 있도록 하는 것"이 클라이언트 사이드 언어이다.  클라이언트 사이드 언어로는 자바스크립트(Java Script)와 이외의 대부분의 스크립트 언어가 있다. 플래시 액션(Action) 스크립트도 클라이언트 사이드 언어라고 할 수 있다. 이런 스크립트 언어는 웹 서버에서 웹 브라우저로 전송된 후 실행된다.



■ 계열별 웹서버의 종류

- Windows : IIS, PWS, httpds, NCSA httpd For Windows, SerWeb, Web4Ham

- Unix, Linux : Apache, CERN httpd, NCSA httpd, EIT httpd, GN Gopher/http, Plexus perl server, WebWorks Enterprise server,

  Netsite Communication Server and Netsite Commercial Server

- Mac : MacHTTP

- NETWare : httpd nlm



■ 각 계열별 대표적인 웹서버

- Windows 계열 : IIS(Internet Information Services)

NT급에서 기본적으로 지원되는 웹서버로 ASP(Active Server Page)라는 개발 언어를 지원한다. 1995년 말 윈도우 NT용 웹서버로 출시 되었으며 윈도우 4.0이 출시되면서 IIS 2.0을 기본적으로 탑재 하였지만 얼마 후 ASP기술이 나오면서 IIS3.0이 새로 출시되었다. 윈도우 NT에서 IIS3.0이상 버전을 설치하기 위해서 별도의 OPTION PACK과 SERVICE PACK을 설치해 주어야 한다.

Windows 2000서버 및 Windows XP Pro에는 IIS 5.0이 포함되어있다.

- Unix, Linux 계열 : Apache, NCSA

아파치 프로젝트의 시작은 처음 1995년경 대중의 사랑을 받던 NCSA의 개발자중 일부가 모여 시작 했습니다. 이것을 시발로 NCSA HTTPD 개발자와 아파치 개발자들이 합류되고 이전에 만들어졌던 아파치 0.6.2를 완전히 개선한 0.8.8을, 그리고 아파치 1.0을 1995년10월에 만들어 냈습니다. 현재(2000년기준)는 60%이상의 사용자를 확보 하고 있다.


■ 웹서버 구축에 필요한 것들 (PHP, APACHE, MySQL)

- PHP(Professional HyperText Preprocessor) : 서버에서 해석되는 HTML에 내장되어 동작하는 스크립트 언어이다.  C, Java, Perl 등에서 많은 문장 형식을 빌려왔으며 웹 브라우저 등으로 실제 코드를 볼 수 없다는 것에 보안상 유리한 점도 있습니다. PHP와 ASP는 근본적으로 서버용 객체 지향적인 스크립트 언어라는 점에서 같지만, ASP의 경우 IIS, PWS와 같은 윈도우 환경에서 움직이는 서버를 지원하는데 반해 PHP는 Apache, IIS, PWS, 서버 등과 유닉스 윈도우 환경에서 움직이는 모든 서버를 지원합니다.

- APACHE : 대중의 힘을 바탕으로 가장 큰 인지도를 얻을 만큼 사용자가 이끌어 가는 무료 웹 서버입니다.

- MySQL : 무료 데이터베이스(DB)

 


웹 프로그래밍 기

1. 웹 어플리케이션과 웹 프로그래밍
 -.웹 어플리케이션 : 웹을 기반으로 실행되는 어플리케이션
 -.일반적으로 웹 브라우저에 기능을 요청하고 요청을 받은 웹 어플리케이션은 요청한 기능에 알맞은 결과 화면을 생성해서 웹   브라우저에 전송한다. 일반적으로 웹 브라우저가 요청한 기능을 제공하기 위해서는 웹 서버, 어플리케이션 서버, 데이터   베이스 와 같은 구성요소들을 필요로 한다. 



-.웹 서버 : 웹 브라우저의 요청을 받아 알맞은 결과를 웹 브라우저에 전송한다. 만약 프로그램의 처리가 필요하다면 어플리케이션 서버를 사용하거나 프로그램을 직접 호출하여 결과를 생성한다. 주로 정적인 HTML, CSS, 이미지 자바 스크립트를 웹 브라우저에 제공할 때 웹 서버가 사용된다. (아파치)

// IIS 등.
-.웹 어플리케이션 서버 (WAS): 게시글 목록, 로그인 처리와 같은 기능을 실행(처리)하고 그 결과를 응답으로 웹 서버에 전달한다.  (톰캣, 웹로직, JBoss 등) // ASP 등이 포함됨
-.데이터베이스 : 웹 어플리케이션이 필요로 하는 데이터를 저장한다. (오라클, MySQL, MS-SQL 등)
-.웹 브라우저 : 웹 서버에 서비스 실행을 요청하며 웹 서버의 처리 결과를 사용자에게 보여준다. (익스플로러, 크롬 등) 


 -.어플리케이션 서버도 웹 서버와 마찬가지로 정적인 HTML, CSS 등을 제공할 수 있다. 하지만 웹 서버에서 정적인 HTML, 이미지 등을 제공하고 어플리케이션 서버가 프로그램을 제공하는 이유는 성능 때문이다. 일반적으로 아파치와 같은 웹 서버는 정적인 HTML, CSS를 제공하는데 초점이 맞춰져 있고, 톰캣이나 웹 로직과 같은 어플리케이션 서버는 JSP, 서블릿과 같은 프로그램을 실행하여 결과를 제공하는 데 초점이 맞춰저 있기 때문이다.

1.1 CGI방식과 어플리케이션 서버 방식
 -. 웹 어플리케이션은 웹 브라우저의 요청을 알맞게 처리하고 그에 대한 결과를 웹 브라우저에 전달한다. 웹 어플리케이
션이 실행되는 과정은 아래의 그림과 같다. (요청-처리-응답)


 위 그림의 2번에서 웹 서버는 웹 어플리케이션 프로그램을 사용해서 우베 브라우저의 요청을 처리한다. 이 때 웹 서버가 웹 어플리케이션을 실행하는 방식에 따라서 CGI방식, 어플리케이션 서버 방식으로 동작방식을 구분할 수 있다.
(Common Gateway Interface, CGI : 웹 서버와 프로그램 사이에 정보를 주고받는 규칙을 의미. 흔히 CGI 프로그래밍이라고 하면 Perl, C/C++언어 등을 사용하여 웹 서버를 통해서 실행할 수 있는 프로그램을 의미한다.)

 CGI 방식과 어플리케이션 서버 방식간의 차이점웹 서버가 직접 프로그램을 호울하는지의 여부에 있다. 먼저 CGI방식은 웹 서버가 어플리케이션을 호출하는 구조를 갖는다. 이에 반해 어플리케이션 서버 방식은 웹 서버가 직접 프로그램을 호출하기보다는 웹 어플리케이션 서버를 통해서 간접적으로 어플리케이션 프로그램을 실행한다.
 접속자가 많은 서비스의 경우 CGI방식보다 어플리케이션 서버 방식의 성능이 좋게 나타난다. 그 이유는 CGI방식의 경우에는 요청 받은 기능이 같은 프로그램을 실행하는 경우라 하더라도 요청이 발생하는 숫자만큼 프로그램을 실행하기 때문에 메모리를 많이 차지하게 된다. 반면에 어플리케이션 서버방식의 경우에는 동시에 여러 웹 브라우저가 동일한 프로그램을 요청하더라도 한 개에 해당하는 메모리만 사용하기 때문에 전체적으로 사용하는 메모리가 적다. 
 
1.2 스크립트 방식과 실행 코드 방식
 웹 어플리케이션 프로그래밍은 구현하는 방식에 따라 실행 코드 방식과 스크립트 방식으로 구분할 수 있다. 

비교 항목 실행 코드 방식 스크립트 방식 
코드 형태  컴파일 된 실행 프로그램  컴파일 되지 않은 스크립트 코드 
실행 방식 컴파일 된 기계어 코드 직접 실행  스크립트 코드를 해석한 뒤 실행 
코드 변경  소스 코드를 다시 컴파일 해야 함  스크립트 코드만 고치면 됨 
종류  C기반 CGI 프로그램 JSP, ASP.net, PHP, Ruby ... 



-.스크립트 코드의 번역은 최초 요청에 대해서 한 번만 발생하며, 이후의 요청에 대해서는 번역 과정 없이 앞서 번역된 코드를 실행하도록 함으로써 번역 횟수를 최소화한다.
-.실행코드 방식의 경우 일반적으로 CGI방식이고 스크립트 코드 방식인 JSP나 ASP는 어플리케이션 서버 방식이기 때문에 전체 처리량에서는 JSP/ASP 기반의 스크립트 코드 방식이 앞선다.
-.기술의 발달로 스크립트 언어를 번역한 코드가 일반 프로그램과 동일한 수준의 성능을 제공하고 있다. 




2. URL과 웹 어플리케이션 주소
 -.사이트에 연결할 때 다음과 같은 형식의 주소를 웹 브라우저에 입력한다.
  이 주소는 자원을 구분할 때 사용되는 문자열로서 이런 문자열을 URL(Uniform Resource Locator)라고 부른다.

http://java.sun.com/javase/6/docs/api./index.html

[프로토콜]://[호스트][:포트][경로][파일명][.확장자][쿼리문자열] 

-.프로토콜 : 서버와 클라이언터의 통신 규약(http. https)
-.호스트 : 클라이언트가 접속할 서버 주소
-.포트 : 서버와 클라이언트가 통신할 때 사용할 포트. 일반적으로 입력하지 않으며 입력하지 않을 경우 기본포트(80)이 사용
-.[경로][파일명][.확장자] : 서버에서 가져올 자원의 위치를 입력하낟. 
-.[쿼리문자열] : 주소 뒤에 붙는 정보로 '파라메터'라고 불리는 데이터를 웹 어플리케이션에 전달할 때 사용된다. [쿼리문자열]은 물음표(?)를 이용하여 경로 부분과 구분되며 1개이상의 파라메터 이름과 값을 같는다. 



3. 자바와 웹 프로그래밍
3.1 서블릿과 JSP
 -.서블릿 : 자바를 개발한 Sun에서 웹 개발을 위해 만든 표준, 이러한 서블릿 규약에 따라 만든 클래스를 서블릿 이라 부름
 -.서블릿을 만들기 위해선 자바 코드를 작성하고 컴파일 하여 클래스 파일을 만들게 된다.(앞서 말한 실행코드 방식) 이런 방식은 데이터를 조금만 바꾸고 싶어도 코드를 수정하고 컴파일하고 클래스를 알맞는 곳에 복사해줘야 하는 작업을 해야한다.

 -.JSP : 위와 같은 서블릿의 단점을 보완하여 만든 스크립트 방식의 표준
 -.JSP는 서블릿 표준을 기반으로 만들어졌다. 때문에 내부적으로 JSP파일이 변역되면 최종 결과물로 서블릿이 만들어진다. 

3.2 JSP (JavaServer Pages) 란?
 -.자바 언어를 기반으로 하는 스크립트 언어로 자바가 제공하는 기능을 그대로 사용 할 수 있다.
 -.HTTP와 같은 프로토콜에 따라 클라이언트의 요청을 처리하고 응답한다.
 -.HTML, XML등 클라이언트가 요청한 문서를 생성하는 데 주로 사용된다.
 -.서블릿/EJB등의 엔터프라이즈 기술들과 잘 융합된다.
 -.표현언어, 표현식, 스크립트릿 등 다양한 스크립트 요소와 액션 태그 등을 제공함으로써 보다 쉽게 웹 어플리케이션을 프로그래밍 할 수 있도록 도와준다.

3.3 웹 컨테이너(Web Container)
 -.웹 컨테이너 : 이름 그대로 웹 어플리케이션을 실행 할 수 있는 컨테이너.
 

JSP 컨테이너 + 서블릿 컨테이너 = 웹 컨테이너

현재 서블릿 규약의 버전은 2.5이고, JSP 규약 버전은 2.1이다. 이 두 규약의 버전 차이에서 알 수 있듯이 서블릿 규익이 먼저 발표되고 그 후 JSP규익이 발표되었다. 처음 서블릿 규약이 발표되었을 때는 JSP가 존재 하지 않았기 때문에 서블릿이 실행 가능한 서버를 서블릿 컨테이너라고 불렀으며 이후 JSP 규약이 발표될 때는 서블릿과 구분하는 의미에서 JSP가 실행 가능한 서버를 JSP 컨테이너 라고 불렀다. 하지마 이 후 거의 모든 엔진이 서블릿과 JSP를 동시에 지우너하면서 이 두 컨테이너를 구분하는게 무의미 해졌으며, 이 후 부터는 서블릿 컨테이너와 JSP 컨테이너를 웹 컨테이너 라고 부르기 시작했다.


3.4 JSP를 사용하는 이유

-.자바 언어를 기반으로 하고 있기 때문에 플랫폼에 상관없이 사용할 수 있다.
-.자바 언어에 대한 깊은 이해가 없더라도 빠르게 배울 수 있다.
-.대규모 어플리케이션을 구현 할 때 사용되는 스프링, 스트럿츠와 같은 프레임워크와 완벽하게 연동되며, 금융권에서 많이 사용하는 EJB기술과도 완벽하게 연동된다. 






'프로그래밍 > 웹 프로그래밍' 카테고리의 다른 글

HTML 기초  (0) 2016.02.21
비즈니스 로직(Business logic)?  (0) 2016.02.14
웹서버(Web Server) / 웹 서버 어플리케이션(WSA)  (0) 2016.02.14
웹 프로그래밍 기초  (0) 2016.02.14
ASP(Active Server Page)  (0) 2016.01.28
IIS란?  (0) 2016.01.25
Posted by GENESIS8

댓글을 달아 주세요