Web Services + EA = SOA

Web Services + EA = SOA

.최근 정보기술의 방향에서 중요한 키워드 중 하나가 바로 서비스(Service)이다. 서비스는 정보기술이 현실에서 지향하는 바를 한 마디로 설명할 수 있는 중요한 단어이다. 서비스 지향 아키텍쳐(Services-Oriented Architecture; 이하 SOA) 역시 서비스의 관점에서 소프트웨어 아키텍쳐를 조망하는 기술로 최근 많은 각광을 받고 있으며, 시장조사업체인 가트너 그룹은 2006년까지 전 세계 비즈니스 애플리케이션의 80% 이상이 SOA를 기반으로 개발될 것이라고 전망하고 있다. ..SOA의 설명을 위해 자연스럽게 떠올리게 되는 두 가지 키워드가 웹 서비스(Web Services)와 전사적 아키텍처(Enterprise Architecture; 이하 EA)이다. 웹 서비스와 EA는 기업 및 공공기관에서 가장 관심을 높게 보이는 기술 이슈이다. 국내의 모든 공공기관들은 EA를 필히 구축해야 하고 전자정부 애플리케이션의 통합 및 연계를 위해서는 기업에 종속적인 EAI 메카니즘이 아닌 표준화된 기술 즉, 웹 서비스를 반드시 적용하도록 규정하고 있다. ..본 고에서 다루고자 하는 내용은 국가적 필수 적용 기술인 웹 서비스, EA와 새로이 떠오르고 있는 기술인 SOA의 관계를 도출하는 것이다. 그렇게 함으로써 SOA의 적용에 Web Services와 EA가 어떤 역할을 할 수 있는 지를 파악하고자 한다. ..이를 위해 먼저 SOA의 개념에 대해 간단히 설명한 후 Web Services, EA와의 관련성을 각각 분석한 후 결론 부문에서 이들 세 기술간의 관계를 도출하였다. SOA 개 ..SOA는 소프트웨어 아키텍처의 일종이다. 따라서, SOA를 이해하기 위해서는 이를 구성하고 있는 요소들을 파악할 필요가 있는데, 본 절에서는 먼저 SOA와 서비스를 정의하고 이를 기반으로 구성요소들을 살펴보도록 한다. 1) SOA의 정의 ..사실 SOA는 이미 CORBA나 DCOM등의 분산 객체 기술에서 그 기본 개념이 사용되었으나, 기술적인 문제(기술적인 미성숙 및 공개 표준의 부재)와 비즈니스 문제들(주요 소프트웨어 벤더들 간 협력의 부재)로 인하여 그리 큰 주목을 받지 못했다. 하지만 XML 기반의 웹 서비스 기술이 등장하면서 SOA는 새롭게 조명을 받고 있다. ..W3C는 SOA를 "호출 가능한 컴포넌트의 집합"으로 정의 하고 있다. 여기서 컴포넌트는 그 인터페이스의 정의 내용이 공개(publish)?발견(discovery) 가능한 것을 의미한다. ..하지만 CBDI는 이 정의에 대해 두 가지 문제점을 지적하고 있다. SOA가 단순한 컴포넌트의 집합이 아니라는 점과, 정의 자체가 아키텍처의 구성 방법 보다는 이미 정의되어 있는 컴포넌트만을 염두 해두고 있다는 점이다. 따라서 CBDI는 SOA를 "애플리케이션의 기능들을 사용자(consumer)에 적합한 크기(granularity)로 공개한 서비스들의 집합으로 제공하고 사용되게 하는 정책(policy), 적용(practice), 또는 프레임워크(framework)"로 정의하고, 이 때 서비스는 "단일한 표준기반의 인터페이스 형태를 사용하여 구현과 독립적으로 추상화되며, 호출(invoke)되고, 공개(publish)되며, 발견(discover)할 수 있는 것"이라 정의하였다. ..즉, SOA란 서비스라 불리는 분할(decomposition)된 애플리케이션 조각들을 단위로 느슨하게 연결해 하나의 완성된 애플리케이션으로 만드는 아키텍처이다. 2) SOA의 구성요소 ..<그림 2>는 SOA의 기본 구성요소를 도시하고 있는데, 각 요소는 다음과 같다. - 서비스 사용자(Service Consumer) : '서비스 제공자'에 의해 제공되고 있는 하나 이상의 서비스를 사용한다. - 서비스 제공자(Service Provider) : '서비스 사용자'가 호출시 입력하는 값을 가공하여, 그에 해당하는 결과를 제공한다. 경우에 따라 '서비스 제공자'는 또 다른 - - '서비스 제공자'의 서비스를 사용하는 '서비스 사용자'가 될 수도 있다. - 서비스 레지스트리(Service Registry) : 서비스에 대한 설명 정보(descriptions)를 저장하고 있다. '서비스 제공자'는 자신이 제공하고 있는 서비스를 등록하고, '서비스 사용자'는 자신의 원하는 서비스를 발견하여 사용한다.

<그림 2> SOA의 구성 요소

위의 그림으로부터 우리는 SOA를 이해하기 위한 세가지 주요 요소를 추출할 수 있다. 서비스, 메시지 그리고 서비스 발견 등이 그것이다. 이들 각각에 대한 이해를 통해, 우리는 SOA의 본질에 보다 가까이 갈 수 있다.

<그림 3> 서비스의 구조

가. 서비스(Services) ..SOA의 관점에서 서비스는 인터페이스를 통해 자신이 가진 비즈니스 프로세스를 처리할 수 있는 컴포넌트로 정의된다. <그림 3>과 같이 서비스는 인터페이스와 구현 부분으로 구성된다. 서비스가 가지는 특징을 다음과 같이 3가지로 요약할 수 있다. ..- 서비스의 인터페이스는 플랫폼에 독립적이다 ..- 서비스는 동적으로 검색될 수 있으며, 호출될 수 있다. ..- 서비스는 self-contained하다. 즉, 자신의 상태를 스스로 유지한다. ..서비스의 탄생으로 인해 자체적으로 소프트웨어를 만드는 기업은 점차 사라지고, 향후에는 만들어져 있는 소프트웨어를 서비스 단위로 구입하여 사용하는 패러다임이 대세를 이룰 것으로 예상된다. 나. 메시지 (Messages) ..SOA를 이루는 두 번째 중요한 개념은 메시지이다. 서비스 제공자와 서비스 사용자는 메시지를 통해 서로 통신한다. 서비스 제공자는 서비스 명세를 통해 자신이 가진 서비스의 인터페이스를 공개하는데, 이 명세 내에는 서비스가 제공하는 기능과 이를 이용하기 위해 사용자와 주고 받아야 하는 메시지의 형식이 정의되어 있다. SOA 관점에서 서비스는 플랫폼 독립적이어야 하므로, SOA에서 정의되는 메시지는 특정 기술에 독립적이어야 한다. <그림 4>는 서비스 제공자와 서비스 사용자가 메시지를 통해 통신하는 모습을 보여준다.

<그림 4> 메시지를 통한 서비스 사용 구조

..이러한 SOA 메시지를 체계를 응용하면 <그림 5>와 같이 보다 복잡한 아키텍처를 구성할 수 있다. 그림과 같이 서비스 제공자는 동시에 서비스 사용자가 될 수 있다. 서비스 제공자는 다른 서비스 제공자로부터 비즈니스 프로세스나 컨텐츠 등을 제공 받아 보다 가치 있는 서비스를 제공할 수 있다.

<그림 5> 서비스 통합 구조

다. 서비스 발견(Discovery) ..서비스 발견이란 서비스 사용자가 서비스 레지스트리로부터 자신의 원하는 서비스 제공자를 찾는 작업을 말한다. 이를 위해서는 서비스 레지스트리는 서비스를 등록하고 발견하는 기능을 제공해야 한다. SOA의 관점에서 서비스 레지스트리는 다음과 같은 요구사항을 만족해야 한다. ..- 서비스의 확장성(scalability) 보장 ..- 서비스 사용자와 제공자의 분리 (decoupling) ..- 서비스의 동적인 변경 기능 제공 (hot update) ..- 서비스 사용자를 위한 검색 기능 제공 (동적인 검색 기능 포함) 3) SOA의 특징 ..SOA가 가지고 있는 중요한 특징을 정리하면 다음과 같다. - 서비스는 발견이 가능하고 동적으로 바인딩 된다. - 서비스는 컴포넌트와 같이 독립된 모듈이다. - 서비스의 플랫폼간 상호 운용이 가능하다. - 서비스는 느슨하게 연결된다. - 서비스는 네트워크 주소로 접근 가능한 인터페이스를 갖는다. - 서비스는 위치 투명성을 제공한다. - 서비스의 조립이 가능하다. - 서비스는 자기 치유(self-healing)를 지원한다. 4) SOA의 이점 ..SOA는 기업 내의 어플리케이션 아키텍처를 보다 유연하고 확장 가능하도록 구성할 수 있게 하는 패러다임이다. 이러한 특징으로 인해 기업은 SOA를 통해 다음과 같은 이점을 얻을 수 있다. - 기존 자산을 최대한 이용할 수 있게 한다. - 빠른 시장 접근이 가능케 한다. - 전반적인 IT 비용을 절감해준다. - 위험관리를 용이케 한다. - 끊임없는 비즈니스 프로세스의 진보를 이루게 한다. - 프로세스 중심의 아키텍처를 유지할 수 있게 한다. SOA vs. Web Services ..SOA와 웹 서비스의 관계는 많은 자료에서 언급하고 있다. 일반적으로 그 내용은 거의 유사하지만 제시하는 기관마다 약간의 시각차이가 존재하고, 특히 SOA를 정의하는 관점에 따라서도 차이가 존재한다. 여기서는 여러 자료를 토대로 SOA와 웹 서비스의 관계를 도출하고 구체적으로 웹 서비스를 통해 SOA를 구현하는 방법까지 정리하였다. 1) SOA와 웹 서비스의 관계 ..SOA는 웹 서비스 개념보다 먼저 출현하였으며, 웹 서비스 보다 포괄적인 개념이다. SOA는 소프트웨어 개발 패러다임에 가깝고, 웹 서비스는 이러한 SOA의 패러다임을 실현하기 위한 다양한 기술 구현 사례라고 할 수 있다. 이름에서 알 수 있듯이 SOA는 아키텍처이다. 웹 서비스와 달리 특정 기술의 집합이 아니다. SOA는 기술적인 것을 초월할 뿐만 아니라 기술로부터 독립적이다. 비즈니스 환경에서 SOA의 순수한 아키텍처적인 정의는 "호출 가능한 잘 정의된 인터페이스를 갖는 독립된 기능의 서비스로 정의한 애플리케이션 아키텍처"이다. 반면, 웹 서비스는 기술의 집합이며 SOA의 개념을 보다 구체화한 것이다. <그림 6>은 이들 간의 관계를 개념화한 것이다.

<그림 6> SOA와 웹 서비스의 관계

..웹 서비스는 단순히 SOA를 구현한 것만은 아니다. 웹 서비스는 SOA 구현의 Best Practice라고 할 수 있다. 왜냐하면 SOA의 근본적인 철학을 고스란히 실현할 수 있도록 플랫폼 독립적인 프로토콜과 기술을 채택했기 때문이다. 앞에서도 밝혔듯이 웹 서비스가 HTTP, XML, SOAP, WSDL, UDDI 등의 프로토콜을 채택한 것은 SOA의 기본적인 요구사항을 만족하기 위해서라고 할 수 있다. 이들 기술은 특정 컴퓨팅 기술에 중립적이며, de-facto 표준에 가깝다. ..웹 서비스는 SOA를 개념 수준에서 구현이 가능한 현실로 끌어올리는데 중요한 역할을 한다. 현재도 웹 서비스를 이루는 기술표준들은 진화하고 있으며, 이들이 보다 견고해짐에 따라 SOA를 채택하기 위한 위험요소도 점차 제거될 것으로 기대된다. 2) 웹 서비스를 이용한 SOA의 구현 ..SOA에서 기본적으로 요구하는 컴퓨팅 관련 사항과 웹 서비스의 대응 기술은 다음과 같다. - SOA는 플랫폼 독립적인 방식으로 호출될 수 있는 서비스로 구성된다 - XML, SOAP - 서비스는 플랫폼, 프로그래밍 언어에 독립적인 인터페이스를 갖는다. - WSDL - 서비스는 표준체계에 의해 등록이 가능하며, 동적으로 발견 가능하다. - UDDI ..웹 서비스는 W3C SOAP 1.2 표준을 통해 서비스 사용자와 제공자 사이의 통신을 구현한다. <그림 7>은 이를 표현한 것이다.

<그림 7> SOAP을 통한 서비스 호출

..웹 서비스에서 사용하는 서비스 기술의 표준은 WSDL이다. WSDL은 서비스 사용자와 제공자가 주고 받을 메시지를 XML로 정의하며, 모든 프로그래밍 언어에 독립적으로 작동한다.

<그림 8> WSDL을 통한 웹 서비스의 기술

<그림 9 > UDDI의 동작 패턴

SOA vs. EA ..SOA와 EA의 관계는 다양한 시각에서 논의되고 있다. 이 둘의 관계는 바라보는 관점이나 적용 범위에 따라 차이가 있을 수 있으나 SOA가 EA의 하위 아키텍처를 구성한다는 관점과 SOA와 EA가 상호보완적 개념이라는 관점이 언급되고 있다. 여기서는 이러한 SOA와 EA의 관계에 대한 몇 가지 관점들에 대해 설명해 보고자 한다. 1) SOA를 EA의 하위 아키텍처로 보는 관점 ..<그림 10>처럼 SOA를 EA의 하위 아키텍처의 구현 방안으로 보는 시각으로서 SOA가 EA의 기술 부문 (데이터/애플리케이션/기술)의 아키텍처라는 시각과 EA의 애플리케이션/기술 아키텍처의 일부라는 시각으로 나뉘어 진다. 이들은 SOA를 비즈니스 관점에서는 배제하고 주로 기술 관점, 특히 기업 애플리케이션을 구현하기 위한 기술 아키텍쳐 관점에서 주로 SOA를 바라보고 있다.

<그림 10> EA의 하위 아키텍처로서의 SOA

가. SOA는 EA의 기술부문(데이터/애플리케이션/기술)에 해당한다. ..SOA가 EA의 기술부문, 즉 데이터/애플리케이션/기술 아키텍처에 해당한다는 관점으로 비즈니스 프로세스 구현에 필요한 기술적인 사항들을 SOA로 구성할 수 있으며 이를 통해 EA가 추구하는 유연하고 민첩한 구조를 달성한다는 관점이다.

<그림 11> SOA를 통한 분산 데이터 아키텍처의 구현

SOA를 통한 조직의 데이터 아키텍처 변화를 <그림 11>에서 표현하고 있다. 이처럼 각각의 서비스가 관련된 데이터를 직접 관리하는 분산 데이터 환경으로 변화하게 된다. 나. SOA는 EA 기술아키텍처를 구성하는 패턴(Pattern)의 하나이다. ..이 관점은 가트너 그룹에서 주장하는 EA와 SOA의 관계로 SOA는 EA를 구성하는 하나의 기술 패턴이라는 관점이다. 패턴이란 '정해진 문제점에 대하여 여러 사람들이 공감하는 해결책'이라고 할 수 있다. 이는 <그림 12>의 가트너 EA 프레임워크를 통해 이해할 수 있다. 여기서는 일반적인 매트릭스 형태의 EA 프레임워크와 달리 EA 구성요소들의 수직적이고 계층적인 관계에 중점을 두고 있다.

<그림 12> 가트너 EA 프레임워크와 SOA

..가트너의 EA 프레임워크에서 SOA의 위치를 살펴보면 비즈니스 프로세스/스타일 하부의 기술 패턴에 위치하고 있으며 SOA의 구현과 관련된 기술들은 패턴의 하부를 구성하는 기술 단위체인 벽돌(Brick) 레벨에 위치하고 있는 것을 알 수 있다. 2) To-Be 아키텍쳐의 구현 방안으로서의 SOA ..EA는 그 정의에서 알 수 있듯이 As-Is 아키텍처와 To-Be 아키텍처 그리고 To-Be 아키텍처의 구현계획과 관련된 표준/가이드로 구성 되어 있다. To-Be 아키텍처의 구현 방법으로는 신규 개발, 외부도입, 기존 시스템의 전환(migration) 등의 방안이 있으며, 이중 기존 시스템의 전환 방안에 SOA가 적용 될 수 있다. 이는 CBDi에서 제시하는 방안으로 <그림 13> 과 같이 기존 시스템을 전환할 수 있다. 초기에는 획일적인 형태의 레가시 시스템을 웹 서비스와 같은 SOA에 적합한 기술을 적용하여 래핑을 실시하여 외부와의 인터페이스를 정형화한 후 최종적으로는 래핑한 내부의 레가시 시스템을 컴포넌트로 재정립함으로써 완전한 형태의 SOA 구조로 변환할 수 있다.

<그림 13> SOA를 이용한 As-Is 아키텍처의 Migration

..이처럼 SOA는 기업의 최종 목표 시스템 아키텍쳐를 구현하기 위한 방안으로서 가장 적절한 대안이라고 할 수 있다. 3) SOA와 EA의 관계 ..앞에서 언급된 여러 가지 SOA와 EA의 관계를 분석해 보면, SOA는 EA와 매우 밀접한 관계를 가지고 있다는 것을 알 수 있다. 이들을 다시 정리해 보면, SOA를 단순히 EA의 하위 아키텍쳐로 바라봄으로써 단순히 기술 아키텍쳐를 표현할 수 있는 패턴으로 보는 관점과 보다 넓은 관점에서 미래 지향형 EA를 구축하기 위한 방안으로 볼 수 있다. ..두 가지 관점 모두 의미가 있지만, 후자의 관점이 보다 설득력이 있다. 결론적으로, SOA는 EA가 추구하는 목표들은 명확하게 달성할 수 있게 해주며, EA가 제공하는 조직의 전사적 구조는 SOA의 적용을 용이하게 해주는 상호보완적 관계라고도 할 수 있다.

<그림 14> SOA와 EA의 관계

..이를 그림으로 표현해보면 <그림 14>와 같다. 즉, 'SOA 개념이 EA에 반영되어 내재화됨으로서 조직의 정보기술구조를 보다 유연하고 민첩하게 할 수 있다'라고 정의하는 것이 바람직하다. Web Services + EA = SOA ?? ..지금까지 SOA, 웹 서비스, EA에 관한 개념과 이들 상호간의 관계에 관하여 다각적인 측면에서 조망해 보았다. 아직은 초기 단계이기 때문인지 대다수가 정답으로 받아들이는 내용은 아직 없다. 그래서 본 고에서는 이들 간의 관계를 주관적이긴 하지만 앞선 연구결과들의 객관성을 반영하면서 전체가 지향하는 방향에 맞게 이들의 관계를 정립해 보았으며, 최종 SOA 방정식의 결과로 아래의 두 가지 명제를 도출하였다. .."웹 서비스는 SOA의 구현을 위한 현존하는 최적의 기술 대안이다." .."SOA는 차세대(To-Be) EA 구현을 위한 최적의 아키텍쳐이다." ..이를 그림으로 표현하면 <그림 15>와 같다. SOA는 EA의 모든 부분을 구현할 수 있는 차세대 아키텍쳐이며, 웹 서비스는 SOA의 기술 도메인과 EA의 기술 아키텍쳐, 비즈니스 프로세스 영역을 담당하고 있으며, SOA 구현을 위한 최적의 기술이라고 할 수 있다.

<그림 15> Web Services + EA = SOA ??

..SOA의 구현을 위한 가장 최적의 기술이 웹 서비스라고 한다면 웹 서비스 성공의 1차 관건은 SOA라는 철학을 기업의 EA에 반영하는 것이다. EA에 반영된 SOA는 EA의 활용/진화 과정을 통해, 웹 서비스 형태로 기업에 내재화 될 것이며 이를 통해 기업은 정보기술분야의 효용성을 증대 시킬 수 있을 것이다. ..이러한 구조는 기업의 정보시스템 구조를 느슨하게 연결된(Loosely Coupled) 형태로 만들어 변화하는 비즈니스 환경에 보다 유연하고 신속하게 대응할 수 있는 능력을 제공한다. 즉, 비즈니스 환경이 변하여 그에 대한 정보기술부문의 요구사항이 발생하면 EA에 정의되어 있는 SOA에 관련된 기술, 표준 등을 통해 자체적으로 서비스를 개발하거나 표준화된 인터페이스에 적합한 외부 서비스를 서비스 중개자(Service Broker)를 통해 조달 하여 비즈니스 부문의 요구사항에 보다 신속하게 대응 할 수 있는 것이다. ..긍극적으로 SOA, 웹 서비스, EA는 미래지향적인 기업의 정보기술구조를 구현하고 관리하기 위해 꼭 필요하며, 이들은 서로가 독립적으로 위치하기도 하지만 상호간에 연결도가 높은 철학, 기술, 개념이라고 할 수 있다