 | |
|
난이도 : 중급 Shantanu Bhattacharya, Chief Consultant, Siemens Information Systems Limited
2008 년 2 월 12 일 여러분의 조직에 서비스 지향 아키텍처(SOA)를 적용하여, 유연하고 적응력 있는 프로세스로 만들고 싶을 때가 있습니다. 하지만, 여러분에게는 이미 비즈니스 프로세스에 사용 중인 시스템이 있습니다. 해결책은 무엇일까요? SOA와 레거시 애플리케이션을 통합하여 가치를 끌어내는 것입니다. 이 글에서, 이를 실현하는데 필요한 단계들을 설명하고, 피해야 할 함정들도 설명합니다.
레거시 시스템을 SOA에 통합해야 하는 이유
레거시 시스템을 가진 기업들은 자신들이 레거시 시스템에서 가치를 이끌어 내기 위해 SOA를 채택해야 하는 필요성을 느끼고 있다. 레거시 시스템은 다른 현대적 시스템들보다 먼저 자동화 되었기 때문에, 최상의 가치를 만드는 비즈니스 프로세스를 제공한다. 이러한 자동화 대부분이 레거시 시스템을 효과적으로 활용할 수 없는 이유는, 이러한 시스템들이 비즈니스 가치를 자동화 이니셔티브에 적용할 수 있는 자동화 전문가들 보다 오래되었기 때문이다. 따라서, 레거시 시스템을 통합하지 않고, 가치를 만들겠다고 하는 전략은 절반의 성공으로 이끌 뿐이다.
프로젝트의 중점 영역으로서 시작되었던 레거시 시스템들이 지속적인 시스템 개발의 원천으로서 그 매력을 잃어가는 이유는 단지 오래된 기술에 추가하는 것뿐이라는 고정 관점 때문이다. 컴퓨팅 기술의 세대 변화는 3년 마다 이루어진다는 것을 고려해 보면, 이 글에서 설명한 문제들 역시도 이와 같은 속도로 발생하고 있다.
하지만, 레거시 시스템들은 엔터프라이즈가 기존 프로세스를 기반으로 계속 향상해 나갈 수 있는 베이스를 형성하고 있다. 따라서, 기술 변화를 위한 비즈니스 전략에는 레거시 시스템들이 포함되어 있어야 한다.
이 글은 다음과 같은 기준에 근거하여 기업에서 찾아볼 수 있는 레거시 시스템을 구분하고 있다:
- 기업이 필요로 하는 런타임 환경은 무엇인가?
- 어떤 플랫폼을 위해 개발되는가?
- 어떤 사용자 인터페이스 환경을 사용하는가?
레거시 시스템은 Oracle Frames같은 실행 환경이나, 고유의 운영 체계에서 실행될 수 있다. 운영 체계에서 직접 실행될 수 있는 레거시 시스템들은 SOA 영역에 쉽게 들어갈 수 있다. 한 가지 예로 DOS나 메인프레임 시스템에서 개발된 시스템을 들 수 있다. 따라서, 여러분이 사용하는 언어와 기술을 신중하게 선택하는 것이 중요하다.
레거시 애플리케이션은 이들이 사용하는 사용자 인터페이스에 기반하여 여러 유형이 될 수 있다:
- 그린 스크린(Green-screen) 애플리케이션.
- 비 GUI 기반 애플리케이션.
- 클라이언트/서버 기반 GUI 애플리케이션.
- 웹 기반 애플리케이션.
이 중에서, 웹 기반 애플리케이션과 클라이언트/서버 기반 GUI 애플리케이션들은 기본 특성상 SOA 기반 애플리케이션과 통합할 때 다루기가 가장 쉽다. 이러한 애플리케이션들은 서비스 프로바이더와 UI를 확실히 구분하는데, 이는 SOA용 서비스로 쉽게 전환된다. 하지만, 그렇다고 해서 다른 애플리케이션들이 SOA 영역에 들어갈 수 없다는 것은 아니다. 다만, 이러한 시스템들은 SOA의 서비스로 되기 전에 '마사지(massage)'가 필요하다.
비록, 다양한 종류의 레거시 애플리케이션들이 이 장에서 언급되었지만, 이제부터는 레거시 애플리케이션들을 SOA에서 실행되는 애플리케이션으로 변형할 때 부딪치게 되는 보다 일반적인 문제들을 상세히 설명하도록 하겠다. 다양한 종류의 레거시 애플리케이션을 이 글에서는 다루지 않겠다.
SOA에 결합할 레거시 시스템 결정하기
레거시 시스템과 SOA를 통합할 때의 문제점을 파악해야 하고, 한꺼번에 모든 애플리케이션들을 SOA에서 실행하는 것은 실수이다. 이는 단계를 더욱 복잡하게 하며, 성공의 가능성을 크게 줄이고 만다.
SOA에서 실행될 레거시 애플리케이션을 구분하는 방법:
- 비즈니스가 제공하는 리턴과, 조직을 유지하기 위해 발생하는 관리 비용의 관점에서 모든 레거시 애플리케이션들을 범주화 한다.
- 기회 비용을 고려한다: 애플리케이션을 SOA에서 실행하지 않아서 드러나지 않은 애플리케이션의 잠재성은 무엇인가?
비즈니스 가치가 높은 애플리케이션들은 SOA로 채택되어야 할 첫 번째 애플리케이션이 되어야 한다. 또한, 개발되지 않은 잠재력이 높은 애플리케이션도 좋은 후보이다.
서비스와 비즈니스 혜택 구분하기
후보 레거시 애플리케이션들을 규명한 후에, 서비스용 후보를 규명하는 일도 똑같이 중요한 일이다. 이는 전체적인 변형을 통해 이룩할 수 있는 성공의 척도를 결정한다.
이것은 두 개의 프로세스로 나뉜다: 1 단계는 서비스로 정의될 수 있는 것이 무엇인지를 규명하는 단계이다. 2 단계는 서비스를 형성하는 것으로부터 얻을 수 있는 비즈니스 혜택을 다룬다.
1 단계: 서비스 규명하기
비즈니스 프로세스를 서비스로 규명할 때, 다음 사항들을 점검해야 한다:
- 인풋과 아웃풋 매개변수의 수가 너무 높아서는 안된다. 이것이 높으면, 비즈니스 프로세스가 여러 서비스들로 나뉠 수 있다. 이유는 간단하다: 서비스 형성 이후에, 매개변수와 네이티브 포맷 간 변환에 상당한 시간이 든다.
- 서비스는 단일 기능을 수행해야 한다. 서비스를 작고, 세분화 된 액티비티로 유지하는 것이 문제 관리에 좋고, 더 많은 시나리오에서 쉽게 사용할 수 있게 된다.
- 각 서비스는 기술적 기능이 아닌 비즈니스 기능을 갖고 있어야 한다. 상응하는 비즈니스 프로세스가 없는 기술 서비스를 반드시 피해야 한다. 기술 서비스는 비즈니스 분석가에 의해서 쉽게 이해될 수 없기 때문이다. SOA의 가장 필수적인 목적 중 하나는 서비스가 비즈니스 분석가들에게 이해될 수 있어야 한다는 것이다.
잠재적 서비스들을 구분하는 예로서, 기본적인 연산이 다음과 같은 주문 항목 애플리케이션을 생각해 보자:
- 고객의 신용도 확인하기.
- 재고 줄이기.
- 고객에게 청구하기.
- 이월 주문 처리하기.
위 액션들 각각은 잠재적 서비스가 될 수 있다. 하지만, 재고 줄이기 같은 기본적인 비즈니스 연산은 또 다른 정황에서 재사용 될 수 있다. 하지만, 고객에게 청구하기는 너무 복잡한 연산이기 때문에, 다음과 같이 나뉘어야 한다:
- 청구 아이템들을 모으기.
- 판매세 계산하기.
- 고객 주소 데이터 수집하기.
- 청구서 만들기.
- 청구서 보내기.
2 단계: SOA에서 더 많은 비즈니스 가치를 이끌어 낼 서비스 선택하기
두 번째 단계는 SOA 환경에서 비즈니스 가치를 이끌어 낼 수 있는 서비스를 선택하는 단계이다. 서비스 선택 기준은 후보 애플리케이션들을 선택하는 기준과 비슷하지만, 몇 가지 차이가 있다. 선택된 서비스들은 높은 가치 계수를 갖고 있어야 한다. 잠재적 서비스의 가치 계수는 다음과 같이 정의될 수 있다:
(서비스의 비즈니스 가치 - 관리 비용) / 대체 비용
따라서, 매우 큰 비즈니스 가치, 최소한의 비즈니스 비용, 최소한의 대체 비용을 갖춘 서비스들이 최상의 서비스 후보가 되는 것이다. 예를 들어, 서비스에 대한 코드가 여러 모듈과 파일들에 퍼져있다면, 많은 관리 비용을 일으킬 것이다.
기존 소프트웨어 컴포넌트를 언어, 목적, 유형, 임계성 별로 구분할 수 있다. 아이템의 가치는 개발 비용, 관리 비용, 대체 비용, 그 아이템이 기여한 연간 비즈니스 가치에 대한 분석을 기준으로 매겨진다.
레거시 코드 구출하기
이 프로세스의 첫 번째 단계 중 하나는 레거시 애플리케이션에서 코드를 (재사용을 위해) 구출하는 것이다. 기존 레거시 코드 베이스에서 코드를 구출하기 위해서는, 코드를 배치하고, 이것의 재사용 가치를 결정해야 한다. 일부 작은 프로그램들이 걸쳐 퍼져있는 코드를 분석하고 평가하는 것은 어렵지 않다; 코드에 익숙한 프로그래머라면 자신들에게 친숙한 텍스트 에디터를 사용하여 이를 수행할 수 있다. 하지만, 재사용 가능한 코드 블록을 찾기 위해서 수 백 개의 대형 프로그램을 분석하는 문제는 다르다. 이 분야의 전문가가 필요하지만, 그들 역시도 Refine/C, Imagix4D, Sniff+, Rigi 같은 자동화 리버스 엔지니어링(reverse engineering) 툴의 지원을 받아야 한다.
레거시 코드를 구출하는데 있어서 가장 중요한 것 중 하나는 코드가 나타내는 비즈니스 프로세스를 규명하는 일이다. 비즈니스 연산을 발견하는 쉬운 방법은 이들이 만들어 내는 결과를 사용하는 것이다. 다시 말해서, 레거시 코드의 실행 결과에 의해 비즈니스 프로세스를 규명해야 한다. 이는 공들이지 않고도 비즈니스 프로세스를 확실히 찾아낼 수 있다. 비즈니스 연산을 처리하는 함수에 의해 리턴된 변수들을 규명함으로써, 함수들을 구분할 수도 있다. 비즈니스 함수들이 C의 함수 또는 COBOL의 문단 같은 하나의 코드 블록에 할당되도록 프로그램이 구현된다면, 이러한 태스크는 간단하지만, 이는 드문 경우이다. 비즈니스 함수는 여러 모듈 속에 있는 코드의 여러 블록에 퍼져있는 경우가 많다. 한편, 코드의 한 블록이 여러 비즈니스 함수들을 처리할 수 있다. 따라서, 코드 블록과 비즈니스 연산은 다대다(many-to-many) 관계이다.
최종 결과에 기반하여 데이터 플로우 분석을 수행함으로써, 결과를 만들어내는데 기여했던 모든 문들을 통해 결과를 추적할 수 있다. 문장이 규명된 후에, 코드 단위들—프로시저, 문단 등—이 있을 곳에 배치한다. 그러한 단위들만이 각자가 참조하는 변수들을 가진 원래 소스에서 복사될 수 있다. 이러한 기술을 일반적으로 코드 스트리핑(code stripping)이라고 한다.
비즈니스 연산의 코드를 규명한 후에, 다음 단계는 그 코드를 추출하고, 이를 고유의 인터페이스와 함께 개별 모듈로 조합하는 것이다. 영향을 받는 코드 단위를 공통 프레임웍에 복사하고, 이들이 참조하는 모든 데이터 객체들을 공통 데이터 인터페이스에 둔다. C에서, 인터페이스는 유형 구조의 매개변수이고, COBOL에서, 객체는 연결 섹션에서 레벨 1의 아이템이다. 모든 경우에서 최종 결과는 콜 인터페이스를 가진 서브루틴이다. 원래의 인풋 인자들은 인풋 매개변수이고, 원래의 아웃풋 인자는 아웃풋 매개변수이다. 비즈니스 로직 코드는 원래 사용자 인터페이스에서 연결되지 않고, 독립된 하위 프로그램이 된다. 이는 래핑(warp)의 전제 조건이다.
구출된 코드 래핑하기
비즈니스 연산에 상응하는 코드가 배치되고, 문서화 되며, 재사용 가치가 발견된 후에, 다음 단계는 이를 래핑(wrap)하는 단계이다. 래핑 프로세스의 목적은 레거시 코드에서 추출된 컴포넌트를 위해 Web Services Description Language (WSDL) 인터페이스에 순응하는 것이다. 각 엔트리를 메소드로 변형하고, 각 매개변수를 XML 데이터 엘리먼트로 변형해야 한다. 데이터 구조는 한 개 이상의 하위 엘리먼트를 가진 복잡한 엘리먼트가 된다. 메소드는 데이터 엘리먼트 디스크립션에 대한 레퍼런스로서 인자와 결과를 갖고 있다. 메소드와 매개변수 모두 XML 스키마로 구현된다.
COBOL과 C/C++에서 이러한 변형을 자동화 할 수 있는 여러 툴들이 있다. WSDL 인터페이스 디스크립션을 만드는 것 외에도, 래핑된 컴포넌트를 두 개의 추가 모듈로 강화시킨다:
- 한 개의 모듈은 인커밍 메시지를 파싱하고, 여기에서 데이터를 추출하는 용도이다. 추출된 값은 래핑된 컴포넌트의 상응하는 인자로 할당된다.
- 다른 모듈은 래핑된 컴포넌트에서 만들어진 결과에서 리턴된 메시지를 만드는 용도이다. 이러한 방식으로, 코드를 수정할 필요 없이, 기본 연산이 웹 서비스로서 재사용 될 수 있다.
이렇게 생성된 두 개의 서브루틴은 WSDL 인터페이스와 원래 코드의 호출 인터페이스 간 다리 역할을 한다.
서비스를 비즈니스 프로세스에 연결하기
레거시 코드에서 웹 서비스를 만드는 세 번째이자 마지막 단계는 웹 서비스를 비즈니스 프로세스에 연결하는 단계이다. 이는 프록시 컴포넌트를 통해 수행될 수 있다. 비즈니스 프로세스는 실제로 프록시를 호출하는데, 이는 프로세스 정의와 같은 주소 공간에서 사용할 수 있다. CORBA에서처럼, 프록시는 매개변수를 검사하고, WSDL 인터페이스를 생성하는데, 이는 IBM® WebSphere® MQ 같은 일부 메시지 서비스에서 애플리케이션 서버로 보내진다.
애플리케이션 서버에는, 인커밍 메시지를 받고, 어떤 웹 서비스가 실행될 것인지를 결정하고, WSDL 콘텐트를 특정 서비스, 이 경우 래핑된 레거시 코드로 전달하는 스케줄러가 있다. 코드의 래퍼는 XML 인풋 데이터를 받고, 그 값을 래핑된 컴포넌트에 알맞은 주소로 옮긴다.
래핑된 컴포넌트가 실행된 후에, 결과는 래퍼에 의해 XML 아웃풋 데이터 구조로 변형되는데, 이는 웹 클라이언트로 전송될 스케줄러로 가게 된다. 이러한 방식으로 비즈니스 프로세스는 클라이언트 어디에서나 실행되고, 원래의 애플리케이션 서버 상의 레거시 함수에 액세스 할 수 있다.
결론
조직의 SOA 이니셔티브에 사용할 수 있도록 레거시 애플리케이션을 래핑하는 것은 SOA를 실행하는 엔터프라이즈에서는 중요한 부분이다. SOA 실행에 있어서 적절한 프로세스가 이루어진다면, 태스크는 에러 없이 깨끗해진다. 이 글을 통해 여러분이 프로세스를 이해하고, 체계화 할 수 있기 바란다.
참고자료 교육
제품 및 기술 얻기
토론
- 포럼에 참여하기.
- Get involved in the developerWorks community
by participating in developerWorks 블로그와 다양한 커뮤니티에 참여해보라, 아래는 SOA와 웹서비스 관련 블로그들이다:
필자소개 | 
| | Shantanu Bhattacharya는 애플리케이션 소프트웨어(유통, 시스템 통합, 보건), 네트워킹 소프트웨어(SNMP 기반 및 TCP/IP 스택), 보안 소프트웨어, 파일 시스템(인도 최초의 수퍼컴퓨터), Real Time Software(Indian Missile Program)을 디자인 및 구축했다. 출판 활동도 활발히 하고 있으며, ACM Computing Surveys의 검수자로도 활동하고 있다. 현재는 인도 방갈로르에 있는 Siemens에서 아키텍트로 일하고 있다. |
기사에 대한 평가
| |
