지난 호에서는 MS에서 제시하고 있는 차세대 웹 서비스라고 하는 닷넷의 개요와 일반적인 전자상거래 업체가 고민할 수 있는 요구사항들에 대해서 알아보았다. 그 중에서 실제 다른 전자상거래 업체나 또는 배송업체, 결제 업체 등의 협력업체 시스템과 연계되어야 할 때 그리고 위와 같은 시스템들이 모두 상이한 하드웨어와 운영체제 그리고 상이한 데이터베이스와 프로그램 언어로 이루어졌다고 가정하였을 때 이를 위한 해결책으로 내세울 수 있는 것이 바로 웹 서비스, 그 중에서도 닷넷이 생산성 측면에서 좋은 대안이 될 수 있다고 언급했었다.

또한 모든 웹 애플리케이션에서 공통적으로 가질 수밖에 없었던 스파게티식 코드(프로그래머가 작성하는 서버 사이드 코드와 디자이너가 작성하는 HTML이 뒤섞여 있는 코드)를 지양하는 방법으로 ASP 닷넷의 코드 비하인드(Code Behind)가 적절한 해결책이 될 수 있다고도 언급했다.

위와 같은 방법은 디자이너가 볼 수 있는 유저 인터페이스 부분과 프로그래머가 보는 로직 부분을 분리시켜서 시스템이 디플로이된 이후에 유지보수하기에 쉬울 수 있도록 하는 방법론이라 할 수 있다.

또한 기존에는 애플리케이션의 성능을 높이기 위해서는 고비용의 캐싱 서버를 따로 두거나 아예 요청이 많은 페이지는 HTML로 따로 파일시스템에 저장하는 방법을 사용하였으나, 닷넷에서는 이를 데이터 캐시나 아웃풋 캐시 등을 사용하여 탁월한 성능을 낼 수 있도록 도와준다. 그럼 위에 열거한 방법들을 하나씩 구체적으로 살펴보도록 하자.

XML 웹서비스

지난 호에서 한 전자 상거래 업체가 가질 수 있는 고민거리를 이야기 한 적이 있다.

즉 1개의 전자 상거래 업체는 내부적으로 보면 레거시 시스템과 고객정보 그리고 타 부서와의 회계 시스템뿐만 아니라 외부적으로는 협력업체(배송업체 또는 지불업체 그리고 타 전자상거래 업체 등)와도 연동이 필요하다. 이 시스템들은 동일한 플랫폼을 사용하는 것이 아니라 이기종 하드웨어와 운영체제 그리고 다른 데이터베이스와 프로그램을 사용하고 있다.

물론 이때 기존의 방법론처럼 가상의 뷰(view) 테이블을 만들고 서로 공유해서 쓰는 방법이나 한쪽에서 서비스하고 있는 HTML 페이지를 가져와서 사용하는 방법(스크래핑 기법) 등이 있을 수 있겠지만, 이때 가져온 데이터의 유효성(Validation)을 어떻게 신뢰할 수 있는가 하는 문제에 봉착하게 된다. 따라서 위와 같은 문제를 오늘날 각 IT 메이저 벤더들은 이런 요구를 해결하기 위하여 웹서비스라는 것을 내세우고 있다. 이는 정보를 제공하는 쪽에서는 공유되는 자료를 XML로 퍼블리싱하고 정보를 받는 쪽에서는 다양한 XSL이나 윈도 애플리케이션이라면 그리드와 같은 컨트롤로 다양하게 표현할 수 있을 것이다.

이때 A라는 사이트에서 가지고 오려는 다른 쇼핑몰의 데이터가 웹 서비스로 제공되고 있다고 가정해보자. 아래의 표와 같이 XML로 카탈로그 정보를 가지고 있고 물론 XML로 구성이 안되어 있다고 해도 최근의 데이터베이스들은 다 XML 지원기능을 포함하기 때문에 (예를 들어 MS-SQL 서버의 경우는 웹 서비스인 IIS에서 실행할 수 있는 ISPAI 애플리케이션을 통해 데이터베이스 개체를 직접 XML 형태로 호출할 수 있는 기능을 제공한다.) 이 데이터를 여러 가지 스킨(웹이라면 HTML일 수 있고 일반 WinApp라면 그리드 형식)이 될 수도 있을 것이다.

<상품정보를 XML 웹서비스로 서비스하는 예제> <상품이름>카세트오디오 <모델번호>BJ-6000 <업체번호>1 <기본 카테고리>Electronics <거래방법>장바구니주문 <배송방법>자체배송 <상품구분>일반 <상품상태>판매예정 <전시우선순위>20

위와 같이 웹서비스를 한다면 클라이언트 쪽에는 다양한 XSL을 통해서 동그라미로 표현할 수도 있고 혹은 세모로 표현할 수 있을 것이다.

아래는 웹서비스하고 있는 동일한 상품정보를 가지고, 하나는 웹 브라우저로 다른 하나는 윈도 애플리케이션으로 서비스되는 것을 보여준다.