IT'S 모든 것

소프트웨어 아키텍처 평가기법

소프트웨어 또는 시스템을 구축하기 위해 가장 중요한 것이 아키텍처죠!

아키텍처에는 시스템의 특성, 요구사항 등을 해결하기 위한 전략과 제약사항 포함되어야 겠죠.

이번에는 이렇게 힘들게 만든 아키텍처가 잘만든 것인지에 대한 평가를 위한 평가기법에 대해 알아 보겠습니다.

1. 소프트웨어 아키텍처 평가기법의 개요

1) 소프트웨어 아키텍처(Software Architecture) 평가기법이란?

 - 아키텍처의 접근법이 품질속성(보안, 성능, UI 등)에 미치는 영향을 판단하여 아키텍처 적합성을 판단 및 평가하는 표준기법

2) 소프트웨어 아키텍처 평가기법 유형

2. 평가기법 관계도 및 평가기법 설명

1) 평가기법 관계도

2) 평가기법 설명

 가. ATAM(Architecture Tradeoff Analysis Method)

 - 아키텍처의 품질속성에 초점을 맞춘 평가기법으로 품질속성 간의 상충관계를 평가

 - 특징

   -> 명확한 분석, Legacy System 분석에 활용가능

   -> 비기능적 요구사항(신뢰성, 사용성, 유지보수성 등) 중심분석

   -> 아키텍처 스타일, 품질속성은 SAAM 영향을 받음

 나. CBAM(Cost Benefit Architecture Method)

 - 아키텍처의 경제적 측면에 초점을 맞춘 평가기법

 - 특징

   -> ATTAM의 결과물을 기반으로하여 아키텍처의 경제성을 분석

   -> ROI 측면의 의사결정을 위한 기준 제시

 다. SAAM(Software Architecture Analysis Method)

 - 사용자의 요구사항 시나리오와 아키텍처 간의 매핑을 통한 적합성 분석

 - 특징

   -> 아키텍처의 Modifiability와 Functionality 집중분석

   -> 평가 경험이 없는 조직에서도 활용가능

 라. ADR

 - 아키텍처의 구성요소 간의 응집도를 평가하는 기법

 마. ARID(Architecture Reviews for Intermediate Design)

 - 전체 아키텍처가 아닌 특정 부분에 대한 품질요소에 집중하여 평가

Application Layer 집중탐구

주요구성 요소

• Web Server : 웹 브라우저와 같은 클라이언트로부터 HTTP 요청을 받아들이고, HTML 문서와 같은 정적 웹 페이지를 반환하는 SW/HW를 총칭

• WAS(Web Application Server) : Java EE 명세를 만족하는 JAVA 구현체로 크게 두 가지로 구분할 수 있다. Java EE 명세를 대부분 지원하고, 다양한 형태의 모듈로 배포가 가능한 고가의 WAS와 웹 모듈의 배포만 가능한 경량 WAS 또는 서블릿/JSP 컨테이너다. 경량 WAS의 대표적인 예로 Tomcat이 있다.

※ Java EE 주요 명세(Specification)를 잠깐 보고 넘어가자!

• Servlet : HTTP를 사용해 JAVA로 웹 서비스를 제공하기 위한 표준

• JSP(Java Server Pages): JAVA 코드에 HTML 태그를 삽입하는 Servlet 방식의 문제점을 개선하기 위해 HTML태그에 Java 코드를 삽입할 수 있는 표준으로 JSP가 처음 실행될 때 Servlet/JSP 컨테이너가 JSP를 Servlet으로 컴파일시켜서 내부적으로는 Servlet으로 동작합니다

• EJB(Enterprise Java Beans) : Java에서 제공하는 분산 컴포넌트 기술로 비즈니스 로직이나 데이터, 메시지를 처리할 수 있습니다

• Remote Method Invocation(RMI): 프록시를 써서 원격에 있는 Java 객체의 메소드를 실행시키기 위한기술입니다

• Java Naming Directory Interface (JNDI): 자바 기술로 만들어진 객체에 이름을 붙여 찾을 수 있도록 단일한인터페이스를 제공

• Java Database Connector(JDBC): 여러 종류의 데이터베이스 시스템에 접근하는 단일한 인터페이스를 제공합니다. 각각의 데이터베이스에 맞는 JDBC 드라이버가 있어야 합니다

• Java Connector Architecture(JCA): 이기종 플랫폼을 통합할 수 있도록 플랫폼 독립적인 인터페이스를 제공합니다

• Java Message Service (JMS): 여러 가지 메시징 시스템에 대한 플랫폼 독립적인 인터페이스를 제공합니다

경량 WAS의 핵심 기술 서블릿과 서블릿 컨테이너

▶ Servlet(서블릿)

• JAVA로 웹 서비스를 구현하기 위한 SUN사의 표준 스펙

• 독립적으로 실행되지 않으므로 main 메소드가 존재하지 않는다

• 서블릿 컨테이너에 의해 생성(init), 호출(service), 소멸(destory) 즉, 서블릿 컨테이너가 서블릿의 상태를 변경하면서 서블릿 인터페이스에 정의된 각 메소드를 호출

▶ 서블릿 컨테이너

• Client의  HTTP 요청을 받고 분석하여 Servlet을 실행시키는 역할을 수행

• 네트워크 통신, 서블릿의 생명주기 관리, 스레드 기반의 병렬처리

웹 애플리케이션과 배치(Deployment)

▶ 웹 애플리케이션

일반적으로 WEB-INF 디렉토리를 가지며, 최상위 디렉토리는 해당 웹 컨텍스트의 최상위 문서 루트가 되고, WEB-INF 디렉토리 아래 web.xml에 서블릿 설정 파일이 존재하며, 독립적인 클래스 로더를 공유하는 웹 프로그램의 모임

▶ 배치(Deployment)

위에서도 설명했지만 배치(Deploy)는 웹 애플리케이션을 서블릿 컨테이너가 인식할 수 있도록 컨테이너 내부로 끌어들이는 과정을 말한다.

위에서 배운 지식을 활용하여 HTTP요청이 Servlet에 전달되는 과정을 보면

▶ Servlet 상속구조 관점에서 HTTP 요청 처리과정

[그림1]

Client 호출 URL 분석

Servlet 상속구조 관점에서 HTTP 요청 처리과정

web.xml

1
2
3
4
5
6
7
8
9
10
web.xml 파일의 서블릿 설정 부분
<servlet>
   <servlet-name>myServlet</servlet-name>
   <servlet-class>MyServlet</servlet-class>
</servlet>
<servlet-mapping>
   <servlet-name>myServlet</servlet-name>
   <url-pattern>myServlet.do</url-pattern>
</servlet-mapping>
 
Colored by Color Scripter
c

▶ 웹 애플리케이션 구조 관점에서 HTTP 요청 처리과정

[그림2]

Web 환경의 이해

Web Framework(Struts, spring 등)가 대중화 되면서 SW의 생산성은 향상되었지만, 웹 서비스를 위해 1997년 SUN에서 제안한 Servlet, Servlet을 배치(Deploy) 및 실행하는 Servlet Container 즉, 웹 환경에 대한 이해의 필요성은 점점 줄어들어 졌습니다.

웹 프레임워크에서 제공하는 기능은 서블릿 컨테이너 위에서 동작하는 서블릿, 필터, 리스너 등을 조합하여 구현한 것이며

웹 애플리케이션은 결국 서블릿 컨테이너 위에서 동작하므로, 서블릿 컨테이너에 대한 이해가 웹 환경에서 가장 중요한 부분입니다.

기본에 충실하다면 빠르게 변해가는 IT(Web) 환경을 따라갈 수 있을거라는 바람으로 웹 환경에 대해 정리해봅니다. 그리고 웹 프로그래밍을 처음 시작하는 분들에게 유익한 정보가 되었으면 합니다.

Web 환경의 기본 아키텍처(3-Tier)

그림[3-Tier 아키텍처]과 같이 Web은 3-Tier 구조를 기본으로 합니다. message를 주고 받기위한 Layer가 3개라는 의미입니다. 또는 message를 주고 받기위한 Network node가 3개라 이해하셔도 될 것 같습니다. 모든 요청 및 응답 메시지는 반드시 Application Layer(Middleware)를 거쳐 가도록 설계되어 있어 대부분의 환경설정은 Application Layer에서 이루어집니다.

• Middleware : 송/수신자 사이에서 메시지를 전달하는 중계자로(Broker) 데이터 포맷 변환, 로드 밸런싱, QoS(Quality Of Service)등을 수행하여 플랫폼의 독립성을 지원하는 소프트웨어

• MVC(Model-View-Controller) : MVC 아키텍처는 View의 변화에 대한 Model의 영향도를 줄이기위한 SW 아키텍처 스타일로 그림[3-Tier 아키텍처]의 Application Layer에서 구현됩니다.

[3-Tier 아키텍처]

요청에서 응답까지의 흐름을 간단하게 설명하고 각 Layer에 대한 설명으로 넘어가겠습니다.

1. 사용자가 Web Browser에서 요청 URL을 입력하거나 이벤트(조회 버튼 클릭 등)를 발생

2. Web Browser는 요청 Message를 HTTP 메시지로 변환하여 Web Server에게 전달

3. Web Server는 요청을 수락하고 HTTP 요청 URL을 분석하여 정적 페이지(HTML, Javascript, CSS 등) 요청이면 Web Server 자신이 처리를 하고 Business Logic 처리가 필요하면 WAS에게 다시 전달

4. WAS는 Database에 접속하여 데이터 Insert, Update, Delete, Select 작업을 완료 후 요청과 같은 Chanel로 처리결과(응답 메시지)를 Web Browser에게 돌려준다

5. Web Browser는 응답 메시지를 파싱 및 렌더링하여 사용자에게 보여준다.