SOA(Service Oriented Architecture)

SOA(Service Oriented Architecture)

정의

IT 자원을 서비스화하여 재사용함으로 비즈니스의 요구에 빨리 대응할 수 있게 하는 아키텍처의 한 형태

자원을 재사용한다는 면에서 컴포넌트를 사용하는 개발방법과 유사하지만 표준 기반의 기술을 사용한다는 측면에서 차이가 있다

SOA가 되기 위해서는 사용할 수 있는 서비스를 Description하고 이런 서비스를 찾을 수 있는 인프라가 제공되어야 하는데 이 인프라를 ESB(Enterprise Service Bus)[1]라고 한다.

 

서비스 지향 아키텍처로 비즈니스 프로세스를 수행하는 하나의 소프트웨어 컴포넌트로 서비스들이 표준 방식에 의해 서로 느슨하게 연결(Loosely Coupled[2])되어 있어 특정 구현에 얽매이지 않은 중립적인 인터페이스이므로 특정 서비스를 변경하더라도 연결된 다른 서비스에는 영향을 전혀 미치지 않는다. 변화에 대한 빠른 대응, 민첩성 및 재활용성, 통합성으로 직결되며 즉, 표준화된 인터페이스 방식, 유연한 업무 서비스 개발 및 구현의 혁신으로 모든 기업이 추구하는 실시간 기업(Real-time Enterprise)실현을 위한 최적의 방법론으로 자리매김하고 있다.

 

SOA구성 요소

1)서비스 사용자(Service Consumer) : 서비스 제공자에 의해 제공되고 있는 하나 이상의 서비스를 사용한다.

2)서비스 제공자(Service Provider) : 서비스 사용자가 호출시 입력하는 값을 가공하여 그에 해당하는 결과를 제공한다. 경우에 따라 서비스 제공자는 또 다른 서비스 제공자의 서비스를 사용하는 서비스 사용자가 될 수도 있다.

3)서비스 중개자(Service Broker) 서비스에 대한 설명정보를 저장하고 있다. 서비스 제공자는 자신이 제공하고 있는 서비스를 등록하고 서비스 사용자는 자신의 원하는 서비스를 발견하여 사용한다.

 

SOA의 장점 :

대부분의 기업은 새로운 application이 필요할 경우 패키지 제품을 구매하거나 직접 개발하고 기존 시스템과 연결하기 위해 기업어플리케이션통합(EAI)를 사용하거나 1:1인터페이스를 직접 개발하지만 SOA 개념을 사용하면 상당수의 어플리케이션을 기존 어플리케이션의 서비스 컴포넌트를 재사용함으로써 구현할 수 있어 개발기간이 단축되고 비용이 절감되며 이기종 시스템 간 통합 구축에도 적합하다.

 

SOA의 이슈들

1)서비스 구성과 관련된 복잡한 일들을 관리하는 것

2)보안적인 문제 : 웹 서비스의 보안 표준들이 아직 확정되지 않음. 이를 극복하기 위해서 SOA를 구축할 때 높은 수준의 보안을 요구하지 않는 비즈니스 프로세스에 초점을 맞춰 천천히 진행해야 한다.

3)네트워크 모니터링 : 현재 웹 서비스 기술 표준들로는 서비스 중심의 이상적인 협업, 프로세스 조율, 모니터링 목표를 현실화 하기에는 부족한 면이 있다.

4)비용적인 문제 : 기존 시스템 아키텍처를 SOA로 구축하기 위한 리엔지니어링 비용과 높은 수준의 인력 필요

 

SOA의 특징

다른 소프트웨어 아키텍처와 차별화되는 SOA의 주요 특징

1)서비스는 발견이 가능하고 동적으로 바인딩(Dynamic Binding)된다 : 어떤 서비스를 필요로 하는 사용자는 작업 수행중(Runtime)에 필요로 하는 서비스를 찾고, 그것을 사용할 수 있다.

2)서비스는 컴포넌트와 같이 독립된 모듈이다 : 각각의 서비스는 독립적으로 개발, 유지, 관리되며 서로의 작동 자체에 큰 영향을 미치지 않는다.

3)서비스는 플랫폼에 관계없이 상호운용이 가능하다 : 각 서비스는 자신을 호출할 수 있는 인터페이스를 제공한다. 이때 호출이 이루어지는 프로토콜과 호출 메시지의 포맷만 이해 할 수 있다면 서로 다른 플랫폼 위에서도 개발, 운영 되는 서비스끼리도 통신이 가능하다.

4(서비스는 느슨하게 연결 된다 : 결합도가 높을수록 한 모듈의 변화가 다른 모듈에도 영향을 주어 파문효과(Ripple Effect)를 일으키는데 파문 효과가 클수록 시스템 유지보수는 어려워진다.

5)서비스는 네트워크 주소로 접근 가능한 인터페이스를 갖는다 : 네트워크를 통해 사용자가 서비스를 사용할 수 있게 되면 각각의 서비스는 불특정 다수의 사용자에 의해 재사용될 수 있게 된다.

6)서비스는 위치 투명성을 제공한다 : 서비스 사용자는 레지스트리에서 서비스를 찾아 바인딩 하기 전까지는 자신이 사용할 서비스의 정확한 위치를 알지 못한다. 같은 이유로 서비스 제공자가 임의의 이유로 자신의 서비스 위치를 바꾸게 되더라도 사용자는 쉽게 바뀐 위치를 서비스를 이용할 수 있게 된다.

7)서비스의 조립이 가능하다 : 모듈화된 서비스들은 하나의 완성된 기능을 제공하기 위해 조립되는데, 그 방법에는 어플리케이션에서의 조립, 서비스연합, 서비스 오케스트레이션 이라는 3가지 방법이 있다.

8)서비스는 자기 치유(Self Healing)를 지원한다 : SOA에 의해 개발된 소프트웨어가 사용하고 있는 특정 서비스가 임의의 원인에 의해 정상적인 기능을 할 수 없는 경우가 있다. 소프트웨어는 그와 같은 기능을 하는 서비스를 새로 찾아 바인딩 함으로써 자신의 내부에 있는 오류의 원인을 제거할 수 있다.

9)프로세스 중심의 아키텍처이다 : 기존의 방식과 달리 SOA에서 어플리케이션은 프로세스를 위해 개발된다. 프로세스를 비즈니스 서비스와 프로세스 서비스로 분리하기 때문에 프로세스는 단계 별로, 각각을 대표하는 비즈니스 서비스로 분해된다.. 이러한 구조는 각 어플리케이션들의 서비스 진입지점을 프로세스 서비스로 단일화하고 업무 프로세스 추적을 가능하게 해준다. 프로세스 서비스의 복잡한 제어 과정을 자동화하기 위해서 WSBPEL1 등의 표준이 개발되었다.

 

웹 서비스와의 관계

SOA는 웹 서비스 개념보다 먼저 출현하였으며, 웹 서비스 보다 포괄적인 개념이다.

SOA는 기술적인 것을 초월할 뿐만 아니라 기술로부터 독립적이다.

 

Web 2.0 과 SOA 비교

	웹 2.0	SOA
서비스 모델	- 웹 서비스	- 웹 서비스
선호하는 서비스 표준	- HTTP, XML, RSS, REST	- WSDL, UDDI, SOAP, BPEL
재사용성	- 매우 높음	- 약간 높음
유연성 및 순응성	- 매우 높음 - 단순한 데이터 포맷 - 가벼운 프로그래밍 모델	- 높음(보다 더 공식적) - 조합과 통합   (Composition and Orchestration)
비즈니스 모델	- 롱테일(Long Tail) 효과  - 네트워크 효과  - 집단지능 활용  - 고객 셀프 서비스	- BPM  - 자산통합(Asset Integration)  - 데이터 퓨전(Data Fusion)  - 래거시 자산의 생명주기 연장  - 비즈니스 활동 모니터링  - 비즈니스 지능 활용
설계 플랫폼	- AJAX  - 신디케이션(syndication)  - 멀티 디바이스 소프트웨어	- Service layer  - Service Bus  - Unit of Work
핵심역량	- 서비스로서의 SW(Saas)  - 데이터 소스에 대한 통제  - 공동개발자로서 사용자 신뢰  - 집단지능 이용  - 롱테일 효과  - 단일 디바이스(PC플랫폼)을    넘어선 소프트웨어  - 가벼운(lightweight) UI,    개발모델, 비즈니스모델 채용	- 기능의 재정비  - 자산(Asset)으로서 데이터  - 접근가능성  - 시스템/데이터 통합  - 비용절감  - 비즈니스 기민성(Agility)  - B2B 셀프서비스  - 오픈스텐다드  - 온톨로지(ontologies)  - 오퍼레이션의 투명성  - 소비자 중심의 비즈니스 프로세스

 

---

[1] ESB(Enterprise Service Bus): 일종의 미들웨어로 기존 시스템의 연동 기능을 제공하는 EAI와 유사한 기능을 제공하고 있지만 EAI가 제공하는 업체가 사용하는 벤더 종속적인 기술을 사용하는 반면, ESB는 표준 기반의 기술을 사용한다는 측면에서 EAI와 가장 큰 차이가 있다.

[2] 느슨한 연결(Loosely coupled): 잘 정의된 인터페이스들을 사용해 서비스들을 연결하는 것. 이 방법을 사용하면 1개 서비스를 손보더라도 이 서비스에 연결된 다른 서비스들을 손볼 필요가 없어진다.