 | 난이도 : 중급 Donald F. Ferguson, Ph.D., IBM Fellow, Software Group Chief Architect, IBM
Marcia L. Stockton, Senior Technical Staff Member, Chair of Programming Model Workgroup, IBM
Martin Nally, Chief Technical Officer, IBM Rational Software, IBM
2005 년 8 월 23 일 언어 중립적인, 컴포넌트 기반의 SOA 프로그래밍 모델은 웹 서비스의 구현을 촉진하고 솔루션으로도 잘 이어진다. 이 프로그래밍 모델을 사용하면 전문 프로그래머가 아니더라도 기존 IT 자산들을 사용할 수 있다. 솔루션 디자이너와 비즈니스 분석가의 필요도 충족시키면서, 구현 기술들간 차이들을 숨기는 고급 추상화 레벨을 제공하여 신뢰성을 높인다.
왜 컴포넌트 기반 프로그래밍 모델인가?
IBM SOA 프로그래밍 모델의 동기를 말하기 위해서 다음 두 가지의 인용문을 소개하고자 한다.
"디자인이 유행을 따라가는 것은 일반적인 현상이다. 소프트웨어 산업계에서 이러한 행태들 중 일부는 기존 아키텍처 제약조건이 왜 유용한지를 이해하지 못하는 데서 기인하고 있다. 다시 말해서, 아키텍처가 재사용에 선택될 때, 그 좋은 소프트웨어 아키텍처에 적용된 원리를 디자이너는 모르고 있다."
-- Roy Thomas Fielding, "네트워크 기반 소프트웨어 아키텍처의 아키텍처 스타일과 디자인(Architectural Styles and the Design of Network-based Software Architectures)" (참고자료.)
이 문제는 아키텍처 제약조건의 원리를 자세히 알고 있는 사람들의 경험이 패턴, 프로그래밍 객체, 툴로서 구현될 때 해결될 수 있다.
두 번째는 인간과 기술이 상호작동 하는 방법에 대한 것이다.
"서비스 지향 아키텍처 솔루션을 만든다는 것은 시스템 구현, 기업이 확보한 기술력, 팀원들이 협업하는 방식 등 현재 사용하고 있는 사례들을 재고한다는 것을 의미한다. 서비스 지향은 솔루션 개발에 기여하고, SOA는 개별 서비스 공급자들간 약결합을 강조하는 아키텍처 스타일이다."
-- A.W. Brown, et. al., "IBM 소프트웨어 개발 플랫폼으로 서비스 지향 솔루션 구현하기(Realizing service-oriented solutions with the IBM software development platform)" (참고자료.)
XML에 기반한 웹 서비스 표준은 이미 컴포넌트 기반의 프로그래밍 모델 양상의 띠고 있다. Web Services Interoperability(WS-I), Web Services Description Language(WSDL), Web Services Policy(WS-Policy) 등의 표준들은 플랫폼-중립의 추상화와 비즈니스 소프트웨어 통합을 위한 범용 프레임웍의 구현을 시도하고 있다. 웹 서비스의 가치는 SOA에서 사용될 때 그 가치가 실현될 수 있다.
웹 서비스에 대한 대부분의 글들이 상호운용성 프로토콜과 서비스 인터페이스 및 그 사용법에 초점이 맞춰져 있다. 대신, 이 글에서는 서비스를 구현하고 이들을 솔루션으로 구성하는 프로그래밍 모델에 초점을 맞추도록 하겠다. 컴포넌트 모델은 서비스의 구현과 조립 과정을 간소화 한다.
정의가 잘 된 컴포넌트 모델은 광범위한 사용자 역할 생태계를 구성한다. 비즈니스 분석가, 통합 개발자, 어댑터 개발자, 솔루션 관리자 등의 역할들로 구성된다. 이들은 사용자의 목표, 기술, 개념적 프레임웍과 매치하는 다양한 컴포넌트 유형을 인스턴스로 만들고, 사용하고, 조립하고 커스터마이징 하여 서비스 지향 애플리케이션을 만든다. (주: 프로그래밍은 전문적이고 중요한 소프트웨어 개발 역할이기는 하지만 SOA에서 생산적으로 작업하기 위해 모든 사람들이 전문 프로그래머가 될 필요는 없다.)
웹 서비스 표준에 근거한 우리의 컴포넌트 모델은 컴포넌트와 컴포넌트 유형에 대해 더욱 분명한 정의를 내리고, 이러한 컴포넌트들이 재사용을 위해 정의되고 구조화 되어 역할에 맞는 툴에 의해 조작될 수 있도록 한다.
컴포넌트 기반의 프로그래밍 모델은 많은 이점들이 있지만, 무엇보다도 복잡성을 현격하게 줄인다는 이점이 있다. 하나의 역할이 기능이나 시스템의 모든 인터페이스들을 구현하는 모든 방법들을 이해 할 필요가 없다. 각 역할의 복잡성은 제한되고 다양한 개발자 역할의 복잡성은 태스크에 맞는 툴을 사용하여 솔루션에 기여한다.
컴포넌트 모델은 추상적이며 언어 중립적이어야 한다. 왜냐하면 그 역할 자체가 기술 상세와 차이점을 숨기는 것이기 때문이다.
또한 전문 프로그래머가 아닌 사람들도 "솔루션 조각들"을 조립 및 테일러링 할 수 있다. 따라서 조립 및 재단되는 모든 컴포넌트(또는 컴포넌트 컬렉션)들은 언어 중립적인 방식으로 분명하게 선언되기 때문에 소스 코드를 수정하는 프로그래머 없이도 툴로 조작될 수 있다. XML을 사용하여 이러한 선언을 표현한다.
SOA의 세밀한 특성화에 대해서는 논의의 여지가 있지만 몇몇 핵심 요소들은 넓게 채택되고 있다.
- SOA는 분산 컴포넌트 아키텍처이다. SOA 컴포넌트들은 기업 안팎에 투명하게 배치되어 있으며, 광범위하게 지원되는 상호운용 가능한 원격 프로시저 호출과 메시징 프로토콜을 통해 서비스로서 접근할 수 있다. 인터페이스 정의 표준은 개발자 툴들간 상호운용성을 가능케 한다. 코드 이식성에 반대되는 개념인 와이어(wire)상의 프로토콜 상호운용성은 SOA 컴포넌트 인터랙션의 중심으로서, 범용 액세스와 플랫폼 독립을 가능케 한다. 호출자는 Java™ 2 Platform, Enterprise Edition(J2EE), Microsoft® .Net, PHP 같은 기반 구현 기술을 알지 못한다.
- SOA 컴포넌트는 기능을 캡슐화하고 비즈니스 분석가와 비즈니스 모델에 의해 모델링 되는 추상화 레벨에서 재사용 된다. 이로서 IT 기능과 비즈니스 기능을 보다 직접적으로 연결하여 신뢰성을 높일 수 있다.
- 선언적이고, 머신 처리 방식의 컨트랙트를 통해 제 3자가 SOA 컴포넌트가 제공하는 서비스에 접근할 수 있다. 이러한 컨트랙트는 기능적 특성뿐만 아니라 비 기능적 능력과 요구사항(서비스 품질)을 명확하게 명시한다. SOA 컴포넌트는 작동을 WSDL로 문서화 한다. Business Process Execution Language for Web Services(BPEL4WS) 역시 컴포넌트에 대한 작동을 정의하는데 사용된다.
- SOA 컴포넌트는 동적으로 발견, 선택, 바인딩 될 수 있다. 또한 구성 메커니즘을 사용하여 통합된다. (본 시리즈 Part 3 참조).
컴포넌트 구현과 특성화된 컴포넌트 유형
개발자는 J2EE, PHP 또는 기타 여러 툴을 사용하여 기본적인 컴포넌트를 구현한다. 프로그래밍 모델로서의 SOA는 컴포넌트 인터랙션과 새로운 합성 컴포넌트, 애플리케이션, 솔루션으로 통합되는 것과 깊은 관련이 있다.
또한 이 프로그래밍 모델은 개발자가 만들어서 솔루션으로 전개하는 일반적인 유형의 객체들을 모델링 하는 방식을 채택한다. 자바 객체(POJO), 비즈니스 프로세스(BPEL4WS), Structured Query Language(SQL) 서비스, Adaptive Business Objects, Customer Information Control System(CICS) 프로그램(J2EE Connector(J2C) 아키텍처 리소스 어댑터를 통해 접근), SAP의 비즈니스 애플리케이션 프로그래밍 인터페이스를 사용하는 애플리케이션, J2EE stateless session beans, IBM MQSeries® 애플리케이션 등이 그 예이다.
SOA 컴포넌트 모델의 가상성 때문에, 많은 SOA 컴포넌트들이 여러 구현 기술들을 지원한다. 다양한 태스크 마다 잘 맞는 구현 기술이 있다. 투명성을 높이기 위해 서비스 컴포넌트 유형의 개념을 도입했다. 각각은 해당 분야의 기술력을 가지고, 특정 태스크를 수행하며, 특정 툴을 사용하는 개발자에 맞춰진다. 쿼리를 하려면 프로그래머는 SQL 파일과 XQuery 문을 포함하고 있는 하나의 파일을 구현한다. 문서 변환을 위해, XSLT 스타일 시트 등이 그 태스크에 맞게 최적화된 툴을 사용하여 구현된다. 웹 서비스, Enterprise JavaBean(EJB), 기타 객체가 개발 시 생성되는지 알 필요가 없다.
프로그래머는 태스크에 맞춰진 특정 컴포넌트 유형을 구현하고 해결할 문제와 사용할 툴에만 집중하면 된다. SOA 개발 툴은 개발자의 기술과 개발자가 이해하는 개념에 초점을 맞춘다. 이제부터는 몇 가지 컴포넌트 유형에 대해 볼 것이다. 세 가지 다른 예제(자바 객체, 정보 관리 시스템(IMS) 트랜잭션, SQL 문)들로 설명할 것이다. 구현 기술들이 일반 SOA 컴포넌트 모델과 연결되는 방식과 특정 개발자의 필요를 어떻게 다루는지도 설명한다.
구성
SOA 구성은 플랫폼 중심의 기술을 사용하여 이루어지는 반면, 새로운 유형의 SOA를 중심으로 한 구성은 또 다른 프로그래밍 모델로 변환될 필요가 없이 독립적이다.
구성 모델은 원하는 인터페이스와 인프라(QoS) 정책을 갖고 있는 서비스들을 발견하여 새로운 서비스, 모듈, 솔루션으로 만든다. 새로운 서비스들도 구성될 수 있다.
우리가 사용하는 방식은 비즈니스 로직을 구현하여 접근하는 패러다임을 통합하는 것이다. EJB 같은 기존 프로그래밍 구조체 보다 더 추상적인 SOA 프로그래밍 모델은 구현 기술의 차이를 숨긴다. 이 모델에서, 컴포넌트들은 모듈로 조립된다. 결국 이것은 솔루션으로 구성될 것이다. 컴포넌트는 서비스를 노출하고, 이 서비스들은 접근 가능한 인터페이스를 통해 호출된다. 인터페이스는 WSDL, 자바, 기타 언어들을 사용하여 기술된다. 구현은 컴포넌트들을 하나로 연결하여 실행하기 전에 필요한 서비스를 참조할 수 있다. 기업 정책과 엔터프라이즈 서비스 버스(ESB) 전개 토폴로지에 대해 알고 있는 솔루션 통합자나 솔루션 어셈블러에 의해 역할-툴을 사용하여 연결 작동이 수행된다.
프로그래밍 없이 커스터마이징 하기
설정, 커스터마이징, 테일러링이 없다면 서비스 자체로는 재사용이 불가능하다. 변경을 해야 한다면 소스 코드를 변경해야 한다. 하지만 광범위한 재사용 컴포넌트를 제공할 수 있는 능력은 컴포넌트를 사용 환경에 적응시키는 능력과 깊은 관련이 있다. SOA 프로그래밍 모델에서는 소스 코드의 변경 없이도 “프로그래머”만이 커스터마이징 할 수 있는 서비스와 모듈을 구현할 수 있다.
SOA용 컴포넌트 기반 프로그래밍 모델은 프로그래밍 없이도 컴포넌트를 커스터마이징 할 수 있는 여러 메커니즘을 제공한다.
재사용 될 컴포넌트는 변이 포인트를 가진 템플릿으로 패키징 될 수 있다. 변이 포인트란 솔루션으로 만들어 질 때 테일러링 될 부분이다. 이러한 유형의 채택 방식은 이 프로그래밍 모델의 핵심이다.
중재(mediation)는 메시지를 중점적으로 처리한다. 중재는 프로그래밍 없이도 구성될 수 있다. 엔터프라이즈 서비스 버스는 멀티 프로토콜의 토대가 된다. 서비스 컴포넌트들간 완벽한 인터랙션을 관리하고, 감사, 로깅, 라우팅, 미스매치 인터페이스의 적용, 동등한 컴포넌트로의 점증적인 대체, 보안 등의 영역들이 기업 전반에 걸쳐 다루어 질 수 있도록 한다. 이를 위해 메시지 경로에 중재라고 하는 특별한 컴포넌트를 삽입하고 기존 엔드포인트를 변경하지 않고 서비스들간 인터랙션을 중재한다.
SOA 프로그래밍 모델의 또 다른 이점은 소프트웨어 수명 주기 동안 여러 번 한 컴포넌트가 다른 컴포넌트로 대체될 수 있다는 점이다. 이는 늦은 바인딩(late binding) 때문에 가능하다. 기능 단위를 대체해야 하는 이유는 많지만, 이 중 가장 중요한 이유는 큰 기업에서 변화 관리의 어려움을 줄이기 위함이다. 점증적으로 변경을 적용하고 인터페이스에 미치는 영향을 제한함으로서 유연성을 높일 수 있다. 이는 또한 약결합과도 맞는 개념이다. 서비스 컴포넌트는 다른 기술, 필요, 시간표를 가진 그룹들이 함께 협업하여 인간과 시스템 자원 모두 효율성을 극대화 할 수 있도록 한다. 비즈니스는 보다 빠르게 변화에 적응할 수 있다.
컴포넌트 정의
SOA 컴포넌트는 다음 스팩들로 정의된다.
- 서비스 스팩(service specification)은 컴포넌트를 하나의 서비스 세트로서 간주한다. 이 서비스 세트는 컴포넌트가 제공하고 또 그 컴포넌트가 필요로 하는 것이다. 다음과 같은 세 가지 스팩으로 정의된다.
- 인터페이스-일반적으로 WSDL
portTypes.
- 트랜잭션 작동과 보안 등 QoS 속성들을 문서화 해 놓은 정책들.
- BPEL4WS 추상 프로세스 같은 작동 정의. Unified Modeling Language, Version 2(UML2) 상태 모델도 예가 될 수 있다. 이것은 다양한 상황에 어떤 작동이 유효한지를 정하고 연산을 통해 발생하는 상태 변화를 기술한다. 호출자는 상태 모델에서 유효한 연산 결과를 계산할 수 있다.
- 서비스 컴포넌트 구현(service component implementation)은 다음 네 가지 스팩에 의해 정의된다.
- 제공된 서비스 스팩.
- 필요한 서비스 스팩 .
- 테일러링 또는 커스터마이징 할 컴포넌트에 설정된 속성.
- 기본적인 지원을 제공하는 속성. 보다 복잡한 시나리오에서는 커스터마이징 컴포넌트에 대한 변이 포인트를 사용한다.
- 구현의 모든 인스턴스에 대해 변하지 않는 컨테이너 정책.
- 컴포넌트의 구현을 정의하는 구현 객체(자바 클래스, BPEL 문서, XSLT 규칙 세트)
- 서비스 컴포넌트(service component, 인스턴스)는 다음으로 정의된다.
- 이름.
- 서비스 컴포넌트 구현 .
- 인스턴스를 테일러링 하도록 설정된 구현 속성 값.
- 구현에 필요한 서비스 스팩을 제공하는 모든 서비스의 스팩. 이들은 컴포넌트 인스턴스를 연결하는 "와이어(wire)"가 될 수도 있고, 인터페이스를 구현하고, 관련 QoS 정책을 갖고 있고, 특정 작동(추상 프로세스 또는 상태 모델)과 매치하는 컴포넌트를 찾기 위해 실행되는 " 쿼리" 가 될 수도 있다.
SOA 컴포넌트 모델을 정의하는 두 가지 방식이 있다. 이 정의는 개발 툴을 사용하거나 개발자가 직접 만들기도 한다.
첫 번째는 제어 파일(control file)이다. 이것은 컴포넌트의 모든 부분들을 제휴시키는 문서이다. 예를 들어, 제어 파일은 (인터페이스가 제공하는) WSDL 정의, 컴포넌트(구현 객체)를 구현하는 자바 클래스, 또는 제휴 정책 문서들(정책 선언)을 참조한다. 이들은 파일 시스템, 클래스 경로, 소스 코드 제어 시스템, 웹 URL에 대한 레퍼런스가 된다. 제어 파일 포맷은 개별적으로 개발된 여러 객체들을 컴포넌트로 구성된 컬렉션으로 모은다. 애플리케이션 개발 툴이 제어 파일을 정의하는데 도움이 된다.
두 번째 포맷은 pragmas를 사용한다. 같은 정보를 지정하는 언어 엘리먼트이지만 하나의 소스 파일의 바디에 저장되어 있다. 자바[JSR 175의 XDoclet 태그] 지원이 향상되어 자바 언어의 주석 부분을 만든다. 하지만 이 방식은 SQL이나 XQuery문 같은 SOA 컴포넌트 구현 기술은 지원하지 않는다. 각 컴포넌트 유형은 자바 파일, 상태 머신, SQL 파일 같은 구현 객체에 대한 제휴 소스 파일 포맷을 갖고 있다. IBM WebSphere® Rapid Deployment의 경우 pragmas를 포함하는 소스 파일에서 컴포넌트를 구성하는 모든 개별 엘리먼트들을 만들 수 있도록 지원된다. 예를 들어, 자바 소스 파일의 컴포넌트는 컴포넌트의 서비스 인터페이스를 정의하는 WSDL에 어떤 자바 메소드가 웹 서비스 연산이 될지를 나타낸다.
요약
태스크 중심 툴과 런타임 인프라에서 지원을 받는 컴포넌트 기반의 프로그래밍 모델은 빠른 SOA 채택의 열쇠이다. SOA 프로그래밍 모델은 비 전문 프로그래머들도 SOA 컴포넌트를 활용하여 새로운 비즈니스 솔루션을 만들고 기존 솔루션을 새로운 비즈니스 필요에 맞게 변화시킬 수 있다.
참고자료 교육
토론
필자소개 | 
| Donald F. Ferguson, Ph.D., Software Group Chief Architect, IBM |
| 
| Marcia L. Stockton, Senior Technical Staff Member, Chair of Programming Model Workgroup, IBM |
| | Martin Nally, Chief Technical Officer, IBM Rational Software, IBM |
기사에 대한 평가
| |
