Andre Tost, Senior Technical Staff Member, IBM

2006 년 10 월 31
IBM 안팎의 아키텍트 및 개발자들과 웹 서비스와 SOA에 대해 논의할 때, 가장 논쟁거리가 되었던 공통 관심사, 질문, 소스들을 소개합니다.
IBM WebSphere Developer Technical Journal발췌.

머리말

IBM WebSphere®Developer Technical Journal에 칼럼을 쓰지 않을 때에는, 웹 서비스와 SOA 기반 솔루션을 디자인 및 구현할 때 직면하는 문제들에 대해 아키텍트와 개발자들과 이야기 한다. 많은 이슈들, 질문들, (격렬한 논쟁을 일으키는)주제들이 되풀이 되고 있기 때문에, 개인적으로 웹 서비스 관련 이슈, 탑 10 리스트를 만들어서 여러분과 함께 나누고자 한다.

이것은 베스트 프랙티스(best practices)가 아니다. 대부분이 쉬운 해답은 아니니까. 어떤 것들은 해답을 찾았고, 이에 대해서는 보다 자세히 연구할 수 있는 자료들을 소개할 것이다. (물론, 대부분이 developerWorks 기술자료이다.) 이러한 주제들이 게시판에서 되풀이 되고 있고, 내 주장에 전적으로 동의하거나 동의하지 않을 수도 있다는 것을 안다. 여러분이 주제들을 추가해도 된다. 내가 빗장을 열 테니, 그 뒤는 여러분이 알아서 해주기 바란다.

1. document/literal Web service란 무엇인가?

이는 의심의 여지가 없는, 매우 중요한 질문이다. 사실, 수년 동안 이 질문을 받았기 때문에, 이것이 여전히 논의 선상에 있고, 이에 대한 많은 오해가 있다는 것이 다소 놀랍다. WSDL 정의로 웹 서비스의 호출과 인코딩 스타일을 정의할 수 있다는 것은 알 것이다. 이것은 와이어(wire) SOAP 메시지가 구현되는 방식에 영향을 주는 반면, 전체 솔루션, 인터랙션 스타일, 프로그래밍 모델에는 아주 작은 영향만 미친다. 따라서 나는 언제나 다음과 같이 조언한다.
하나의 특정한 스타일만 사용하지 않도록 한다. 다양한 스타일을 사용해야 하는 이유들이 있고, 여러분도 그 이유들은 알고 있을 것이다.
이 문제를 구현 상세로 간주하고, 이것이 여러분의 시스템 디자인에 영향을 미치지 않도록 하라.
Russ Butek의 기술자료, 나에게 맞는 WSDL 스타일은? (한글)을 참조하기 바란다. 이 차이점을 가장 잘 설명한 글이라고 생각한다.


2. 웹 서비스가 느리다. -- 원래 그런가?

웹 서비스를 사용하는 데에는 퍼포먼스 대가가 따른다는 것은 일반 상식이다. 일정 포맷으로 포맷된 데이터에서 XML 문서를 구현하고, 이 문서를 네트워크로 보내는 문제라면, 이것은 전혀 놀라운 일도 아니다. 크로싱 프로세스, 심지어 네트워크를 통한 프로세스는 언제나 로컬 호출 보다 느리기 마련이다. 웹 서비스 퍼포먼스의 향상에 대해 듣는다면 분명 놀랄 것이다.

여기에 기여하는 많은 것들이 있다. 지능형 XML 파서 기술(SOAP과 XML 생성물들을 핸들하도록 최적화 되었다) 또는 IBM DataPower® 같은 XML 장비(하드웨어 레벨의 XML 프로세싱을 지원한다)도 여기에 일조했다. 나는 퍼포먼스를 상당히 향상시키는 WebSphere Application Server에서의 웹 서비스 캐싱 지원도 추가하고 싶다. 사실, 어떤 상황에서는, 최신 WebSphere Application Server 런타임 상에서 SOAP over HTTP 호출이 RMI over IIOP에서 같은 기능을 호출하는 것 보다 빠르다.

따라서, 분산 컴퓨팅에 대한 기본적인 베스트 프랙티스를 견지하면서(예를 들어, 네트워크 트래픽 줄이기), 퍼포먼스에 민감한 상황에도 웹 서비스를 생각해보는 것도 권하고 싶다.




3. 내 XML 스키마가 당신의 제품과 맞지 않는다!

Hello World 스타일의 테스트 애플리케이션을 개발하는 단계를 지났다면, XML 스키마 스팩의 몇몇 고급 요소들이 여러분의 툴에서는 지원되지 않거나, 잘 지원되지 않는다는 것도 알게 될 것이다. 예를 들어, WebSphere 툴링에는, 스키마에서 자주 사용되는 <xsd:choice> 엘리먼트에는 어떤 매핑도 없다. 이 경우, 스키마를 변경하거나, 자신의 코드를 개발하여 이 같은 스키마에 기반한 XML을 처리할 수 있다. 스키마를 여러분의 웹 서비스 구현에 매핑하기 위해서는 수동 개입이 필요함을 잊지 말라. 두 개의 기술자료를 소개하겠다.:

Use polymorphism as an alternative to xsd:choice
How to choose a custom mapping technology for Web services
이러한 문제를 단번에 풀 수 있는 비법은 없다. 하지만, 차기 표준과 제품에서 고급 스키마에 대한 지원이 향상되기 바란다.




4. UDDI는 어떤가? 이것을 사용하는 사람은 있는가?

웹 서비스가 처음 대중화 되었을 때, SOA 환경에 존재하는 세 개의 메인 역할에 대해 주지를 받았다.:

서비스 요청자
서비스 공급자
서비스 브로커.
브 로커의 역할은 UDDI 표준을 따르는 레지스트리에 의해 표현된다. 여러분은 공용 레지스트리를 사용하여 자신의 엔트리를 만들고 다른 것을 재사용 할 수 있다. WebSphere Application Server에는 개인 UDDI 레지스트리가 포함되어 있다.

하지만, 실제 상황에서 UDDI를 사용하는 것은 잘 볼 수 없다. 대부분의 IT 기업들은 서비스 정의와 엔드포인트를 가져오는 방식들을 스스로 구현하거나(LDAP 사용), 아니면 서비스 레지스트리에 대한 그야말로 새로운 방식을 기다리면서 이 문제를 피해간다. 어떤 사람들은 UDDI에 상용 확장을 추가한다. IBM과 다른 곳에서 운영하는 퍼블릭 UDDI 레지스트리는 중단되었다.

UDDI는 시간이 흐르면서 아직은 등장하지 않은 새로운 기술로 대체될 것으로 보인다.



5. 웹 서비스의 동기화

서 비스가 동기식인지, 비동기식인지, 프로그래밍 모델과 비교하여 각각의 통신 프로토콜이 어떤 역할을 하는지에 대해서는 빈번한 논의 대상이다. 예를 들어, 웹 서비스가 SOAP over JMS 바인딩으로 제공된다고 가정해보자. 비동기식 인터랙션을 지원하는 JMS를 사용한다는 것은 비동기식 웹 서비스라는 것을 의미한다. 하지만, WebSphere Application Server에서 JAX-RPC 지원을 사용한다면, 서비스 소비자는 제어를 리턴하기 전에 응답이 돌아올 때까지 기다려야 한다. 그 이유는 JAX-RPC 1.1이 사용되는 프로토콜과 관계없이, 요청자와 공급자 간 동기식 인터랙션을 실행하기 때문이다. 다시 말해서, 웹 서비스를 호출하기 위해 사용하는 프로그래밍 모델은 네트워크 프로토콜이 아닌 호출의 동기성을 결정한다.

진정한 비동기식 인터랙션을 구현하려면, 두 가지 옵션이 있다. WebSphere Application Server V6.1의 WS-Addressing 지원을 활용하여, 정보를 교환하는 일방(one-way) 서비스를 구현한다. developerWorks 기술자료 :WS-Addressing이 SOAP에 미치는 영향을 읽어보기 바란다.

다른 옵션으로는 비동기식 호출에 Service Component Architecture (SCA) 지원을 활용하는 것이다. SCA는 요청을 보내는 사람과 응답을 받는 사람을 디커플링하는 클라이언트 API를 제공한다. 앞으로, 새로운 JAX-WS 2.0 표준이 비슷한 지원을 할 것이다.


6. ESB

Enterprise Service Bus (ESB)와 관련된 많은 질문들이 올라온다.:

ESB가 무엇인가? 제품인가, 패턴인가, 아니면 둘 다인가?
SOA의 모든 구현에 ESB가 필요한가?
ESB가 허브라면, 잠재적인 병목 현상을 보이는가?
ESB 안에는(in) 무엇이 있으며, ESB 상에는(on) 무엇이 있는가?
이러한 질문들에 답을 달기 전에, SOA 프로그래밍 모델이라는 정황에서 IBM 버전의 ESB를 매우 잘 설명해 놓은 자료를 소개하겠다: IBM Enterprise Service Bus 소개 (한글).

위 질문에 답을 달기 위해서는 기술자료 시리즈를 할애해도 모자라기 때문에, 간단한 답만 달겠다.:

Enterprise Service Bus는 아키텍처 패턴이다. 제품은 이 패턴의 특정 인스턴스의 생성을 촉진시킨다.
ESB 의 핵심 특징은 영역의 분리이다. 통신 프로토콜 차이, 인터랙션의 라우팅과 감사, 보안 등의 문제는 실제 서비스 요청자와 공급자의 외부에서 다루어질 수 있다. 이렇게 구별하지 않고 솔루션을 시작할 수 있다면, 지금 당장은 ESB가 필요 없다. 대부분의 프로젝트에서, 이 같은 경우는 없다.
ESB는 거의 모든 인스턴스들이 분산 방식으로 물리적으로 전개된 개념상의 허브이다.
이 는 대답하기 힘든 문제이지만(그리고, 여러분이 사용하는 제품에서 운영되지만), 인프라스트럭처 로직 대 비즈니스 로직을 생각해보면 좋을 것 같다. 인프라스트럭처와 관련된 일이 이 버스에서 발생하지만, 비즈니스 관련 문제들은 여기에서는 발생하지 않는다.
이렇게 간단한 대답으로 충분한 답이 되지 못하겠지만, 이해의 실마리 정도는 될 것이다.


7. 헤더와 기타 콘텍스트 데이터

웹 서비스 디자인의 핵심은 서비스 안팎을 오가는 메시지를 정의하는 것이다. 메시지는 언제나 두 개의 핵심 부분을 갖고 있다라고 하는 것이 더 맞는 말일 것 같다. 비즈니스 기능과 관련된 실제 페이로드와 (메시지 아이디, 트랜잭션 또는 세션 아이디, 보안 정보 같은) 콘텍스트 데이터가 바로 그것이다. 각 메시징 프로토콜은 이러한 콘텍스트 정보를 위한 장소를 제공한다. 예를 들자면, SOAP 헤더, JMS 헤더, WebSphere “workspaces” 등이 있다. 이러한 다양한 메커니즘을 다루는 일관된 방식이나 API는 없고, 대부분의 실제 SOA 환경에서는 한 개 이상의 메시징 프로토콜이 있기 마련이다.

이 같은 차이점을 다루고, 하나의 헤더 구조를 다른 구조로 매핑하기에 최적의 장소는 ESB이다. (이것 역시 ESB의 장점이다. 아래에는 최소한 한 개 이상의 예가 더 있다.)

이것을 어떤 방식으로 다루든지 간에, 이에 대한 전략을 설계 및 디자인하고, 여러분의 모든 프로젝트에 일관성을 유지하는 것이 중요하다.


8. 어느 만큼의 (웹) 서비스가 적당할까?

이 질문에 대해서는 우선, 서비스를 규명하는 과정을 도울 방법을 제안하겠다. 한 예가, IBM Global Business Services에서 추진하고 있는 Service Oriented Modeling and Architecture (SOMA) 방식이다. IBM Rational® Unified Process (RUP)와 결합되면, SOA에 대한 일반적인 문제들을 해결할 수 있다.

두 번째로, IT의 모든 기능 조각들을 조각을 웹 서비스로 래핑하지 말라. “바톰업(bottom-up)” 방식을 사용하여, 여기에 풍부한 툴링 지원을 하고 싶은 유혹을 받는다. 대부분의 경우, 이러한 방식들을 취했고, 이는 너무나 세분화 된, 수 많은 서비스들을 만들어냈고, 결국 재사용 할 수도 없고, 비즈니스 관련성도 없다.

다시 말하지만, 이를 해결하는 비결은 없다. 알맞은 레벨의 세분성으로, 알맞은 서비스를 정의 및 만드는 문제는 비즈니스 분석가와 IT 아키텍트 모두에게 어려운 일이다.


9. 웹 서비스 소비자로서 레거시 애플리케이션

기 존 기능을 웹 서비스로 인에이블링 하는데 대부분의 초점이 맞춰지고 있다. 하지만 똑같이 중요함에도 불구하고, 비교적 적게 논의되는 부분이 기존 애플리케이션으로 새로운 서비스를 활용할 수 있는 기능이다. 한 기업이 SOA에 대해 혁신적인 방식을 따르고 있고, 점점 더 새로운 서비스를 만들고, 이들을 기존 환경에 통합한다고 가정해 보자. 기존 애플리케이션들 중 하나는 RPG로 작성되어 IBM iSeries 시스템에서 실행되고 있다. 하지만 이 시스템을 맡고 있는 개발자는 SOAP이나 XML 관련 기술력을 갖추지 못했고, RPG 기반 웹 서비스 패키지도 사용할 수 없다.

이 같은 문제에 대한 가장 일반적인 해답은 SOAP과 XML 프로세싱을 ESB로 위임하라는 것이다. COBOL이나 RPG로 작성된 애플리케이션들은 WebSphere MQ 큐들과 레코드-포맷 메시지들을 쉽게 교환할 수 있다. 이에 대한 지원 체계는 잘 확립되었고 이미 사용 중이다. WebSphere ESB나 WebSphere Message Broker 같은 ESB 제품들은 MQ에서 데이터를 받아, 이를 XML로 변형하고, 새로운 웹 서비스의 호출을 처리한다.

다시 말해서, 기존 애플리케이션에 대한 새로운 서비스의 영향력을 최소한으로 유지하고, 프로토콜과 메시지 포맷의 상세는 ESB로 위임하는 것이 좋다.


10. “The devil is in the details”

최 근에, 프랑스에 있는 IBM Industry Solutions Center에 방문했다. 유통, 보건, 은행 같은 다양한 산업 분야에 IBM 기반 솔루션들을 선보이는 자리였다. 발표자는 특정 IT 제품들을 언급하는 대신, 그 솔루션의 실제 (비즈니스) 기능을 강조했다. “물론, 여러분께서 지금 보고 계신 것은 SOA 기반입니다.”라고 발표자는 늘 말하고 있었다. 하지만 나는 그렇게 생각하지 않는다. 비동기식 인터랙션을 위해 여러 프로토콜들에 WS-Addressing 헤더를 유지하는 방법에 너무 치중했다. ..

하지만, 웹 서비스와 SOA를 설계, 디자인, 구현할 때는 매우 세세한 기술적인 도전 과제들에 직면하게 된다. 우리는 새로운 표준, 새로운 프로그래밍 모델, 새로운 제품을 사용하고 있다. 이종의 플랫폼들간 상호 운용성, IT 서비스의 재사용, LOB 수요에 따른 시스템의 기능 요구 사항의 빈번한 변화를 지원하는 솔루션을 만든다면 예견하지 못한 문제들을 겪게 된다.

그래서, 어쩌면 다음에 여러분의 상사가 찾아와서, “모든 사람들이 쉽게 사용할 수 있는 SOA 솔루션을 만들기 바라네.” 라고 말할 수도 있겠다. 이때 여러분은 내 동료 Greg Flurry처럼 다음과 같이 응수하면 된다. “The devil is in the details(악마는 아주 사소한 곳에 있는 법입니다.)!”

기사의 원문보기

Comment lines: Andre Tost: My top 10 Web services issues

참고자료

WSDL 고르기 (한글)

Web services tip: Use polymorphism as an alternative to xsd:choice

Web Services Custom Data Binding, Part 1: How to choose a custom mapping technology for Web services

The hidden impact of WS-Addressing on SOAP

웹 서비스 구현을 위한 SOA 프로그래밍 모델, Part 4: IBM Enterprise Service Bus 소개 (한글)

필자소개





Andre Tost works as a Senior Technical Staff Member in the Software Group's Enterprise Integration Solutions organization, where he helps IBM's customers establishing Service-Oriented Architectures. His special focus is on Web services technology. Before his current assignment, he spent ten years in various partner enablement, development and architecture roles in IBM software development, most recently for the WebSphere Business Development group. You can contact Andre at atost@us.ibm.com.