프로젝트 계획(11-2) 미들웨어 [소프트웨어공학]

이번에는 미들웨어를 알아보자

 

미들웨어 딱 들으면 뭔가 중간에 있는 ?? 그런 느낌이 난다 

 

진짜인지 아닌지 알아보자

 

---

소프트웨어 아키텍쳐는 빌딩 아키텍쳐와 비슷하다고 말하곤 하는데

 

빌딩을 설계할 때 여러 각도에서 설계도를 작성하고 빌딩의 구조와 기하학 및 특성을 나타내도록 한다.

다시 말해서 설계는 요구를 기초로 건축 공간, 기능, 미학적 또는 기능적 품질 , 예산을 고려해서 표현한다.

 

설계도를 이제 정말 시공회사가 건축할 수 있을 정도로 바꾸려면 더 많은 작업이 필요한데

예를 들어서 벽, 바닥 레이아웃, 계단, 전기 시스템, 수도 등등 추가로 설계할 것들이 엄청나게 많다.

 

위에 설명을 왜 했느냐???

 

다 미들웨어를 설명하기 위해서 했다.

 

미들웨어를 건축에 비유하자면 배관이나 배선에 해당하는 부분이라고 할 수 있다.

 

이유는 여러가지가 있다.

 

대표적으로 미들웨어는 소프트웨어 컴포넌트를 연결하기 위한 준비된 인프라 구조를 제공한다. 

 

다시 나눠서 말하자면

 

다양한 애플리케이션에 적용 가능하고
일반적이며 환경에 따라 바꿀 수 있는 융통성을 가짐
미들웨어는 애플리케이션의 여러 컴포넌트들을 연결하는 증명된 방법을 제공한다.
미들웨어는 여러 컴포넌트를 1대1, 1대 다, 다대 다 등 여러가지 연결 형태로 연결하는데 유용하게 사용된다.
사용자는 애플리케이션과 상호작용한다.
미들웨어 역할을 알아야 하는 유일한 경우는 고장이다.

 

 

---

 

 

?? 그래서 뭐 어쩌냐고?

 

우리가 미들웨어의 역할을 알아야 하는 이유는 고장이라고 설명했지만

우리는 배우는 사람이니까 알아봐야할거 아녀 ㅎㅎ

 

 

 

실제 미들웨어는 정말 다양한 기술을 사용하고 있는데

 

트랜스포트가 기초라서 트랜스포트부터 설명해보자면

 

1. 트랜스포트

소프트웨어 컴포넌트 사이에 요구를 보내고 데이터를 이동하기 위한 기본파이프 역할을 한다. 파이프는 분산 애플리케이션 아키텍쳐에서 데이터를 직접 교환하는 메커니즘을 제공한다.

 

2. 애플리케이션 서버

기본 트랜스포트 층 위에 구축되고 트랙잭션, 보안, 디렉토리 서비스와 같은 기능을 제공한다.

또한 멀티 스레드 서버 기반의 애플리케이션을 구축하기 위한 프로그래밍 모델도 제공한다.

 

3. 메시지 브로커

기본적인 트랜스포트 + 애플리케이션 서버를 이용해 메시지 처리 엔진을 추가시킨 것으로 빠른 메시지 전달을 위한 기능과 애플리케이션 컴포넌트 사이에 메시지를 교환하고 라우팅하는 방법을 정의하는 언어 기능을 제공한다.

 

4. 비즈니스 프로세스 관리자

메시지 브로커 기능에 워크플로 스타일 애플리케이션을 지원하기 위한 기능을 추가한 것으로 특정 작업을 수행하기 위하여 사람이 동원되어야 하므로 끝내는 데 시간이 많이 걸릴 수 있다. 

++ 중간 상태를 관리하는 도구를 제공한다.

 

 

 

그냥 그러한 기술들이 있구나?? 알고 지나가자

 

---

따로 기술을 분리해서 알아보려고 했지만 얘도 너무 복잡하기에

++글 쓰려니까 ... 쓰면 복잡할 것 같아서

 

살짝만 알고가자

 

 

바로 분산 객체라는 것이다

 

분산 객체 기술은 미들웨어 기술 중의 하나이다. CORBA로 알려진 분산객체 기술은 1990년대부터 사용 되었다.

 

CORBA에서는 서버 객체가 CORBA IDL (Interface Definition Language)을 이용하여 기술한 인터페이스를 지원한다.

 

 

IDL 인터페이스는 파라미터와 리턴 타입과 함께 서버 객체가 지원하는 메소드를 정의한다. 

살짝 예를 들자면

 

 

module ServerExample{
        interface MyObject
        {
                String isAlive();
        };
};

 

더 설명하고 싶지만.. 생략

 

---

차라리 메시지 중심 미들웨어를 더 설명해보겠다.

 

메시지 중심 미들웨어(Massage-Oriented Middleware) 는 대규모 엔터프라이즈 시스템을 구축할 때 중요한 기술이다.

서로 다른 독립적인 애플리케이션을 하나의 통합된 시스템으로 묶기 위한 접착제 같은 역할을 한다.

 

 

++ 여러 가지 애플리케이션을 다양한 기술과 다양한 플랫폼을 이용하여 구축할 수 있다.

 

**그렇지만 메시지 기반 미들웨어를 사용하면 사용자는 현재의 애플리케이션을 엔터프라이즈급의 애플리케이션에 추가하기 위하여 다시 구축하거나 근본적인 변경을 가할 필요가 없다.

 

++왜냐하면 송신측과 수신측 사이에 큐를 놓고 통신하는 동안 간접참조를 제공함으로써 해결가능하기 때문이다.

 

 

 

 

 

메시지 중심 미들웨어는 기본적으로 느슨한 결합의 비동기 기술이다.

++메시지의 송신측과 수신측이 강하게 결합되어 있지 않다.

 

**동기화 미들웨어 기술을 많은 강점이 있지만 모든 컴포넌트와 네트워크 연결이 동시에 성공적으로 작동되고 있어야 한다는 점 때문에 취약한 설계가 될 수 있다.

 

그래서 메시지 인프라 구조는 아래처럼 설계를 한다.

 

메시지 큐를 중간에 두어 송신측과 수신측이 느슨하게 연결되도록 한다.

 

** 송신측에서는 메시지큐에 메시지만 보내면 자기 일은 끝이다. 수신측이 받았는지는 모른다.

모든 것을 큐에 맡긴다.

 

 

기본적이 메시지 중심 기술로는 엔터프라이즈 애플리케이션에 응용하기 위해 충분치 않다.

그러려면 메시지 전달과 성능이 보장되어야만 한다.

 

따라서 사용메시지 중심 미들웨어 제품들을 서버의 신뢰성, 사용성, 확장성을 높인 추가기능을 제공한다.

 

지금까지 메시지 중심 미들웨어는 1 대 1 통신을 기초로 했지만

多 대 多 통신을 가능하게 하기 위해서 기본 MOM(Message-Oriented Middleware) 을 확장해서

Publish-subscribe 메시지도 제공한다

 

즉 구독자만 메시지를 수신할 수 있게하는 것이다. 

 

**이는 브로드캐스팅이 가능해져서 메시지 대기 시간이 짧아지고 메세지 처리량이 많아진다.

 

---

하나 더 알아볼 기술을 애플리케이션 서버다.

 

뭔데 위에서 그렇게 많이 나오나 궁금했을거다

아님말고..

 

애플리케이션서버라는 건

 

N-tier 아키텍처의 중간층에 위치하면서 분산 통산, 보안, 트랜잭션, 영속성을 제공하는 컴포넌트 기반의 서버 기술

 

++인터넷 기반의 애플리케이션을 구축하는 데 널리 이용

 

 

여기도 앞에 메시지 중심 미들웨어 같이 층이 많구나??

 

하나하나 알아볼까??

 

 

1. 클라이언트층

 웹 애플리케이션에서 클라이언트 층은 HTTP 요청을 제출하고 웹 서버로부터 HTML 페이지를 다운받는 인터넷 브라우저로 구성되는데 이 부분은 애플리케이션 서버의 일부가 아니라 브라우저 상품이라고 한다.

 

2. 웹층

클라이언트의 요청을 다루기 위하여 웹 서버에 실행되고 요청의 오면 웹 서버는 서브릿, JSP, ASP와 같은 웹 서버 호스트 컴포넌트를 구동시킨다. 유입되는 요청은 호출될 웹 컴포넌트를 정확히 식별한다. 요청된 파라미터를 처리하여 원하는 정보를 가져올 수 있는 비즈니스 로직층을 호출한다. 

++다음에 웹 컴포넌트는 사용자에게 리턴할 결과를 HTML 같은 태그로 포맷팅한다.

 

3. 비즈니스 컴포넌트층

애플리케이션을 위한 핵심 비즈니스 로직으로 구성된 층으로 비즈니스 컴포넌트는 JEE의 EJB, NET, CORBA 객체로 구현할 수 있다. 비즈니스 컴포넌트는 웹층으로부터 요청을 받아 이를 만족시키기 위하여 하나 이상의 데이터 베이스에 접근하고 그 결과를 다시 웹층으로 리턴한다.

 

4. 엔터프라이즈 정보 시스템층

하나 이상의 데이터베이스나 메인 프레임과 같은 백엔드 애플리케이션, 또는 다른 레거시 시스템으로 구성된다. 비즈니스 컴포넌트는 요청을 처리하기 위하여 데이터 저장소에 질의하고 상호작용한다.

 

 

++ 부가설명

 

JEE에서 지원하는 EJB모델로 살짝 설명해보자면... 많으니까 살짝만 설명하고 마치자

 

 

 

 

세션 빈(session bean) 은 일반적인 비즈니스 로직을 나타낸다.
세션 빈은 두 가지 종류, 상태 없는(State-less)세션 빈과 상태(Stateful) 세션 빈이 있다.

 

 

 

 

정말 살짝만 건드렸음 ㅎㅎ

 

 

---

마지막으로 아키텍쳐를 거의다 배웠으니 

지금까지한 아키텍쳐를 문서화 하는 작업인 설계 문서화 작업을 알아보려고 한다.

 

 

아키텍쳐 문서를 작성하는 이유는 2가지가 있다.

1. 설계자나 설계팀이 더 좋은 설계 결정을 내리는데 도움을 준다

2. 다른 사람과 설계에 대하여 이야기를 할 수 있다.

 

**문서화 하지 않으면 맨날 가서 설명할 것도 아니고 ... 어떻게 전달할거야???

 

문서를 누구하고 공유할 것이냐고??

 

1. 설계를 구현할 사람 즉 프로그래머
2. 미래에 설계를 변경할 엔지니어
3. 설계된 시스템과 인터페이스 할 다른 시스템 또는 서브시스템을 개발하는 엔지니어

 

 

 

설계 문서는 일반적으로 몇가지 정보를 포함시킨다.

실제 적용하는 프로젝트에서 환경에 맞는 보다 자세하고 일관된 포맷을 사용하여야 할 것이다.
 
(1) 목적

문서가 기술하는 대상이 무엇인지?

(2) 우선순위

설계 작업 과정을 설명할 우선순위 기술을 해야한다.

 

(3) 설계의 아웃라인

개괄적인 소개를 하기 위해 최상위로 추상화된 설계를 제시해야한다.

(4) 설계 이슈

해결되어야 할 이슈를 논의한다.

(5) 설계 상세 사항

아직 언급하지 않은 것 중에 꼭 알아야 하는 것들을 기술한다.

예를 들어서 자료구조와 알고리즘, API사용법 등

 

설계문서에서 제외할 사항
1. 훈련된 프로그래머나 설계가에게 당연한 것으로 여겨지는 정보를 문서화하는 것은 피한다.

//이미 알고 있는 것을 말하는 것은 추상화에 어긋난다

2. 코드의 코멘트(주석) 안에 포함되어 있는 것이 더 좋을 내용은 설계 문서에서 피한다.

// 거기서 충분히 언급될 예정이니까.

3. 코드에서 자동으로 추출될 내용, 예를 들면 public 메소드의 리스트는 설계문서에서 제외한다.

//당연한 내용은 뺀다.