관련 통계자료 다운로드 ebXML 과 웹서비스 비교 기업간(B2B) 전자상거래에 대해 조금이라도 관심이 있는 사람 혹은 이를 도입하거나 시스템을 구축하는 기업이라면 흔히 갖게 되는 의문 중에 하나가 ebXML과 웹서비스 중 과연 어느 쪽을 선택할 것인가 하는 것이다.
ebXML은 지난 2001년 5월 버전 1.0이 발표된 이후 UN/CEFACT와 OASIS라는 국제표준화기구가 중심이 돼 지금까지 표준규약 개정 작업을 계속 진행해 오고 있으며 사실상 B2B 부문 국제표준으로 인식되고 있다.
반면 웹서비스는 지난 2000년 4월 상호 정보교환을 위한 SOAP 프로토콜 1.1이 발표된 이후 IBM, MS, 아리바(Ariba) 등 소프트웨어 벤더들이 주도가 돼 표준 개정 작업을 진행하고 있으며 인터넷 표준을 주도하는 W3C에서는 확장성표기언어(XML) 및 인터넷 부문의 정보교환 표준으로 사실상 승인하고 있는 상태다.
이처럼 XML을 기반으로 한 두 표준방식이 서로 평행선을 그으면서 두 가지 방식을 전자상거래와 관련된 핵심적인 측면에서 함께 생각해 보는 것은 향후 기업간 전자상거래를 도입하려는 업체나 관련 기술을 개발하려는 기업에 어느 정도 가이드라인을 제시해 줄 수 있을 것이다.
먼저 두 가지 표준의 탄생 배경을 살펴보면 ebXML의 경우 두 개의 국제표준화기구를 중심으로 글로벌하고 단일한 e마켓 플레이스를 만들자는 취지에서 시작됐다.
이전에도 XML을 기반으로 수많은 B2B부문의 지역적인 표준들이 존재하고 있었지만(예를 들어 xCBL, RosettaNet, eCo, cXML 등과 같은) 나름대로 규약을 정해 사용하다 보니 로컬 표준간의 정보교환은 상상도 못 할 일이었다. ebXML은 로컬 표준의 한계를 극복하고 전자거래를 위한 제반 기능, 업무 규약, 통신, 콘텐츠, 비즈니스 양태 등 B2B 모든 영역의 표준을 제시하고자 제정됐다.
또 이전에 존재하던 XML 기반의 전자거래 규약의 장점들을 최대한 수용하고 단점들을 극복해 나가는 방향으로 만들어졌기 때문에 효과적이고 실질적인 전자거래용 규약이라 할 수 있다.
웹서비스의 경우, 인터넷 공간의 정보자원을 보다 효과적으로 활용할 수 있는 방안에 대한 연구의 산물이라 볼 수 있다. 즉 지금까지 웹기술은 e비즈니스 분야에서 클라이언트 인터페이스의 표준으로 자리를 잡았지만 주로 클라이언트와 서버간의 자료 전달에 치중하고 인터넷의 정보들은 밀접하게 결합된 형태가 아닌 독립된 정보를 가진 섬들에 지나지 않았다.
따라서 이런 인터넷의 정보들을 어떻게 효과적으로 묶고 애플리케이션이나 업체간의 협업(Collaboration)이 가능하게 할 것인가에 대한 연구의 산물이 웹서비스라고 볼 수 있다.
이런 측면에서 웹서비스는 인터넷의 정보 통합이라는 기술 수요에 의해 탄생됐고 ebXML은 글로벌 전자시장을 형성하기 위해 XML기술의 표준을 제정한 것이 배경이라 할 수 있다. 이러한 배경의 차이는 두 표준의 내용에 있어서도 큰 차이점을 갖고 있다.
첫째, 두 표준이 지향하는 업무 프로세스의 정의 방법이다. ebXML의 업무 프로세스는 BPSS(Business Process Specification Schema)라는 규약에 의해 정의되는데 기업간 전자거래를 위한 제반 업무 프로세스의 정의에 초점을 맞추고 있다. 즉 기업 내부의 업무 흐름에 대해서는 철저하게 각 기업에 맡기고 트랜잭션, 협업, 적용 문서, 비즈니스 액션, 시큐리티 등의 기업간 업무 흐름에 집중하고 있다.
반면 BPEL이나 WSCI에 의해 정의되는 웹서비스의 프로세스 처리는 정보의 흐름제어나 서비스 제공자간의 상호작용 인터페이스에 더 큰 비중을 둔다.
웹서비스가 WSDL(Web Service Description Language)을 사용해 단순하면서도 유연한 거래 파트너간 상호작용 기능을 제공하면서 광범위하고 일반적인 업무 도메인에 보편적으로 적용함을 목표로 하고 있다면 ebXML의 경우는 비즈니스 트랜잭션을 수행하는 데 필요한 구체적인 규약을 보장하고 각종 규약의 상세 정의를 목표로 하고 있다.
따라서 트랜잭션 처리나 안전한 거래를 위한 보안 기능, 시간 제어 기능, 위험 내구성(Fault-Tolerancy) 등이 파트너간 정보교환에 중요한 요소가 될 경우에는 ebXML이 유리하다고 판단이 되며 거래 파트너나 업무처리 다양성, 상황에 따른 유연하고 신속한 업무 변경 등이 중요한 결정 요소가 되는 경우에는 웹서비스의 도입이 보다 유리하다 하겠다.
둘째, 업무 데이터의 구성방법에 있어 ebXML은 데이터 항목의 표준화에 많은 노력을 기울이고 있음을 알 수 있다. 이는 ebXML이 추구하는 글로벌한 단일 전자시장의 형성이라는 취지에서 당연하다고 볼 수 있으며 CCTS(Core Component Technical Specification)를 통해 거래 항목과 관련한 시맨틱스, 연관관계, 항목정의를 위한 템플리트, 저장 및 조회방법까지 정의함으로써 거래 당사자들간의 정보 교환에 필요한 각종 항목들을 일목요연하게 파악할 수 있도록 하고 있다.
따라서 ebXML의 경우 산업이나 특정 업무 혹은 법적인 제한과 관계없이 독립적인 형태의 데이터(코어 컴포넌트라고 함) 정의가 가능하며 특정 산업 영역에 이 데이터를 적용해 산업 특성이 반영된 데이터(BIE:Business Information Entity)를 제작할 수 있다.
이 방법에 따르면 데이터 항목의 제작과정에 있어 근원·파생관계가 명확하게 정의됨으로써 산업 공통의 표준 코어 컴포넌트에 대한 추적 검색이 용이해지고 이후 만들어지게 될 수 많은 산업 데이터 항목들의 관리가 보다 용이해진다는 장점이 있다.
반면에 웹서비스는 주고받는 XML 스키마의 정의 외에는 별도 데이터 항목에 대한 정의 규칙을 포함하고 있지 않다. 사용자는 WSDL을 이용해 스키마를 새롭게 정의하기만 하면 언제든지 새로운 업무 영역에서 웹서비스를 이용할 수 있지만 사용자들간의 데이터 연동성에 있어서는 세심한 주의를 기울여야 할 것이다. 새로운 스키마를 정의하는 과정에 있어서도 현재 이미 정의된 데이터 타입에 대한 세심한 파악을 필요로 한다.
최근 OAG나 UBL의 경우는 정보 항목의 표준적 정의가 XML 스키마 내에서 가능하도록 XML 스키마를 새롭게 디자인하고 있는데 이런 방법에 의하면 정의된 데이터 항목은 웹서비스나 ebXML에서 별도의 노력없이 곧바로 사용될 수 있을 것이다.
이에 따라 산업간 데이터 교류와 같이 이질적인 환경에서 새로운 비즈니스 문서를 생성해야 하는 경우, 거래 파트너간 데이터의 정합성이 중요한 관건이 되는 경우에는 현재로서는 ebXML의 CCTS 표준체계에 의한 데이터 항목 재활용 방법이 유리할 것이다.
반면 데이터의 정합성보다는 거래 파트너에 따라 유연하고 신속하게 서비스 인터페이스를 바꾸어 적용해 나가는 환경에서는 웹서비스에 의한 데이터 교환이 유리할 것으로 보인다.
셋째, 서비스 측면에서 살펴 보면 웹서비스 방식이 개별 서비스 제공자가 주로 소프트웨어 컴포넌트를 사용할 수 있는 인터페이스를 제공하는데 주력한다면 ebXML의 경우는 거래 당사자간의 계약이나 합의에 의한 양방간의 관계설정에 보다 중점을 두고 있음을 알 수 있다.
그 결과 ebXML 방식이 웹서비스에 비해 거래 파트너간의 거래 행위가 보다 단순화되며 상호 역할에 따라 메시지를 주고 받는 과정에서 메시지의 순서를 제어하기 위한 별도의 트랜잭션 처리 순서 규정을 할 필요가 없다.
반면 웹서비스 방식은 서비스를 규정함에 있어 보다 다양한 방법을 제시하고 있으며 유연할 수 있지만 항상 트랜잭션 처리에 따른 데이터 정합성을 보장하기 위한 별도의 메커니즘을 필요로 한다. 또 웹서비스의 경우 서비스 타입이 단방향인데 반해 ebXML의 경우는 양방 서비스 타입이고 다자간 서비스 타입의 정의가 가능하다는 장점이 있다. 양방 서비스 타입의 경우 서비스 제공자와 서비스 소비자로 구분할 수 있고 다자간 서비스 타입의 경우 양방간 서비스 타입의 조합에 의해 많은 역할을 정의할 수 있다.
이는 ebXML이 거래 파트너 역할의 구체적인 정의에 의해 보다 엄격한 방식으로 정보를 교환할 수 있음을 의미한다. 기능적인 측면에서는 웹서비스의 경우 서비스 타입의 기능이 상호작용의 이름과 하위 기능의 조합에 의해 제공되지만 ebXML의 경우는 양방간 서비스 타입이 이름과 사전 혹은 사후 조건, 하위 서비스로의 분리와 상호작용 등에 의해 정의된다.
웹서비스의 경우 서비스 타입은 하나의 주요 역할과 다수의 부수적인 역할을 한정짓게 되는데 단지 하나의 주요 역할의 기능적, 행태적, 정보적 속성만이 명시적으로 정의되고 부수적인 역할들의 속성은 주요 역할과의 관계에서 요구되지 않는 한 별도로 정의되지 않는다.
ebXML 방식에서는 거래 파트너의 역할이 거래 발생자와 응답자로 구분되고 이는 거래 진행에 있어 권한과 의무의 소재를 명확하게 해 준다.
다자간 서비스 타입에서는 다양한 역할을 정의하며 역할간의 관계는 양방간 서비스 관점에서 다시 정의된다. 거래 파트너간의 역할 규정과 권한 및 책임, 트랜잭션 수행에 따른 사전·사후 조건 등이 거래 성사여부의 중요한 변수로 작용할 경우 현재까지는 ebXML 방식이 보다 추천할 만하다고 보여진다.
웹서비스 방식과 ebXML 방식은 개념적으로 기능적으로 서로 직접 상호작용 할 수 있는 방법이 아직 없다.
하지만 ebXML의 트랜잭션 처리방법이나 기능적 작동상의 차이점을 무시한다면 웹서비스의 상호작용방식을 ebXML의 표현방식으로 기술할 수 있을 것이다. 반면 ebXML의 상호작용 방식이 웹서비스의 상호작용방식에 의해 기술될 수도 있다. 이 방법은 ebXML로서는 할 수 없는 매우 다양한 방법에 의거해 거래 파트너들을 연결할 수 있는 대안을 제시해 줄 것이다.
서비스 제공이라는 관점에서 살펴보면 ebXML의 제한된 표현력과 기능 때문에 ebXML을 가지고 웹서비스 시스템이 제공해 주는 서비스를 모두 표현한다는 것을 불가능할 것이다. 반면 ebXML의 서비스를 웹서비스 방식에 의거해 표현하는 것은 어느 정도까지 가능할 것이다. 물론 트랜잭션의 의미나 처리방법 그리고 양방간 혹은 다자간 관계 설정과 같은 부분은 아직 웹서비스 방법을 이용해 표현하기에는 한계가 있다.
정리하면 ebXML 접근 방식이 현실적으로 제반 B2B 환경에 적용하기에 보다 적합하다고 보여진다. 왜냐하면 보다 구체적인 표준 규약과 전형적인 B2B 애플리케이션을 지원할 수 있는 표현력 및 이로 인한 거래 방식의 명확성 등을 이유로 들 수 있다. 하지만 웹서비스 방식은 글로벌한 소프트웨어 벤더들로부터 강력한 지지를 받고 있으며 기존의 소프트웨어 컴포넌트와 밀접히 결합된 형태로 혹은 다양한 툴과 함께 제공된다면 그 파급효과는 대단할 것으로 예상된다. 어쩌면 B2B 프레임워크 자체를 변화시킬 수도 있을 것이다.
현재 이 두 가지 방식을 접목할 수 있는 가장 좋은 대안은 B2B 프로토콜을 UML과 같은 모델링 언어를 사용해 개념적으로 디자인하고 그로부터 웹서비스 방식이나 ebXML 방식에 공통으로 적용할 수 있는 아키텍쳐를 도출해 내는 것이다. 물론 이 방식은 B2B 프로토콜의 정의와 이와 매핑되는 웹서비스나 ebXML용 UML 프로파일의 정의를 전제로 한다. 하지만 그러한 UML 프로파일은 이미 OASIS나 OMG에서 작업 중에 있으므로 머지않아 적용 사례들이 나올 것으로 기대된다. < yklee@posdata.co.kr >
이영곤 포스데이타 e-Biz 연구소 e-BI 개발팀장
◇ 90년 서울대 자원공학과 졸업(학사)
◇ 92년 한국과학기술원 산업공학과 졸업(석사)
◇ 97년 한국과학기술원 정보통신학과 졸업 (박사)
◇ 97년 포스데이타 입사
◇ 2001년 ∼ 현재 포스데이타 e-Biz 연구소 e-BI 개발팀장
