Service Oriented Architecture에 대한 고찰
<Source. /blog.naver.com/jirubak/60021839389 at 2006/04/23>
SOA(Service Oriented Architecture)는 지난 2005년 가장 기술적으로 각광받던 키워드 중 하나였다.
가트너를 비롯한 유수의 건설팅 업체와 MB,IBM,BEA 그리고 국내의 Tmax soft 등 관련 솔루션 업체들이 대거 SOA 플랫폼과 도입 전략 등에 대한 마케팅을 강화하면서 IT 관련 종사자에게는 시스템의 아키텍쳐를 설계하면서 많은 참고 모델로 각광받았다. 특히, 정부의 G4C 등 주요 시스템 구축시 SOA를 유행처럼 도입했고 정부와 전산원 주도하의 SOA기반의 Web Service 들이 개발되었다고 보고된 적이 있다.
그러나 이러한 국내의 움직임이 민간기업이나 일반 시스템 개발에 있어서 광범위하게 적용되지 못하고 있다. 아무래도 여러 이유가 있게씨만 SOA를 프레임웍으로 바라보는 것이 아니라 구현 기술로 바라 보는 경향이 있어서가 아닌가 싶다. 다시 말해 SOA의 구현 기술인 SOAP , WSDL , UDDI 등의 개발 기술로 보는 경향이 강하기 때문이 아닌가 싶다.
하여간 실제 SOA 프레임웍을 도입해서 많은 성과를 얻은 기업들이 존재하며 현재에는 기업을 벗어나 전체 온라인 웹 서비스로 확산되고 있다. 특히, Web2.0이란 참여와 공개를 통한 웹의 본질 회복이라는 추세와 더불어 서비스와 데이타베이스의 공개를 위해 SOA가 도입되어 광범위하게 확산되고 있다.
SOA와 Web Service
SOA와 Web Service는 같으면서도 다르다. SOA가 머리이면 web Service는 다리를 말한다. SOA가 이종간의 통합과 변화에 대한 적응을 위한 IT 전략이라면 web service는 SOA의 구현 방안이다. 따라서 SOA는 이종시스템 및 서비스 와의 통합과 경쟁 환경의 변환에 효과적으로 적응하기 위한 프레임웍과 정책, 규범 등 기술,문화,정책 등 모든 것이 포함되는 것이며 이렇나 정책을 구현하기 위한 표준 방법이 Web Service이다.
SOA의 출현 배경
IT 산업과 기술의 발전 배경에는 항상 동일한 키워드가 존재한다. 바로 통합이라는 것이다. 이기종 환경들의 통합, 서로 다른 데이타의 통합, 서로 다른 네트웍의 통합, 서로 다른 운영체제간의 통합, 서로 다른 시스템 및 프로세스 간의 통합.... 한마디로 IT의 역사는 통합의 역사라 해도 과언이 아닐 것이다. 이러한 이종간의 통합과 더불어 변환에 대한 대응 속도가 또 하나의 중요한 키워드 이다. 경쟁 환경과 고객의 요구사항에 대한 대응 속도야 말로 기업의 생존을 결정하는 가장 중요한 경쟁력이다.
Centerized Computing :
Client/Server Computing : 2tier --> 3tier --> N tier
Distributed Computing : Distributed Object --> Component ->Service
과거 중앙집중식 환경하에서 C/S 환경으로 그리고 다시 분산 컴퓨팅으로 IT의 패러다임이 발전을 했다. 또한 분산 컴퓨팅에서 있어서도 초기 Java RPC나 DCOM,CORBA같은 분산 객체에서 발전하여 컴포넌트,그리고 다시 서비스에 이르기 까지 발전해 오고 있다. 여기에 숨겨져 있는 기본 배경에는 이들 분산 객체나 컴포넌트, 그리고 서비스 모두가 위치나 프로토콜 등 이종의 환경에 상관없이 따로 또 같이 운영될 수 있는 것이다. 하지만 그 단위와 인터페이스에 있어서 분산 객체의 경우 가장 작은 객체 단위의 인터페이스라면 컴포넌트는 그 보다는 더욱 추상화된 같은 기능들을 중심으로 인터페이스가 통합된 것이라면 서비스는 컴포넌트 보다 더 표준화된 인터페이스 말하는 것이라 할 수 있다.
또한 분산 객체와 컴포넌트가 프로그래밍 차원이 인터페이스에 의미를 둔다면 서비스는 말 그대로 다른 서비스나 서비스를 필요하는 응용 서비스를 위한 인터페이스를 말한다. 따라서 각각은 사로 다른 목적의 인터페이스를 위해 설계되고 구현된다. 실제 대부분의 서비스는 내부에 컴포넌트로 구성이 되고 각 컴포넌트는 객체들로 구성된다.
SOA 용어
서비스 - 특정 기능을 제공하기 위해 협약된 방법에 의해 공개된 인터페이스들
서비스 제공자 - 해당 서비스를 구현한 실제 소프트웨어
서비스 소비자 - 해당 서비스를 필요로하는 다른 서비스나 응용 프로그램
서비스 브로커 - 요청된 서비스를 다수의 서비스 제공자에게 전달해 주는 서비스
서비스 로케이터 - 해당 서비스를 등록해 주고 서비스 소비자에게 원하는 서비스를 찾게 해주는 시스템 서비스
실제 구현하는 입장에서 보면 객체지향 설계를 통해 인터페이스를 설계하고 이를 SOAP 인터페이스를 통해 구현하며 해당 서비스를 WSDL(Web Service Description Language)로 작성한 후 UDDI라는 서비스 로케이터에 이를 등록한다. 만일 이 서비스를 이용하려면 반대로 UDDI를 통해 원하는 서비스의 명세를 얻고 이 명세에 따라 서비스를 요청하여 원하는 서비스를 수행할 수 있다.
CORBA의 경우 naming service를 통해 oject reference를 얻은 후 이를 통해 원하는 메소드를 수행하는 것과 동일하며 java RMI의 경우에도 RMIregistry에 method를 등록하고 이를 lookup하여 사용하는 절차와 동일하다.
SOA 아키텍쳐 스택
실제 SOA는 표준화된 것이 아니다. 하지만 따라서 많은 관련 업체들은 각기 나름대로의 SOA 프레임웍을 구성하고 이를 지원하고 있다. 물론 Web Service는 표준이다. 하지만 SOA는 단순한 구현기술이 아니다. 다음은 일반적인 SOA의 구현 스택이다.
- 기능 스택
비지니스 프로세스 - 해당 서비스들을 이용하여 고객의 요구에 대응하는 응용 프로그램
서비스 - 실제 제공되는 서비스
서비스 명세 & 서비스 레지스트리 - 호출 방법 등 서비스의 명세 작성 방법과 이를 저장하는 저장소
서비스 전송 - 서비스 소비자와 공급자 사이의 서비스 요청과 처리 결과가 전송되는 방법
- QOS스택
서비스 정책 - 서비스 제공자의 서비스 공급 정책 , 예) 유/무료 여부 , 일일 이용 한계 등
서비스 보안 - authorization,authentication 등의 보안 정책
서비스 트렌젝션 - 서비스의 무결성 관리 정책
서비스 관리 - 서비스 공급자와 제공자들에 대한 관리
실제 SOA는 기업내에서 시스템을 개발하거나 새로운 서비스를 기획하는 데 있어 많은 가이드를 제공한다. 무정지 시스템을 운영하며 새로운 기능과 서비스를 창출하는 것은 무척 어려운 일이다. 이를 위해서는 초기 단계부터 SOA를 고려해서 개발한다면 통합과 변화란 현안을 해결할 수 있다. 현실적으로 안타까운 것은 항상 시간에 쫒겨 이러한 사실을 꼼꼼히 적용할 기회가 힘들다는 것이다. 하지만 결국 가야 할 길이다.