응용 서비스 개발 방법과 국내외 개발현황①

출처 : http://www.ionthenet.co.kr/newspaper/view.php?idx=10016&forum=0

웹 서비스 기반의 개방형 API에 대한 관심이 BcN의 진행과 함께 높아지고 있다. 지난 호 까지 팔레이 X의 여러 개방형 서비스 API를 알아봤다. 이번 호를 마지막으로 개방형 API 구현 기술을 바탕으로 한 응용 서비스 개발에 대해 알아보고, 더불어 국내외 개발 현황도 살펴보자.


김형환_한국전자통신연구원, 개방형서비스플랫폼팀 선임연구원

최근 들어, 차세대 통신망을 구축하는 광대역통합망(BcN : Broadband convergence Network)에 개방형 API라는 표준화된 인터페이스를 사용해 구현되는 개방형 서비스가 적용되면서, 기존의 지능망 기반의 서비스 개발이 갖는 문제들을 해결할 뿐 아니라 보다 더 사용자 중심적인 서비스를 개발할 수 있는 토대가 마련됐다.
사용자의 입장에서 보면 개방형 서비스는 한 장소에서 다양한 고급 음식들을 고루 맛볼 수 있는 고급 호텔의 뷔페식당과 같다고 볼 수 있다. 개방형 API를 통해 통신망이나 통신 프로토콜 기술 등에 관한 지식이 없어도 다양하고 풍부한 내용의 새로운 서비스와 특화된 개인화 서비스들을 쉽게 생성하고 사용할 수 있다.
팔레이 그룹에서는 통신망에서의 개방형 API 개발을 목표로 CORBA 기술을 토대로 하는 팔레이/OSA API 규격과 웹 서비스 기술을 토대로 하는 팔레이 X API 규격을 표준화하고 있다.
지난 강좌까지 총 5회에 걸쳐서 팔레이 X API 규격들이 소개됐다. 이들은 HTTP를 전송 프로토콜로 사용하는 웹 서비스 기술을 사용함으로써 인터넷을 통한 접근이 용이해 광대역통합망이나 통신 프로토콜 기술 등에 관한 지식이 없어도 다양하고 풍부한 새로운 서비스 와 자신만의 특화된 개인화 서비스들을 쉽게 생성하는 데 사용될 수 있었다. 또한 기업들이 개발한 웹 서비스들과 조합해 더욱 다양한 신규서비스의 개발에 적용될 수 있다.
이번 호에서는 개방형 API 구현 기술로 사용된 웹 서비스에 대해 소개하고 응용 서비스의 개발을 예로 보여주고 이를 사용하는 방법을 알 수 있도록 설명, 마지막으로 국내외 개발현황을 간략히 소개한다.

웹 서비스 개요
웹 서비스는 SOA(Service Oriented Architecture) 개념을 구현하는 기술로서 네트워크를 통한 서비스들의 상호연동에 초점을 두고 있으며, 차세대 분산 컴퓨팅 모델로써 폭넓게 인정 받고 있다.
웹 서비스의 기원을 되짚어 보면 썬의 RPC(Remote Procedure Call)가 있다. RPC 기술은 OMG의 CORBA/IIOP(Internet Inter-ORB Protocol)나 마이크로소프트의 DCOM(Distributed Component Object Model), IBM의 DSOM(Distributed System Object Model) 등과 같은 분산 컴퓨팅 기술로 성숙됐다.
웹 서비스는 이런 분산 컴퓨팅 환경에서 얻어진 지식들 위에 새롭게 구축된 것이다. 이런 분산 컴퓨팅 기술을 구현한 제품들은 독자적인 프로토콜을 사용했기 때문에 제품간 호환성이 없었다. 이기종 분산 컴퓨팅 제품들간의 상호연동 방법을 찾기 위한 많은 노력들이 있었지만 널리 사용되지는 못했다. 이는 각 기업에서 처음부터 동일한 제품으로만 분산 컴퓨팅 환경을 구축했기 때문이다. 그러나 사업의 규모가 커지고 기업간 전자 상거래가 활발해 짐에 따라 서로 다른 시스템간의 연동은 불가피 하게 됐다. 따라서 적은 비용으로 시스템들을 통합할 수 있는 새로운 분산 컴퓨팅 기술이 요구되기 시작했으며, 이런 노력의 정상에 웹 서비스가 위치하게 됐다.
웹 서비스를 기업에 도입할 경우, 매출 증가, 처리의 효율성, 고객의 편리성 증진 등 많은 장점이 있지만 이 부분은 이번 강좌의 범위를 벗어나므로 다른 문헌을 참조하길 바란다.
웹 서비스 기술의 철학을 제공하는 SOA는 네트워크에 위치하고 있는 서비스들을 공통의 프로토콜을 이용해 연결하는 방법의 한가지로, 서비스가 어떻게 위치되고 실행되며, 어떻게 모니터링 되고 보안상 안전하게 하는가 등을 정의하고 있다. SOA는 다음과 같이 네 가지 주요 역할로 구성된다.

· 서비스 공급자 : 서비스 공급자는 서비스 규격을 구현하고 이 규격을 서비스 디렉토리를 통해 공개하며 서비스 소비자에게 활용된다. 전통적으로는 서버에 해당한다.
· 서비스 소비자 : 서비스 소비자는 서비스 디렉토리에 공개된 서비스를 찾고, 그 서비스를 사용할 수 있도록 애플리케이션에 결속시킨다. 전통적으로는 클라이언트에 해당한다.
· 서비스 디렉토리 : 서비스 디렉토리는 서비스 정보를 위한 레지스트리로 동작하는 특별한 종류의 서비스 공급자로서 서비스 공급자에 대한 인터페이스와 서비스의 위치를 검색할 수 있도록 한다.
· 서비스 브로커 : 서비스 브로커는 특별한 종류의 서비스 공급자로서 서비스 요청을 하나 이상의 추가적인 서비스 공급자에게 전달할 수 있다.

SOA를 구성하는 네 가지 주요 역할이 웹 서비스 기술에서는 서비스 공급자, 서비스 소비자, 서비스 레지스트리 역할들로 구성된다. 이 구조는 (그림 1)에 잘 나타나있다. 웹 서비스 개발자가 서비스를 개발하고 서비스에 관한 규격을 UDDI(Universal Description, Discovery and Integration)에 공개하면, 웹 서비스 소비자는 서비스 레지스트리를 통해 필요한 웹 서비스를 검색해 접속을 위한 인터페이스와 서비스의 위치(URI : Uniform Resource Identifier)를 알아내 서비스를 사용하는 프로그램에 결속시킨다. 이로써, 웹 서비스가 사용되는 것이다.

이 시점에서 웹 서비스가 무엇인가를 정의해 본다면, 웹 서비스는 SOAP(Simple Object Access Protocol)/HTTP를 사용해 웹 상에서 URL(Uniform Resource Locator)을 통해 접근 가능한 소프트웨어 애플리케이션이며, 실제 사용을 위한 웹 서비스 애플리케이션의 인터페이스와 바인딩은 WSDL(Web Services Description Language) 파일에 정의된다고 할 수 있다. SOAP, WSDL, UDDI 등에 관한 설명은 다음의 웹 서비스 표준에서 다루고 있다.
웹 서비스는 클라이언트에서 웹 브라우저라는 사용자 인터페이스를 통해 서버에 접근하던 전통적인 웹 애플리케이션처럼 대화형 형태(interactive type)가 아니라 사용자의 인터페이스 없이 애플리케이션 간(application-to-application)에 직접 연동이 이루어지는 프로그램 형태(programmatic type)다. 이처럼 웹 서비스는 HTML 페이지들로 한정되는 GUI를 통해서만 사용할 수 있었던 기존 웹 애플리케이션의 한계를 넘어섰다는 것에서도 차별화된다.
웹 서비스의 특징과 장점들은 많지만, 다음과 같이 요약할 수 있다.

·커넥션리스(Connectionless) : 연결지향형인 기존의 클라이언트 서버 모델과 달리 연결 상태를 유지하지 않는다.
·스테이트리스(Stateless) : 웹 서비스의 요청에 대해 응답한 후, 바로 연결이 종료되므로 상태를 유지하지 않는다.
·SOAP 기반의 프로토콜 : 웹 서비스의 요청과 응답에 SOAP 프로토콜을 사용한다. XML을 처리할 수 있는 시스템간의 통신에는 SOAP을 사용할 수 있기 때문에 웹 서비스 서버와 클라이언트가 별개로 개발될 수 있다.
·이기종간의 연동 : 분산된 서로 다른 서비스들이 다양한 소프트웨어 플랫폼과 구조들에서 동작할 수 있고 각 서비스들은 구현 언어(프로그래밍 언어), 운영체제에 종속되지 않는다. 이는 주고받는 데이터 값이 텍스트인 XML 형태(SOAP)로 표현되기 때문이다. 따라서 기존의 분산 컴퓨팅 환경과는 달리 이기종간 연동이 쉽다.
·웹을 통한 비즈니스 서비스 : 기업들은 웹 서비스를 이용해 WWW(World Wide Web)이 갖는 장점들을 얻을 수 있다. 기업의 비즈니스 로직(예: 상품목록과 저장물량 조회, 구매 등)을 웹 서비스로 공개하면 누구나 손쉽게 사용하고 있는 웹을 통해 소비자가 직접 기업의 비즈니스 로직들을 서비스로 사용할 수 있게 된다. 이로써 공급망 관리를 보다 효율적으로 할 수 있다. 또한 HTTP프로토콜을 사용하므로 보안이 강화된 인터넷에서 방화벽에 의해 접속이 차단되는 제약을 받지 않아 시스템간 상호연동을 위한 통신이 제약받지 않으며, 서버가 URL로 식별되기 때문에 원격 메소드에 대한 호출은 HTTP의 요청과 응답에 상응하는 문제로 단순화됐다.