‘애플리케이션 서버 익스텐션형·플랫폼형’ 두 가지 … ‘노벨 익스텐드’ 최고
한쪽 부류는 아파치(Apache), BEA시스템즈(BEA Systems), 아이비엠, 노벨 및 썬에서 내놓고 있는 기존 애플리케이션 서버에 대한 확장판, 즉 익스텐션(extension)들이다. 그리고 다른 한 쪽은 케이프클리어소프트웨어(Cape Clear Software), 아이오나테크놀로지즈(Iona Technologies) 및 시스티네트(Systinet Corp.) 등의 제품들로, 독립적으로 존재하거나 기존의 J2EE 순응 애플리케이션 서버에 놓일 수 있게 만들어진 플랫폼들이다. 그리고 그 중간에는 윈도 서버 2003에 구축되는 자체 웹 서버를 갖춘 마이크로소프트가 있다.
웹서비스 플랫폼은 웹서비스 능력을 제공하는 데만 초점을 두는 경향이 있어 결과적으로 보다 강력하고 복잡한 이행이 된다. 이들은 모두 기존의 J2EE 애플리케이션 안으로 배치되기 때문에, 웹서비스의 애플리케이션 서버 이행에 따르는 모든 이점들, 즉 클러스터링, 부하조절, 데이터베이스 접속 풀링 등을 얻을 수 있다. 이 방안의 단점으로는 관리와 지원을 들 수 있다. 복잡한 환경에서는 단일 업체 구성이 보다 바람직하지만, 플랫폼에 의해 제공되는 유연성은 그냥 지나치기에는 너무 아쉽다. 마이크로소프트의 솔루션은 유연성은 별로 없지만 편리한 이용법과 친숙성을 따라잡기 힘든 강점으로 갖고 있다.
참가 제품들
본지에서는 BEA, 케이프클리어, 아이비엠, 아이오나, 마이크로소프트, 마인드일렉트릭(MindElectric), 노벨, 오라클, 시스티네트 및 썬을 위스콘신주 그린베이에 위치한 리얼월드 랩으로 초청해 이들의 비밀 소스가 우리의 엄중한 테스트를 견딜 수 있는지 확인해 보았다. 아이비엠은 곧 더 나은 릴리즈가 나온다며 넘어갔고, 마이크로소프트는 향후 윈도 서버 2003으로 하겠다며 마지못해 거절을 했다. 마인드일렉트릭은 자원 문제를 이유로 정중히 거절했으며, 오라클은 우리 마감일에 맞추기 위해 애를 썼지만 역시 자원 문제로 참가하지 못했다.
따라서 우리는 BEA, 케이프클리어, 아이오나, 노벨, 시스티네트 및 썬 제품을 스웨덴 요리사처럼 정열적으로 던져 넣고 휘젓고 섞고 두드렸다. 모든 제품들은 상호운용성에 있어 갈채를 받을만했는데, 테스트 동안 우리 클라이언트와의 상호운용성에서 생긴 오류는 각각의 클라이언트를 구축하는 데 사용된 운영시스템/개발 언어 플랫폼과 관계없이 대수롭지 않았으며, 제품에서 만들어진 WSDL(Web Services Definition Language)에 최소한의 변경만 가하면 모든 상호운용성을 얻을 수 있었다.
테스트 방법
우리는 HP 프롤라이언트 DL 750을 셋업하고 여기에 8개의 제온 프로세서와 2GB램을 장착했다. 그런 다음 마이크로소프트 윈도 200 어드밴스드 서버로 8개의 SCSI-18GB 드라이브를 상상하고, 기가비트 이더넷 NIC를 연결한 다음 테스트 준비를 마쳤다.
각각의 제품은 준비된 드라이브들 중 하나에 설치한 다음, 이들의 관리 능력, 모니터링 및 구성 옵션을 평가했다. 그런 다음 같은 기능성을 갖고 하나는 DOC/리터럴(DOC/Literal)을, 다른 하나는 RPC/인코디드를 이용해 두 가지 웹서비스를 만들어서 업체측의 개발 환경을 사용해 플랫폼에 이들을 배치시켰다. 각 플랫폼에는 각각 WS-I의 상호운용성 테스트에 있는 간단한 케이스를 기반으로 두 개의 웹서비스를 구축했으며, 두 가지 서비스 모두 에코인트(echoInt)라는 이름을 붙였다. 두 서비스는 하나의 정수 인수를 취했으며, 이 인수에 하나를 더해서 돌려보냈다. 두 서비스간의 유일한 차이점은 인코딩 모델이었다.
또한, 본지의 고객 데이터베이스로 연결된 서비스를 이행했는데, 이 ‘겟네임(getName)’ 서비스는 고객의 사용자 이름을 취해서 그 고객의 성과 이름을 돌려보냈다. 각 제품은 같은 버전의 썬마이크로시스템즈 자바 버추얼 머신, 즉 버전 1.3.1에서 테스트되었다.
성능 테스팅은 모두 레드햇 리눅스 8.0을 구동하고 아파치벤치(ApacheBench)를 통해 SOAP 요청을 테스트 중인 제품으로 전송해주는 다섯 개의 델 옵티플렉스(Dell Optiplex) 기계를 이용해 수행되었다. 각 테스트는 1분 동안, 혹은 각 기계당 동시에 10개 수준으로 5만 개의 요청을 돌리도록 구성했으며(어떤 스레숄드에든지 도달하면 테스트는 끝난다), 각 웹서비스에 대해 세 번 실행되었다. 그리고 추가로 같은 시간 및 요청 제한으로 한 클라이언트 기계에서 10개, 20개, 30개씩 동시에 테스트를 했다.
각각의 클라이언트 기계는 공중 NPT(Network Time Protocol) 서버와 시간이동기화가 되었으며, 스크립트는 다섯 개의 부하 생성 클라이언트를 조화시켜 테스트를 시동시키도록 짜여졌다.
상호운용성은 각 제품에 의해 지원되는 WSDL(Web Services Definition Language)에서 마인드일렉트릭 GLUE(Mind Electric GLUE, 자바)와 마이크로소프트 닷넷 클라이언트를 만든 다음 서비스에 대해 각각의 클라이언트를 구동시키는 방법으로 테스트했다. 아파치벤치는 성능 테스트에서도 사용되었지만, 각 제품의 상호운용성을 나타내주기도 했는데, 그 이유는 이 서비스가 테스트 수행을 위해 툴과의 상호작동을 필요로 했기 때문이다. 특히 닷넷 클라이언트에서 웹서비스 액세스를 시도했을 때 몇 가지 문제가 드러났다. WSDL을 약간 바꿈으로써 이런 문제를 해결할 수 있긴 했지만, 이로써 상호운용성에 대한 염려가 전혀 근거가 없는 것은 아니라는 사실이 입증되었다.
| [REPORT CARD] 웹서비스 제품별 최종 평가 | |||||||
테스트 | 노벨 | BEA 시스템즈 | 케이프 클리어 | 시스티 네트 | 썬 | 아이오나 | |
| 사양 관리 | 40% 10% | 5 | 5 | 3 | 4 | 3 | 4 |
| 모니터링 | 10% | 4 | 4 | 2 | 4 | 2 | 3 |
| 가용성 | 5% | 5 | 5 | 3 | 0 | 0 | 0 |
| 배치 | 5% | 4 | 5 | 5 | 4 | 3 | 4 |
| 개발 | 5% | 4 | 4 | 5 | 2 | 3 | 2 |
| 메시징/ DB지원 | 5% | 4 | 4 | 3 | 2 | 4 | 2 |
| 상호운용성 클라이언트 | 25% 15% | 4 | 5 | 5 | 5 | 4 | 5 |
| 표준 | 10% | 4 | 4 | 5 | 4 | 4 | 4 |
| 보안 인증/권한부여 | 15% 5% | 4 | 4 | 4 | 4 | 4 | 2 |
| SSL | 5% | 5 | 5 | 5 | 5 | 5 | 5 |
| XML | 5% | 1 | 0 | 2 | 2 | 0 | 0 |
| 성능 DOC/LIT | 10% 5% | 3 | 2 | 3 | 4 | 5 | 2 |
| RPC/END | 5% | 4 | 2 | 3 | 3 | 5 | 2 |
| 가격 배치 가격 | 10% 5% | 2 | 2 | 4 | 3 | 4 | 3 |
| 개발 가격 | 5% | 4 | 4 | 4 | 5 | 4 | 4 |
총 평균 | 3.90 | 3.75 | 3.70 | 3.65 | 3.40 | 3.05 | |
평가 | B | B | B | B- | C+ | C+ | |
업체명 / 제품명 | 노벨 / 익스텐드 애플리케이션 서버 4.0 BEA 시스템즈 / 웹로직 7.0 케이프클리어 / 케이프커넥트 4 서버 시스티네트 / 자바 4.5용 WASP 서버; C++ 4.5용 WASP 썬마이크로시스템즈 / 썬 원 애플리케이션 서버 7 아이오나 / 오빅스 E2A 웹서비스 인티그레이션 플랫폼 | ||||||
| A≥4.3, B≥3.5, C≥2.5, D≥1.5, F＜1.5 A~C등급은 범위 내에 +,- 포함 총 평균과 비중 점수는 0~5 범위 기준 | |||||||
멋진 SOAP
웹서비스에서 가장 멋진 것 중 하나는 SOAP(Simple Object Access Protocol) 배후의 불가지론적 속성이다. SOAP에서 WSDL, UDDI(Universal Description, Discovery and Integration), 그리고 WS-시큐리티에 이르기까지 기존의 모든 웹서비스 표준들은 XML을 기반으로 하고 있기 때문에, 제품이 의존하는 기반 운영시스템이 무엇이든 실질적으로 문제가 되지 않는다. 이는 즉 웹서비스가 J2EE 접시에 나오건 마이크로소프트 닷넷 접시에 나오건 관계없이 그 비밀 소스의 절반은 제품에 의해 사용되는 XML 파서(parser)라는 얘기다. 그리고 나머지 절반은 제품이 인수(argument)의 마셜링과 언마셜링(marshaling/unmarshaling)을 처리하는 방식이다.
마셜링은 제출된 XML 문서에서 구매 주문이나 고객 ID와 같은 인수를 확보해서 이것을 개발자가 사용할 언어 전용의 포맷으로 두는 과정을 말하며, 언마셜링은 그 역의 과정, 즉 그 언어 전용의 포맷을 다시 XML로 바꿔놓는 것이다. 이 재료들 중에 어떤 것이든 표준 미달이라면, 그것은 곧 성능이 떨어지고 개발자가 자신들의 웹서비스를 만드는 데 더 힘든 시간을 보내게 된다는 것을 의미한다.
이런 창안이 어떤 것이든 그 성공은 또한 개발 환경과 웹서비스 구축을 위한 지원에 따라 달라진다. 현재 수많은 새로운 표준들이 활약 중이며, 테스트한 모든 제품은 이런 표준을 학습할 필요를 최소화하고자 애쓰고 있기 때문에, 웹서비스의 세계에 진출하기는 어렵지 않을 것이다. 개발 환경이 타깃 배치 플랫폼에 유연하게 통합될 수 있는 정도가 중요한데, 그 이유는 이것이 곧 웹서비스를 신속하게 개발할 수 있는(최소한의 교육으로) 제품의 능력이기 때문이다. 제품이 프레임워크를 만들어낼 수 있고, 개발자가 비즈니스 로직 코드를 만들고 배치 버튼을 누르기만 하면 된다면, 이 제품은 개발자를 웹서비스의 세계로 가게 할 미끼를 갖고 있는 셈이다.
보안의 경우는 테스트한 거의 모든 제품에서 전반적으로 XML-SIG와 XML-인크립션 지원이 없어 실망스러웠다. 우리는 대다수 업체들이 WS-시큐리티 지원을 포함시키기 싫어한다는 점은 이해할 수 있지만(아직 개발 중이기 때문에), XML-SIG는 아직 완성되진 않았지만 1999년 이래로 사용 가능했으며, XMP-인크립션은 2001년에 등장했다. BEA와 썬은 자사 제품의 다음 릴리즈에서 두 표준을 모두 지원할 것이라고 말했으며, 다른 업체들은 WS-시큐리티가 완성될 때까지 제품 지원을 기다리는 입장이다.
이런 모든 점을 감안해서, 우리는 뛰어난 외관과 따라하기 쉬운 웹서비스 배치 및 관리, 그리고 폭넓은 기능들을 갖춘 노벨의 익스텐드 4.0에 에디터즈 초이스를 주었다. BEA의 웹로직 7.0은 익스텐드와 거의 어깨를 나란히 했으며, 케이프클리어의 케이프커넥트가 그 뒤를 바짝 따랐다.
