어떤 분이 질문을 하셔서 테스트를 하다가 알아낸 내용입니다. 닷넷 프레임워크 2.0에서는 DataTable 객체를 Serialize 할 수 있게 되어서 DataTable을 웹 서비스에서 직접적으로 사용할 수 있게 되었다고 되어 있습니다(닷넷 프레임워크 2.0에서 ADO.NET의 새로운 기능 참조). 하지만 이 말은 100% 맞다고 할 수 없습니다. Visual Studio 2005의 버그로 인해 데이터 테이블을 직접 사용하는 웹 서비스를 사용하는데 문제가 발생합니다. 이 글은 이러한 문제를 살펴보고 이를 Work Around (피해가는) 방법을 알아보도록 하겠습니다.

질문을 받은 지 2주 정도 되었지만 이제서야 글을 쓰네요... 요즘은 귀차니즘 때문이 아닙니다. 정말로 요즘은 마니 바뿌답니다... 믿거나 말거나 지만... -_-;

Bug: Using DataTable in XML Web Service

닷넷 프레임워크 2.0의 새로운 기능들을 자랑(?)하는 What's New 자료 중에서 ADO.NET 2.0의 새로운 기능을 기술하는 문서를 살펴보면 여러 가지 새로운 기능 중에 DataTable의 기능이 여러 모로 향상되었음을 알 수 있다. 시간 관계상 이들을 다 언급할 수는 없고... 그 중 DataTable이 DataSet에 대해 독립적으로 Serialize(직렬화)할 수 있다고 되어 있다. 그래서 웹 서비스 같은 곳에서 DataSet 뿐만 아니라 DataTable을 독립적으로 사용할 수 있다고 되어 있다.

Introduction

이 말은 사실이다. 간단한 리스트1의 코드를 살펴보면 복잡할 거라곤 하나도 없는 아주 간단한 웹 서비스 구현이다. 이 웹 서비스의 달랑 하나 존재하는 TestMethod가 DataTable을 반환하고 있음을 노려봐야 한다.

리스트1. DataTable을 반환하는 간단한 웹 서비스

리스트1의 코드를 ASP.NET 1.x에서 수행하면 얄짤없이 화면1과 같이 NotSupportedException이 발생한다. 이는 닷넷 프레임워크 1.x 에서 DataTable이 XML로 Serialize 되지 않았음을 알 수 있다.

하지만 이 코드를 ASP.NET 2.0에서 돌려보면 언제 그랬냐는 듯이 아주 잘 작동하며 결과 역시 테이블의 내용을 아조 잘 보여준다. 이로써 닷넷 프레임워크 2.0에서 ADO.NET의 새로운 기능이란 문서에서 주장하듯 DataTable이 Serialize 된다는 것이 구라가 아님을 확인할 수 있다.

화면1. 닷넷 프레임워크 1.x에서 DataTable을 사용하면 나타나는 졸라 무정한 예외 메시지

Problem When Writing Client

여기까지만 테스트 했다면 누구도 태클을 걸지 않을 것이다. 필자도 여기까지만 테스트하고 말았어야 했다. 클라이언트를 구현해 본답시고 웹 서비스 클라이언트를 만든 것이 화근 이였다. 보통 때 처럼 Console 어플리케이션을 생성하고 아무 생각 없이 웹 참조를 수행했다. 그리고 웹 서비스를 호출하는 코드를 작성했는데... 아무리 봐도 VS 2005 가 생성해 준 웹 서비스 프록시 클래스의 TestMethod() 메쏘드의 리턴 타입이 이상한 것 아닌가?

리스트2. VS 2005 혹은 wsdl.exe 가 생성해 준 웹 서비스 프록시의 TestMethod() 메쏘드

리스트2는 VS 2005가 생성해 준 웹 서비스 프록시 클래스인 TestService 클래스의 TestMethod() 메쏘드이다. 이 메쏘드의 리턴 타입은 놀랍게도 DataTable이 아닌 열라 이상하게 생긴 TestMethodResponseTestMethodResult 클래스이다.

이 메쏘드를 호출하는 코드를 작성하고 수행해 보면 결과값은 DataTable이 아닌 엉뚱한 XML 노드 몇개를 받게 된다. 또한 TestMethodResponseTestMethodResult 이란 클래스를 DataTable로 캐스팅(casting; 형변환)할 수 있는 것도 아니다. 그렇다면 당췌 클라이언트는 웹 서비스가 리턴해 준 DataTable 객체를 어케 받아낼 수 있단 말인가?

분기 탱천한 필자... 미친척하고 TestMethod() 의 TestMethodResponseTestMethodResult 타입 대신 DataTable로 바꾸어 보았다. 리스트3과 같이 말이다.

리스트3. 리턴 타입을 수정한 메쏘드

우씨 그랬더니 떡하니 DataTable이 리턴 되는 것이 아닌가? 이는 명백히 웹 서비스 프록시를 생성해 주는 VS 2005 혹은 wsdl.exe가 DataTable 타입에 대해 제대로 된 프록시 코드를 생성해 주지 못하는 버그로 보인다.

Work Around

앞서 언급한 버그를 피해가는 가장 좋은 방법은 DataTable을 사용하지 않고 예전처럼 DataSet을 사용하는 것이다. 나중에 설명하겠지만 DataTable을 사용한다고 해서 성능이 좋아질 것이라는 막연한 기대는 하지 말자. 하나의 테이블에 대해서 DataSet을 사용하건 DataTable을 사용하건 그 성능 차이는 거의 없다.

패 죽여도 DataTable을 꼭 써야겠다면(고집 무쟈게 세네... -_-;), VS 2005 혹은 wsdl.exe가 생성해 준 프록시 코드를 졸라 찾아 다니면서 리턴 타입 혹은 매개변수 타입을 DataTable로 수정해 주면 된다. 정말 이렇게 해야만 할까? 열심히 생성된 프록시 코드를 수정했다가, 웹 서비스 참조를 갱신(update)라도 하면 수정해 놓은 코드는 한 순간에 날라가 버리기 때문에 이 방법은 피하고 싶을 것이다.

C# 2.0에 추가된 partial 클래스 기법을 사용하거나, 상속을 받아서 overload 하는 방법은 없을까? 필자가 이렇게 저렇게 다 해본 결과 모두 다 실패였다. 필자가 아는 한 생성된 코드를(VS 2005의 경우 Reference.cs 파일) 수정하는 방법 밖에 없다.

마지막으로 MS가 이에 대한 수정할 때까지 기다리는 것이다. 언제 서비스 팩이 나올지 모르겠지만 그때는 이 문제가 해결되지 않을까? 아님 말고... (필자는 걍 DataSet 을 계속 사용할 것이다).

DataTable vs. DataSet in XML Web Service

앞서 잠깐 언급했지만 필자가 웹 서비스에서 DataTable을 사용하는 것을 미련 없이 포기할 수 있었던 것은 다 이유가 있어서 이다. 필자가 그냥 숏 꼴리는 대로 결정한 것은 아니고... 웹 서비스 상에서 DataTable을 사용할 때와 DataSet을 사용할 때의 성능 테스트를 수행한 결과 둘의 차이가 없었기 때문이다. 이제 필자가 수행한 성능 테스트의 결과를 독자들에게 공개하고자 한다. 애초에는 그래프까지 보여주면서 성능 비교를 하려고 했으나 귀차니즘이 몰려오고(쓰바 지금 새벽 6시다. 출근해야 하는데... 필자는 이젠 완전히 조뙤따...) 별 의미도 없기 때문에 간단히 말로 때우기로 한다.

테스트에 사용한 서버는 필자의 데스크톱 PC 로서Pentium 2.8GHz Dual Core (D820), 2GB 메모리, Windows 2003 SP1, IIS 6.0 이였다. 그리고 스트레스를 생성할 클라이언트는 필자의 노트북으로서 Pentimum 1.8GHz Mobile, 1.5 GB 메모리, Windows 2003 SP1 이다. 두 컴퓨터는 100Mbps 네트워크로 연결되어 있으며, 테스트에 사용한 테스트 툴은 VS 2005 Team Suite에 포함된 테스트 툴 이였다.

그리고 DataTable을 반환하는 웹 서비스를 호출하기 위해 VS 2005가 생성해준 프록시 코드에서 리턴 타입을 DataTable로 바꾸어서 웹 프록시를 반복적으로 호출하는 형태를 취하였음을 밝혀 둔다.

Returning Single Table

첫 번째 테스트는 Northwind 데이터베이스의 Products 테이블 하나를 DataSet에 넣어 반환할 때와 DataTable로 반환할 때 성능 비교를 수행해 보았다.

결론부터 말하자면 둘의 성능 차이는 1% 내외로 비슷했다. 단순히 DataTable이 빠를 것이라고 생각했다면 큰 오산이다. 그리고 여기서 또 한가지 뽀인뜨는 DataSet을 반환했을 때 XML과 DataTable의 반환했을 때의 XML이 거의 차이가 나지 않는다는 점이다. 직접 독자들이 살펴봐도 알겠지만 처음 한 두 줄을 제외하곤 판박이처럼 같다. 직접 복잡하게 스트레스 테스트를 해보지 않아도 이 두 XML을 비교해 봐도 성능이 비슷할 것이라는 예상을 할 수 있었고 실제 스트레스 테스트 결과도 그러하게 나왔다.

Returning Multiple Table

두 번째 테스트는 2개의 테이블(Products 테이블과 Customers 테이블)을 DataSet에 넣어 반환하는 경우와 DataTable의 배열로 반환하는 경우에 대한 테스트이다. 2개 이상의 테이블을 반환할 때 DataSet이 나은가 아니면 DataTable의 배열이 나은가에 대한 호기심에 함 테스트해본 것이다.

어느 것이 더 빨랐을까? 놀랄 것도 없이 둘의 차이는 1% 내외의 차이를 보였을 뿐 성능은 거의 비슷하게 나왔다.

Test Summary

테스트가 엄정한 환경에서 빡세게 진행된 것은 아니지만, 웹 서비스 상에서 DataTable을 반환하는 것과 DataSet을 반환하는 것의 성능차이는 거의 없었다. 이로써 버그까지 가지고 있는 DataTable을 굳이 웹 서비스에 사용할 필요가 없다는 것이 필자의 주장이 되겠다.

Summary

닷넷 프레임워크 2.0에서 DataTable이 DataSet과는 독립적으로 Serialize가 가능해 짐으로써 웹 서비스 상에서 DataSet 이 아닌 DataTable을 웹 서비스의 매개변수 혹은 리턴 타입으로 사용할 수 있게 되었다. 웹 서비스는 훌륭하게 DataTable을 Serialize 해 주지만 VS 2005와 wsdl.exe가 생성해 주는 웹 서비스 프록시는 DataTable을 제대로 인식하지 못해서 잘못된 결과를 반환하는 코드를 생성해 준다. 이는 VS 2005와 wsdl.exe의 버그로 추측되며 이러한 상황을 유도한 MS는 쑛잡고 반성해야 할 것이다.

이러한 버그를 피해 가기 위해서는 생성된 웹 서비스 프록시 코드를 수정하여 DataTable이 제대로 반환되도록 하면 된다. 하지만 이러한 방법은 웹 서비스가 수정되어 프록시 코드를 다시 생성해야 할 때에 변경한 부분이 유지되지 않고 사라져 버린다는 단점이 있다.

필자의 개인적인 성능 테스트 결과 웹 서비스가 DataSet을 반환하거나 DataTable을 반환할 때 둘의 성능적인 차이는 거의 없었으며, DataSet과 DataTable이 생성해 내는 XML 역시 매우 흡사하였다. 따라서 현재까지의 상황에서 버그까지 가지고 있는 DataTable 보다는 DataSet을 웹 서비스에 사용하는 것이 유리하다는 것이다. 물론 추후에 MS가 DataTable의 Serialization 성능을 향상시키고 VS 2005 및 wsdl.exe의 버그(?)를 수정한다면 이야기는 달라질 수 있다.