Tech Point 웹서비스
상태바
Tech Point 웹서비스
  • 승인 2006.04.24 00:00
  • 댓글 0
이 기사를 공유합니다

SOA 인프라 구축 위한 최적 표준으로 자리매김
적합한 스펙·표준 확보 중요 … 새로운 아키텍처 모델로 SOA 주목

서비스 지향 아키텍처(SOA)가 모멘텀을 얻게 되면서, 웹서비스 표준으로 유지시키는 것이 성공의 열쇠가 되고 있다. 이를 위해 알아둬야 할 것들을 정리했다.

SOA는 엔터프라이즈 애플리케이션과 패키지로 이뤄진 애플리케이션 인프라 모두를 위한 새로운 아키텍처 모델로 모멘텀을 확보해 나가고 있다. SOA 구축을 지원하는 스위트들이 하루가 멀게 출시되고 있는가 하면 관련 표준과 정보 역시 빗발침에 따라 기업들에게는 오히려 부담이 될 정도다.
패키지 애플리케이션을 구매하거나 SOA 선도를 위한 고객 전용 소프트웨어를 개발하든지 간에, 나날이 늘어나는 웹서비스 표준의 미로를 통해 자신의 길을 찾아가는 것은 성공의 필수적인 요소다. 이를 위해서는 우선 알아둬야 할 것
들이 몇 가지 있다. WSDL(Web Services Definition Language), SOAP(Simple Object Access Protocol), WSS (Web Services Security) 등의 표준은 웹서비스 아키텍처를 구축하는 데 필요하다. 그러나 웹서비스 라우팅 프로토콜(WS-Routing)과 같은 일부 프로토콜은 하나 또는 그 이상의 보다 새로운 표준에 의해 대체되고 있다.

웹서비스 표준 관리 단체
WS-I(Web Services Interoperability Organization)를 비롯 W3C(World Wide Web Consortium), OASIS (Organization for the Advancement of Structured Information Standards) 등의 단체들은 웹서비스의 표준과 스펙을 우선적으로 책임진다. 이 단체들은 웹서비스 기반의 솔루션 벤더들의 대표와 산업 전문가를 포함해 구성된 기술 위원회를 통해 표준과 스펙을 공식화한다. 산업 안에서 이들의 영향력은 IETF(Internet Engineering Task Force)와 유사하다.
IETF의 표준과 마찬가지로 이러한 웹서비스 단체에 의한 표준과 스펙의 벤더 수용은 아직 강요되지는 않고 있다. 그러나 마이크로소프트, IBM, 썬, BEA 등과 같은 대형 벤더들이 이러한 웹서비스 표준을 따라야 한다는 중요성에 동의하고 있어 점차 힘을 받고 있다.

WS-I(www.ws-i.org)는 웹서비스 솔루션 구현을 위한
호환성을 증진시키고 있다. WS-I는 WSDL와 UDDI (Universal Description, Discovery and Integra-tion), SOAP 등의 웹서비스 표준의 핵심 구성에 대한 상호 작용을 위한 가이드라인인 WS-I 베이직 프로파일(일반적으로 1.1 버전)에서 움직이는 것으로 잘 알려져 있다. 또한 보조 가이드라인과 같은 WS-I 베이직 시큐리티 프로파일에 대한 책임을 갖고 있다.
이는 OASIS WSS 표준을 구현하는 솔루션들의 호환성 가이드라인 구성을 상술하고 있다. 이러한 가이드라인의 수용이 진전되고 대부분의 웹서비스 벤더들이 이를 지원함에도 불구하고 강요되지는 않고 있다. WS-I 프로파일의 수용은 벤더와 기업에 의해 채택된 최상의 실천이다.
W3C(www.w3c.org)는 WSDL, UDDI, SOAP 등 웹서비스 표준의 핵심 구성 요소의 뒤에 있는 단체로 OASIS 표준이 구현되는 XML 기반의 스펙에 대한 책임을 갖고 있다. 이들 사이에 XSL(Extensible Stylesheet Language)과 XSLT(XSL Transformations), XPath, XQuery 등과 같은 XML 시그니쳐와 유틸리티 표준, XML 암호화가 있다. 더불어 IT 기능 또는 특정 비즈니스를 가능케 하는 웹서비스와 연관된 대다수의 표준은 OASIS 기술 위원회에서 제시
된다.
OASIS(www.oasis-open.org)는 웹서비스 표준을 주도하는 단체들에게 영향을 미치고, 가장 많은 결과를 산출한다. OASIS의 표준은 WSS처럼 시장에 광범위하게 퍼져있는 제품을 만들어 냈다. OASIS는 WSS와 WS-Addressing, WS-Reliability를 포함한 다양하면서 광범위한 WS-* 표준의 근거지다. OASIS의 표준과 스펙은 매니지먼트에 대한 거래 지원으로부터 IT 경계를 넘나든다.
WS-Policy와 같은 표준은 WS-SecurityPolicy와 미래에 나타날 또 다른 것들과 같은 많은 서브세트 표준을 포함하고 있다. OASIS의 스펙은 명세는 객체(object) 지향 원리에 깊게 뿌리를 두고 있고, 유전적 원리와 마찬가지로 쉽게 확장이 가능하다.
WS-*는 엔드포인트에 관한 정보를 운반하는 엔드포인트 레퍼런스 요소와 같은 객체의 공통 사용을 허용한다. URI를 말하는 좋은 방법으로, mailto를 비롯 HTTP, FTP와 같은 엔드포인트에 교신하는 프로토콜에 필수적으로 실리게 된다. 엔드포인트 레퍼런스 요소는 스펙의 다양함 속에서 클라이언트와 엔드포인트를 묘사하는데 사용된다.
WS-Addressing과 WS-Policy는 이것에 깊게 의존하는데, WS-SecurityPolicy와 같은 특정 스펙은 도메인에 기원을 둔다. 엔드포인트 레퍼런스 요소와 같은 공통된 레퍼런스 요소를 이해하는 것은 새로운 웹서비스 스펙 연구를 위한 출발의 근원이 될 것이다.
WS-Policy 주장과 요구는 서브 기술 설명을 가로질러 일치하는 것으로, 도메인에 특정 프로세싱 명령을 내리기 위해 만들어진 새로운 프로토콜의 정의보다 도메인을 특화함에 따라 속성과 요소를 해석할 수 있도록 정책 엔진에 융통성을 부여한다. 이는 간단하면서 확장 가능한 정책 엔진이 다중 특성을 다룰 수 있다는 것을 의미하는 것으로, 각 도메인 베이시스에 정책 엔진을 구축하는 비용 및 오버헤드를 줄일 수 있다.

끝은 무엇인가?
그렇다면 어떤 표준과 스펙에 집중해야 하며, 어떤 것을 무시할 수 있을까. 많은 스펙과 표준은 웹서비스 상에서 알 필요가 있는 것들의 리스트 위에 이것을 만들지도 모른다. 그러나 내년에는 세 가지 핵심 표준과 스펙에 대해 스스로 친숙해져야만 하고 웹서비스 기반의 제품 평가에 대한 어떤 요구를 더하는 것은 OASIS의 WSS를 비롯한 WS-Policy, WS-Addressing 등이다.
WSS는 OASIS 표준으로 승인됐지만, WS-Policy와 WS-Addressing은 이와는 다르다. 두 가지 모두 가까운 미래에 표준으로 자리잡을 것으로 기대되고 있는 가운데 다양한 웹서비스 제품 슈트로 폭넓게 채택되고 있다. WSS는 데이터의 해독, 암호화 인증, 권한 부여, 디지털 사인의 검증에 관해 지원한다. HTTP BasicAuth가 오랫동안 웹서비스의 안전을 위해 사용돼 왔지만 인증과 위임 문제에 대한 전략적인 솔루션이라기보다 전술적이다.
다수의 이용자 또는 서비스 접근을 관리하기에는 실용적이지 않다. 연관된 관리비용이 각 부분의 균등한 성장으로 점차 늘어나기 때문이다. 데이터파워, 포럼시스템즈, 리액티비티 등과 같은 보안 업체들에 의해 적절하게 구현된 WSS는 CPU 집약적 암호화와 해독 의무에 대한 퍼포먼스에서 부스트(boost)를 공급하고 관리의 몫을 절감할 수 있다. 그러나 웹로직, 웹스피어, 오라클AS 등을 포함한 대다수의 기업 서비스 플랫폼 상에서 WSS를 구현할 수 있다. 웹서비스 시행을 어디에서 구현하는 것과 관계없이 WSS-compliant가 될 전망이다.
WS-Policy는 일반적인 SOAP 정책 포맷을 정의한다. 스펙은 주어진 정책의 구현이라기보다는 메타데이터에 관한 것이다. 하지만 WS-Policy에 관해 배우는 것은 개발하는 대로 미래의 웹서비스 특성화 정책과 보안, 매니지먼트에 관해 정보를 어떻게 분산시킬지 이해하게 되는 것이다. 이는 정책이 어떻게 포맷되는지 정의하는 것뿐 아니라 SOAP 메시지와 연관되거나 또는 덧붙이는 방법에 관해서 서술하고 있다.
예를 들면 OASIS의 WS-SecurityPolicy 스펙은 보안 정책이 첨부될지 모르는 WSDL 안에 다중 지점을 정의하는 것으로 형태, 메시지, 바인딩 등을 의미한다. WS-Addressing은 엔드포인트와 같은 지점 형태를 특성화할 수 있는 WS-Policy 요소를 덧붙이는 매커니즘을 포함한다. WS-Policy는 보안과 프라이버시, 트래픽 컨트롤 등과 같은 특정 도메인 내 정책을 적용하기 위해 프로세싱 엔진을 지시하는 어서션(Assertion)을 사용한다. 보안 도메인 내 어서션은 신용카드번호나 사회보장번호(SSN) 등을 즉각 암호화할 수 있는 것과 같은 요소를 요구할 수 있다.
WS-Policy는 웹서비스 전략으로 중요하다. 특정 정책이 네트워크를 가로질러 흐르는 데이터에 어떻게 적용될지를 지시하는 다양한 표준과 스펙에 의해 사용되기 때문이다. WS-Addressing은 WS-Routing에 대한 스펙을 대체한다. 이 것은 메시지를 인식하고(메시지ID), 수령인을 조건 지정하며(To), 누구에게 보내질(ReplyTo)에 관한 매커니즘을 포함한다. SOAP 헤더 속으로 입력되며, 액션(Action) 속성으로 WSDL 포트 타입 요소 안의 잘못된 메시지와 I/O를 확장한다. 이러한 용법과 사용은 SMTP와 유사한데, 메시지가 자체적으로 계획된 목적지에 도달하기 전에 여러 중간단계를 통해 흐르기 때문이다.
WS-Addressing은 외부에서 발생한 것처럼 보인다. 결국 대부분의 SOAP 메시지는 HTTP를 통해 보내지며, 발송자와 수신자는 알려져 있다. SOAP 액션은 HTTP 헤더에서 운반된다. 그러나 WS-Addressing은 SOAP로부터 수송에 의존해 이를 제거한다.
목적지의 엔드포인트가 JMS(Java Messaging Service)라면 URI는 콜을 위한 어떤 작동을 결정할 HTTP 헤더를 사용할 수 없으며, 클라이언트가 서비스를 회신할 엔드포인트를 필요로 할 지 가정할 수 없다. 이를 대신해 JMS 헤더를 사용할 수 있을 것인가. 물론 가능하다. 하지만 이것은 SOAP가 자급자족하며, 주어진 어떤 운송에 의존하지 않는 기본적인 전제를 방해한다.
WS-Addressing은 웹서비스에 접근하기 위해 파라미터 매커니즘 또는 운송 헤더 상의 어떤 신뢰도 제거한다. 이는 SOA 구현에서 점점 더 중요해지고 있다. 최근 대다수의 구현상에서 이러한 유비쿼터스 프로토콜의 이점을 이용함에도 불구하고 서비스는 HTTP 상에서 전송돼야 한다는 것은 아니다.
향후 선보일 스펙과 표준은 SOA 인프라에 중요하다. 트랜잭션 기반의 스펙, 매니지먼트, 시큐리티와 신뢰성 높은 메시지는 현재 개발이 진행되고 있다. 그러나 WS-Policy를 비롯 WS-Addressing, WS-Security는 아직 드러나지 않은 표준 기반 마련과 SOA 인프라 구축을 위한 최적의 표준으로 자리잡기 위한 가속을 붙여 나가고 있다.

웹서비스를 이끄는 단체

웹서비스를 이끄는 세 개의 단체는 WS-I와 W3C, 그리고 OASIS다.
>> WS-I (www.ws-i.org)
WS-I는 웹서비스 구현간의 호환성을 증진시킨다. WSDL과 UDDI, SOAP 등 웹서비스 표준의 핵심 구성을 위한 호환성 스펙 가이드라인인 WS-I 베이직 프로파일(현재 1.1 버전)을 개발 중이다. 또한 WS-I 베이직 시큐리티 프로파일을 책임지고 있다.
>> W3C (www.w3c.org)
W3C는 WSDL과 UDDI, SOAP 등 웹서비스 표준의 핵심 구성을 개발했다. 또한 XSLT과 XPath, XQuery와 같은 유틸리티 표준, XML 암호화와 XML 시그니쳐와 같은 XML 기반의 스펙을 책임지고 있다.
>> OASIS (www.oasis-open.org)
OASIS는 WSS를 포함한 폭넓은 웹서비스 커뮤니티에서 대부분의 영향력 있는 표준을 개발해 왔다. 또한 WSS와 WS-Addressing, WS-Reliablity 등을 포함한 WS-X 표준을 만들었다.


댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.