서비스 기반 아키텍처 (SOA) : 개념, 정의, 개요, 목표, 특징

서비스 기반 아키텍처를 구성하는 목표

다양한 기존의 레거시 시스템, 이미 존재하고 있는 시스템들이 복잡하게 연결되어 있습니다. 어떠한 기업에서 이미 가지고 있는 다양한 시스템들이 있습니다. 이런 시스템들을 서로 상호작용하게 해서 또 다른 새로운 애플리케이션을 만듭니다.

이미 새롭게 개발된 시스템들이 있는데 그런 것들하고 어떻게 연동시킬지는 어려운 문제입니다. 그래서 서비스 기반 아키텍처를 구성하는 첫 번째 목표 중에 하나는 기존의 레거시 시스템들을 잘 활용해서 새로운 애플리케이션을 만들어내자는 목표입니다.

두 번째 중요한 목표는 기존에 기업에서 제공하는 다양한 서비스를 웹을 통해서 사용자들한테 노출하는, 사용자들이 사용할 수 있게 하는 목표가 있습니다. SOA를 사용하게 되면 기존에 기업에서 제공하던 여러 Capability들을 웹을 통해서 쉽게 접근할 수 있도록 하는 장점이 있습니다.

 

 

서비스 기반 아키텍처의 목표

최근에는 실생활에 다양한 스마트기기, Internet of Things라고 부르는 IoT 기기들이 존재하게 됩니다. 이런 것들을 활용하는 차원에서도 SOA는 굉장히 유용하게 활용될 수 있습니다. 즉, 이러한 기기들을 서비스화를 해서 기존에 존재하고 있는 웹이나 클라우드에 존재하는 서비스와 서로 Integration을 합니다. 사용자가 원하는 Task를 수행할 수 있도록 하는 차원에서도 서비스 기반의 아키텍처는 매우 중요한 역할을 합니다.

 

 

서비스 기반 아키텍쳐 구성 시 발행하는 문제

먼저 굉장히 큰 기업에서 다양한 시스템들이 존재합니다. 그런 것들을 서로 연동해서 애플리케이션을 개발할 때는 여기 복잡한 분석 과정을 거치게 됩니다. 많은 경우에 있어서 개발자들이 분석하는 과정에서 굉장히 큰 문제를 겪게 됩니다. 그런 것들을 ‘분석의 마비 상태다.’ 이렇게 부릅니다. 그래서 분석이 복잡해지면 결국 결론적으로 굉장히 Flexibility가 떨어지는 아키텍처를 개발하게 됩니다.

그다음에 두 번째 문제는 이러한 분석의 복잡성을 피하기 위해서 표준 기술들을 많이 적용할 수도 있습니다. 그렇지만 굉장히 다양한 시스템이 있습니다. 그 시스템들은 굉장히 다양한 표준들을 필요로 하기 때문입니다. 너무 극단적으로 표준을 적용하게 되면 Stovepipe 시스템이 될 가능성이 있습니다.

즉, 다른 말로 하면 각각의 서브시스템마다 별도의 표준들을 따라서 개발이 되기 때문에 결론적으로는 이러한 서브시스템들이 서로 연동될 수 없는 형태가 됩니다.그래서 그러한 문제가 발생하게 됩니다. 또한 이렇게 복잡한 시스템들을 공통된 데이터 포맷으로 통일하다 보면 너무 그런 것들이 제한적이기 때문에 향후에 시스템을 확장하거나 다른 시스템과 연동하는 데 굉장히 큰 문제가 발생하게 됩니다.

이러한 복잡한 기업 시스템에서 발생하는 문제들을 해결하기 위해서 사람들이 Service-Oriented Architecture라고 부르는 기술을 적용해서 활용하고 있습니다. 먼저 서비스 기반 아키텍처를 사용하는 첫 번째 목표는 기업들에서 어떤 표준을 적용함으로써 다양한 시스템들이 잘 연동되도록 하자는 목표를 가집니다.

두 번째는 애플리케이션을 개발함에 있어서 모든 것들을 초기부터 새롭게 개발하는 것이 아닙니다. 가능하면 이미 존재하고 있는 유용한 것들, 보통 Commercial Off-The-Shelf(COSTs)라고 부르는 소프트웨어 요소들이 있습니다. 그런 것들을 가능한 잘 활용하자는 것이 두 번째 목표입니다.

그리고 세 번째 목표는 기업들은 자신들이 이미 사용하고 있는 레거시 시스템들이 있습니다. 이런 것들을 가능한 잘 활용해서 새로운 시스템과 잘 연동되도록 하자는 것이 세 번째 목표입니다.

마지막으로 네 번째는 애플리케이션들을 개발함에 있어서 자세한 데이터 포맷에 신경 쓰지 않고 Independent하게 애플리케이션을 개발함으로써 효용성을 높이자는 목표가 있습니다.

 

 

서비스 기반 아키텍처의 기본 정의

SOA라는 것을 정의할 때 ‘어떤 컴포넌트들의 집합이다.’라는 정의가 있습니다. 즉, 컴포넌트라는 것은 어떤 명사를 가지고 Publish가 돼서 그것들을 효과적으로 Discover해서, 뭔가를 구축할 수 있는 그러한 존재를 의미합니다.

즉, SOA라는 것은 어떤 명사를 통해서 검색하고 유효한 걸 찾아서 조합해서 시스템을 만들 수 있는 그러한 전체적인 틀입니다. 두 번째 정의에서는 SOA는 분산 시스템 아키텍처라고 이야기합니다.

즉, 분산 시스템 아키텍처에서는 서비스들이 각자 독립적인 서비스 Provider에 의해서 제공이 됩니다. 또한 이런 서비스들은 누구나 인터넷 혹은 네트워크 환경을 통해서 Access가 가능한 형태가 됩니다. 그리고 서비스 간에는 메시지를 교환함으로써 서로 Interaction하게 되는 구조가 어떤 분산 시스템 아키텍처로서의 SOA라고 할 수 있습니다.

서비스 Consumer는 자기가 원하는 서비스를 공급하는 서비스 Provider를 찾게 되면 그다음에는 요청 메시지를 보내서 서비스를 제공받게 됩니다. 이것이 바로 SOA의 기본 구조입니다. 즉, SOA는 두 개의 아주 중요한 Party, 중요한 Entity가 있는데 그것은 서비스 Provider 그리고 서비스 Consumer가 됩니다. 이 둘 사이에는 메시지를 교환함으로써 Interaction하게 됩니다. 메시지는 즉 서비스를 Request하는 메시지, 서비스의 결과를 전달하는 Response 메시지로 이루어지게 됩니다.

 

 

서비스 기반 아키텍처의 특징

SOA의 첫 번째 Property는 ‘Logical View를 가지고 있다.’ 입니다. 즉, 서비스라는 것은 서비스 공급자, 서비스를 소비하는 소비자 관점에서 정의가 되는 것이기 때문에 굉장히 추상적인 존재가 되겠습니다. 그래서 서비스는 이런 Logical View에서 정의가 되고 활용이 된다는 것이 첫 번째 특징이 됩니다.

주로 이러한 Logical View에서는 무엇을 하는가, 무엇을 필요로 하는가에 초점을 두게 돕니다. 두 번째 SOA의 Property는 메시지를 기반으로 Interaction입니다. Message Orientation이 되겠습니다. 이 Property는 서비스라는 것이 서로 Independent하게 제공되는 것이기 때문에 서로 굉장히 Loose하게 연결이 됩니다. 그 Loose한 연결을 메시지의 교환을 통해서 한다는 특징이 됩니다.

세 번째 SOA의 Property는 Description Orientation입니다. 이것은 어떠한 서비스가 publish가 될 때는 그것에 대한 상세한 명세가 같이 제공이 된다는 의미입니다. 이러한 명세는 메타데이터라고도 합니다. 특히 어떤 프로그램이나 머신이 읽어서 그것을 분석할 수 있는 형태, Machine-Processable한 메타데이터를 제공한다는 특징이 있겠습니다.

그다음 네 번째 특징은 Granularity, 크기입니다. 그 크기가 서비스는 일반적인 Function들에 비해 좀 더 커서 이러한 것들을 조합해서 다른 서비스들을 만들 수 있는 형태가 됩니다.

그다음 특징은 Network Orientation이 됩니다. SOA는 분산 시스템의 형태이기 때문에 네트워크가 없으면 서비스들이 서로 접근되고 연동될 수가 없습니다. 그래서 Network Orientation의 특징이 있습니다.

마지막으로 서비스라는 것은 플랫폼에 상관없이 접근해서 활용할 수가 있기 때문에 Platform Neutral입니다. 즉, XML이나 이런 플랫폼하고 상관없는 메시지 포맷을 통해서  서비스에 접근해서 그 결과를 얻을 수 있습니다.

 

https://www.w3.org/TR/ws-arch/#SOAP

 

서비스를 제공하는 Provider Entity 그리고 서비스를 제공받아서 사용하는 Requester Entity가 존재합니다. 이 둘 사이는 처음에 서로 먼저 알게 되는 과정이 필요합니다. 즉, 서비스를 제공받아야 되는 사람은 자신이 필요한 서비스를 어딘가에서 찾아 그 서비스를 제공하는 Provider를 Contact합니다.

이렇게 서로 알게 되면 그다음에는 서로 간에 어떤 Agreement가 필요합니다. 동의가 필요합니다. 즉, 서비스를 사용하는 사람이 진짜로 필요한 서비스를 서비스 Provider가 제공할 수 있는가 하는 것들을 서로 비교해서 Agreement를 하는 그런 과정이 필요합니다.

서로 어떤 동의가 이루어지면 서비스를 공급하는 Provider Entity는 어떠한 소프트웨어 형태로 만들어진 Provider Agent를 구동시켜서 Requester가 원하는 서비스의 Capability를 제공을 시작할 수 있게 됩니다.

그리고 서비스를 받는 Requester 입장에서도 마찬가지로 Client 소프트웨어가 돌아갑니다. 그걸 Requester Agent라고 합니다. 그런 Requester Agent와 서비스를 공급하는 Provider Agent는 네트워크 환경을 통해서 직접적으로 Interaction을 해서 서비스를 주고받게 되는 그러한 과정이 됩니다.