Jay G.’s weblog

WOA = SOA + WWW + REST

웹 2.0의 등장과 함께 엔터프라이즈 시장도 변화하고 있다. 복잡한 웹 서비스(Web Services) 기술과 WS-* 표준으로 대표되던 SOA(Service-Oriented Architecture)에 웹 2.0의 가벼운 프로그래밍 모델(Lightweight Programming Models)을 접목시키는 시도도 이러한 변화중 하나이다.

민첩성(Agility)과 재사용성(Reusability)이 중요한 엔터프라이즈 환경에서 지난 몇 년간 SOA는 가장 각광받는 패러다임 중 하나였다. 하지만 그 기대와 달리 ROI에 대한 회의적 시각과 구현의 어려움은 SOA의 확산을 가로막았다. 그리고 결국 사람들은 웹 “서비스”가 아닌 “웹” 서비스를 선택했다.

Web-Oriented Architecture

2005년 가트너(Gartner)의 닉 갈(Nick Gall)은 웹 기반의 SOA에 WOA(Web-Oriented Architecture)라는 이름을 붙인다.

WOA = SOA + WWW + REST

하지만 공식적인 정의나 의미에 대한 명확한 합의없이 WOA는 논란에 휩싸인다. 다이온 힌치클리프(Dion Hinchcliffe) 등 몇몇 전문가들이 WOA를 정의해 보았지만, 전문가들 사이에도 조금씩 이견은 있었다. 그리고 마침내 지난 11일 가트너가 WOA에 대한 공식적인 문서를 발행한다.

WOA는 웹의 아키텍처를 기반으로 전세계적으로 연결된 하이퍼미디어를 통해 시스템과 사용자를 통합하는 SOA의 아키텍처 서브스타일이다. WOA는 다음의 다섯가지 기본적인 인터페이스 제약을 통해 글로벌 네트워크 효과를 얻기 위한 인터페이스(UI와 API)의 일반성(Generality)을 강조한다.

1. 리소스의 식별(Identification of resources)
2. 표현을 통한 리소스의 조작(Manipulation of resources through representations)
3. 자기설명적 메세지(Self-descriptive messages)
4. 하이퍼텍스트를 어플리케이션 상태의 엔진으로(Hypermedia as the engine of application state)
5. 어플리케이션 중립성(Application neutrality)

저자의 말처럼 WOA의 5가지 인터페이스 제약 중 처음 4가지는 REST의 단일 인터페이스 제약(Uniform Interface Constraints)과 동일하다. 하지만 마지막의 어플리케이션 중립성이 새롭게 추가되었다.

Application Neutraility

SOA의 가장 중요한 목표 중 하나는 재사용성(Reusability)을 극대화하는 것, 다시 말해 확장성(Scalability)을 보장하는 것이다. 그리고 확장성있는 시스템은 미들아웃(Middle Out) 아키텍처를 통해 구축할 수 있다.

미들아웃 아키텍처는 탑다운(Top Down)이나 바텀업(Bottom Up) 방식이 아니라, 가운데 추상화된 인터페이스를 먼저 설계하고 이를 바탕으로 위, 아래 양방향으로 확장하는 방식을 말한다. 이때 인터페이스는 IFaP로 불리는 식별자(Identifier), 포맷(Format), 프로토콜(Protocol)의 조합으로 구성된다.

인터넷은 미들아웃 아키텍처의 대표적인 예이다. 인터넷의 인터페이스는 IP 주소, IP 패킷, IP 프로토콜로 구성되며 각각은 식별자, 포맷, 프로토콜의 역할을 한다. 그리고 이를 바탕으로 지난 35년간 인터넷은 웹, VoIP 등 다양한 어플리케이션과 함께 리눅스 같은 새로운 플랫폼으로 확장되어 안정적인 서비스를 제공해왔다.^[1]

WOA의 어플리케이션 중립성도 IFaP에 대한 것이다. 팀 버너스-리(Tim Berners-Lee)와 로이 T. 필딩(Roy T. Fielding)이 강조한 것처럼 웹의 가장 기본적인 특징은 우연한 재사용(Serendipitous Reuse)에 있다. 그리고 이는 일반적이고 어플리케이션 중립적인 인터페이스를 통해 이루어질 수 있다. 다시 말해, 인터페이스가 일반적일수록 더 많은 재사용이 일어난다.

• “예상치 못한 재사용이 웹의 가치다(Unexpected reuse is the value of the Web)” (팀 버너스-리)
• “행운을 쫓는 엔지니어(Engineer for serendipity)” (로이 T. 필딩)

하지만 WS-* 표준은 어플리케이션 중립성보다 구현 중립성(Implementation Neutrality)에 중점을 두고 있다고 저자는 말한다. WS-* 표준의 구현 중립성은 다양한 미들웨어를 지원할 수 있도록 돕지만, 전체 시스템의 네트워크 효과를 극대화 시키기 위해서는 어플리케이션 중립성이 더 중요하다고 한다. 따라서 WOA는 어플리케이션 중립성을 매우 강조한다.

어플리케이션 중립성은 인터페이스의 첫 번째 목표여야 하고, 구현 중립성이 두 번째 목표가 되어야 한다.

How Neutral?

Jazoon’07에서 로이 T. 필딩은 SOA가 어떠한 제약도 갖지 않는 널 아키텍처 스타일(Null Architectural Style)이라고 말한다. 하지만 WOA는 적어도 REST의 4가지 단일 인터페이스 제약을 갖는다. 문제는 5번째 제약인 어플리케이션 중립성이다.

저자는 어플리케이션 중립성이 REST가 묵시적으로 포함하고 있는 제약이라고 주장한다. 그리고 모든 인터페이스 요소는 가능한 일반적으로 정의되어야 한다고 말한다.

단순히 일반적인 인터페이스 위에서 어플리케이션을 개발하지 말아라. 일반적인 인터페이스 위에서 조금 덜 일반적인 인터페이스를 만들어라.

하지만 도대체 얼마나 일반적이어야 할까? 인터페이스가 일반적이라는 것을 판단하는 기준은 무엇일까? 어플리케이션의 한정된 기능을 향해 연속적으로 구체화가 이루어진다면, 그 입도(Granularity)는 얼마나 세밀해야 할까?

실제로 엔지니어들이 WOA를 올바르게 적용하여 시스템을 만들기 위해서는 이 질문들에 대한 구체적인 답이 필요해 보인다.

1. CSTB and NRC, The Internet’s Coming of Age, National Academies Press, 2001, p. 128. [↩]