[펌] SOA소개 - 가트너 14 April 2003

 

Strategic Planning, SPA-19-5971 Research Note

 

Y. Natis, R. Schulte 14 April 2003

 

서비스 지향 아키텍처 소개

 

웹 서비스의 모멘텀에 이끌려 서비스 지향 아키텍처는 첨단 소프트웨어 프로젝트에서 주류로 위상을 옮기게 될 것이다. 하지만 대부분의 기업들이 SOA의 이점에 대해 혼란을 느끼고 있고 리스크는 제대로 이해하지 못하고 있다.

서비스 지향 아키텍처(SOA)는 클라이언트/서버 소프트웨어 설계 방식으로서 이 설계 방식에서 애플리케이션은 소프트웨어 서비스와 소프트웨어 서비스 소비자(또는 클라이언트나 서비스 요청자)로 구성된다. 소프트웨어 구성 요소들간의 느슨한 결합을 중시하고 별도의 독립적 인터페이스를 사용한다는 면에서 SOA는 비교적 보편화된 클라이언트/서버 모델과는 차이가 있다.

 

SOA 원리는 애플리케이션 설계, 개발 및 배치 중에 반영된다. 이들은 봉입과 유연한 결합이라는 필수 원칙은 공유하지만 자세히 보면 차이가 있다. SOA의 근본 의도는 새로운 실시간 상황에서 소프트웨어 구성 요소(서비스)를 독립적으로 재활용하는 것이다. SOA의 설계와 개발은 이러한 기민한 실시간 환경의 확보를 목적으로 수행된다.

 

서비스 인터페이스는 SOA 설계의 정수

설계에서 서비스는 서로 구분되어 정의된 한 쌍의 요소들(서비스 인터페이스와 서비스 구축)로 표현되는 포장된 비즈니스 소프트웨어 구성 요소들이다. 인터페이스는 서비스에서 근본적이고 일정한 구성 요소이다. 서비스는 항상 다른 소프트웨어 구성 요소(서비스 소비자)로부터의 프로그램 액세스를 위해 존재한다. 서비스 인터페이스는 서비스에 대한 프로그램 액세스 "계약"을 정의한다.
서비스 구현은 서비스의 비즈니스 기능을 충족시킨다. 설계 작업의 구체화 수준에 따라 서비스 구현은 개발 도중에 시험해 보아야 할 "블랙 박스"로 남을 수 있다. 그 밖의 경우에는 새로운 모듈로서 이전 SOA 모듈에 대한 숨겨진 액세스 또는 새롭고 선행하는 소프트웨어 모듈에 대한 복수의 조건부 호출의 합성물이 될 것이다

서비스 구현의 설계는 SOA의 설계에서 부차적인 문제이지만 서비스 인터페이스의 설계는 중요하다. SOA는 근본적으로 서비스 인터페이스의 흐름 및 관계이다. SOA의 설계에는 서비스 인터페이스간, 그리고 서비스 인터페이스와 서비스 소비자 사이의 인터랙션과 서비스 인터페이스에 대한 정의가 관련된다.

 

블랙 박스적 속성은 서비스에 필수적이다.

서비스 인터페이스는 서비스의 정체성과 서비스 호출의 규칙을 수립하는 계약이다. 서비스 인터페이스는 내부 디자인 및 컨텐츠를 고려하지 않고 서비스를 규명(찾고 이해함)하고 사용할 수 있기에 충분한 수준의 정보를 갖고 있어야 한다. 블랙 박스적 성격은 서비스에 필수적이다. 이는 모든 입력 데이터, 모든 응답 데이터(응답 데이터가 있는 경우), 그리고 발생된 모든 예외적 조건들이 인터페이스에 기록되어야 함을 의미한다. 또한 서비스의 목적과 함수를 파악하기 위해 인터페이스에 충분한 메타 데이터가 제공되어야 함을 의미한다. 서비스의 이름에 의존하는 것은 수용할 수는 있지만 약한 형태의 아이덴티티이다. 서비스의 기능을 정의하는 검색할 수 있는 저장소는 보다 세밀한 밀도로 수많은 서비스를 지원할 수 있고 많은 수의 독립적 소스로부터 올 수 있다.
느슨한 결합은 SOA를 기본적인 소프트웨어 모듈와와 차별화시킨다.
SOA는 느슨하게 결합된 형태의 서비스와 서비스 소비자 배치이다. 설계에서 느슨한 결합이란 서비스를 특정 서비스 소비자에게 유사하게 설계하지 않는다는 것을 의미합니다. 서비스 내부에서는 서비스 소비자의 목적, 기술 특성 또는 비즈니스 성격과 관련한 어떤 정보도 전제되지 않는다. 따라서 서비스는 서비스 소비자와 완전히 분리된다.
하지만 서비스 소비자는 서비스에 종속되어 있다(다시 말해 서비스 인터페이스에 대해 엄밀한 의미에서의 참조가 내장되어 있다). 따라서 SOA는 어느 정도는 결합된, 즉 느슨하게 결합된 아키텍처이다. SOA는 모든 참여 소프트웨어 구성 요소들이 다른 구성 요소들과 분리되어 있다는 면에서 사건 기반(event-driven) 아키텍처와 다르며, 모든 소프트웨어 구성 요소가 최초 의도했던 맥락에서만 작동하도록 설계된다는 면에서(다시 말해 논리적으로 타이트하게 결합된) 단일형 아키텍처(monolithic architecture)와 차이가 있다.
설계 당시의 느슨한 결합은 서비스 인터페이스를 비 침해적 재사용을 가능케 하기 때문에 SOA에 필수적이다. 하지만 툴들로는 설계 과정에서의 느슨한 결합을 보장할 수 없다. 논리적으로 서비스 소비자에게 묶이도록 잘못 설계된 서비스는 SOA 스타일의 기술을 사용하고서도 애플리케이션을 단일형 아키텍처로 만들 수 있다.

 

서비스의 최적 입도는 사용, 툴 및 기술에 좌우된다.

서비스 인터페이스는 여러 개의 엔트리 포인트(메소드) 또는 한 개의 엔트리 포인트를 나타내도록 디자인된다. 고객 관리는 여러 개의 메소드를 노출시키는 서비스의 예가 될 수 있다(예를 들어 고객을 만들고 삭제하거나 고객 정보를 수집). "고객 정보 수집" 메소드는 그 자체로 단일 엔트리 포인트를 갖는 완전한 서비스가 될 수도 있다. 최적의 서비스 인터페이스 입도는 많은 요소들에 좌우된다("Service-Oriented Integration Architectures for Healthcare" 참조).
서비스 인터페이스 개념은 SOA 개발의 핵심이다.
개발 과정에서 서비스 인터페이스는 별개의 독립적인 인터페이스 정의 파일로서 표현된다. 설계 과정에서와 마찬가지로 서비스 인터페이스는 SOA의 필수 구성 요소로 남는다. 인터페이스 파일은 합의된 모든 구문론을 사용해 정의할 수 있지만 표준 기반 구문론을 사용할 경우 서비스의 폭 넓은 도입을 활성화시킬 수 있다.
웹 서비스 기술 언어(WSDL; Web Services Description Language)를 사용해 서비스 인터페이스를 인코딩할 때 서비스는 웹 서비스이다.
WSDL은 새로운 개발 툴 대부분에서 서비스 인터페이스 정의를 위해 사용되는 추천 표준이다. 초기의 SOA 개발은 CORBA IDL(Interface Definition Language), COM/DCOM Microsoft IDL(MIDL), CICS(Customer Information Control System) COMMAREA(common area) 및 기타 좁은 범위로 정의된 사양들을 바탕으로 했다.
전형적인 SOA 애플리케이션 개발 프로세스는 인터페이스 정의로 시작되고 그 뒤에 서비스 구현 소프트웨어와 서비스 소비자 소프트웨어의 개발이 뒤따른다. 대부분의 개발 툴들은 인터페이스 정의의 정확한 언어를 숨기지만 SOA 지향 툴들의 개발 방식은 서비스 인터페이스의 정의, 발견 및 상호 연결을 중심으로 남는다.
서비스 구현 소프트웨어는 고유한 아키텍처를 갖고 있다.
개발 중에 서비스 구현은 어댑터를 통해 오래 된 애플리케이션에 연결하는 새로운 프로그램 또는 래퍼이거나 여러 개의 기존 및 새 프로그램들이 조건적으로 통합된 형태가 될 수 있다. 서비스 구현 개발은 단순히 새로운 프로그래밍 시도, 순수한 레거시 래핑 및 수정, 또는 애플리케이션 통합 시도가 될 수 있다. 각각의 작업을 위해서는 서로 다른 툴과 개발 기법이 필요하다.

충분한 서비스 분리가 이루어지지 못할 경우 결과적으로 애플리케이션이 단일 체제로 된다.

개발 과정에서의 느슨한 결합에는 여러 상황에서 호출할 수 있는 프로그래밍 서비스 구현이 필요하다. 서비스 구현 소프트웨어 개발자들은 서비스의 핵이 새로운 상황에서 재사용될 수 있는가 여부라는 점을 이해해야 한다. 서비스 구현은 서비스 소비자의 기술이나 비즈니스 로직에 관한 어떤 가정도 해선 안 된다. 하지만 툴들은 이러한 요건을 강요할 수 없다. 개발자와 개발자들의 프로젝트 리더들은 서비스 구현의 분리성을 보장해야 한다. 서비스 구현 내부 설계의 분리가 제대로 이루어지지 못할 수록 서비스 재사용 비용이 비싸질 것이다. 충분한 분리가 이루어지지 못하면 SOA 툴과 미들웨어를 사용하더라도 서비스 구현의 재사용이 힘들어지며 최종 애플리케이션이 단일 체제 형태가 된다.
독립적인 서비스의 조합을 위해선 통합이 필요하다.
서비스 분리는 재사용을 가능케 하지만 복잡성이 증대된다. 독립적인 서비스는 독립적이지만 충돌 가능성이 있는 정보와 프로세스 모델을 갖게 된다. 이는 서비스의 조화 유지를 힘들게 만든다. 대부분의 경우 서비스 조합을 위해선 서비스 간 차이점을 해결하고 공통된 상황과 오류 해결을 위해 별도의(통합) 기술이 필요하다.
실시간 SOA는 동적으로 재사용할 수 있는 전사적 범위의 소프트웨어 구성 요소에서 명확하다.
실행 중에 서비스 인터페이스는 일반적으로 인터페이스 정의 파일로부터 개발 툴에 의해 생성되지만 수작업에 의해 개발되어 개발 과정에서 다른 소프트웨어에 내장되기도 하는 서비스 인터페이스 스텁과 서비스 인터페이스 프록시 등 한 쌍의 프로그램으로 유지된다.

이 스텁은
 . 서비스 구현용 서버에 배치된다.
 . 서비스 구현에 적합한 로컬 커뮤니케이션 메소드와 데이터 인코딩을 사용해 서비스 구현과

      상호 작용한다.
    . 프록시는 서비스 소비자에 로컬로 배치된다.
 . 서비스 소비자의 구현에 적합한 로컬 커뮤니케이션 메소드와 데이터 인코딩을 사용해 서비스

      소비자와 상호 작용한다.

 

일반적인 예로는 Java 서블릿으로서의 스텁과 Visual Basic 구성 요소로서의 프록시를 들 수 있다. 이 프로그램 쌍은 서비스 인터페이스를 구현한다. 모든 새로운 실시간 애플리케이션은 자체 인터페이스 프록시를 통해 서비스에 액세스하여 서비스의 비 침해적 실시간 재사용을 제공한다.

 

서비스 스텁과 서비스 프록시 커뮤니케이션에서 SOAP가 재사용될 때 서비스는 웹 서비스이다.
이론적으로 생성된 인터페이스 스텁과 프록시 모듈 쌍은 서비스 인터페이스 매개 변수를 전달하기 위해 XML, SOAP 메시지 인벨로프, HTTP, 메시지 지향 미들웨어(MOM) 또는 공유 메모리를 사용한다.
서비스 스텁과 서비스 프록시 커뮤니케이션은 "사적인 비즈니스"이지만 벤더의 형태와 툴 독립성을 유지하기 위해 대부분의 생성 툴은 표준 프로토콜을 사용해 연결을 한다. 하지만 실제로 "표준" 프로토콜은 자동적인 상호운용성을 보장할 정도의 "표준" 자격은 갖고 있지 못하다. 성능 최적화를 위해서도 덜 표준적이면서 융통성이 좋은 커뮤니케이션 프로토콜을 사용할 필요가 있다. 따라서 표준에도 불구하고 2006년까지 서비스 인터랙션을 위해 서비스 스텁 및 서비스 프록시 인코딩 구현의 조정이 필요해질 것이다(확률: 80%).

실시간에서 기술적으로 느슨한 결합은 HTTP 또는 MOM과 같이 기반이 되는 "sessionless" 커뮤니케이션에 의해 이루어진다. 이 낮은 수준의 느슨한 결합은 서비스를 논리적인 느슨한 결합으로 설계하고 개발한 경우에만 효과적이다. 그렇다면 느슨하게 결합된 미들웨어 사용은 새로운 서비스 소비자의 동적인 실시간 추가를 허용한다(즉, 기존 시스템에 사실상의 아무런 영향도 주지 않으면서 실행 중인 시스템에 새로운 사용자 경험을 추가함). 아니면 느슨하게 결합된 미들웨어가 전체 시스템을 위해 더 큰 처리 능력을 제공하겠지만 시스템의 민첩성은 높이지 못한다.
SOA의 실시간 미들웨어는 견고하게 결합된다(예: Java Reomote Method Invocation(RMI) 또는 Microsoft .NET 리모팅). 서비스 설계 및 개발이 논리적으로 느슨하게 결합되면 밀접하게 결합된 실시간 미들웨어에 관계 없이 SOA가 갖고 있는 민첩성이 실시간으로 구현된다.

 

SOA가 항상 올바른 아키텍처인 것은 아니다.
SOA는 체계적인 애플리케이션 엔지니어링에 유용하다. 특히 요청/응답이 소프트웨어 구성 요소들 간의 자연스런 관계 패턴인 환경에서는 더욱 그러하다. 하지만 SOA는 추가적인 설계 및 개발 시도를 희생함으로써 가능해지며 또한 미들웨어 결합의 필요성이 수반된다. 짧은 시간 동안 사용할 제한적 범위의 애플리케이션들은 가용 수명 기간 중에 비즈니스 로직을 재사용하거나 변경하지 않기 때문에 SOA로부터 아무런 혜택도 받지 못한다. SOA는 또한 비 동기 단방향 인터랙션을 사용하는 애플리케이션 용으로는 좋지 않다. 여기서 SOA의 느슨한 결합은 불필요하고 바람직하지도 않다.
결론: 서비스 지향 아키텍처는 요청/응답 패턴의 애플리케이션을 체계적으로 설계하는 데 있어서는 추천할 만한 아키텍처이다. SOA의 주요 목적은 비즈니스 레벨에서의 소프트웨어 모듈화 및 새로운 환경에서의 빠르면서도 비 침해적인 비즈니스 소프트웨어 재사용에 있다. 사용자들은 SOA의 정수를 이해하고 그와 동시에 장단점을 제대로 인식해 현대적인 전사적 IT의 전체 아키텍처에서 SOA가 어떤 역할을 하는지 파악해야 한다.