서비스 지향 아키텍처를 통한 웹 서비스 비전 확대, Part 2

문서 옵션 JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다. 영어원문  제안 및 의견 피드백

난이도 : 초급

Mark Colan, e-business evangelist, IBM Corporation

2007 년 10 월 02 일

이 글에서는 서비스 지향 아키텍처(SOA)를 자세히 연구합니다. Part 1에서는 SOA의 특성을 이야기 했습니다. 이 글에서는 SOA Connection Architecture를 설명합니다. SOA에서의 역할, 서비스 요청자와 서비스 공급자가 통신하는 방법, 서비스 공급자가 서비스를 서비스 요청자에 통합하는데 필요한 정보를 지정하는 방법, 서비스 요청자가 필요한 정보를 찾는 방법을 설명합니다. 메시지 교환 패턴도 설명하고 동기식/비동기식 교환을 비교합니다.

표음문자 보다는 표의문자들로 구성된 한자어는 방언들간 발음은 다르지만 같은 문자로 표시된다. 진 왕조 시절에 공용어는 실현되지 않았지만, 중국 사람들은 서로의 글자를 이해하지 못하더라도 공용어로 통신할 수 있다.

소셜 북마크 mar.gar.in Digg del.icio.us Slashdot

웹 서비스도 비슷한 개념을 적용하고 있다. XML은 다른 프로그래밍 언어들로 작성된 프로그램들 간 교환 매개체로서 사용될 수 있고, 다양한 종류의 머신 명령어를 실행할 수 있다. XML은 모든 웹 서비스 기술의 기초이며 상호 운용성의 열쇠이다. 모든 웹 서비스 스팩은 XML에 기반하고 있다. 특히, SOAP은 XML로 작성된 정보의 교환을 규정하고 있고, WSDL은 XML 어휘로 SOAP 상세를 기술하고 있다.

본 시리즈 Part 1(참고자료)에서 필자는 SOA와 그 특성을 정의했고, 웹 서비스 기술들과의 관계를 설명했다. SOA는 애플리케이션 시스템들을 구성하고 있는 아키텍처 스타일이며, 재사용을 위해 패키징 된 애플리케이션 함수이다.

필자는 웹 서비스를 오늘날 SOA를 구현하는 최상의 표준 세트라고 설명했다. 웹 서비스에 대한 많은 글들이 있기 때문에, 상세한 부분들은 다른 글들을 참조했다. (참고자료) 필자가 SOA의 아키텍처 개념을 설명할 때, 여러분은 이것이 웹 서비스 개념과 겹치는 부분을 발견할 것이다. 하지만, SOA는 웹 서비스 비전을 확대했다. 이것이 바로 이 글의 주제이다.

서비스 역할

웹 서비스와 마찬가지로, SOA에는 두 가지 핵심적인 역할들이 있다. 서비스 요청자(service requestor)와 서비스 공급자(service provider)이다. 요청자 애플리케이션은 요청 메시지를 보내고 응답 메시지를 처리함으로써 한 개 이상의 공급자 애플리케이션들이 제공한 서비스를 호출한다.

일부 서비스 공급자들은 서비스 요청자도 될 수 있다. 다른 서비스 공급자들에게서 기능들을 모아서 복합적인 고급 서비스들을 구현한다. 자바 또는 C# 같은 기존 언어들 또는 Business Process Execution Language (BPEL) 같은 특수한 구성 언어를 사용한다.

UDDI와 WS-Trust 같은 SOA 기술들은 서비스 브로커(service broker)라고 하는 제 3의 역할을 도입하고 있다. 서비스 브로커는 서비스 공급자와 서비스 요청자 간 매개체(서비스 배치, 신뢰성 있는 정렬 중개)이다.

이러한 세 개의 역할들로 모델링 된 엔터티들은 통신할 때 Service Invocation (SOAP 메시지)을 사용한다.

위로

서비스 호출

W3C SOAP 1.2 표준은 서비스 요청자와 서비스 공급자 간 통신에 XML로 포맷된 메시지의 사용을 정의한다. 애플리케이션 요청(XML)은 SOAP envelope(XML) 안에 놓이고, 요청자에서 공급자로 보내진다. 공급자가 보내는 응답은 같은 폼을 취한다. 이 글을 쓰고 있는 현재, 시중에 나와 있는 대부분의 제품들은 이전 SOAP 1.1 스팩을 지원하지만, SOAP 1.2가 향후 제품 릴리스에서는 지원될 것이다. SOAP에 대한 자세한 사항은 참고자료 섹션을 참조하기 바란다.

SOAP은 파트너들과 개별 IT 인프라스트럭처들 간 약결합 인터랙션으로 서비스 호출을 지원하는 최상의 방법이다. 이것은 플랫폼 중립 및 벤더 중립의 표준이기 때문이다. 하지만, SOA는 SOAP을 사용할 필요가 없다.

SOAP 이전에, 일부 기업들은 IBM® WebSphere® MQ를 사용하여 XML 문서를 다른 컴퓨터로 보냈고, 여기에서 애플리케이션 프로그램은 문서의 내용에 따라서 액션들이 수행되도록 한다. eBay XML over HTTPS 인터페이스는 아이템들을 경매에 부치는 것과 비슷한 방식으로 작동한다. 이러한 웹 서비스들이 SOAP을 사용하지 않기 때문에 이들을 호출하지 않지만, SOA에서는 이것을 서비스 호출로 여전히 부르고 있다. 요즘, WebSphere MQ 역시 SOAP 메시지들을 직접 지원한다.

모든 엔터티들이 자바로 작성되기만 한다면, J2EE에서 사용할 수 있는 장치들만을 사용하여 SOA를 구현할 수 있다. 하지만, 이 같은 방식은 비 자바 애플리케이션과의 상호 운용성에는 만족할 만한 솔루션을 제공하지 못한다.

여러분이 IT 시스템용 코드에 대한 제어권을 갖고 있는 기업 내에서, XML 콘텐트를 구현 및 인터프리팅 하지 않고, 여러분은 서비스 호출을 위해 SOAP 외에 다른 방식들을 고려할 수 있다. 이렇게 하면 더 나은 성능을 나타내며, 기존 함수 주위에 SOAP 래퍼 코드를 작성할 필요가 없게 된다. 단순함을 위해서, 다른 프로토콜들을 사용하여 서비스를 호출할 수 있는 단일 호출 API 스타일을 갖는 것이 좋다.

위로

멀티 프로토콜 서비스 호출

JAX-RPC 스팩(JSR-101)은 자바 프로그램에서 웹 서비스를 쉽게 호출할 수 있게 하는 자바 API를 정의한다. 최소한, JAX-RPC 구현은 HTTP를 사용하여 SOAP 1.1를 지원해야 한다. 하지만, 서비스 호출에 다른 프로토콜을 지원할 수 있다. 멀티 프로토콜 서비스 호출(Multi-protocol Service Invocation)은 같은 API를 사용하여 다른 프로토콜을 지정하는 기능이다. (예를 들어, URL 변경)

현재 WebSphere Application Server 릴리스의 JAX-RPC 구현은 JSR-101-호환이지만, SOAP over JMS 호출도 가능하다. WebSphere MQ 같은 JMS 서버를 다루는 폼으로 URL을 변경한다. 가까운 미래에, 이러한 멀티 프로토콜 스타일은 RMI over IIOP를 사용한 서비스 호출도 가능케 할 것이다. 결과는 EJB와의 효율적인 인터랙션이다.

단순함의 정수는 프로토콜에 관계 없이 서비스에 같은 API를 사용하는 것이다. 바로, SOAP over HTTP 보다는 WSDL로 프로토콜을 기술하는 것이다.

위로

서비스 디스크립션

Web Services Description Language (WSDL) 스팩은 서비스 요청자와 서비스 공급자간 요청 및 응답 메시지의 관점에서 콘트랙트(contract)를 정의하기 위한 XML 어휘를 정의한다. 웹 서비스를 SOAP 메시지 인터페이스를 기술하는 WSDL 문서의 수단으로 재사용 가능한 애플리케이션 함수를 제공하는 소프트웨어로서 정의한다. 이는 표준 전송 프로토콜을 사용하여 전달된다.

WSDL 디스크립션에는 서비스 요청자가 특정 서비스를 사용하는데 필요한 상세들이 포함된다.

• 요청 메시지 포맷
• 응답 메시지 포맷
• 메시지를 보낼 곳

WSDL은 XML에 기반하기 때문에, WSDL 문서는 머신에서도 읽힌다. (machine-readable) 따라서, 개발 환경은 이들을 사용하여 서비스를 요청자 애플리케이션으로 통합하는 프로세스를 자동화 할 수 있다. 예를 들어, WebSphere Studio는 서비스를 구현하는 로컬 객체 같이 작동하는 자바 프록시 객체를 생성할 수 있지만, 실제로, 응답 메시지의 요청 및 번역만 핸들한다. 자바 프록시 객체는 서비스가 자바, C# 또는 다른 언어 등 어떤 것으로 구현되든지 간에, WSDL 디스크립션에서 웹 서비스를 호출하기 위해 생성된다. 사실, WSDL은 프로그래밍 언어 같은 구현 상세들을 기술하지 않는다.

확장 기능을 가진 WSDL은 SOAP over HTTP 와는 다른 프로토콜로 서비스를 정의한다. SOA의 관점에서, WSDL로 기술할 수 있는 어떤 애플리케이션의 함수도 서비스로 호출될 수 있다고 주장할지 모른다. SOA는 특히 WSDL을 필요로 하지 않고, 다른 서비스 디스크립션 언어를 사용할 수 있지만, 대부분의 벤더와 제품들은 WSDL을 지원한다.

위로

메시지 교환 패턴

요청-응답이라고 하는 유명한 교환 패턴에서, 서비스 요청자는 요청 메시지를 서비스 공급자(또는 엔드포인트)로 보내고, 요청을 처리한 후에, 공급자는 응답 메시지를 요청자에게 보낸다. 서비스 인터랙션은 대화형이고, 여러 요청-응답 쌍들로 구성된다. 하지만, 성능, 디자인의 단순함, 약결합의 효과에서 볼 때, 한 트랜잭션에 필요한 교환의 수를 최소화 하는 대단위(coarse-grained) 인터페이스를 디자인 하는 것이 좋다.

요청-응답 패턴 외에도, WSDL 역시 다음을 정의한다.

• 엔드포인트로 보내지는 일방향 메시지(one-way message) -- 응답을 필요로 하지 않는 요청.
  
  그림 7. 일방향 요청
  
  
  
• 엔드포인트에서 보내지는 일방향 메시지, 공지(Notification)
  
  그림 8. 공지
  
  
  
• 간청-응답 모델(Solicit-Response model), 엔드포인트는 메시지를 보내서 응답을 받는다.
  
  그림 9. 간청-응답
  
  
  

오늘날의 SOA 구현은 일반적으로 HTTP를 사용하는데, 이는 동기식(synchronous) 통신이 되게 하며, 요청자는 처리 전에 응답을 기다린다. 동기식 교환은 비교적 짧은 시간(수초 또는 수분 내) 동안 완료되어야 하는 서비스를 호출하는데 사용된다.

또한, 비동기식 서비스 인터랙션도 가능한데, 여기에서 서비스 요청자는 응답을 기다리지는 않고, 나중에 전달되기를 기대한다. 이는 장기 실행(long-running) 트랜잭션에 알맞다. 예를 들어, 비즈니스 프로세스를 호출하여 항공기용 견적서를 요청하는 것에는 많은 파트너와 휴먼 인터랙션이 개입되며, 완료될 때까지 수일 또는 수주가 걸릴 수 있다. 비동기식 교환은 (서버 관리 등으로 인한) 연결과 응답을 잃을 위험 부담을 피한다.

WS-Addressing 스팩은 reply-to 주소를 SOAP envelope Header 엘리먼트용 확장으로서 제안하고 있다. 서비스 요청자는 WSDL 문서에 지정된 포트에 요청을 대기열에 놓지만 기다리지는 않는다. 대신, 응답이 도착할 때까지 다른 작업을 수행한다. 서비스 공급자가 응답을 보낼 준비가 되면, reply-to 주소를 요청 메시지의 SOAP:Header에서 사용한다.

WebSphere MQ 같은 메시지 큐 제품을 사용할 때, JMS를 사용하여 비동기식 메시지를 구현할 수 있다. 요청자는 요청을 대기열에 놓지만, 프로세싱이 완료되기를 기다리지 않고, 다른 작업을 수행하면서 응답 큐에 응답이 있는지를 주기적으로 검사한다.

비동기식 메시징 방식을 적용하여 여러 공지(주식 시세 변동 공지)들을 받는 요청 같은 다른 교환 패턴을 생성할 수 있다.

위로

서비스 발견

서비스 호출(Service Invocation)과 서비스 디스크립션(Service Description)은 SOA의 요구 사항으로 간주되는 반면, 서비스 발견(Service Discovery)은 선택적인 기능이다. UDDI (Universal Description, Discovery, and Integration)은 서비스의 가용성을 드러내고 요청된 서비스를 찾는데 (SOAP 메시지에 기반하여) 표준 인터페이스를 정의한다. UDDI 구현은 SOAP 요청을 번역하여 기반 데이터 스토어용 데이터 관리 함수 호출로 서비스들을 퍼블리시 및 찾는다.

UDDI는 웹 서비스를 실행하고 찾을 수 있는 표준 SOAP 메시지를 정의함으로써 서비스 레지스트리(Service Registry)를 구현한다. 이 레지스트리는 서비스 브로커인데, 서비스를 찾아야 하는 요청자와 UDDI에 가용성을 퍼블리시 하는 서비스 공급자간 중개 역할을 한다. 서비스 요청자가 특정 서비스를 사용하기로 결정했다면, 개발자는 요청을 보내고 응답을 처리함으로써 서비스에 액세스 하는 코드를 만들어서 서비스를 바인딩 하는데, 대게는 IBM WebSphere Studio나 Microsoft® Visual Studio .NET 같은 개발 툴을 사용한다.

SOA 애플리케이션들을 구현하기 위해 필요한 서비스를 발견할 수 있는 전자 옐로 페이지(yellow pages)와 같다. WebSphere Studio의 UDDI 브라우저 같은 툴을 사용하여 애플리케이션 디자인 시 적절한 서비스를 찾는다. SOA는 UDDI의 사용을 필요로 하지 않지만, UDDI는 서비스 발견을 위한 좋은 솔루션이다. 작업을 수행할 때 SOA에 기반하기 때문이다.

여러 다양한 방식으로 UDDI를 사용할 수 있다. (Steve Graham의"여섯 가지 UDDI 종류" - 참고자료) 특히, 이 글은 재사용을 장려하고 엔드포인트 독립성을 촉진시키기 위해 내부 서비스를 관리할 때 IT 기업 내에서 이것을 사용하는 것에 대해 언급하고 있다. 예를 들어, 필요한 서비스의 위치는 애플리케이션에 저장될 수 있다. 서비스가 다른 서버에 재 전개 되면, 서비스 요청자는 UDDI를 사용하여 새로운 위치를 찾고 향후 사용에 대비하여 이를 저장(cache)한다. UDDI가 내부적으로 전개될 때, 서비스 요청자 애플리케이션들은 서비스 전개 시 변경 사항들을 자동으로 받아들인다. (로드 밸런스 관리)

UDDI는 다른 기업들에서 제공된 공식적으로 사용할 수 있는 비즈니스 서비스를 찾을 때 호출될 것이다. 또한 런타임 시 동적인 서비스 선택에도 유용할 것이다. 이 부분은 서비스 구성법(Service Choreography)을 다루면서 설명하겠다.

위로

요약

이 글에서는 SOA의 기본적인 엘리먼트와 다른 서비스를 찾아서 인터랙팅 하는 방식을 설명했다. 재고 서비스들을 내부적으로 또는 파트너들로부터 개발하고 이러한 서비스들을 사용하여 새로운 애플리케이션들을 개발하는 코드를 작성함으로써 SOA에 기반한 IT 아키텍처를 생성할 수 있다. 서비스 공급자는 다른 서비스들을 요청함으로써 작업을 수행할 수 있기 때문에, 자신의 디자인에 맞게 복합 서비스들을 사용할 수 있다. 간단한 요청-응답 메시지 모델이 가장 유명하지만, 다른 메시지 모델로 시스템을 디자인 할 수 있다. WSDL 문서는 서비스를 통합하는 방법에 대해 기술하고 있다. UDDI는 필요한 서비스를 찾는데 도움이 된다.

다음 글에서는, 서비스 구성법과 다른 서비스들에서 서비스와 애플리케이션 시스템을 구현하는 다양한 방법들을 설명하겠다.

위로

이 글에 사용된 제품

developerWorks 회원이라면, 싱글 유저 라이센스를 통해 WebSphere MQ, WebSphere Studio와 DB2®, Lotus®, Rational®, Tivoli® 제품들을 사용하여 애플리케이션들을 개발, 테스트, 평가, 실현할 수 있다. 회원이 아니라면 지금 등록하기 바란다.

참고자료

• 기술자료 "서비스 지향 아키텍처 입문 (한글)" : SOA에 관한 정보와 참고 자료 (한국 developerWorks, 2004).
  
  
• 이 기술자료의 Part 1, "서비스 지향 아키텍처를 통한 웹 서비스 비전 확대, Part 1 (한글)" (한국 developerWorks, 2007년 8월).
  
  
• SOAP 1.1, SOAP 1.2, WSDL 1.1 스팩, WSDL 2.0(World Wide Web Consortium) 리뷰.
  
  
• OASIS UDDI 2.0 스팩, 또다른 기본 웹 서비스 프로토콜.
  
  
• WS-Addressing 스팩
  
  
• Steve Graham의 UDDI 관련 기술자료: 웹 서비스에서 UDDI 노드들의 역할, Part 1: 여섯 개의 UDDI 종류, 웹 서비스에서 UDDI 노드들의 역할, Part 2: 개인 노드와 연산자 노드 (developerWorks, May 2001).
  
  
• Redbook WebSphere Version 5.1 Application Developer 5.1.1 Web Services Handbook.
  
  
• BPEL 1.1 Specification.
  
  
• JAX-RPC 1.1 Specification, J2EE 표준 파트.
  
  
• Joshy Josephy의 JAX-RPC 관련 기술자료: 개발자를 위한 JAX-RPC 소개서, Part 1, Part 2 (developerWorks, November 2002 and January 2003).
  
  
• 웹 서비스 전망: SOAP, WSDL, UDDI를 실제 프로젝트에 적용하기(Zimmermann O, Tomlinson M, Peuser S (Springer-Verlag, 2003, ISBN 3540009140).
  
  
• "서비스 지향 아키텍쳐로 전환, Part 1 (한글)" (한국 developerWorks, 2003년 12월) : 서비스 지향 아키텍쳐(SOA)의 가치를 정확히 이해하기.
  
  
• "서비스 지향 아키텍처로 전환, Part 2 (한글)" (한국 developerWorks, 2003년 12월) 서비스 지향 아키텍처(SOA)의 가치를 정확히 이해하고, 현재의 인프라를 평가하여, 서비스 지향 아키텍처로 전향할 때 현실적인 계획을 수립할 수 있도록 기획되었다.
  

필자소개

		Mark Colan은 IBM의 이-비즈니스 기술 전도사이다. 웹 서비스와 XML 기술 및 전략 분야에서 일하고 있다. 2000년과 2001년 대부분의 XML 컨퍼런스를 비롯하여 Java One '98과 '99에서 강연도 했다. 최신 프리젠테이션 자료(PDF)는 http://ibm.com/developerworks/speakers/colan에서 제공하고 있다. IBM에 입사하기 전, Lotus Development Corporation에서 12년 동안 근무했으며, 상용 제품들을 개발했다. 상용 소프트웨어 제품과 기술의 디자인 및 구현에 20년 경력을 쌓았으며, 컴포넌트 소프트웨어 전략, 운영 체계, 소프트웨어 툴에도 정통하다. Lotus에서 개발된 자바 표준 확장인 InfoBus Technology의 아키텍트 리더이다. (mcolan@us.ibm.com)

기사에 대한 평가

보다 나은 서비스를 제공하기 위함이오니 잠시 짬을 내어 이 양식을 제출하여 주십시오. 귀하께서 원하시는 정보를 얻었습니까? 예 아니오 잘 모르겠음   이 페이지 개선을 위한 의견을 주십시오:   이 정보가 얼마나 유용했습니까? (1 = 전혀 도움이 되지 않음, 5 = 매우 유용함) 1 2 3 4 5

위로