2. SOA 라이프 사이클
상태바
2. SOA 라이프 사이클
  • 승인 2006.03.12 00:00
  • 댓글 0
이 기사를 공유합니다

Tech Guide - SOA
SOA 라이프사이클, 빠른 투자효과의 기본
모델링·조립·운영 단계 거쳐 … 융통성 있는 비즈니스 첩경

지난호에서는 SOA의 개념과 정의에 대해 알아봤다. 1부에서 빠르게 변화하는 기업 환경에 유연하고 융통성 있게 대처하기 위해 제안된 SOA의 가치와 대략적인 구현단계를 알아봤다면 이번호에서는 SOA의 라이프사이클에 대해 구체적으로 살펴본다. <편집자>

연재순서
1. SOA 는 무엇인가?
2. SOA 라이프 사이클
(이번호)
3. SOA, 어떻게 시작하는가?

정해영
한국IBM 웹스피어 마케팅 부장
hyjeong@kr.ibm.com

SOA를 구축, 구현, 관리하고 기존 프로젝트 성과를 바탕으로 프로젝트를 쉽게 이행해 빠른 투자 효과와 높은 가치를 실현하기 위해서는 효율적인 통합 솔루션이 필요하다. 기업들은 다양한 출발점에서 SOA에 접근하지만 IBM이 경험한 바에 의하면 엔터프라이즈 아키텍처에서 서비스를 전개하는 과정에서는 SOA 라이프 사이클 개념이 적용된다.
먼저 비즈니스 요구 사항을 수집하고, 시뮬레이션을 통해 원하는 비즈니스 프로세스를 설계, 최적화하는 ‘모델링’ 단계에서 시작한다. 비즈니스 프로세스가 최적화됐다면, 신규 서비스와 기존 서비스를 결합함으로써 반복적인 재사용이 가능한 컴포지트 애플리케이션을 구성하는 ‘조립’ 단계가 이어진다. 이 자산은 안전한 통합 환경에서 ‘운영’돼 사람, 프로세스 및 정보의 통합을 지원하는 전문화된 서비스를 활용하게 된다.
운영 단계가 완료되면 기업은 컴포지트 애플리케이션 및 그 기반 자원을 IT/비즈니스 관점에서 관리하고 모니터링 한다. 관리 단계에서 수집된 정보는 비즈니스 프로세스를 실시간으로 파악하면서 더 나은 의사 결정을 내리는 데 활용될 뿐 아니라 다시 라이프 사이클에 투입돼 지속적인 프로세스 개선을 가능하게 한다. SOA 라이프 사이클 단계를 살펴보면 다음과 같다.

모델링
지금까지 전통적인 애플리케이션 개발은 현업의 요구사항을 받아서 이를 분석, 디자인 하고 애플리케이션을 작성, 테스트 한 후에 운영하고 이를 모니터링해 현업의 요구사항이 제대로 반영됐는지를 확인했다.
항상 현업의 요구사항을 시스템 구축에 반영하려는 노력이 있었지만 여전히 현업의 요구사항과 실제 구현된 IT 시스템 사이의 간극은 발생한다. 이러한 간극이 발생하는 가장 큰 이유는 현업 요구를 IT에서 개발하기 위한 모델 작성을 하는 개발 담당자가 현업 업무에 대한 지식이 많지 않기 때문이다.
SOA는 비즈니스 드리븐 디벨로프먼트(Business Driven Development)를 통해 현업의 요구사항과 IT 시스템 개발 사이에 존재하는 간극을 최소화하는 방안을 제공한다. 현업과 IT사이의 간극을 최소화 하는 방안은 현업이 직접 요구사항을 반영한 비즈니스 모델을 디자인 하게 하는 것이다. 비즈니스 모델을 현업이 직접 작성함으로써 요구사항이 가장 잘 반영되고 이렇게 디자인된 비즈니스 모델이 툴에서 자동으로 코드를 생성해 IT 개발자가 사용하는 개발 툴로 그대로 반입, 애플리케이션으로 만들어 지면 전통적인 방식에의 현업 요구사항을 제대로 반영하지 못하는 위험성을 상당히 낮추면서 개발할 수 있게 된다.
좀더 구체적으로 살펴보면, 현업 사용자가 SOA를 위한 비즈니스 모델링 툴을 사용해 요구사항을 반영한 비즈니스 모델을 그린다. 이렇게 작성된 비즈니스 모델은 우리가 흔히 볼 수 있는 플로우 차트의 모양을 가진다.
기존 플로우 차트 작성 툴로 작성된 결과물은 IT 개발 단계로 가면 다시 IT 전문가에 의해 디자인돼야 한다. 이때가 바로 현업 요구와 IT 개발 사이에서의 의도가 충실히 반영되지 못할 수 있는 순간이 된다.
SOA 모델링 툴이 기존 플로우 차트 작성 툴과 다른 점은 현업 담당자가 그린 플로우 차트 그림이 바로 SOA의 핵심 표준 중의 하나인 BPEL(Business Process Execution Language) 컴포넌트를 자동으로 생성하고 UML 형태로 변환돼 IBM 래쇼날 로즈(Rational Rose) XDE 같은 IT 모델링 툴로 즉시 반입이 될 수 있다. 이런 과정이 전통적인 방식에서의 현업 요구 반영이 안 되는 위험성을 없앨 수 있다.
또한 SOA 모델링 툴은 시뮬레이션 기능을 통해 미리 정의된 비즈니스 프로세스의 유용성을 확인할 수 있다. 기존의 애플리케이션 개발 방식은 현업의 요구사항이 제대로 반영되었는지 확인하기 위해서는 개발, 테스트, 운영을 거쳐 모니터링을 해야만 그 결과를 알 수 있다.
결과가 비즈니스 모델을 수정하는 것이라면 다시 IT 개발자가 현업의 요구사항이 제대로 반영되지 않은 부분을 찾아내 수정한 후 테스트, 운영, 모니터링을 거치는 과정을 반복하게 된다. 이러한 방식은 비용과 시간이 많이 들어서 적시에 요구하는 서비스를 제공할 수 있는 가능성을 상당히 떨어뜨리게 된다.
SOA 모델링 툴은 기존 방식과는 달리 모델링 툴에서 만들어진 비즈니스 프로세스 모델을 개발에 들어가기 전 미리 시뮬레이션을 해 기존 비즈니스 프로세스에 비해서 얼마나 프로세스가 향상됐는지를 확인할 수 있고 다양한 형태의 비즈니스 프로세스 모델을 미리 시뮬레이션을 함으로써 가장 최적의 비즈니스 모델을 찾아낼 수 있게 도와준다. 따라서 최소한의 비용과 시간을 투입, 최적의 SOA 애플리케이션을 만들어 낼 수 있는 방법을 제시해 준다.

조립-컴포지트 애플리케이션 작성
SOA 애플리케이션은 컴포지트(조립) 애플리케이션이라 부른다. SOA 애플리케이션 개발은 두 방향에서 시작된다. 비즈니스 영역에서부터 시작하는 부분은 비즈니스 업무를 프로세스를 정의하고 이들 비즈니스 프로세스를 기본적인 기능을 하는 업무 단위인 서비스로 정의한다.
IT 영역에서는 기존 애플리케이션을 분석해 컴포넌트화 하거나 없는 컴포넌트를 새롭게 작성한다. 이 두 방향에서 시작된 개발은 정의된 서비스와 컴포넌트를 조립해 실행될 수 있는 SOA 애플리케이션을 만들어 낸다.
<그림 1>에서 보듯 SOA 애플리케이션은 비즈니스 영역과 IT 컴포넌트 영역에서 별개로 진행된다. 처음에 업무 분석가가 비즈니스 프로세스 모델을 정의하면 이를 받아서 비즈니스 영역에서는 정의된 비즈니스 프로세스 모델을 표준 기반의 BPEL(Business Process Execution Language) 컴포넌트를 만든다. 한편 IT 개발자가 진행하는 IT 컴포넌트 개발 부분에서 보면 업무 분석가가 정의한 비즈니스 프로세스 모델을 가지고 서비스를 정의하고 컴포넌트 모델을 만든다.
이렇게 만들어진 서비스 정의와 컴포넌트 모델을 가지고 EJB, 웹 서비스, 자바 컴포넌트 등을 만든다. 이 과정은 비즈니스 영역에서 BPEL 컴포넌트를 만드는 과정과 동시에 진행된다. 컴포넌트-BPEL 컴포넌트와 IT 컴포넌트(EJB, 자바 컴포넌트 등)는 통합 개발자에 의해 조립돼 실제 SOA 애플리케이션으로 만들어져 SOA 애플리케이션을 컴포지트(조립) 애플리케이션으로 부른다.
현업 업무 전문가가 작성한 BPEL 컴포넌트와 자바 또는 .NET 기술을 통해 만들어진 IT 컴포넌트를 통합 개발자 역할을 담당한 사람이 컴포지트 애플리케이션을 조립하는 툴을 사용해 서로 매핑시켜 주는 역할을 한다. 컴포지트 애플리케이션이 비즈니스 컴포넌트와 IT 컴포넌트로 구성돼 있기 때문에 SOA는 유연성을 가질 수 있다.
비즈니스 환경이 변화돼 현재 비즈니스 프로세스가 바뀌어야 한다면, 현업 업무 전문가가 비즈니스 프로세스를 변경하고 이를 바로 BPEL 컴포넌트로 생성하면, 이미 만들어 놓은 서비스 또는 컴포넌트를 이 새로운 BPEL 컴포넌트에 결합해 바로 새로운 기능을 제공하는 새로운 애플리케이션을 만들게 되는 것이다.
만약 새로 만들어진 BPEL 컴포넌트에 결합되는 서비스가 없다면, IT에서 필요한 서비스만 새로 만들면 된다. 전체를 다시 만들 필요가 없다

운영
SOA 애플리케이션을 실행하는 엔진은 BPEL을 관장하는 프로세스 엔진과 EJB, 서블렛 등의 컴포넌트를 실행시켜 주는 엔진이 필요하다. SOA 운영환경은 다음과 같은 컴포넌트로 구성된다.

- 비즈니스 프로세스 컴포넌트: 비즈니스 프로세스 컴포넌트는 BPEL을 지원한다. 고도로 확장 가능한 인프라에서 장단기 실행 비즈니스 프로세스에 대한 지원을 통해 운영된다. 서비스를 엮어서 원하는 서비스를 제공하는 서비스 연출(choreography)를 가능하게 한다.
- 인위적 태스크(Human Task): 인위적 태스크는 직원에게 작업을 배정하거나 그 밖의 다른 서비스를 호출할 때 사용 가능한 독립형 컴포넌트다.
- 비즈니스 상태 시스템(Business State Machine): 비즈니스 상태 시스템은 비즈니스 상태 및 이벤트를 기반으로 비즈니스를 나타낸다.
- 비즈니스 규칙(Business Rule): 비즈니스 규칙은 비즈니스 기능을 외부화해 비즈니스 정책을 이행, 집행하는 수단이다. 따라서 비즈니스 프로세스를 동적으로 변경함으로써 비즈니스 환경의 대응력을 강화할 수 있다.
ESB(Enterprise Service Bus)는 SOA 운영환경에서 각각의 서비스가 서로 통신하고 메시지를 주고 받을 때 사용되는 백본(Back-bone)이다.
ESB는 다음과 같은 기능을 제공한다.

- 중계서비스: 메시지 라우팅 및 변환
- 이벤트 서비스: Publish & Subscribe
- 트랜스포트서비스: 동기/비동기, 영속적/비영속적
- 표준 기반 전송: HTTP/HTTPS, JMS, SOAP 등

ESB는 적용 가능한 서비스 레벨을 제공하고 이 기종 환경에서의 운영과 통합을 위한 SOA 인프라스트럭쳐를 가능하게 해준다. 또한 하나의 서비스가 수행되는 경우 다른 서비스에 영향을 미치지 않고 수행될 수 있게 한다. 이러한 특징은 이 기종 환경에서 서비스의 위치와 통신 프로토콜에 독립적으로 수행될 수 있게 한다.

관리
운영중인 SOA 애플리케이션은 개선을 위해서 적절히 모니터링 돼야 한다. SOA 라이프 사이클에서는 관리단계에서 모니터링 된 비즈니스 프로세스 모델을 평가해 개선사항을 정의하고 비즈니스 모델을 변경, 조립단계를 거쳐 운영하고 모니터링 하는 사이클을 반복하게 된다.
관리 단계에서의 모니터링이 없으면, 정의된 비즈니스 모델이 최선인지, 개선할 부분이 없는지 알 수가 없다. 이 과정을 통해서 비즈니스 성과를 측정하고, 비즈니스 프로세스 플로우를 추적하고 기간, 비용 등을 평가한다. 또한 다양한 리포팅 결과를 가지고 비즈니스를 분석한다.

SOA 라이프사이클과 IBM
SOA 라이프 사이클은 어떤 방식으로 SOA를 구축하든 꼭 필요한 과정이다. 이 과정을 요약하면, 프로세스 모델을 디자인하고 분기조건을 정의하고 모니터링 대상 프로세스를 정의하는 프로세스 모델링 단계를 거쳐, 프로세스 모델로부터 나온 BPEL 컴포넌트와 IT 컴포넌트를 작성한 후 조립해 컴포지트 애플리케이션 개발 단계를 거쳐 컴포지트 애플리케이션을 실행 엔진에 올려 운영하는 단계 및 운영에 대한 비즈니스 성과 모니터링 단계를 거치게 된다.
모니터링 결과는 다시 프로세스 모델링 단계에 반영돼 지속적으로 프로세스를 개선하는 과정을 거치게 된다. <그림 3>는 이러한 과정을 그림으로 보여주고 있다.
IBM은 전체 SOA 라이프사이클의 각 단계에서 필요한 솔루션을 제공하고 있다. 이들 솔루션은 서로 강력히 통합돼 있어 앞 단계에서의 결과물이 다음 단계의 입력으로 사용돼 전체적으로 무결성 통합 툴 세트를 구성한다.


댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.