SOA를 아키텍처 스타일로서 정의하기

비즈니스 모델과 기술의 결합

SOA는 비지니스와 연계되어 있는 기업의 서비스를, 솔루션을 디자인 하고 구현하는데에 있어 가장 기본적인 단위로 보는 아키텍쳐 스타일입니다. SOA가 진정 비즈니스와 IT를 연결시키는데에 어떻게 도움을 주는지, 또 이 SOA를 구현하는데 사용될 수 있는 패턴 언어는 무엇인지 알아 봅시다.

"아키텍처는 컴포넌트로 구체화된 시스템의 기반 구조이고, 서로에 대한 관계이며, 디자인과 진화를 이끄는 원리이다."

• 비즈니스와 IT를 잘 연결한다.
  
• 더욱 유연하고 반응적인 IT 인프라스트럭처를 만든다.
  
• 통합 구현을 단순화 한다.

데이터 섬(Islands of data)

각각의 데이터는 엔터프라이즈 객체에 대해 고유의 의미 또는 정의를 갖는다. (참고자료 [6]) 예를 들어, 하나의 애플리케이션에서 "price"가 원가를 의미하지만, 다른 애플리케이션에서는 같은 용어가 세금을 의미한다. "address"라는 객체가 두 개의 애플리케이션에서 같은 의미를 지니고 있더라도, 이중 하나가 주소 라인으로서 이를 정의할 수 있고, 다른 것은 이를 street address, city, state, ZIP, country로 처리할 수 있다. 두 경우 모두 애플리케이션 간 의미적 차이를 만들어 낸다.
각각은 또 다른 섬의 콘텐트와 겹치는 정보를 갖고 있다. 예를 들어, 건강과 치과 관리를 다루는 애플리케이션이 보험 적용자를 위한 정보를 저장한다. 동시에 고객 관리(CRM) 애플리케이션에는 보험자의 주소와 통계가 저장된다. 이러한 중복은 데이터 무결성 문제를 만들어 낸다.

어떤 누구도 엔터프라이즈 데이터에 대한 완전한 그림을 제공할 수 없다. 예를 들어, 모기지 관리 애플리케이션에는 다른 비즈니스 라인에서 대출자가 받은 대출 정보가 포함되어 있지 않다. 엔터프라이즈 데이터의 통합 뷰를 만들려면 여러 소스들에서 정보들을 통합해야 한다.

자동화 섬(Islands of automation)

각각의 자동화 섬은 엔터프라이즈 내의 한정된 액티비티들에 초점을 맞춘다. (참고자료 [6]) 예를 들어, 건강 관리 애플리케이션은 클레임만 처리하고, 전체적인 엔터프라이즈 비즈니스 프로세스에서의 이러한 액티비티의 역할과 위치를 고려하지 않는다. 사용자가 작업을 수행하기 때문에 생산성에 영향을 미친다.
다른 섬들 내에 포함된 비즈니스 프로세스들 간 중복이 있다. 예를 들어, 보험 회사는 인수 합병의 결과로서 여러 개의 클레임 처리 시스템을 가질 수 있다. 여러 애플리케이션들간 변경 사항들의 동기화가 필요하며, 프로세스와 비즈니스 규칙의 일관성을 보장해야 하며 프로세스를 지원해야 한다.

• 정보 충실도(Information fidelity)): 데이터 섬들 간 비즈니스 데이터의 중복은 엔터프라이즈 데이터를 부정확하게 표현할 수 있다. 심지어 주기적인 동기화가 발생할 때도 그렇다. 표현 그 자체는 조정하기가 어렵다. 개별 애플리케이션들은 독립적으로 진화하기 때문에 문제의 복잡함 또한 증가한다.
  
  
  
• 비즈니스 프로세스 단편화(Business processes fragmentation): 개별 애플리케이션들은 제한된 엔터프라이즈 기능만 제공한다. 비즈니스 프로세스를 구현하려면 프로세스의 부분적인 구현들을 포함하고 있는 애플리케이션들을 연결해야 한다.

Organization

모든 SOA 관련 구성물들(모델, 서비스, 프로세스, 리소스)을 소유하고, 이들의 생성, 사용, 액세스, 유지 등을 관리한다. 이러한 구성물들의 역할은 조직과 이 조직의 비즈니스 목표를 지원하는 것이다.

Business model

엔터프라이즈의 운영 및 전략적인 비즈니스 목표를 달성하는데 필요한 비즈니스 리소스와 프로세스를 표현한다.
비즈니스 모델은 서비스와 비즈니스 목표와 요구 사항들을 성공적으로 제휴시키고, 결국 전체적인 SOA 구현을 성공하는데 있어서 중요하다.

Semantic data model

엔터프라이즈에 대한 표준 비즈니스 데이터 객체들(고객, 계약)을 정의한다. 이러한 객체들은 엔터프라이즈의 기능을 기술하는 일반적인 개념과 콘텐트를 정의함으로써 엔터프라이즈 데이터의 온톨로지를 효과적으로 만든다.
비즈니스 서비스 인터페이스들을 정의하기 위해 데이터 모델을 사용하면 상호 운용 가능한 시맨틱 서비스 인터페이스 정의를 만들 수 있다. 바로 시맨틱 SOA(semantic SOA)가 만들어지는 것이다.

Services

특정 엔터프라이즈 비즈니스 기능을 구현하고, 이것의 데이터와 리소스에 액세스 한다. 잘 정의된 서비스와 비즈니스와 제휴된 서비스들은 유연하고 확장성 있는 엔터프라이즈 SOA 구현의 핵심 요소들이다.
서비스들의 구조에서 서비스들은 독립적으로 개발 및 전개된다. 서비스들을 비즈니스와 시맨틱 모델들과 올바르게 정의 및 제휴하면 "plug-and-play" 구현이 되며, 다른 엔터프라이즈 비즈니스 프로세스와 솔루션과 효과적으로 결합될 수 있다.

Business processes

비즈니스 서비스들의 실행을 조정하여 비즈니스 모델에 지정된 대로 엔터프라이즈 기능들을 구현한다. (오더 프로세싱 또는 클레임 프로세싱)
비즈니스 프로세스들은 핵심 퍼포먼스 지수(KPI)의 형태로 보험 클레임 프로세싱 또는 엔지니어링 개발 프로세싱 같은, 운영 목적과 비즈니스 목표와 제휴된다. 프로세스 구현의 일부로서 수집된 KPI는 엔터프라이즈 기능들의 효과를 평가하는데 사용된다.

Information

기업의 데이터 리소스들을 나타낸다. 데이터는 다른 스토어, 애플리케이션 포맷에 존재한다. 다양한 레벨의 데이터들은 다양한 레벨의 SOA 구성체에 의해 사용된다. 시맨틱 데이터 모델은 비즈니스 프로세스와 서비스에 대한 데이터를 정의한다. SOA는 원시 운영 포맷에서 비즈니스 서비스에 필요한 시맨틱 데이터로 데이터를 변형하는 메커니즘을 정의한다.

Documents

엔터프라이즈의 의무와 파트너의 의무를 정의하는 법적 엔터티들(금융 문서, 보험 정책과 클레임, 정부 규제)을 나타낸다. 문서들은 현대적인 엔터프라이즈의 핵심적인 부분이고, SOA에 포함되어야 한다.

• 메시지 중심 모델은 콘텐트(헤더와 바디), 전달, 기원 및 실행 에이전트의 관점에서 메시지를 정의한다.
  
• 리소스 모델은 URI, 표현, 소유 구조의 관점에서 리소스 또는 구현을 정의한다.
  
• 정책 모델(policy model)은 주제(리소스와 액션)와 조직의 관점에서 정책을 정의한다. 정책은 보안 정책처럼 허용 가능한 액션이나 상태에 대한 제약 조건이다.

• OO에서는, (동시에 존재하는) 같은 유형을 지닌 다중의 객체 인스턴스들은 내부 상태에 기반하여 구별되면서, 특정 실행 콘텍스트를 나타낸다. 결과적으로, 객체의 라이프 사이클은 객체 생성을 통해 소비자에 의해서 명확하게 제어된다.
  모든 객체는 여러 메소드들을 노출하는데, 이들은 특정 인스턴스(실행 콘텍스트)에 속해있고, 주어진 인스턴스에 대해 변수를 조작할 수 있다.
  
  
• SOA에서, 서비스들은 특정 소비자의 실행 정황을 지원하는 것이 아니라, 특정 서비스들과 제휴된 엔터프라이즈 리소스의 상태를 지원한다. 전형적인 서비스 호출은 stateless이다. 예외는 대화형 합성 서비스로서, 일반적으로 실행 콘텍스트를 갖고 있으며 특정 대화를 지원한다.
  결과적으로, 서비스 라이프 사이클은 특정 소비자의 라이프사이클과 제휴되지 않기 때문에, 특정 소비자가 이를 호출하는지의 여부와 상관 없이 존재한다. 결과 프로그래밍 모델은 서비스에 대한 호출이라 할 수 있다.
  

실행 상태와 호출 상태 아래 두 가지 상태들에는 큰 차이가 있다. 실행 상태(Execution state)는 실행 동안의 서비스 상태를 나타낸다. 내부 변수들이 언제나 포함되어 있으며, 서비스 실행 동안에 생성된다. 어떤 서비스 실행이 완료되었는지를 지속적으로 추적하면서, 부분적인 서비스 실행 결과와 서비스 구현의 여러 컴포넌트들 간 전달된 매개변수들을 저장한다. 이 상태는 일반적으로 서비스 구현으로 캡슐화 되며, 서비스 소비자에게는 보이지 않는다. 호출 상태(Invocation state)는 특정 대화에서 서비스 소비자와 서비스 구현 간 공유 정황이다. 소비자는 같은 서비스의 다른 메소드들을 호출하면서, 특정 메소드 호출 동안 서비스로 전달되었던 정보를 모든 연속적인 호출 동안에 서비스에 사용할 수 있다고 간주한다. 이 경우, 서비스는 다른 소비자들과의 다중 대화에 참여하고, 각 대화를 개별적으로 추적한다. 세션 변수 또는 Java™ 2 Platform, Enterprise Edition (J2EE)의 세션 빈에서 호출 상태가 사용된다. 이러한 유형의 상태를 대화 상태(conversation state)라고도 한다. (주: 서비스의 stateful 호출과 stateless 호출에 대해서 주목하기 바란다.)

• 비즈니스 서비스(비즈니스와 제휴된 IT 구성물들을 나타낸다.)
  
• 통합 서비스(SOA 기술, 특히 웹 서비스를 통한 통합 구현)
  
• 인프라스트럭처 서비스(인프라스트럭처 지원에 초점을 맞춘 일반 IT 구성물들을 나타낸다.)

서비스 비즈니스 기능(Service business functionality)

엔터프라이즈 비즈니스 모델에 의해 정의되며, 엔터프라이즈 비즈니스 목표에 맞춰 구현된다.

서비스 콘트랙트(Service contract)

서비스, 인터페이스, 한 개 이상의 서비스 엔드포인트 어드레스의 비즈니스 기능을 정의한다.

서비스 인터페이스(Service interface)

잠재적인 소비자에게 제공될 서비스 기능들을 기술한다. 인터페이스는 서비스 이름과 서비스에 의해서 지원되는 연산(메소드) 이름으로서 정의된다. 모든 연산의 디스크립션에는 연산 호출(요청)에 필요한 매개변수에 대한 정의와 연산에 의해 리턴된 결과(응답)이 포함된다. 이 디스크립션은 연산의 기능과 사전 및 사후 조건들이 포함된다.

서비스 메소드(Service method)

네트워크 위치로 정의된 엔드포인트 어드레스를 통해 액세스 될 수 있다. 모든 엔드포인트 어드레스는 액세스 정책에 의해서 관리된다. 이러한 정책들은 데이터 전송에 사용되는 통신 프로토콜, 실제 서비스 호출, QOS(엔드포인트 어드레스에 필요한 보안 및 프라이버시)를 정의한다.

세분성과 약결합

중요한 서비스 디자인 애트리뷰트를 나타낸다.

서비스 구현

기존 엔터프라이즈 IT 기능들을 재사용 할 수 있도록 한다.

서비스 오케스트레이션(Service orchestration)

서비스들을 더 큰 서비스로 합성하고, 서비스에서 엔터프라이즈 솔루션을 구현하는 메커니즘을 나타낸다.

실제로, 서비스들이 다중 Enterprise JavaBeans (EJB) 컴포넌트로서 구현될 때, 인트라 서비스 호출은 원격이 될 수도 있다.

• 강결합(Tighter coupling) 방식은 시간이 지날수록 비용이 많이 든다.
  
  
  
  • 변경을 위해 여러 조직들을 동기화 한다.
    
  • 다른 것들에 영향을 주지 않고 업데이트 된 컴포넌트를 채택 및 재전개 한다.
    
  • 변경하기가 어렵거나 비용이 들고, 또는 변경 자체가 불가능하다.
    
  • 솔루션의 다른 부분들을 개별적으로 관리하기 어렵다.
    
  • 이동, 스케일링, 분산, 재배치가 어렵다.
    
  • 커플링이 많이 개입될수록 테스팅은 더욱 비용이 많이 든다.
  
  
• 약결합은 더 많은 투자가 필요하다.
  
  
  
  • 더욱 많은 디자인 작업이 필요하다.
    
  • 더욱 많은 구현 작업이 필요하다.

기능적 커플링(Functional coupling)

인터페이스 기반 디자인이 새로운 것은 아니지만, SOA는 (서비스) 인터페이스를 엔터프라이즈 중심의 의미(semantic)에 기반하고 있다. 서비스 상호 운용성에 있어서 엔터프라이즈 중심 의미론의 중요성은 초기 SOA 채택자들은 간과했다. 웹 서비스 커뮤니티는 잘 정의된 콘텐트와 SOAP 메시지 구조가 XML로 표현된 페이로드와 전송의 표준화와 결합하여 웹 서비스 통신의 상호운용성을 보장해주기를 바랬다. 현실적으로, 이것은 기술적인 상호운용성만 제공하고, 한 시스템에서 오는 SOAP 메시지가 수신되고 다른 시스템에 의해서 성공적으로 처리될 수 있다. 하지만, 시맨틱 상호 운용성에는 도움이 되지 않았다. 두 개의 시스템들이 서로를 "이해해야 하기 때문이다."
이 같은 차이점은 어디에서나 발견할 수 있다. 예를 들어, 많은 언어들이 Roman을 사용하기 때문에 이러한 알파벳을 공유하는 다른 언어들로 이야기하는 사람들이 서로를 이해한다는 것을 의미하지 않는다. 알파벳에 대한 순수한 지식으로는 언어를 이해하기에는 부족하다.

서비스 인터페이스 정의에 대한 엔터프라이즈 시맨틱 데이터 모델의 사용은 상호운용 가능한 시맨틱 인터페이스 정의를 이끌었다. (참고자료 [13]) 이러한 시맨틱 SOA는 서비스들 간 매우 향상된 상호운용성을 제공한다. 이들 모두가 인터페이스 레벨에서 같은 모델로 작업한다.

시맨틱 메시지를 도입하려면, 서비스 구현이 두 개의 완전히 다르지만 똑같이 중요한 데이터 모델을 지원해야 한다. (참고자료 [17]).

• 내부 데이터 모델: 서비스 구현에 의해 사용된다. 이 모델은 서비스의 내부 구현과 관련되기 때문에 기반 서비스와 컴포넌트에 고유한 것이 된다. 내부 데이터 모델은 서비스 소비자에게는 노출되지 않는다.
  
• 외부 데이터 모델: 서비스간 교환에 사용되고, 엔터프라이즈 시맨틱 데이터 모델이다.

각 서비스는 엔터프라이즈와 내부 데이터모델들 간 시맨틱 중재 및 변형을 책임지고 있다.

일시적 커플링(Temporal coupling)

서비스들, 특히 웹 서비스는 동기식 서비스 호출에 초점을 맞추는 경향이 있다. 현재 구현의 단점은 SOA 그 자체의 단점으로 간주된다. 따라서, 이벤트 중심 아키텍처(EDA)와 SOA-2를 SOA 문제를 해결하는 수단으로 간주하고 있다. 내 생각으로는 픽스가 필요한 것은 SOA가 아니라 현재의 사용법인 것 같다.
서비스 호출에 대한 동기식 통신은 서비스 소비자와 공급자 간 일시적 강결합을 만들어낸다.

• 서비스 공급자는 서비스 소비자가 액세스 할 수 있도록 실행시켜야 한다.
  
• 동기식 호출은 블로킹 호출이기 때문에, 서비스 실행이나 요청/응답 딜리버리에서의 성능 변화는 서비스 소비자 실행에 중요한 영향을 미친다.

개별 응답 호출을 가진 비동기식 서비스 호출은 소비자가 계속해서 실행하면서, 공급자는 응답할 기회가 주어진다. 이로써 임시적으로 디커플링(decoupled)된 시스템이 만들어진다. 일시적 서비스 공급자 중지 및 네트워크 딜레이는 이 경우 영향력이 적다. 서비스 공급자가 응답만 리턴한다면 전체 시스템은 올바르게 작동한다.


서비스는 전체 소프트웨어 시스템에 대단위 싱글톤을 나타내는데, 이 경우 서비스의 확장성과 고가용성이 매우 중요한 문제이다. 더 나은 확장성과 가용성을 보이는 비동기식 호출이 SOA 구현에는 더 알맞다.

트랜잭션 커플링(Transactional coupling)

트랜잭션, 특히 Atomicity(원자성), Consistency(일관성), Isolation(고립), Durability(내구성)(ACID)는 분산 컴퓨팅의 신뢰성 문제들을 해결하는 방식이다. 금융 애플리케이션들은 자금 이체 프로세스에 이것을 사용하고, 전자 상거래 시스템은 결제 프로세싱에 사용하며, 제조 애플리케이션은 재고 컨트롤에 사용하고, 통신 요금 시스템들은 통화 요금에 이것을 사용한다.
ACID 트랜잭션은 트랜잭션 모니터(Tuxedo, CICS, Encina) 또는 J2EE 애플리케이션 서버 또는 MTS 같은 컴포넌트 플랫폼을 사용하여 구현된다. ACID 트랜잭션 지원에는 트랜잭션 환경을 통한 커플링이 필요하기 때문에 상호운용성과 유연성에 제한이 생긴다.

ACID 트랜잭션 구현의 또 다른 요구 사항은 트랜잭션 동안의 리소스 잠금이다. 서비스들을 짧은 시간 동안 실행해야 한다. 오랜 트랜잭션 시간은 트랜잭션 리소스들의 처리량을 감소시킨다.

ACID 트랜잭션은 객체와 컴포넌트에는 완벽하게 맞지만 서비스들에는 제한이 많다. SOA는 트랜잭션 two-phase commit 프로토콜을 통한 비즈니스 트랜잭션을 선호한다. ( 참고자료 [18]과 [19]).

• 비즈니스 서비스는 안정적인 비즈니스 구성물들을 지원하면서, 프로세싱과 규칙들을 통합한다. (서비스 구현은 시간이 흐르면서 변한다.)
  
• 비즈니스 프로세스는 매우 유동적인 비즈니스 절차와 규칙을 지원하는데, 몇 달, 몇 주마다 변할 수 있다.
  
• 비즈니스 프로세스와 비즈니스 서비스들간 인터랙션은 엔터프라이즈 시맨틱에 기반하고 있고, 서비스의 변화가 비즈니스 프로세스에 미치는 영향을 최소화 하며 비즈니스 서비스에서 프로세스를 구현하는 과정을 단순화 한다.

"패턴과 패턴언어는 베스트 프랙티스를 기술하는 방식이고, 입증된 디자인이며, 다른 사람들이 이러한 경험에서 배울 수 있도록 과거 경험들을 포착하는 것이다. 패턴들은 디자인 가이드라인을 빠르게 이해할 수 있는 입증된 방식이며 다양한 콘텍스트이다. " --John Evdemon(참고자료 [23])

• 서비스 액세스와 인프라스트럭처 (참고자료 [21])
  
• 서비스 컴포지션 (참고자료 [22])
  
• 서비스 정의와 구현 (참고자료 [23])
  
• 서비스 버전관리(versioning) (참고자료 [24])
  
• 서비스 보안 (참고자료 [25])
  
• 엔터프라이즈 데이터 액세스 (참고자료 [26])

서비스 디자인

이 패턴은 가장 중요한 서비스 디자인 액티비티를 포함한다. 서비스 지향 디컴포지션 패턴은 시작 포인트를 제공하면서, 당면한 문제에 기반하여 서비스들을 정의하는 방식을 기술하면서 엔터프라이즈 비즈니스 모델과 필수적인 장기 아키텍처 품질을 포함시킨다.
서비스 콘트랙트 패턴은 서비스에 대한 공식 정의를 만들고, 서비스 디자이너가 구현에 가장 알맞은 서비스를 선택할 수 있도록 하고, 서비스 아키텍트와 개발자들이 이를 올바르게 호출할 수 있도록 한다.

서비스 리파지토리 패턴은 엔터프라이즈 내에서 서비스 관련 구성물들을 구성하는 솔루션들을 정의하면서, 서비스 정의, 생성, 사용에 개입된 관련 당사자들의 협업을 단순화 한다.

서비스 버전관리(versioning) 패턴은 서비스 콘트랙트와 구현에 있어서의 불가피한 변화들을 다루는 가이드라인을 제공하면서 이러한 변경 사항들이 서비스 소비자에게 미치는 영향을 줄일 수 있도록 한다.

서비스 구현

이 패턴들은 서비스 구현 액티비티와 관련된 문제들을 다룬다. 서비스 구현 레이어는 기존 엔터프라이즈 애플리케이션들의 포트폴리오가 엔터프라이즈 비즈니스 모델과 제휴된 서비스들을 구현하는 방식을 보여준다. 서비스 구현 컴포넌트 패턴들은 전형적인 서비스 구현과 인터랙션에 개입된 주요 컴포넌트들을 정의함으로써 이전의 패턴들을 보완한다.
합성 서비스 패턴은 서비스 소비자들이 요구하는 기능들을 지원하기 위해 기존 여러 서비스들의 기능들을 결합할 방식들을 연구한다.

서비스 인프라스트럭처

이 패턴은 서비스 런타임 인프라스트럭처에 있어서 몇 가지 중요한 문제들을 다룬다. 서비스 레지스트리 패턴은 중앙화된 레지스트리를 통해서 서비스 호출에 대한 후기 바인딩 구현에 초점을 맞추면서, 서비스의 전개와 런타임 기능에 대한 엔터프라이즈 중심의 제어 포인트에 적용한다.
서비스 보안은 특별한 패턴 언어로서(참고자료 [25]) 일련의 패턴들을 정의하고, 서비스 보안의 디자인과 구현을 관리한다.

서비스 로깅과 서비스 예외 관리 패턴들은 고도로 분산된 SOA 환경에서 중앙화된 로깅과 예외 관리용 방식을 정의한다.

서비스 모니터링과 관리 패턴은 서비스 실행을 감시하고 관리하는 방식에 초점을 맞춘다. 마지막으로, 엔터프라이즈 서비스 버스 패턴은 서비스 통신이 가상화에 집중하며, 이전에 언급한 인프라스트럭처 패턴을 더욱 쉽게 구현한다.