서비스 지향 아키텍쳐와 통합을 위한 패턴 언어, Part 1: 서비스 생태계 구현하기

문서 옵션 JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다.  제안 및 의견 피드백

난이도 : 초급

Ali Arsanjani, Ph.D., 아키텍트, SOA and Web services Center of Excellence, IBM

2005 년 7 월 13 일

IT 산업이 성숙해지면서 서비스 지향 아키텍쳐(SOA)의 성공적인 디자인과 구현이 더욱 많이 생기고 있다. 이와 동시에, 약간 다른 형태이긴 하지만 근본적으로는 같은 문제를 반복하는 것 같은 문제에 직면하게 된다. 이 같은 문제들을 다루기 위해 여러 패턴들이 서비스 지향 아키텍쳐(SOA)와 서비스 지향 통합(SOI)과 관련된 프로젝트에 생겨났다. 이러한 프로젝트들은 서비스 지향 아키텍쳐의 마이그레이션, 모델링, 디자인, 구현에 초점을 맞추고 있고 약결합 방식으로 서비스들을 통합하는데 초점을 맞추고 있다. 이것이 서비스 지향 통합이다. 이 시리즈에서 이들의 사용법과 관련된 패턴과 경험들을 나눌 것이다. 또한 SOA와 SOI의 마이그레이션, 모델링, 디자인, 구현과 관련된 문제에 대한 솔루션도 모색해 볼 것이다

머리말: SOA 채택과 SOA 접근방식

하나의 SOA 솔루션으로 모든 문제들을 해결할 수 없다. 오히려 SOA 솔루션들은 접근방식과 기업의 성숙도에 맞춰져야 할 것이다. 네 가지 SOA 채택 레벨이 있다. 아래 표 1로 설명해 놓았다.

서비스 지향 아키텍쳐(SOA)의 채택과 통합에 있어 기업들의 성숙도 레벨은 각기 다르다. 어떤 기업은 기술 인스턴스를 사용하여 SOA 세계에 진입한다. 바로 웹 서비스이다. 기존 기능들을 래핑하고, 이를 제3자, 클라이언트, 비즈니스 파트너가 호출할 수 있도록 노출시킨다. 개발 팀을 끌어들이고 SOA를 잘 지원하는 기업 문화로 변화하기 시작하고 새로운 기술과 비즈니스 기능들을 탐지해 나가기 시작한다. 이것이 "레벨 1" 단계이다.

SOA 채택의 "레벨 2" 단계는 웹 서비스의 초기 테스트가 성공적으로 끝나고, 조직이 서비스들을 사용하여 시스템과 애플리케이션들을 통합하기 시작하는 단계이다. 이것은 엔터프라이즈 애플리케이션 통합(EAI)보다 윗 단계이다. 상용 프로토콜, 글루 코드, 포인트 투 포인트 연결은 개방된 표준 기반의 프로토콜과 각 시스템이 노출하는 서비스 디스크립션에 기반한 인터랙션으로 변화하고 있고 서비스 지향 통합의 경지에 이르게 된 것이다. 이 분야에서 엔터프라이즈 서비스 버스는 최상위를 차지한다. 이것은 point-to-point 연결과 관련된 많은 단점들을 극복하는데 도움이 된다.

표 1. SOA의 채택 레이어

위로

SOA를 구현하는 여섯 가지 접근방식

비행할 때 가장 어려운 두 가지 일은 이륙과 착륙이라는 말이 있다. 날씨, 운항 조건, 풍속 등 운항 제어 가이드라인에 따라 다양한 진입 방식으로 활주로에 착륙할 수 있다. 성공적인 SOA로 정착하기 위해서는 적어도 여섯 개의 접근 방식이 있다.

어떤 클라이언트는 비즈니스 프로세스로 시작하고 그러한 프로세스를 지원하는데 필요한 서비스로 나아가기를 바란다. 또, 어떤 클라이언트는 클라이언트, 파트너, 서비스 생태계로 노출되어야 하는 기능들을 레거시 시스템에 가지고 있다. 후자의 경우 기능이 삽입되어 있고 쉽게 접근할 수 없기 때문에 상당한 레거시 변형과 컴포넌트화가 수행되어 기능들을 끌어내고 서비스로 노출해야 한다. 좋은 서비스인지 아닌지의 여부는 또 다른 문제이다. SOA로 접근하는 탑다운(top-down) 방식 중에 MDA(모델 중심의 아키텍쳐)가 있다. 이 툴을 사용하면 코드를 만들어 낼 수 있는 모델을 정의하여 서비스를 구현할 수 있다. 지금까지 우리는 두 개의 탑다운 방식과 두 개의 바톰업(bottom-up) 방식을 고려해왔다.

기타 프로젝트는 데이터와 이 데이터와 관련된 현황에 액세스를 제공해야 한다. 이것은 SOA에 대한 정보 아키텍쳐 또는 데이터 아키텍쳐이다. 하지만 대부분이 시스템을 통합하는 방법을 모색하고 그 무엇보다도 메시징을 통해 시스템과 애플리케이션을 통합하는 방법을 더 신경 쓰고 있다.

표 2. SOA에 대한 여섯 가지 접근 방식

위로

패턴 언어 연구

개요

기업이 강력하고 신속한 아키텍쳐를 갖추기 위해서는 두 가지가 필요하다. a) 핵심 기능 위주로 이니셔티브를 다양화하는 것에 초점을 맞추고 b) 인력, 파트너, 프로세스, 데이터의 약결합 및 동적으로 재구성 가능한 통합 레벨로 옮겨가야 한다. 기존 서비스에서 합성 애플리케이션을 구현할 때에는 동적 재구성이 핵심이다. 이로서 서비스는 기업 내/외부에서 재사용 가능한 방식으로 노출될 수 있는 것이다.

기업들이 SOA로 이동하면서 주요한 채택 방식 또는 엔트리 포인트 중 하나는 서비스 지향 통합(SOI)이다. 이것의 핵심은 기존 IT 시스템을 활용하는 것이다. 현실적으로, 서비스 통합은 기업 애플리케이션 통합 이상의 단계이고 최소한의 "글루 코드"를 사용하여 비 상용 프로토콜을 통해 약결합 서비스들을 정의 및 활용하게 될 것이다. 이 방식은 서비스의 사용과, 다중 시스템들간 또는 상태계의 비즈니스 파트너들간 데이터와 프로세싱의 인터랙션에 의존한다.

SOI 접근방식으로 성공을 거두려면, 그리고 IT 시스템의 관점에서 실리적으로 시작하여 엔터프라이즈 내에서 점진적으로 서비스로 진화하려면 여러 가지 장애나 도전들을 극복해야 한다. 이러한 문제들은 간단하고 대부분 사소한 문제들에서 점점 복잡한 문제로 번져간다. SOA의 사용과 구현에서 더욱 성숙해 지고 이에 상응하는 비즈니스와 IT 효과도 누리게 되면서 말이다. 여기에서 설명한 패턴들은 그러한 문제들을 해결하는데 도움이 된다. 복잡한 문제들을 해결하기 위한 솔루션을 구현할 때 더욱 세분화된 패턴들을 사용하게 될 것이다. 예를 들어, 하루아침에 ESB를 갖는 대신 서비스 전략으로 시작하여 서비스 어댑터와 프록시를 만들고 가상 공급자에서 서비스 통합자로 그 다음 ESB로 옮겨가는 것이 보다 신중한 행태이다. 이러한 패턴들의 사용은 실질적인 프로젝트에 달려있고 다른 프로젝트 마다 다르게 사용하게 될 것이다.

처음에 부딪치는 문제는 프로젝트, 업종, 기업 내에서 SOA의 가치를 구체적으로 판단하는 것이다. 이것은 유연성과 실제 서비스 공급자를 바꾸는 능력과 관련이 있다. 일단 서비스 품질이 떨어지거나 필요한 기능을 제공하지 못할 경우 서비스 공급자를 바꿀 수도 있는 것이다. 이러한 유연성이야 말로 SOA의 핵심 가치이다. 이것은 원격 서비스 전략을 통해 유연성을 획득하는 단계를 이해함으로서 실현될 수 있다. 이 글에서 제안하는 패턴을 사용하는 것과 관련하여 두 가지 문제가 있다.

이 패턴들은 패턴 언어의 핵심이다. SOA 채택 레벨 중에서 고급 레벨로 옮겨가면서 SOA와 SOI에 관련하여 더욱 광범위한 문제들을 다루게 된다.(그림 1) 점증적인 채택 레벨을 통해 SOA로 마이그레이션하는 기업들은 일반적으로 상용 인터페이스와 글루 코드를 사용하는 강결합 시스템에서 출발하여 부분적으로 노출된 서비스들간 point-to-point 연결로 이동해 간다. 두 개의 포인트는 SOA의 잠재성을 실현하는 관점에서의 처음 두 단계들을 나타낸다. 각 단계는 더 나은 성숙도와 비즈니스 가치 및 IT 효과의 증대를 나타낸다. 예를 들어, 접근이 불가능한 기능의 Point-to-Point 노출은 하드 코딩 사일로에서 한 단계 나아간 것으로 볼 수 있다. 사일로에는 임베딩 되어 있으면서 접근도 불가능한 기능들이 포함되어 있다. 접근이 까다로운 임베디드 기능에 접근하기 위해 애쓰는 대신 기업은 과잉의 기능들을 만들어낸다. 이것 역시 다른 정황에서는 접근이 불가능하다. 애플리케이션 포트폴리오 통합(다른 말로 감축)은 분산 시스템들에서 공통된 기능을 규명하는 것이다. 이를 추출하고 고립화하여 단일 액세스 포인트를 제공하는 것이다. 이로서 관리가 쉬워지고 비용도 낮출 수 있다. 아울러 인수 합병 시 빠른 통합도 가능해진다.

표 3의 패턴들은 다양한 프로젝트에서 발굴해 낸 SOA와 SOI용 패턴이다.

표 3. 패턴과 장점

아래 다이어그램의 각 포인트는 주어진 상황에서는 가장 적절한 것이지만 오른쪽으로 간다고 해서 모두 좋은 것 만은 아니다. 이 진행과정은 성숙도가 높아진다는 것을 의미하며 더욱 복잡해지는 비즈니스를 다루기 위해서는 더욱 성숙해져야 한다.

이어지는 섹션에서는 SOA/SOI용 패턴 언어의 기본을 형성하는 근본적인 패턴을 소개한다. 여기서 "근본적(fundamental)"이라고 쓴 이유는 클라이언트가 이러한 패턴들과 관련된 문제들에 먼저 직면하게 되고 SOA로 나아가기 위해서는 이들을 해결해야 하기 때문이다. SOA는 점진적인 작은 변형의 과정이다. 다중 서비스 공급자가 제공하는 서비스 구현에서 서비스 디스크립션을 점증적으로 분리한다. 아래에 제시된 솔루션은 이러한 문제들이 어떻게 해결되고 하나의 패턴으로서 프로젝트를 도울 수 있는지를 설명한 것이다. 여느 다른 패턴과 마찬가지로, 정황과 힘에 맞게 채택되어야 한다.

패턴의 논의와 정황

대부분의 기업들은 많은 이종의 백엔드 레거시 시스템들을 갖추고 있다. 자금 지원을 받는 것만이 SOA에 참여할 수 있다. 종종 기업은 LOB(line of business)로 구분된다. LOB는 전체 시스템의 한 부분을 차지하고 있다. 하나의 비즈니스 프로세스를 지원하는 애플리케이션에 대한 제어권은 없다. 따라서 비즈니스 프로세스는 다양한 시스템 소유자들이 개입된 채 다중 비즈니스 라인을 방해한다. 엔드투엔드 프로세스의 각 참여자는 지금 지원을 받을 수 있는 위치가 아닐 수도 있고 SOA 마이그레이션에 순응하지 않거나 적절한 시기에 이를 수행하지 않을 수도 있다. 따라서 SOA로 기능을 마이그레이션을 하겠다는 기업 내 부서의 결정에는 종속 기능을 제공하는 다른 LOB나 파트너들이 포함되지 않는다.

따라서 초기 단계에서는 SOA로 마이그레이션 하는 과정 중에는 기업이 극복해야 하는 학습 및 통합 과정이 포함된다. 예를 들어, SOI 패턴인 가상 공급자가 이를 돕는다. 기업들은 SOA로의 점증적인 마이그레이션을 통해 이러한 문제들을 해결할 수 있다. 기존 인프라, 시스템, 관리, 정책들을 활용하고 때로는 변경하고 증대한다. 서비스 공급자는 외부 서비스들에 의존할 수도 있다. 이 외부 서비스란 생태계 내의 LOB나 조직에서 제공하는 것이다. 가상 공급자 패턴은 이러한 문제를 다루고 있다. 공급자가 서비스 소비자 측에서 SOA를 만들고 서비스 공급자 측에서 가상 서비스 공급자를 만드는 것이다. 그 사이에 서비스 소비자는 가상 공급자를 사용하여 SOA를 만들고 공급자의 서비스에 연결한다. 일단 서비스 전략을 통해 실제 SOA 구현으로 올라타게 된 것이다. 가상 공급자를 갖추게 되면 SOA에서의 통합 레이어(Integration Layer)의 생성이 더욱 쉬워진다. 통합 레이어의 성숙도와 효과에는 엔터프라이즈 서비스 버스의 생성이 내포되어 있다.

[원격] 서비스 전략은 독립적으로 사용되거나 두 개의 주요 패턴과 결합되어 사용될 수 있다. 이 패턴은 근본적으로 서비스의 다형성의 개념을 시뮬레이션하고 전략적 디자인 패턴을 구현하지만 객체 지향적 개념은 아니다. 대신, 이것은 원격 호출이라는 서비스 지향 영역에 적용된다. 이 분야에서는 새로운 엔드포인트에 대한 유연한 재할당과 마이그레이션이 적용되어야 한다. 이로서 서비스 소비자의 관점에서 비용 효율적이고 일관된 방식으로 서비스를 제공할 수 있다. 따라서 소비자가 자신들의 비 기능적 요구사항에 대한 변경을 요구하거나 현재의 공급자가 기능이나 비 기능적 요구사항을 처리할 때 적당한 방법에서 벗어나면 서비스 전략을 통해 서비스에 대한 엔드포인트로서 다른 서비스 공급자의 재할당이 애플리케이션과 인프라에 최소한의 영향만 주면서 적용된다. 중요한 것은 초보적인 웹 서비스에서 보다 성숙한 SOA로 이동한다는 것이다. 과잉을 줄여 하나의 액세스 포인트를 갖추고 보다 일관성 있게 레지스트리, 리파지토리, 브로커를 갖추는 것이다. 우리가 "게이트웨이(Gateway)"라는 용어를 선택하지 않았다는 것에 주목하라. 이 단어는 적절한 단어이긴 하지만 웹 서비스 게이트웨이(Web Service Gateway) 제품처럼 제품을 나타낼 때도 쓰일 수 있기 때문이다. 여기에서는 비즈니스 기능에 대한 통합 액세스 포인트에 초점을 맞추도록 하겠다.

만약 여러분이 "서비스 통합을 통해 SOA의 최종 상태에 이르기 위해 서비스 버스에 기반한 견고한 통합(레이어) 아키텍쳐로 점증적으로 나아가기 위해서는 어떻게 해야 할까?"라는 질문을 한다면? 첫 번째 패턴은 유연성의 관점에서 본 SOA의 가치에 대한 것이다. 두 번째 패턴은 SOA를 엔터프라이즈에서 실행하기 위해 중요한 집단을 만드는 것과 관련이 있다. 세 번째는 가상 공급자를 다음 레벨에서 서비스 통합자로서 작동시키는 것이다. 결국 이렇게 하면 ESB를 구현해야 하는 단계에 도달하게 될 것이다.

이 글에서는 ESB에 다다르기 위해 취해야 하는 단계들을 설명할 것이다. 어떤 경우에는 기업 문화와 툴, 기술, 미들웨어가 잘 갖춰져 있을 경우 ESB로 직접 갈수 있다. 이것은 기업이 매우 성숙해야만 가능하다.

Pattern 1: 원격 서비스 전략

현상과 문제: 이것은 SOA의 아키텍쳐에 적용될 수 있는 전략 디자인 패턴의 변종이다. 이것은 약결합과 관련된 문제를 다루고 있고, 인풋 상황이나 서비스의 품질에 기반하여 서비스 구현을 변경할 수 있는 유연성을 갖추기 원할 때 사용된다. 순전한 객체 지향 전략 패턴은 상속에 기반한 다형성에 의존하여 정황에 따라 바뀔 수 있는 알고리즘을 구현한다. SOA에 객체 계층 대신, 서비스 공급자를 변경할 수 있어야 한다. 대부분의 경우 구현자는 원격 기능 단위의 공급자이다. 대부분 내부 네트워크나 인터넷에 존재한다. 따라서, 더 많아진 트랜잭션 분량이나 보안 제한으로 인해 서비스의 필요가 변경되면 OrderEntry 애플리케이션의 VerifyAddress 서비스의 공급자는 변경되어야 한다. 그렇지 않을 경우, 옛날처럼, 공급자는 같은 기본 서비스에 대해 두 배의 분량을 부과해야 한다. 이제, 서비스 공급자를 변경할 수 있는 유연성을 갖추게 되었다. IT 시스템에는 최소한의 변경만 이루어지고 비즈니스와 사용자는 온라인 쇼핑 시 어떤 영향도 받지 않게 되는 것이다.

많은 경우 서비스 공급자는 원격이고, 실제 구현자로의 바인딩은 웹 서비스 바인딩을 통해서이다. (WSDL 인터페이스의 SOAP 호출 즉, 발견된 URI 또는 기존 URI의 프리셋이다.)

솔루션: 서비스 공급자에 대한 액세스와 통신 방식을 하드코딩 하는 대신, 서비스의 인터페이스를 서비스 구현자의 레이어(예를 들어, Enterprise Component Layer)에서 분리하는 서비스 레이어를 만든다. 이로서 IT 시스템의 코드에 큰 변화 없이도 서비스 인터페이스를 구현하는 서비스 공급자를 유연하게 변경할 수 있다. 하드 코딩된 커스터마이징 대신 "재구성(Reconfiguration)"이 본 솔루션의 핵심이다. 동적으로 구성이 가능한 아키텍쳐 스타일은 SOA가 제안하는 핵심 가치이다.

결과와 변종: 이 패턴을 구현하는 등급이 있다. 더 높은 수준의 커플링으로 시작하여 낮은 수준으로 옮길 수 있다. 기존 서비스 공급자의 WSDL에 대한 하드 코딩 URI 대신에 공급자의 서비스 레지스트리를 만들고 공급자를 동적으로 변경(UDDI, LDAP 등)하여 공급자를 변경할 수 있도록 한다. 더 심화된 레벨이 필요하면 발견과 협상 프로세스는 여러분이 제어하지 않는 레지스트리에서 발생하지만 "가장 잘 맞는 " 것을 찾아줄 외부 서비스 브로커에 의해 제공된다.

서비스 공급자를 쉽게 변경하는데 필요한 의미론의 표준화가 필요하다. 다행히도 다양한 비즈니스 영역에 표준들이 존재한다. 보다 복잡한 시나리오에서 공급자들을 변경하는데 필요한 문법의 기초를 형성한다.

Pattern 2: 서비스 어댑터

(또는 서비스 래퍼)

현상과 문제: 서비스 어댑터의 목적은 서비스 지향이 아닌 시스템들이 서비스 지향 아키텍쳐에 참여할 수 있도록 하는 메커니즘을 제공하는 것이다.

그와 같은 서비스들은 일반적으로 레거시 시스템이거나 패키지 애플리케이션으로서 SOA에 의해 정의된 명확한 인터페이스를 제공하지 못한다. 이는 종종 되풀이 되는 문제이다. 오늘날 많은 핵심 비즈니스 프로세스들은 오랜 기간 다져진 시스템에 의해 지원을 받기 때문이다. 이러한 시스템들은 주류 SOA에는 없는 기술을 사용하고 매우 복잡하기 때문에 변경되기도 힘들다. 따라서 이들은 SOA 내에서 재사용할 수 있는 좋은 후보이기는 하지만 시스템에 서비스 기반 액세스를 제공하기 위해서는 작업이 필요하다. 어떤 경우, 벤더들은 서비스 어댑터를 제공한다.(CICS용 웹 서비스가 대표적인 예이다.)

레거시 시스템에 래퍼 서비스를 제공하려면 어댑터 기술 또는 "서비스 어댑터"가 필요하다. 이 기술의 목적은 비 SOA 시스템을 통합하여 데이터나 프로토콜 변형을 가하여 레거시 기능을 나타내는 명확한 서비스 인터페이스를 노출하는 것이다. 이 인터페이스는 "래퍼 서비스"로서 퍼블리시된다. 서비스 소비자는 어댑터를 통해 이 래퍼 서비스에 바인딩 될 수 있다.

보다 지능적이고 기능적인 어댑터가 필요하게 되면서 이 언어 내의 다른 패턴들도 필요하게 되었다. 따라서 가끔은 래퍼를 작성해야 한다. 어떤 경우, 실제로 소유했는지 여부, 퍼포먼스와 특징에 따라 SOA에 더 많은 변이와 지능이 요구된다

결과: 명료한 인터페이스를 제공하기 위해 애플리케이션이나 레거시 코드가 수정될 수도 있다. 코드용 컨테이너(CICS)가 적절한 기술을 지원하는 분야에서 특히 알맞다.(CICS SOAP 지원 또는 XML과 메시징 기술 지원)

고려해야 할 내용이 더 있다.

• 분명한 어댑터의 사용(예를 들어, Java 2 Connector 또는 WebSphere Business Integration Adaptor)
• 보다 일반화된 미들웨어의 사용. 예를 들어, 브로커로서 EAI 기술은 중앙화된 기능을 제공하여 다중 애플리케이션이나 레거시 시스템에 어댑터 역할을 한다.
• ESB의 사용. 서비스 요청을 중재하는 기능 외에도 ESB가 사용되고 있고, ESB가 EAI와 비슷한 통합 기능을 갖고 있다면 다중 애플리케이션이나 레거시 시스템에 어댑터 역할을 할 수 있다.

Pattern 3: 서비스 프록시

현상과 문제: 여러분의 고객이 서비스를 직접 지원하는 능력이 없거나 WSDL을 사용하여 서비스 호출을 하지 않는다. 그러나 여러분은 미래의 몇몇 공급자가 제공하는 서비스 오퍼링과 관련된 서비스의 기능과 품질을 사용할 기회를 주어야 한다. 오늘날 아마도 그 공급자는 웹 서비스 같은 기능을 제공하는 것이 아닌, 레거시 포맷으로 미래에 마이그레이션 할 계획을 세우고 있다. 서비스 공급자는 서비스 노출 기술이 아직 없다.

과제: 서비스를 완벽하게 실행 할 정도의 기능이 없다면 실제 WSDL과 웹 서비스 기술이 갖추어 지지 않더라도 그 서비스를 핸들 해야 한다.

솔루션: 소비자가 서비스 인터페이스를 사용하여 기능에 접근하는 수고를 덜어주기 위해 여러분은 미래의 SOA 기능에 대한 대행자로서 서비스 프록시를 제공한다.

이 패턴은 가상 공급자를 지원하는 서비스 어댑터와 연결하여 사용된다.

Pattern 4: 가상 공급자

이 패턴에서는 여러분이 아마도 서비스 어댑터와 서비스 프록시를 갖추었을 것이다. 이제 가상 공급자를 구현할 수 있다.

현상과 문제: 이 생태계에서는 여러분이 제공하는 서비스에 의존하는 서비스 소비자들이 있다. 마찬가지로 여러분은 서비스 공급자들이 제공하는 서비스들에 의존한다. 하지만 실제 세계에서는, 이 생태계는 점진적으로 발전한다. 여러분이 필요로 하는 모든 서비스들이 웹 서비스로서 또는 서비스 스팩을 통해서 사용할 수 있는 것은 아니다. LOB, 엔터프라이즈, 생태계를 움직이는 많은 서비스들을 개발해야 한다.

과제: API 호출로서가 아닌 서비스로서 여러분이 의존하는 기존 공급자들의 기능을 획득해야 한다. 하지만 이들은 아직 서비스로서 노출될 준비가 되어있지 않다. 여러분은 잠재적 공급자들과 협상하여 여러분이 필요로 하는 서비스들을 획득해야 한다. 기능뿐만 아니라 서비스 레벨 계약이나 비 기능적 요구 사항들까지 획득해야 한다. 여러분이 제공하는 서비스 스팩이나 디스크립션도 예외는 아니다. 공급자가 여러분이 원하는 방식으로 서비스를 제공하지 않을 수도 있기 때문에 문제에 직면하게 될 것이다. 문제 유형은 다음과 같다. a) 공급자가 즉각적인 요구사항에 대해 제때에 서비스를 공급하지 않을 수도 있다. b) 세분성에 맞지 않는 다른 기능을 제공할 수도 있다. c) 비 기능적 요구 사항들을 수행하지 않을 수도 있다.

여러분에게는 서비스를 제공할 누군가가 필요하지만 어떤 누구도 없다.

솔루션: 여러분이 필요로 하는 서비스를 지정하고 이것이 제공된다는 것을 가정하여 가상 공급자를 구현한다. 프록시를 사용하여 공급자를 만들어서 레거시 시스템과 통신하면서, 어댑터를 사용하여 사용된 프로토콜을 서비스 디스크립션/계약에서 정의된 것에 맞게 변형한다. 프록시와 어댑터를 façade에 캡슐화한다. 어댑터의 수는 앞으로 변형되어야 하는 새로운 시스템과 프로토콜에 따라 무작위로 늘어나기 때문이다. 따라서 façade를 사용하여 기존 API와 통신할 어댑터를 캡슐화 한다.

결과: 여러분은 이제 점증적인 방식으로 SOA로 마이그레이션 할 수 있는 수단이 생겼다. 여러분의 현재 생태계가 준비가 덜 되어있더라도 말이다. 일단 공급자의 서비스에 직접 연결되면 그 공급자는 서비스를 생성, 퍼블리시, 제공하게 될 것이다. 여러분은 새로운 코드를 작성할 필요가 없으며 기존 공급자의 API의 새로운 프로토콜을 위한 새로운 어댑터만 있으면 된다.

관련 패턴: 중재, 라우팅, 변형, 정책에 대한 규칙 객체들이 가상 공급자에 추가된다면, 후자는 엔터프라이즈 서비스 버스(Enterprise Service Bus)라고 부를 수 있다.

가상 공급자에는 façade, 프록시, 목표 시스템의 연결 유형에 대한 한 개 이상의 어댑터가 포함되어 있다. 가상 공급자 내에 라우팅과 정책 관리용 규칙 객체들을 추가하면 이것은 서비스 버스가 된다.

가상 공급자를 실현하기 위해 적소에 배치되어야 하는 몇몇 패턴들은 관리와 관계된 것이다. 조화로운 기부 패턴이란 의미는 중앙 기업이 서비스의 실행이나 생성에 대한 자금을 지원하기 위해 두 개의 기업 단위들 간 공평하게 나뉜 자금을 매치할 것이라는 의미이지만 다른 비즈니스 라인만 혜택을 보기 때문에 예산 내에서 이루어지지 않을 수도 있다. 이러한 문제들은 기업 내에 중앙 액세스 포인트를 통해 해결된다.

Pattern 5: 서비스 통합자

현상과 문제: 여러분은 가상 공급자를 적용하고, 원격 서비스 전략을 사용하여 비즈니스 요구 사항들의 필요를 채우고 있다. 하지만 레거시 시스템(커스텀 애플리케이션과 패키지 애플리케이션)에 갇힌 과잉의 백엔드 기능을 통합하는 것은 도전이 된다. 새로운 조합 내에서 그러한 개별 기능들을 재구성 하려면 백엔드 기능에 대한 단일 액세스 포인트가 필요하다.

여러분은 불안정하고 임시적으로 개발된 기능을 갖고 있는 서비스 공급자의 생태계 속에 있다. 연결도 "일회성"이다. 통합은 상용이고 임시적인 것이다. 서비스들을 구성할 때 단일 액세스 포인트를 사용할 수 없다.

과제: 현재 시스템은 인터페이스에 알맞은 세분성을 제공하지 못한다. 서비스의 모델링이나 서비스 구분이 어떤 메커니즘을 통해 수행되지 않을 때 이 같은 일이 발생한다. 이 메커니즘으로 서비스의 세분성은 비즈니스 목표와 IT 시스템과 연결된다. (SOMA 메소드에서의 목표-서비스 모델링[1]). 게다가 서비스들은 부적절하게 리팩토링되고, 연결 없이는(stateless) 노출되지 않는다. 따라서 통합 시, 점대점 상태와 새롭게 변경될 때 마다 부풀려진 글루 코드를 함께 다루어야 한다. 가상 공급자와 서비스 전략을 활용할 수 있는 유연하고 강력한 단일 액세스 포인트가 필요하다.

솔루션: 따라서 특정 통합 레이어를 서비스 통합용 아키텍쳐에 도입하고 서비스 통합자를 통해 그 레이어를 관리한다. 서비스 통합자는 과잉의 서비스들에 단일 액세스 포인트를 제공한다.

이를 활용하려면 최종 구현 시 가상 공급자의 정황 내에서 이것의 변종들을 원격 서비스 전략으로 노출한다. 이러한 방식으로 불안정한 강결합 아키텍쳐에서 보다 동적이면서 재구성 가능한 약결합 아키텍쳐로 성공적으로 이동할 수 있는 기초를 구현하는 것이다.

서비스 통합자는 다중 통합 레이어를 관리한다.(그림 3 (layer 6)). 서비스 컴퓨팅 생태계에서 서비스 통합자는 단일 통합 포인트, 모니터링, 생태계 관리가 가능하다. 이 생태계는 근본적으로 프랙탈(fractal)이다. 이 아키텍쳐에 있는 기업은 다양한 범위에서 발견될 수 있다. 프로젝트 레벨로 시작하여 비즈니스 라인으로 올라가고 다양한 기존 애플리케이션들을 엔터프라이즈 아키텍쳐에 위임한다. 이로서 생태계 내의 협업을 위한 두 개 이상의 엔터프라이즈 아키텍쳐의 통합이 가능하다.

가상 공급자와 원격 서비스 전략 패턴을 적용하여 시작되었던 생태계를 더욱더 진화시키려면 여러 백엔드 시스템들과 소스들에서 기능과 서비스들을 통합하여 애플리케이션 포트폴리오를 줄이거나 크기를 조정하고 이들을 비슷한 기능을 위한 단일 액세스 포인트로 재구성해야 한다. 종종 이러한 통합은 다중 비즈니스 프로세스 구성(구성법)에 기반한다. 많은 경우 이러한 구성법은 BPEL 처럼 외부화된 약결합 기술로 실현되지 않는다. 비 기능적 요구 사항들에 대한 비용이 너무 비싸기 때문이다. 비 기능적 문제를 줄이기 위해 구성 자체가 하드코딩 된다. 이 패턴에 대한 대안은 별로 없다. 서비스 구성은 다중 애플리케이션 소스들을 서비스 통합자와 함께 연결되어 표현 레이어에서 포탈로서 통합, 재구성, 렌더링 된다.

가상 공급자가 서비스 통합자로서 사용된다면, 가상 공급자(서비스 통합자)내에서 라우팅 및 정책관리용 규칙 객체를 추가한다면 서비스 버스가 된다.

결과: 여러분은 이제 여러분의 기업 내에서나 외부에서 생태계에 있는 기능과 서비스들을 감시, 관리, 마이그레이션 할 수 있다. 다른 외부 서비스 공급자, 패키지 애플리케이션, 기타 레거시 기능들을 다루는 애플리케이션들을 통합 및 재구성 할 수 있고 SOA의 소비자 레이어(표현 레이어)에서 포탈로 렌더링 될 수 있는 새로운 서비스 조합에 단일 액세스 포인트를 제공할 수 있다.

논의: 그렇다면 이 시나리오는 엔터프라이즈 서비스 버스(ESB)와는 어떻게 다른가? 간단히 말해서 사전(pre) ESB 상태로의 성공적이고 점진적인 마이그레이션을 실행 할 수 있는 디딤돌을 논의하게 될 것이다. 그 후에 ESB가 구현 및 활용되어 향상된 서비스 기능을 제공할 수 있다. 따라서 우리는 클라이언트가 배선에 의한(hard-wired) 통합에서 시작해서 결국 점대점 서비스 통합으로 진행하는 것을 보게 될 것이다. 가상 서비스 공급자와 서비스 통합자는 두 개의 추가 단계를 제공한다. ESB로 향하기 위한 점증적인 변형도 포함되어 있다.

Pattern 5: ESB (엔터프라이즈 서비스 버스)

현상과 문제: 이 글에서 설명한 패턴들은 SOA가 약속하는 유연성 요소들을 현실성 있고 점증적인 방식으로 제공하기 위해 일반적으로 사용하는 기술들을 다루었다. 하지만 기업들이 애플리케이션, 레거시 시스템, 채널 기술 전반에 걸쳐 서비스 지향을 적극적으로 채택하면서 서비스들을 지원하는데 필요한 미들웨어와 그러한 미들웨어를 지원하는데 사용할 수 있는 서비스와 기술들은 복잡한 문제가 되었다. 이러한 복잡성을 관리할 수 있는 중요한 솔루션은 서비스 통신, 중재, 변형, 통합에 공통 인프라를 제공하는 것이다. 이러한 인프라는 서비스 관리, 보안, 모니터링, 인프라를 서비스 지향 아키텍쳐에 적용할 수 있는 제어 포인트로서의 역할도 한다. 이 같은 공통 인프라는 엔터프라이즈 서비스 버스로 설명된다.

과제: 많은 서비스를 가진 기업은 기능을 제어할 수 있는 공통적인 관리 및 운영 모델을 필요로 한다.

• 많은 서비스 인터랙션을 관리해야 한다.
• 고급 서비스 인터랙션 기능(트랜잭션, 저장 및 전달, 인프라 서비스, 보안, 서비스 품질)을 지원해야 한다.
• 동기식 요청/응답, 메시징, 퍼블리시/등록, 이벤트 같은 다양한 인터랙션 스타일을 지원해야 한다.
• SOA의 원리에 부합한 강력한 분산 통합 인프라를 제공해야 한다.
• 서비스 라우팅과 대체, 프로토콜 변형, 기타 메시지 프로세싱을 지원해야 한다.
• 웹 서비스와 전통적인 EAI 통신 표준과 기술을 지원해야 한다.

솔루션: 서비스 인터랙션을 지원하기 위해 기업 전반에 걸쳐 미들웨어 기능을 제공하는 엔터프라이즈 서비스 버스를 만든다. ESB는 서비스에 필요한 통신, 중재, 변형, 통합 기술을 지원해야 하고 지역적으로 분산된 전개도 수행할 수 있어야 한다. 하지만 관리에는 공통 모델을 사용한다. 그림 11은 IBM Redbook, "Patterns: 엔터프라이즈 서비스 버스를 사용하여 SOA 구현하기"에서 인용한 것으로서 ESB의 핵심 기능들을 설명하고 있다.

• 한 개 이상의 "허브(hub)" 컴포넌트로서 전개된다. 각 허브는 로컬화 되었지만 탄력적인 기능을 제공하여 라우팅, 변형, 보안, "중재" 기능들을 수행한다.
• 서비스를 관리하는데 사용되는 네임스페이스 디렉토리와 관리 서비스를 갖고 있다. 여러 지역에 전개된 ESB에서 관리 서비스는 협업 Hub의 네트워크를 통해 설정의 일관성을 관리한다.
• 많은 인바운드 포트를 갖고 있다. 각 인바운드 포트는 특정 프로토콜(SOAP/HTTP 또는 WebSphere MQ)을 사용하여 서비스 요청을 수신하도록 설정된다.
• 많은 아웃바운드 포트를 갖고 있다. 각 아웃바운드 포트는 특정 프로토콜을 사용하여 요청을 송수신 하도록 설정된다.

이러한 설정을 통해 ESB는 가상 서비스 공급자 패턴과 원격 서비스 전략을 지원할 수 있다. 게다가 ESB는 다양한 보안, 데이터 포맷, 서비스 요청자와 공급자 간 트랜잭션 모델들 간 변형을 제공한다. ESB는 엔터프라이즈라는 이종의 복잡한 상황을 제어 및 캡슐화하는 역할을 한다.

ESB 패턴에 대한 자세한 내용은 ESB Redbook을 참조하라.(참고자료)

ESB 패턴은 다양한 기술과 제품을 사용하여 구현될 수 있다. 각 구현은 기업 특유의 요구사항에 따라 다르다. IBM Redbook(참고자료)에서는 ESB 패턴과 IBM Software로 구현하는 방법에 대해 자세히 설명하고 있다. ESB의 공통 구현 기술에는 EAI 미들웨어(WebSphere BI Message Broker), 웹 서비스 라우터(WebSphere Web Services Gateway), CORBA와 XML 등이 있다.

논의: 보안과 기타 비 기능적 요구 사항들은 SOA의 서비스 품질에 영향을 미치게 될 엔드 투 엔드 개념이다. ESB는 서비스를 관리할 수 있지만 "서비스를 관리하는 것"은 보다 복잡한 개념이다. 예를 들어, 웹 서비스 관점에서 볼 때 서비스를 관리한다는 것은 JAX-RPC 핸들러를 추가하거나 제거한다는 의미일 뿐만 아니라 서비스(레지스트리)의 네임스페이스를 시작/중지 및 관리한다는 의미이다.

위로

결론

이러한 패턴들은 SOA로 마이그레이션 하는 것과 관련된 문제를 해결하기 위해 이러한 패턴들이 결합되어 사용될 수 있다. 또한 많은 경우 자신의 기업 내에 대규모의 SOA로 진행하는 과정으로서 서비스 지향 통합 모델로 나아가야 한다.

• 기존 기능에 대한 변경을 최소화하면서 SOA로 마이그레이션할 수 있다. SOA가 점점 성숙해 가면서 효과는 증대된다.
• 래핑 작업과 새로운 SOA 개발을 통합할 수 있다.
• 현재 실행중인 시스템을 없애지 않고, 비즈니스 클라이언트에 가치를 제공하고 그들의 필요를 다루는데 있어 혼란을 야기시키지 않는 점진적인 마이그레이션 전략을 사용한다.

가상 공급자는 서비스 패러다임의 최고 구조체의 생성을 가능하게 함으로서 서비스 생태계를 구현하는 것을 돕는다. 이 프로젝트의 세분성은 중요하다. 더 작은 프로젝트는 서비스 어댑터와 서비스 프록시를 사용하여 기존 기능이나 비 SOA 기능에 연결해야 한다. 기업 내의 LOB가 SOA의 표준화를 결정했다면 가상 공급자를 고려해야 한다. 엔터프라이즈 레벨에서는 다양한 LOB 마다 프로젝트가 있다. 서비스 버스의 생성을 위한 첫 번째 단계는 가상 공급자를 생성하는 것이 당연한 수순으로 받아들여 진다. (여기에는 필요한 기능에 대한 서비스 어댑터의 구현이 포함된다. 그 기능에 서비스로서 접근하려면 서비스 소비자에 서비스 프록시를 제공해야 한다.) 퍼포먼스나 보안상의 이유로 액세스를 삽입해야 한다면 서비스 어댑터가 그 기능에 접근할 수 있도록 하면 된다. 이 서비스를 구현하는 엔터프라이즈 컴포넌트는 그와 같은 어댑터가 함수를 호출하도록 한다. 하지만 이것을 서비스로서 소비자에게 노출할 필요는 없다. 소비자에게 노출되어야 하는 서비스들만 서비스 프로시나 요청 핸들러를 갖고 있어야 한다.

기업이 SOA의 사용과 채택에 있어 더욱 성숙해지면 내부 시스템에서 벗어나 몇몇 파트너들과의 점대점 통합을 넘어서 서비스의 생태계로 진입한다. 이때에는 앞서 우리가 언급했던 패턴들을 사용하여 서비스 생태계로 진입할 수 있다. 다른 기능들로는 서비스 지향 엔터프라이즈 아키텍쳐(SOEA), 서비스 지향 모델링 및 아키텍쳐 메소드(SOMA), 서비스 지향 레퍼런스 모델(그림 7), 관리, 패턴 등이 있다. 이 모두 서비스 생태계 내에서 유연성을 확립하는데 필요한 것들이다.

위로

감사의 말

이 글에 여러 가지로 도움을 준 친구와 동료에게 감사를 전한다. 특별히 Kerrie Holley, Rick Robinson, Arnauld Desprets에게 감사의 말을 전하는 바이다. 이 외에도 Donald Ferguson, George Galambos, Jonathan Adams, Ed Kahan, Michael Ellis, Paul Verschueren, Abdul Allam, Rolando Franco, Tony Fricko, Kishore Channabasavaih, Liang-Jie Zhang, Joe Hardman, Kyle Brown, Bobby Wolf, Emily Plachy, Stefan Puehl, Sri Ramanathan에게 감사의 말을 전하고 싶다.

위로

참고자료

• "On the Criteria to be used in decomposing a system into Modules" (ACM, 1972)
  
  
• "서비스 지향 모델링과 아키텍쳐" (developerWorks, November 2004)
  
  
• "Patterns: Implementing an SOA using an Enterprise Service Bus," (IBM, July 2004)
  
  
• Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions
  
  
• "Patterns: Implementing an SOA Using an Enterprise Service Bus with WebSphere Application Server V6" (May 2005).
  
  
• "Rule Pattern Language 2001: A Pattern Language for Adaptive Manners and Scalable Business Rule Design and Construction" (IEEE, 2001).
  

위로

필자소개

		Ali Arsanjani, Ph.D.: 아키텍트, SOA and Web services Center of Excellence, IBM

위로

기사에 대한 평가

보다 나은 서비스를 제공하기 위함이오니 잠시 짬을 내어 이 양식을 제출하여 주십시오. 귀하께서 원하시는 정보를 얻었습니까? 예 아니오 잘 모르겠음   이 페이지 개선을 위한 의견을 주십시오:   이 정보가 얼마나 유용했습니까? (1 = 전혀 도움이 되지 않음, 5 = 매우 유용함) 1 2 3 4 5

위로