웹 서비스를 구현하는 SOA 프로그래밍 모델, Part 1: IBM SOA 프로그래밍 모델 개요

문서 옵션

JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다.

제안 및 의견

피드백

난이도 : 초급

Donald Ferguson, IBM Fellow and Software Group Chief Architect, IBM
Marcia Stockton, Senior Technical Staff Member and Chair, Software Group Programming Model Workgroup, IBM

2005 년 6 월 14 일

서비스 지향 아키텍처(SOA)를 위한 IBM 프로그래밍 모델을 통해 프로그래머가 아닌 사람들도 전문적인 IT 기술 없이도 IT 자산을 만들고 재사용 할 수 있다. 이 모델에는 컴포넌트 유형, 와이어링(wiring), 템플릿, 애플리케이션 어댑터, 유니폼 데이터 표현, 엔터프라이즈 서비스 버스(ESB)가 포함되어 있다.

SOA 프로그래밍 모델 시리즈

놀라운 속도로 번식해 가고 있는 기술, 방법, 툴, 플랫폼을 효과적으로 익히고 적용하는 것이 점점 어려워지고 있다. 하지만 비즈니스 프로세스의 변형이 이루어지면 상당히 많은 비 전문 프로그래머들도 기존 IT 자산들을 사용하여 일을 처리해야 하고 기반 기술의 상세를 배운다는 것은 불가능한 일이다. 본 시리즈에서는 새로운 서비스 지향 아키텍처(SOA) 프로그래밍 모델을 설명한다. 이 모델의 목표는 기업 내에서 다양한 기술적 수준과 역할을 가진 사람들(반드시 IT 전문가에 국한될 필요는 없음)이 소프트웨어 개발 사이클의 각 단계마다 IT 자산을 만들고 사용할 수 있도록 하는 것이다. 온 디맨드를 활용하는 기업에 놀라운 민첩성이 기대된다.

위로

머리말

IBM 제품들은 SOA와 프로그래밍 모델을 꾸준히 구현하고 있다. 프로그래머들은 서비스를 구현하고, 서비스를 사용하며 서비스들을 한데 모으는 솔루션을 개발한다. 우리는 이 글에서 "프로그래머"란 용어를 포괄적인 의미로 사용할 것이다. 왜냐하면 SOA 프로그래밍 모델의 핵심 요소는 "프로그래밍"을 광범위한 비 전통적인 개발자 역할과 기술로 확장하는 것이기 때문이다. 비즈니스 분석가와 스크립팅 언어 사용자가 그 대표적인 예이다.

웹 서비스에 대한 연구 대부분이 주로 서비스 인터페이스와 사용법에 초점이 맞춰져 있다. 인터페이스 표준과 최상의 용례를 완성시키기 위해 IBM은 서비스를 구현하고 이들을 솔루션에 모으는 프로그래밍 모델을 도입했다. 광범위한 사용자 커뮤니티(비 전통 프로그래머 포함)까지 IBM 소프트웨어 플랫폼을 확장시키면서 사용자의 역할, 목표, 기술, 개념적 프레임웍에 맞는 새로운 컴포넌트 유형을 제공한다. 이러한 컴포넌트 유형들은 보다 직관적인 개발 툴을 실행한다. 또 다른 주제는 프로그래밍 모델의 특징과 기능의 적극적인 노출을 통한 소비가능성(consumability)이다.

본 시리즈를 통해 IBM SOA 프로그래밍 모델을 자세히 다룰 것이다. 이 시리즈에서 여러 가지 새로운 프로그래밍 모델을 소개하도록 하겠다. 여러분이 선택, 개발, 전개, 권고, 관리하는 소프트웨어를 보다 쉽게 개발, 재사용, 소비할 수 있도록 이들을 활용하는 방법을 설명할 것이다. 서비스로서 구조화 된 소프트웨어는 온 디맨드 기업에게 특히 가치가 있다. 왜냐하면 이것은 덜 숙련된 개발자에 의해 솔루션으로 "연결" 될 수 있거나 비즈니스 프로세스 구성법 흐름으로 조합되어 빠르게 변화하는 비즈니스 요구에 부응하기 때문이다. 여러분이 대기업의 개발자이든 중소 기업의 개발자이든, 독립 소프트웨어 벤더(ISV)이든 애플리케이션 개발자이든 미들웨어 벤더이든 간에 이러한 방식으로 소프트웨어를 개발하면 효과를 누릴 수 있다. SOA 원리를 바로 지금 적용해 보도록 하자.

위로

SOA 프로그래밍 모델의 특징

지금부터는 SOA 프로그래밍 모델의 핵심적인 기능들을 소개하겠다.

서비스 데이터 객체(SDO)는 IBM SOA의 근본적인 개념이다. SDO를 통해서 개발자는 보다 생산적으로 작업을 할 수 있다. 특정 백엔드 데이터 소스, 애플리케이션, 서비스에 액세스 하는 방법에 대해 개발자들은 신경 쓰지 않아도 된다. 프로그래머가 비즈니스 로직에 집중할 수 있도록 하는 간단한 추상화를 제공한다. SDO는 서비스들과 인터랙팅하고, 데이터 표현을 위한 기술의 혼란을 종식시키며, 하나의 일관된 모델로 액세스한다.

SOA 프로그래밍 모델은 비즈니스 로직을 구현하고 액세스하는데 통합된 패러다임을 필요로 한다. 쉽게 소비될 수 있도록 서비스는 구현 기술들간 차이를 숨겨야 하고 기본 프로그래밍 구조체(예를 들어, Enterprise Java™Beans (EJB)) 보다 더 높은 추상화 레벨에 있어야 한다. 서비스가 모듈로 어셈블리 된 컴포넌트에 의해 구현될 수 있다는 것을 생각해 보라. 솔루션으로 구성될 수도 있다. 컴포넌트는 인터페이스 통해 접근하여 서비스를 노출시킨다. 여러분은 Web Services Description Language(WSDL), 자바, 기타 언어를 사용하여 인터페이스를 기술한다. 이러한 구현 스타일에서는 컴포넌트들이 함께 연결됨으로써 실행 전에 충족되어야 할 서비스에 대한 레퍼런스를 가질 수 있다.

이러한 프로그래밍 모델에서는 개발자가 만들어서 솔루션으로 전개하는 일반적인 객체를 모델링 하는 컴포넌트 유형을 도입한다. 자바 객체, Business Process Execution Language(BPEL) 프로세스, structured Query Language(SQL) 서비스, Adaptive Business Objects, Java Connector Architecture(J2C) 리소스 어댑터를 통해 액세스 되는 CICS® 프로그램, SAP의 비즈니스 애플리케이션 프로그래밍 인터페이스를 사용하는 애플리케이션, Java 2 Enterprise Edition(J2EE) stateless 세션 빈, MQSeries® 애플리케이션 등이 그 예이다.

엔터프라이즈 서비스 버스는 서비스 컴포넌트들을 완벽한 인터랙션으로 엮는 멀티 프로토콜 뼈대 역할을 한다. 잘 맞지 않은 인터페이스의 감시, 기록, 라우팅, 적응, 대등한 컴포넌트로의 점증적인 대체, 보안 같은 엔터프라이즈 문제들이 엔터프라이즈 중심으로 해결될 수 있도록 한다. 기존 엔트포인트들을 변경하지 않고 서비스들 간 브로커 인터랙션으로 가는 메시지 경로에 중재(mediation)라고 하는 특별한 컴포넌트를 삽입한다.

새로운 프로세스 언어는 IT 개념과 비즈니스 객체들 간 격차를 줄인다. 대표적인 것이 BPEL이다. 비즈니스 분석가가 연결시킬 수 있는 그래픽 툴을 사용하여 프로세스가 정의될 수도 있는데 이것 역시 실행 프로그램이다. 프로세스들은 온 디맨드 비즈니스 변형에 중요한 역할을 한다. 예를 들어, 확장된 밸류 체인의 장기 실행 프로세스를 기술할 경우가 그렇다. 확대된 밸류 체인에 의해 다중의 공급자와 IT 영역들로 비즈니스를 확대할 수 있다. 소매자와 많은 개별 공급자들, 보험 회사와 많은 3자 조정자들, IT 아웃소싱 상황 등으로 확대될 수 있다.

비즈니스 상태 머신(business state machine)은 비즈니스 분석가가 그래픽 툴을 사용하여 만들 수 있는 또 다른 프로그래밍 구현이지만 프로세스 구성법 엔진에서 실행한다. 상태 머신은 구매 주문과 보험 청구 같은 비즈니스 객체를 나타낼 수 있다. 이들은 "이벤트"라는 특별한 라이프 사이클에 대응하여 정의가 잘 된 여러 상태들을 통해 이동한다.

재사용을 목적으로 하는 컴포넌트는 변화가능성을 가진 템플릿으로서 패키지 될 수 있다. 솔루션으로 만들어질 때 커스터마이징 될 수 있다. 이러한 적용 방식은 규칙 언어(rules language)와 관련 툴과 더불어 프로그래밍 모델의 중요한 부분이고 새로운 유형의 사용자에게 커스터마이징 기능도 제공한다.

또 다른 혁신 분야는 새로운 솔루션 모델이다. 전개자, 관리자, 기타 비즈니스 사용자들이 컴포넌트를 조립하여 솔루션으로 만들 수 있다. 개발 시, 서비스 구현을 호스팅 토폴로지(시스템 아키텍트가 모델링하는 개발 토폴로지)와 제휴할 수 있다. 이 모델에 의해 파악된 시스템 요구 사항들과 환경은 구현에 대해 일찌감치 확인하여 신뢰성과 안정성을 높이는 동시에 애플리케이션의 수명 주기 동안 드는 비용을 줄인다. 후기 바인딩(late binding), 데이터를 변형 중재, 엔터프라이즈 서비스 버스를 통해 서비스 중심의 인터랙션을 가능케 하는 기존 애플리케이션용 어댑터들이 이 모델의 특징이다.

요약해 보면, SOA 프로그래밍 모델은 개발과 전개 작업을 개별 단계들로 구분한다. 각 단계는 다른 시간에 발생할 수 있고 다른 기술을 사용하여 다른 사람들에 의해 수행될 수 있다. 이것이야 말로 영역의 진정한 분리이며 소프트웨어 컴포넌트의 목적변경(repurposing)을 실현하는 것이다. 또한 소프트웨어 경험을 각 사용자의 역할, 기술, 태스크에 맞게 변경시킨다. 마지막으로 소프트웨어 수명을 관리하여 온 디맨드 기업에 맞춘다. 비즈니스 기민성을 위해 IT 프로세스를 리엔지니어링 함으로서 효용성을 증대할 수 있는 것이다.

위로

프로그래밍 모델의 개념

프로그래밍 모델은 일반적으로 IBM SOA와 IBM 제품의 중심이다. 이것은 개발자가 구현하고 사용하는 개념과 추상화를 정의한다. WebSphere® Application Server, DB2®, CICS 같은 런타임 제품들은 프로그래밍 모델 객체들을 실행하거나 호스팅한다. 개발 툴은 프로그래밍 모델 객체들의 모델링과 구현을 지원하고 어셈블리를 애플리케이션(솔루션)으로, 그리고 런타임으로 전개한다. 마지막으로 시스템 관리 제품, 에이전트, 기구는 런타임의 관리를 지원하고, 각자 호스팅하는 프로그래밍 모델 객체들을 지원한다.

프로그래밍 모델이란 무엇인가? 일반적으로 정의된 것은 없지만 다음과 같이 정의할 수 있다.

프로그래머가 구현하는 파트 유형(part types)이다. 파트 유형들은 다양한 프로그래밍 모델 객체들을 아우른다. Hypertext Markup Language(HTML) 파일, 데이터베이스 저장 프로시저, 자바 클래스, Extensible Markup Language(XML) 스키마 정의, MQSeries 메시지를 정의하는C 스트럭트 등이 있다.
비슷한 기술과 지식을 갖고 있는 개발 커뮤니티와 관리 커뮤니티 멤버들을 그룹핑하는 역할. 이러한 방식으로 개발자들을 구분하여 비 전문 프로그래머들도 서비스를 구현하고 서비스에서 솔루션들을 만드는 역할 중심 툴을 만들 수 있다. 비즈니스 프로세스를 정의하는 비즈니스 분석가와 고객을 구분하고 제품 디스카운트를 계산하는 정책을 정의하는 마케팅 전문가들은 이러한 새로운 유형의 개발자로 볼 수 있다. 각각의 역할에는 다음 사항들이 포함된다.

각 역할들이 갖고 있는 기술. 예를 들어, 사용자 인터페이스 개발자는 애플리케이션이나 솔루션의 기능적 객체들을 나타내는 인터페이스를 개발한다. 이 역할은 개발과 비즈니스 목표 하에 애플리케이션을 알고있고 애플리케이션의 사용자와 그들의 태스크에 대해 충분히 이해하고 있으며 여러 가지 사용자 인터페이스 디자인 방식에 대해 전문적으로 알아야 하며 각 태스크에 맞는 올바른 유형을 선택함으로써 사용이 쉬운 사용자 인터페이스를 만들 수 있어야 한다.
역할이 인터랙팅(소비 또는 생산) 할 파트 유형과 애플리케이션 인터페이스. 예를 들어, 동적 페이지의 디자이너(역할)는 기존 정보와 애플리케이션 소스를 래핑하는 JavaServer Pages(JSP)를 만들고 EJB를 소비한다. (파트 유형).
역할이 사용하는 툴. 웹 개발자의 역할에 맞는 툴의 예제는 동적 페이지를 구현하고, HTML과 JSP 태그 라이브러리와 관련된 제어를 사용하며 그 제어를 EJB에 연결하기에 알맞은 페이지 디자인 툴이다.

구현이 쉽고 사용하기도 쉬운 웹 서비스의 핵심은 기존 기술과 지식의 점증적인 확대이다. 이렇게 함으로서 SOA도 소비할 수 있는 것이다. CICS COBOL 트랜잭션 프로그램의 형태로 되어있는 서비스는 BPEL로 작성된 프로그램과 약간 비슷하다. 프로시저에 저장된 데이터베이스에서 서비스를 호출하는 것은 JSP에서 이를 호출하는 것과는 다르다. 기술과 기대하는 것이 다르다. 여러분은 다양한 기술에 파트 유형을 적용시키고 개발 프로세스의 단계에 적용하기 위해 툴의 분류를 통해 더 나은 소비가능성을 얻을 수 있다.

본 시리즈를 통해서 SOA 프로그래밍 모델을 구성하고 있는 파트 유형들을 보다 자세하게 설명할 것이다.

위로

제품 아키텍처

그림 1. 제품 아키텍처
product architecture

SOA를 지원하는 IBM 제품들은 크게 두 개의 범주로 나뉜다. 서비스 엔드포인트와 이들을 서로 연결하는 메시지 전송 구조가 그것이다. 이러한 일반적인 아키텍처는 많은 제품들에 포함되어 있다. (그림 1)

그 핵심에 서비스들간 연결을 지원하는 ESB가 있다. ESB는 멀티 프로토콜이고, 점대점의 퍼블리시-등록 스타일의 통신을 지원하고 메시지를 처리하는 중재 서비스이다. IBM WebSphere MQ, IBM WebSphere MQ Integrator Broker, 웹 서비스 및 Java Message Services(JMS)를 지원하는 WebSphere가 첫 번째 범주에 속한다.

서비스는 컨테이너로 알려진 추상 호스팅 환경에 상주해 있고 특정 프로그래밍 장치를 제공한다. 이 컨테이너는 서비스의 구현 코드를 로딩하고 ESB로 연결하여 서비스 인스턴스들을 관리한다. 다양한 유형의 서비스들이 다른 컨테이너에 상주한다.(디자인 회귀라는 대표적인 예에서 ESB는 중재 서비스용 컨테이너로 간주된다.) 표 1은 주요 IBM SOA 호스팅 환경과 호스팅 되는 컴포넌트 유형을 정리해 놓은 것이다.

표 1. 다양한 컴포넌트와 서비스 유형을 호스팅하는 컨테이너

서비스/컨테이너 유형	컨테이너
COBOL, PL/1, 기타 언어들로 작성된 트랜잭션 프로그램	CICS 또는 IMS (정보 관리 시스템 -- 기업 트랜잭션 처리 시스템). 프로그래머는 SOAP/HTTP, WebSphere MQ, J2EE J2C 연결을 사용하여 서비스에 액세스 할 수 있다.
비즈니스 프로세스 구성법	WebSphere Business Integration Server Foundation. 이 컨테이너는 웹 서비스 인터페이스를 구현하여 다른 웹 서비스에 대한 연산을 호출하는 장기 워크플로우를 지원한다. 또한 오랫동안 실행하는 비즈니스 액티비티 트랜잭션도 지원한다.
애플리케이션 어댑터 – 기존 애플리케이션과 시스템에 대한 SOA/웹 서비스 façade 제공	WebSphere Business Integration Server Foundation에서 제공하는 애플리케이션 어댑터 컨테이너. 어댑터는 SOA 프로토콜과 포맷간 변환을 수행하고 기존 애플리케이션과 시스템들도 변환한다. 예를 들어, SAP용 어댑터는 SOA로 인코딩된 XML-over-Hypertext Transport Protocol을 SAP의 기존 비즈니스 애플리케이션 프로그래밍 인터페이스 포맷과 Remote Function Call(RFC)로 변환한다.
사전 정의된 SQL 쿼리, XML 쿼리에 의해 구현된 서비스 또는 프로시저에 저장된 데이터베이스	WebSphere Application Server와 연결된 DB2. 쿼리용 매개변수들은 SOA 연산의 인풋 메시지에서 가져오고 결과는 아웃풋 메시지를 제공한다.
자바 클래스와 EJB를 사용하여 구현된 서비스	WebSphere Application Server.