-
[펌] SOA vs. EADreamFactory 2005. 9. 12. 17:34
2.6 SOA vs. EA
SOA와 EA의 관계는 다양한 시각에서 논의되고 있다. 이 둘의 관계는 바라보는 관점이나 적용 범위에 따라 차이가 있을 수 있으나 SOA가 EA의 하위 아키텍처를 구성한다는 관점과 SOA와 EA가 상호보완적 개념이라는 관점이 언급되고 있다. 여기서는 이러한 SOA와 EA의 관계에 대한 몇 가지 관점들에 대해 설명해 보고자 한다.
2.6.1 SOA를 EA의 하위 아키텍처로 보는 관점
SOA를 EA의 하위 아키텍처의 구현 방안으로 보는 시각으로서 SOA가 EA의 기술 부문 (데이터/애플리케이션/기술)의 아키텍처라는 시각과 EA의 애플리케이션/기술 아키텍처의 일부라는 시각으로 나뉘어 진다. 이들은 SOA를 비즈니스 관점에서는 배제하고 주로 기술 관점, 특히 기업 애플리케이션을 구현하기 위한 기술 아키텍쳐 관점에서 주로 SOA를 바라보고 있다.‘SOA는 EA 기술아키텍처를 구성하는 패턴(Pattern)의 하나이다’
이 관점은 가트너 그룹에서 주장하는 EA와 SOA의 관계로 SOA는 EA를 구성하는 하나의 기술 패턴이라는 관점이다. 패턴이란 '정해진 문제점에 대하여 여러 사람들이 공감하는 해결책'이라고 할 수 있다. 이는 [그림 2-14]의 가트너 EA 프레임워크를 통해 이해할 수 있다. 여기서는 일반적인 매트릭스 형태의 EA 프레임워크와 달리 EA 구성요소들의 수직적이고 계층적인 관계에 중점을 두고 있다.
가트너의 EA 프레임워크에서 SOA의 위치를 살펴보면 비즈니스 프로세스/스타일 하부의 기술 패턴에 위치하고 있으며 SOA의 구현과 관련된 기술들은 패턴의 하부를 구성하는 기술 단위체인 벽돌(Brick) 레벨에 위치하고 있는 것을 알 수 있다.
[그림 2-14] 가트너 EA 프레임워크와 SOA
2.6.2 To-Be 아키텍쳐의 구현 방안으로서의 SOA
EA는 그 정의에서 알 수 있듯이 [1]As-Is 아키텍처와 [2]To-Be 아키텍처 그리고 To-Be 아키텍처의 구현계획과 관련된 표준/가이드로 구성 되어 있다. To-Be 아키텍처의 구현 방법으로는 신규 개발, 외부도입, 기존 시스템의 전환(migration) 등의 방안이 있으며, 이중 기존 시스템의 전환 방안에 SOA가 적용 될 수 있다.
[
그림 2-15] SOA를 이용한 As-Is 아키텍처의 Migration이는 CBDi(http://www.cbdiforum.com)에서 제시하는 방안으로 [그림 2-15] 과 같이 기존 시스템을 전환할 수 있다. 초기에는 획일적인 형태의 레가시 시스템을 웹 서비스와 같은 SOA에 적합한 기술을 적용하여 래핑을 실시하여 외부와의 인터페이스를 정형화한 후 최종적으로는 래핑한 내부의 레가시 시스템을 컴포넌트로 재정립함으로써 완전한 형태의 SOA 구조로 변환할 수 있다.
이처럼 SOA는 기업의 최종 목표 시스템 아키텍쳐를 구현하기 위한 방안으로서 가장 적절한 대안이라고 할 수 있다.
2.6.3 SOA와 EA의 관계
앞에서 언급된 여러 가지 SOA와 EA의 관계를 분석해 보면, SOA는 EA와 매우 밀접한 관계를 가지고 있다는 것을 알 수 있다. 이들을 다시 정리해 보면, SOA를 단순히 EA의 하위 아키텍쳐로 바라봄으로써 단순히 기술 아키텍쳐를 표현할 수 있는 패턴으로 보는 관점과 보다 넓은 관점에서 미래 지향형 EA를 구축하기 위한 방안으로 볼 수 있다.두 가지 관점 모두 의미가 있지만, 후자의 관점이 보다 설득력이 있다. 결론적으로, SOA는 EA가 추구하는 목표들은 명확하게 달성할 수 있게 해주며, EA가 제공하는 조직의 전사적 구조는 SOA의 적용을 용이하게 해주는 상호보완적 관계라고도 할 수 있다.
[
그림 2-16] SOA와 EA의 관계이를 그림으로 표현해보면 [그림 2-16]과 같다. 즉, 'SOA 개념이 EA에 반영되어 내재화됨으로서 조직의 정보기술구조를 보다 유연하고 민첩하게 할 수 있다'라고 정의하는 것이 바람직하다.
2.7 SOA에서의 Web Services 와 EA
지금까지 SOA, 웹 서비스, EA에 관한 개념과 이들 상호간의 관계에 관하여 다각적인 측면에서 조망해 보았다. 아직은 초기 단계이기 때문인지 대다수가 정답으로 받아들이는 내용은 아직 없다.
그래서 본 고에서는 이들 간의 관계를 주관적이긴 하지만 앞선 연구결과들의 객관성을 반영하면서 전체가 지향하는 방향에 맞게 이들의 관계를 정립해 보았으며, 최종 SOA 방정식의 결과로 아래의 두 가지 명제를 도출하였다."웹 서비스는 SOA의 구현을 위한 현존하는 최적의 기술 대안이다."
"SOA는 차세대(To-Be) EA 구현을 위한 최적의 아키텍쳐이다."이를 그림으로 표현하면 [그림 2-17]과 같다. SOA는 EA의 모든 부분을 구현할 수 있는 차세대 아키텍쳐이며, 웹 서비스는 SOA의 기술 도메인과 EA의 기술 아키텍쳐, 비즈니스 프로세스 영역을 담당하고 있으며, SOA 구현을 위한 최적의 기술이라고 할 수 있다.
[그림 2-17] SOA에서의 Web Services 와 EA
SOA의 구현을 위한 가장 최적의 기술이 웹 서비스라고 한다면 웹 서비스 성공의 1차 관건은 SOA라는 철학을 기업의 EA에 반영하는 것이다. EA에 반영된 SOA는 EA의 활용/진화 과정을 통해, 웹 서비스 형태로 기업에 내재화 될 것이며 이를 통해 기업은 정보기술분야의 효용성을 증대 시킬 수 있을 것이다.
이러한 구조는 기업의 정보시스템 구조를 느슨하게 연결된(Loosely Coupled) 형태로 만들어 변화하는 비즈니스 환경에 보다 유연하고 신속하게 대응할 수 있는 능력을 제공한다. 즉, 비즈니스 환경이 변하여 그에 대한 정보기술부문의 요구사항이 발생하면 EA에 정의되어 있는 SOA에 관련된 기술, 표준 등을 통해 자체적으로 서비스를 개발하거나 표준화된 인터페이스에 적합한 외부 서비스를 서비스 중개자(Service Broker)를 통해 조달 하여 비즈니스 부문의 요구사항에 보다 신속하게 대응 할 수 있는 것이다.
궁극적으로 SOA, 웹 서비스, EA는 미래지향적인 기업의 정보기술구조를 구현하고 관리하기 위해 꼭 필요하며, 이들은 서로가 독립적으로 위치하기도 하지만 상호간에 연결도가 높은 철학, 기술, 개념이라고 할 수 있다.[그림 2-18] SOA Orchestration layer