SOA:Software-Oriented Architecture

Architecture

by jeonghojin 2022. 2. 24. 01:11

* 학습목적으로 정리해놓은 내용입니다. 하단에 출처 표기

SOA 란,

서비스 인터페이스를 통한 소프트웨어 컴포넌트의 재사용을 가능하게 하는 방법을 말한다. 이러한 인터페이스는 매번 깊은 통합을 수행하지 않고도 새 애플리케이션에 빠르게 통합될 수 있는 방식으로 공통 통신 표준을 활용한다.

즉, 개별적인 비즈니스 기능 단위로 묶어서 표준화된 호출 인터페이스를 통해 서비스라는 소프트웨어 컴포넌트 단위로 통합하여이 서비스를 조합하여 업무 기능을 구현한 애플리케이션을 만들어내는 소프트웨어 아키텍처이다.

또한, 기존의 시스템이 각각의 독립된 업무 시스템으로 개발되어왔던 반면 SOA는 기업의 전체 업무가 하나의 거대한 SOA 시스템으로 구성이 된다.

SOA가 1990년대 후반에 등장하기 전에는 애플리케이션을 다른 시스템에 있는 기능또는 데이터에 연결하려면 복잡한 지점간 통합, 즉 개발자들이 각각의 새로운 개발 프로젝트에 대해 부분적으로 또는 전체적으로 재작성해야 했던 통합이 필요했다.

SOA의 등장 이후 서비스 인터페이스의 느슨한 결합이 가능하다. 이는 아래에 구현되는 방법에 대한 지식이 거의 없거나 전혀 없이 호출될 수 있다. 서비스는 데이터 읽기 또는 변경 요청의 전송을 위해 SOAP(Simple Object Access Protocol)/HTTP 또는 JSON/HTTP 등의 표준 네트워크 프로토콜을 사용하여 노출된다.

서비스 인터페이스를 이용하여 새로운 업무를 구현할 때 새롭게 시스템을 신규 개발하는 것이 아니라 기존의 이미 제공되어 있는 서비스들을 조합하여, 하나의 업무를 구현할 수 있다. 이것이 SOA의 기본적인 개념이다.

SOA는 소프트웨어의 재사용성, 레고웨어의 연장성에 있는 것이다.

* 레고웨어 : 주.소프트웨어 모듈을 레고블럭처럼 재 사용성이 높은 단위로 구성한 후, 애플리케이션을 마치 레고 블록을 조립해서 하나의 조립물을 만들듯이 제작하는 개념

SOA가 주목받는 이유는 무엇인가?

예전에 서비스 구축을 위한 표준 인터페이스에 대한 방안으로 제시되었던 CORBA등의 기술의 난이도가 높은 점이 문제가 되어 왔으나 현재에는 XML/HTTP나 SOAP 기반의 웹서비스 기술등의 등장으로 서비스의 구현의 기술 난이도 문제가 해결되었고,

e비즈니스 환경에서 기존 업무 환경을 전산화하는데에만 목적이 맞춰져 있어서 각각의 업무별로 독립된 시스템의 형태로 개발되어, 이에 대한 통합이 필요하게 되었으며 [예를 들어 고객 정보를 매출 내용과 연계하여 판매 전략을 수립하는 경우 등]

급격한 비즈니스 환경의 변화에 따라 비즈니스의 요구를 민첩하게 IT시스템에 반영되어야 할 필요성이 대두됨에 따라 이에 대한 대안으로 SOA가 주목받게 되었다.

* CORBA : 네트워크에서 분산 프로그램 객체를 생성, 배포, 관리하기 위한 구조와 규격.

네트워크 상 서로 다른 장소에 있고 여러 벤더들에 의해 개발된 프로그램들이 '인터페이스 브로커'를 통해 통신하도록 해준다.

SOA는 크게 서비스와 이를 조합하여 애플리케이션을 구성하는 것 으로 구성된다.

서비스란?

서비스란 플랫폼에 종속되지 않는 표준 인터페이스를 통해 비즈니스적인 의미를 가지는 기능들을 모아놓은 소프트웨어 컴포넌트를 의미한다.

ex_ 임진원 정보 서비스, 계좌이체 서비스, 상품 주문 서비스

일반적으로 SOA에서 정의하는 서비스는 비즈니스 서비스를 의미한다.

서비스 구성

서비스 인터페이스
서비스 규약
서비스의 구현체

서비스 인터페이스는 서비스 내의 하나의 업무 기능을 이야기한다.

즉, 주문 서비스라는 서비스가 있을 때, 이 서비스는 '상품 주문'과 '주문 내용 조회'라는 인터페이스를 가진다.

그리고 이 서비스를 사용하기 위한 여러가지 규약들 데이터 포맷이나 변수형 서비스를 호출하기 위한 인자나 인터페이스 이름등이 정의되는 곳이 서비스 Contract이다.

이에 대한 실제 구현체가 Implementation 이다.

현대의 SOA에서는 대부분이 웹서비스를 표준 인터페이스로 사용하기 때문에 서비스 Contract는 WSDL로 정의된다.

* WSDL : 웹 서비스 기술언어 또는 기술된 정의 파일의 총칭으로 XML로 기술된다. 웹 서비스의 구체적 내용이 기술되어 있어 서비스 제공 장소, 서비스 메시지 포맷, 프로토콜 등이 기술된다.

서비스의 특징

수직적 분할(Vertical Slicing)

애플리케이션을 여러 개의 서비스로 나누고 각각의 서비스를 독립적으로 개발하는 것을 말한다.

이전 소프트웨어 개발은 애플리케이션을 각 Data Layer, Business Logic, View Layer와 같이 수평적으로 분리하였다.

그러나 SOA 에서는 각각의 서비스가 Data Layer, Business Logic, View에 대한 모듈을 모두 가지고 있고 그래서 각 서비스간의 의존성이 최소화 된다.

느슨한 결합(Loosley Coupled)

각 서비스 컴포넌트들은 다른 서비스에 대해서 의존성이 최소화되어 있어서 서비스의 구현 내용을 변경하였을 때 다른 서비스는 이에 거의 영향을 받지 않는다.

표준 인터페이스 기반(Has Standard Interface)

서비스가 제공하는 인터페이스는 표준 기술로 구현되어야 한다. 서비스를 사용하고자 하는 사람이 '서비스 규약' 만을 가지고도 해당 서비스를 호출할 수 있어야 한다. 또한, SOA 시스템 내에서 플랫폿이나 기술에 종속되지 않아야 한다.

조합 가능(Composable)

서비스형 컴포넌트들은 서로 연결되어 하나의 조합된 형태의 애플리케이션을 구성해야하기 때문에, 서비스간에 연결 및 조합이 가능해야 한다.

Coarse grainned

서비스의 구성단위나 인터페이스의 단위는 업무 단위를 기본으로 한다. IT 개발 조직이 아니라 현업의 비즈니스 조직이라도 해당 서비스가 무엇이고 무슨 기능을 하는지 이해할 수 있어야 한다.

Discoverable

서비스에 대한 정보가 검색 가능해야 한다. SOA 시스템의 규모가 증가함에 따라 서비스의 중복 발생할 수 있고, 이를 방지하기 위해서 이미 구현된 서비스가 있는지를 검색할 수 있어야 하며, 검색 내용에는 서비스의 내용과 서비스에 대한 사용방법, 권한, 보안에 대한 정보들이 포함되어야 한다.

SOA 아키텍처 모델

서비스의 구성 방법은 기업의 SOA 성숙도와 발전 정도에 따라 단계적으로 적용되어야 한다.

application front end 서비스들이 사용되어 최종 사용자에게 보이는 곳. 일반적인 웹사이트나 기업 포탈, X 인터넷 클라이언트

1. Fundamental SOA[통합]

가장 기본적인 형태의 SOA로 비즈니스 서비스와 애플리케이션 서비스만 존재하며 이 서비스들의 조합들은 application front end에서 이루어진다.

Fundamental SOA의 가장 큰 목적은 기존의 시스템을 각각 서비스화하는 것과 독립되었던 시스템들을 통합하여 하나의 시스템으로 운영한다는데 목적이 있다.

2. Networked SOA[유연성과 통제 추가]

서비스화하여 통합된 SOA 시스템은 크기가 증가됨에 따라 서비스와 Front-End 사이에 연결이 복잡해진다.

그리고 서비스의 내용이 변경 또는 보강되어 가면서 의존성에 의해서 서비스 간에 수정이 필요한 경우가 발생한다. 이는 서비스의 변화를 어렵게 만들고 결과적으로 기업 업무에 대한 '경직성'을 유발하는데, 이를 해결하기 위해서 모든 서비스들을 중앙에 하나의 버스를 통해서 관리하여 서비스간 연결의 복잡도를 해소하고 Intermediary 서비스를 추가함으로써, 서비스의 내용이 변경되었을 때 그 차이를 보강해줄 수 있어야 한다.

이렇게 중앙에 버스 역할을 하는 것이 Enterprise Service Bus(ESB) 이고, 여기에는 서비스에 대한 모니터링과, Intermediary 서비스 기능의 제공, 위치에 대한 투명성 제공을 통해서 기본적인 '통제'와 '유연성' 제공을 특징으로 한다.

3. Process Oriedted SOA[민첩성의 추가]

기업의 업무 프로세스가 자주 변화가 되고, IT 시스템이 이에 민첩하게 반응해야 하거나, SOA로 구현해야 하는 기업 업무들에 복잡한 업무 플로우가 존재할 경우 이 업무 프로세스들을 BPM 기반으로 구현하는 SOA를 고려해볼 수 있다.

각 서비스를 조합하는 것을 BPM으로 구현함으로써, 업무의 조합이 별도의 코딩없이 BPM 툴로 이루어지게 되고, 업무 프로세스가 바뀌었을 떄 BPM 툴에서 업무 프로세스를 조정하는 것만으로도 빠르게 비즈니스 조직의 요구에 대응하여 IT 시스템이 비즈니스 업무에 대한 민첩한 대응력을 확보할 수 있다.

또한 업무 조직과 기술 조직간의 의사소통에 있어서도, 기존에 업무조직은 EJB나 JAVA와 같은 기술적인 내용을 이해하지 못하였고, 기술조직의 경우 업무에 대한 이해도가 낮았기 떄문에 의사소통에 있어서 많은 문제를 유발하였는데, BPM을 도입할 경우, 이 BPM에서 사용되는 모든 서비스는 이미 '업무적인 의미를 가지는 컴포넌트'이기 때문에 IT 조직과 업무 조직간에 의사소통을 하는데 문제가 없으며, 특히 업무 프로세스의 경우 직접 업무 조직이 큰 흐름을 정의하고 IT 조직이 구현화에 있어서 보강만 함으로써 빠르고 정확한 의사소통을 이룰 수 있다.

BPM과 함께 생각할 수 있는 것이 BPA(Business Process Analysis)와 BAM(Business Activity Monitoring)이다. BPA는 실제 업무 플로우를 BPM으로 구현하기 전에 업무팀에서 해당 업무 플로우에 대한 설계를 하고 이에 대한 시뮬레이션을 할 수 있는 Business Process 분석 설계 도구이다.

BPA를 통해서 현 업무팀에서 해당 업무프로세스를 정의하고, 작동 내용을 시뮬레이션 함으로써 보다 완성된 업무 프로세스를 얻을 수 있으며, 이렇게 설계된 업무 IT 개발팀에 의해서 BPM으로 변환이 된다.

BPM으로 변환된 업무는 SOA 시스템에 반영되어 실제 운영이 되게 되고,

BAM이라는 비즈니스 프로세스 모니터링 도구를 이용하여 반영된 BPM에 대한 평가가 이루어진다. 이 평가를 기반으로 업무팀에서는 다시 BPA를 이용하여 해당 업무의 최적화를 수행하고 다시 이는 BPM으로 구현이 된다. 이러한 반복을 통해서 업무의 개선과 SOA 시스템이 최적화를 이룰 수 있다.

* BPA : 비즈니스 프로세스의 자동화 및 다양한 비즈니스 시나리오들에 대한 분석을 수행하는 기능

* BPM : 조직 및 경영 관점에서 조직 내 프로세스와 조직 간 프로세스를 통합적으로 관리하는 솔루션으로, 워크플로우 기술에

EAI 또 WEB서비스 기술을 접목시킨 개념

* BPM 의 목적 : 시스템 통합 및 일상화된 업무의 자동화, 비즈니스 프로세스 모든 과정의 통합적 관리와 가시성 및 통제력을 제공

* BAM : 업무 운용의 속도 및 효율을 극대화하기 위해 주요한 업무 성능 지표를 실시간으로 접근하는 기능

SOA 아키텍처 모델의 구현

Fundamentals SOA, Networked SOA, Process Oriented SOA 아키텍처를 실제로 구축하는데 있어서 고려할 사항이 있다.

1. 서비스화

먼저 Fundamental SOA에서 가장 중요한 것은 기존의 시스템을 '서비스화' 시키는 것이다. 현재의 서비스 인터페이스는 대부분 SOAP기반의 웹서비스를 사용하는데, 솔루션 중에는 이미 Legacy System에 대해서 웹 서비스를 제공하는 '서비스 어답터'가 제공된다.

(SAP, Siebel 어답터, EAS의 Tuxedo 웹서비스 어답터 SALT etc)

대부분의 서비스 어답터를 통해서 서비스화 된 '기존 메서드'들은 비즈니스 적인 의미를 가지지 않는 Application 서비스가 될 가능성이 많다. 서비스화를 하기 전에 기존 시스템에 기능을 업무 단위의 Coarse grainned된 컴포넌트로 묶은 후에 서비스화 하는 것이 좋다.

2. 스펙과 범위

고려사항 중 하나가 트랜잭션이나 Reliable 메시징과 같은 웹 서비스 스펙에 해당하는 문제이다. 현재 웹서비스의 확장 규약인 WS*(Webservice Extention)의 경우에는 트랜잭션이나 Reliable Messaging과 같은 기능들을 제공하고 있지만 문제는 서비스화를 시켜주는 솔루션에는 이에 대한 지원이 의무사항이 아니라는 것이다.

즉, 트랜잭션 기능들을 웹 서비스에서 지원하는 기능을 사용하려고 했다가 막상 해당 시스템의 웹 서비스에서 트랜잭션 기능들을 지원하지 않아서 문제가 될 수 있다. 서비스를 정의할 때 어떻게 이런 기능들을 구현할지에 대한 고려가 앞서야 한다.

* WS-ReliableMessaging : 소프트웨어 구성 요소, 시스템 또는 네트워크 장애가있는 경우 분산 응용 프로그램간에 SOAP 메시지를 안정적으로 전달할 수있는 프로토콜

이런 서비스 구현에 있어서 유용하게 사용할 수 있는 것이 EAI이다. EAI는 시스템 간의 통합을 목적으로 하는 솔루션으로, SOA는 다르게 Tightly Coupled 되고 비즈니스적인 통합이 아니라 IT 시스템간의 통합을 지원함으로써, SOA 통합에서 다루기 힘든 트랜잭션이나 보안에 대한 내용을 해결해준다.

[EAI 솔루션에도 IT 시스템 간의 연계 흐름을 정의하기 위해서 BPM이 사용되는데, 시스템 간의 흐름과 업무 흐름을 분리하기 위해서 이를 각각 IC-BPM가 HC-BPM으로 구분하여 부른다.]

3. 보안

암호화 선택할 때는 전체 메시지를 암호화할지 메시지 내용 중 일부만 암호화 할지를 결정해야 하며, 중앙에서 각 서비스에 대한 사용권한과 계정에 대한 관리를 할 수 있는 솔루션을 구성할 필요가 있다.

4. 모니터링

여러 시스템을 하나의 SOA 시스템에 구축한 만큼 각각의 서비스에 대한 모니터링과 성능 측정은 매우 중요한 요소로 작용한다.

SOA 시스템을 구축할 때 로깅과 모니터링 성능 측정에 대한 기능을 미리 구현할 필요가 있다.

5. 서비스검색

SOA 시스템에서 이미 개발된 서비스를 재사용하기 위해서 검색할 수 있어야 하며, 서비스에 대한 메타 정보(보안, 과금체계 등에 대한 규약 등)들도 검색할 수 있어야 한다. 웹서비스에서는 이를 UDDI로 구현한다.

* UDDI : 웹 서비스 관련 정보의 공개와 탐색을 위한 표준. 서비스 제공자는 UDDI라는 서비스 소비자에게 이미 알려진 온라인 저장소에 그들이 제공하는 서비스 목록들을 저장하게 되고, 서비스 소비자들은 그 저장소에 접근함으로써 원하는 서비스들의 목록을 찾을 수 있게 된다.

6. Application-front-end

Application Front End 는 최종 사용자에게 업무 기능을 제공하는 부분으로, 일반적인 웹 인터페이스를 이용할 수도 있으며, Rich Client의 개념을 웹에 도입한 AJAX 기반이나 Flex와 같은 X-Internet 솔루션을 사용할 수도 있다.

단, SOA시스템은 여러 시스템을 통합한 것으로 여러 메뉴와 UI가 통합되기 때문에 권한과 메뉴 등에 대한 관리 기능이 필요하게 되며, 이는 Enterprise Portal(EP) 솔루션 등을 이용해서 쉽게 구현할 수 있다.

Coarse-Grained
하나의 작업을 큰 단위의 프로세스로 나눈뒤, "Single Call"을 통해 작업 결과를 생성해내는 방식
* Distributed System 상에서 유용

Fine-Grained
하나의 작업을 작은 단위의 프로세스로 나눈뒤, 다수의 호출을 통해 작업 결과를 생성해내는 방식
* Flexible System