IT/모바일
By 돈 박스(Don Box), 역 한빛 리포터 1기 서성용
필자가 XML에, 좀더 세부적으로는 SOAP을 연구한 지 3년 남짓 되었다. 그 기간 동안 SOAP을 연구한 결과물은 너무 보잘 것 없다. 이는 주로 정해진 XML 스키마 규약이 없었기 때문이지만, 수천 개에 달하는 SOAP 지원 체계를 구축하겠다는 생각 자체가 망상이었던 것 같다. 이제는 XML Schema WG가 이 작업을 다소 완성했으므로, 필자가 하던 일을 다시 해야겠다. SOAP 연구를 다시 시작하기 전에 필자가 처음으로 “공식적으로” 한 것은 어떻게 여기까지 왔는지를 생각해 보는 것이다. 그래서 지금 이 글을 쓰고 있다. 제 1단계: SOAP 98 1998년 초에 처음으로 SOAP이 등장했을 때는, 스키마 언어라든가 XML 형태 체계(사실 XML 1.0은 그때 완전한 권고문이 되었다)와 같은 것이 없었다. SOAP 규약 초기 버전(1998년 SOAP 규약의 서브셋인 XML-RPC와 같은)을 살펴보면, 규약의 초점이 형태 체계를 정의하는 데 맞춰져 있음을 알 수 있다. SOAP의 원 형태 체계(XML-RPC 역시)는 이름(즉 구조)으로 접근하는 콤퍼짓(composite)이거나, 위치(배열)로 접근하는 콤퍼짓과 같은 원시적인 형태였다. 일단 이러한 대표 형태가 생기자, 구조 쌍에 따라 운영/메소드를 정의함으로써 행동 형태를 모델링했다. 최소한 DevelopMentor와 마이크로소프트(MS) 측에서는 이러한 운영을 인터페이스로 통합했다. 그래서 RPC에서는 사람들이 SOAP을 연구하는 것을 좋아하는 것이다. XML에 행동 형태 체계를 부가하려는 시도는 SOAP이 처음이 아니다. 그 당시의 광경이 기억난다. 지금의 제안은 기저에 COM 형태 체계를 가정하고 있거나(우리는 1998년에 이미 COM이 궁극적인 형태 체계가 아니라는 것을 알고 있었다), 일부 개발 커뮤니티를 소외시켰던 EDI 같은 것이었다. 이 때문에 우리는 현재 일련의 포맷(ASN.1 BER, NDR, XDR, CDR, JRMP)과 RPC 프로토콜(GIOP/IIOP, DCE/DCOM, RMI, ONC)을 살펴보고, 80%는 쉽게 만족시키고, 변형시키면 나머지 20%에도 적용될 수 있는 핵심부분을 찾아내려고 했다. 그렇다면 우리가 1998년 후반에 SOAP을 발표하지 않은 이유는 무엇인가? 바로 MS의 정책 때문이다. MS 내부에서 SOAP에 기여한 최초의 공헌자들은 COM/MTS 팀에서 일했다. 같은 시기에 MS 내부의 XML 그룹은 XML-Data 작업을 하고 있었는데, 이는 오늘날 우리가 알고 있는 XML 스키마 언어의 기초가 되었다. 두 그룹이 모두 거대한 회사에 속해 있다 보니, 견해가 일치하지 않아서 SOAP에 대한 공개적 지원은 MS 내부에서 일정 기간 보류되었다. MS가 SOAP 개발을 지연하자, 데이브 위너는 단독으로 처음 SOAP 유형 체계의 서브셋에 기반한 XML-RPC 규약을 발표했다. 필자는 Java 클래스 파일을 XML로 변환하는 프로젝트 중, 따분한 Java 메타데이터를 작업하는 데 그 해의 남은 시간을 보냈다. SOAP 2단계: 1999-2000 SOAP 규약이 마침내 "SOAP"이라는 이름으로 발표될 때까지(1999년 4분기), W3C XML 스키마 언어는 아무 것도 완성되지 않았다. 하지만 SOAP 창시자들이 일의 능률을 올려야 하며, Schema Working Group의 작업을 통합해야 한다는 것은 느끼게 되었다. 기본 유형은 SOAP에 필요하다고 생각하는 상위 집합이었으며, 콤포짓 유형 체계는 SOAP에 필요하다고 생각하는 상위 집합이었다. 그들의 이러한 노력을 무시하는 처사는 결코 올바르지 않다. SOAP은 XML 스키마의 표시 유형 체계를 그대로 받아들이고, 행동 유형과 오퍼레이션/메소드의 개념을 추가만 했어야 했다. 하지만 XML 스키마는 유형화된 참조나 배열 같은 통합적인 유형에 대한 지원이 부족했다(현재도 그렇다). 유형화된 참조와 배열처럼 보이는 것을 스키마 언어로 정의할 수는 있으나, 이 구조는 XML 스키마에만 있는 것은 아니다. 게다가 이러한 참조와 배열 유형을 미리 정의하고자 할 때, 자바 클래스와 XML 스키마 유형의 경우, 그 둘 사이에서 동일 구조로 변환하기 어렵다. 그래서 SOAP에서는 soap:reference와 soar:Array처럼 유형 체계를 확장해야 했던 것이다. Schemas Working Group이 유형화된 참조에 대해 다루긴 했지만, 대부분의 프로그램 유형 체계에서 나타나는 유형화된 참조를 지원하는 솔루션은 개발하지 못했다. 1999년 4분기 SOAP 규약의 대부분은 유형화된 참조와 배열을 W3C XML 스키마 유형 체계로 모델하는 방법을 단순히 설명하는 것이었다. 또한 선택적이거나 필수적인 프로토콜 헤더를 추가하는 모델(코바의 서비스 컨텍스트나 DCOM의 ORPCTHIS/THAT)이 있었지만, 모두 비슷했다. 솔직히 스키마 규약은 1999년 4분기에 완전한 권고안이 되긴 했지만, 그 당시 SOAP 규약은 많아야 3-4 페이지 밖에 되지 않았다. 그 이후 XML 스키마 규약은 계속되는 작업마다 급속도로 변화해서, 필자처럼 SOAP을 연구하는 사람들은 일을 진척시키기 위해, 1999에서 2000년 사이의 W3C XML 스키마라는 하나의 흐름에서 빠져나와야 했던 것이다. 개인적으로 1999년과 2000년에 SOAP이 직면한 가장 큰 기술적인 이슈는 메타데이터의 부족이었다. DevelopMentor는 XML 스키마 유형 체계와 동일구조인 간단한 메타데이터 포맷(CDL)을 도입하려 했으나, 보다 유동적인 스키마 언어는 아직 나오지 않았다. 데이브 위너는 인간이 읽을 수 있는 설명이 필요한 것의 전부라고 암시하면서, 메타데이터의 개념을 포기했다. 확실히 에릭 레이몬드와 같은 사람은 이에 동의하는 것 같았다. 그러나 우리가 CDL을 포기한 이유는 MS의 고팔(Gopal)과 논쟁한 것 때문이었다. 그는 XML 스키마에 SOAP에만 해당되는 설명을 덧붙여 주기만 하면 된다는 점을 우리에게 납득시켰다. 그리고 스키마 규약으로 이러한 설명이 가능하다고 했다. 이 시점에서 DevelopMentor가 Schemas WG에 동참했고, 우리는 XML 스키마 지원 쪽으로 무게 중심을 옮겼다. 내부에서는 C++ 용 XSD 컴파일러를 탑재한 DM과 관련해 XML 스키마를 사용한다. 1999년과 2000년에 SOAP이 직면한 비기술적 이슈는 벤더 전쟁의 끔찍한 본성이다. 통상 압력과 업체들의 웹사이트 주변에 돌다다니던 FUD는 매우 곤란했다. 필자는 최근 썬 사의 Reality Check을 발견했는데, 이 때문에 기분이 많이 상했다. 다음에 인용해 놓은 것은 특히 심하다. SOAP 은 많이 변해왔다. MS가 초기에 확립한 그저 그런 규약에 IBM이 추가하면서 흥미롭게 변했다. 만약 SOAP/1.0(IBM 이전 최후 버전)이 좋지 않은 개념이었다면, SOAP/1.1(W3C에 제출한 IBM 이후 최초 버전)도 마찬가지였다. SOAP 1.1에는 1.0과 크게 달라진 점이 없었다. 규약은 SOAP의 모듈적 디자인을 보다 명백하기 위해 재구성되었다. 그러나 우리가 만든 기술적 변화들은 분명히 후퇴하고 있었다(사실 나는 새로운 SOAPActor로 무언가 의미 있는 것을 하는 SOAP 구현이 없다는 것이 시대에 뒤떨어진다고 생각한다). SOAP 이후 시기: 2001년 이후 그래서 우리는 지금 어느 곳에 있는가? 어려운 질문이다. 지금부터는 현재 진행 중인 상태에 대해 살펴보자. XML 스키마 규약은 안정적이고 이제는 확정된 권고안이다. XML 프로토콜과 메시징, 특히 SOAP에 관심이 많은 필자와 같은 사람에게 이것은 가장 중요한 개선점이다. 완전한 W3C 권고안으로 발전하기 전에 더 이상의 변화는 없을 것이라는 사실은, 전체 산업계가 XML에 유형을 적용해야 할 때 그들이 무엇을 다루고 있는지를 안다는 뜻이다. 위에서도 언급했지만, 필자는 스키마 없이는 XML은 조각난 표준일 뿐이며, 소프트웨어, 컴포넌트, 서비스 통합에서 XML의 활용은 매우 미미하다고 생각한다. 스키마 규약은 SOAP을 가장 무겁게 떠받치고 있으며, 새로운 스키마 언어를 발표하기 위해서 SOAP/1.2를 우리가 작업할 수 없다는 사실은 필자를 괴롭힌다. 이에서 다음과 같은 사실을 알 수 있다. 이제 W3C에는 XML Protocol Working Group이 있다. SOAP은 이제 제대로 된 위치에 있다. W3C가 SOAP을 인수하기 전까지, 업체들은 변덕스럽게 행동했다. 이제 SOAP이 XML Protocol Working Group에 포함되었으므로, 대형 벤더들은 대체적으로 SOAP에 대해 논쟁을 그만두었고, 우리는 꽤 열린 과정으로 프로토콜을 다듬어서 모양새를 갖추게 되었다. 필자의 의견으로는, WG이 행한 가장 현명한 작업 중의 하나는 XML 스키마 유형 체계에 대한 WG의 관계를 정의한 것이다. 우리는 SOAP의 표준화된 메타데이터 포맷에 어느 정도 근접해 있다. 완전하지는 않지만, WSDL은 잘 동작하는 메타데이터 표준에 근접했다. 이 표준은 한 번에 일주일 이상의 기간에 세 사람 이상이 동의할 수 있다. WSDL은 긴 관점에서 보면 완벽하지 않다. 대부분의 경우에는 이용할 수 있다. 그러나 WSDL과 같은 것이 없으면 SOAP/XML 메시징은 의미가 없다. 필자는 WSDL이 XML 스키마에 이상하게 관련되어 있다고 생각한다(사실 WSDL과 XML 스키마는 여러 군데에서 전혀 호환되지 않는다). 이것이 WSDL에 대한 필자의 유일한 비판이다. 이러한 필자의 비판에도 불구하고, WSDL은 최근 3년 간 다뤄 본 모든 SOAP 환경이나 애플리케이션에서 매우 잘 작동했다. 다소 장황하고 우회적이기는 하지만 말이다. XML Protocol Activity는 WSDL 규약을 마무리하는 데 초점을 둘 것이고, 설명, 비준 그리고 XML 기반 서비스의 자동화를 적절한 방식으로 발표할 것이다. 사람들은 SOAP에 대한 논쟁을 멈추었다. 대부분의 사람은 SOAP이 성공했다고 평한다. 벤더들은 SOAP을 지원하기 시작했다. 상호운용이 가능한 구현(확실치 않은)에 대한 보고도 있었지만, 솔직히 말해서, 상호운용이 가능한 메타데이터 없이는 유선에서의 상호운용성이 별로 중요하지 않은 것 같다. W3C에서 더 좋은 것을 내놓기 전까지 사람들은 WSDL을 지지할 것이다. 그래서 2001년 3분기 말까지는 아마도 상호운용성을 실제로 볼 수 있을 것이다. 후기 SOAP의 원래 의도는 상당히 소박하다. 즉 임시적인 XML 문서를 전송하여 원격 호스트가 작동하거나 반응하게 만드는 과정을 성문화하는 것이다. 다소 늦게 개발에 참여했기 때문에, Schema WG가 벌써 해결한 문제에 부딪혀야 했고, 이 때문에 Simple Object Access Protocol의 줄임말인 "SOAP"이 전혀 단순하지(Simple) 않다. 이 시점에서 필자는 중장기적으로 다음의 두 가지만을 수렴해야 한다고 확신한다.
서성용님은 한빛 리포터 1기로 활동 중이며, 서울대학교 컴퓨터공학부 3학년에 재학중입니다. 현재 학부 체계 관리자 그룹 ACCESS의 UNIX Team Chief이며, Linux, kernel, network, computer architecture에 관심이 많다고 합니다.
필자가 XML에, 좀더 세부적으로는 SOAP을 연구한 지 3년 남짓 되었다. 그 기간 동안 SOAP을 연구한 결과물은 너무 보잘 것 없다. 이는 주로 정해진 XML 스키마 규약이 없었기 때문이지만, 수천 개에 달하는 SOAP 지원 체계를 구축하겠다는 생각 자체가 망상이었던 것 같다. 이제는 XML Schema WG가 이 작업을 다소 완성했으므로, 필자가 하던 일을 다시 해야겠다. SOAP 연구를 다시 시작하기 전에 필자가 처음으로 “공식적으로” 한 것은 어떻게 여기까지 왔는지를 생각해 보는 것이다. 그래서 지금 이 글을 쓰고 있다. 제 1단계: SOAP 98 1998년 초에 처음으로 SOAP이 등장했을 때는, 스키마 언어라든가 XML 형태 체계(사실 XML 1.0은 그때 완전한 권고문이 되었다)와 같은 것이 없었다. SOAP 규약 초기 버전(1998년 SOAP 규약의 서브셋인 XML-RPC와 같은)을 살펴보면, 규약의 초점이 형태 체계를 정의하는 데 맞춰져 있음을 알 수 있다. SOAP의 원 형태 체계(XML-RPC 역시)는 이름(즉 구조)으로 접근하는 콤퍼짓(composite)이거나, 위치(배열)로 접근하는 콤퍼짓과 같은 원시적인 형태였다. 일단 이러한 대표 형태가 생기자, 구조 쌍에 따라 운영/메소드를 정의함으로써 행동 형태를 모델링했다. 최소한 DevelopMentor와 마이크로소프트(MS) 측에서는 이러한 운영을 인터페이스로 통합했다. 그래서 RPC에서는 사람들이 SOAP을 연구하는 것을 좋아하는 것이다. XML에 행동 형태 체계를 부가하려는 시도는 SOAP이 처음이 아니다. 그 당시의 광경이 기억난다. 지금의 제안은 기저에 COM 형태 체계를 가정하고 있거나(우리는 1998년에 이미 COM이 궁극적인 형태 체계가 아니라는 것을 알고 있었다), 일부 개발 커뮤니티를 소외시켰던 EDI 같은 것이었다. 이 때문에 우리는 현재 일련의 포맷(ASN.1 BER, NDR, XDR, CDR, JRMP)과 RPC 프로토콜(GIOP/IIOP, DCE/DCOM, RMI, ONC)을 살펴보고, 80%는 쉽게 만족시키고, 변형시키면 나머지 20%에도 적용될 수 있는 핵심부분을 찾아내려고 했다. 그렇다면 우리가 1998년 후반에 SOAP을 발표하지 않은 이유는 무엇인가? 바로 MS의 정책 때문이다. MS 내부에서 SOAP에 기여한 최초의 공헌자들은 COM/MTS 팀에서 일했다. 같은 시기에 MS 내부의 XML 그룹은 XML-Data 작업을 하고 있었는데, 이는 오늘날 우리가 알고 있는 XML 스키마 언어의 기초가 되었다. 두 그룹이 모두 거대한 회사에 속해 있다 보니, 견해가 일치하지 않아서 SOAP에 대한 공개적 지원은 MS 내부에서 일정 기간 보류되었다. MS가 SOAP 개발을 지연하자, 데이브 위너는 단독으로 처음 SOAP 유형 체계의 서브셋에 기반한 XML-RPC 규약을 발표했다. 필자는 Java 클래스 파일을 XML로 변환하는 프로젝트 중, 따분한 Java 메타데이터를 작업하는 데 그 해의 남은 시간을 보냈다. SOAP 2단계: 1999-2000 SOAP 규약이 마침내 "SOAP"이라는 이름으로 발표될 때까지(1999년 4분기), W3C XML 스키마 언어는 아무 것도 완성되지 않았다. 하지만 SOAP 창시자들이 일의 능률을 올려야 하며, Schema Working Group의 작업을 통합해야 한다는 것은 느끼게 되었다. 기본 유형은 SOAP에 필요하다고 생각하는 상위 집합이었으며, 콤포짓 유형 체계는 SOAP에 필요하다고 생각하는 상위 집합이었다. 그들의 이러한 노력을 무시하는 처사는 결코 올바르지 않다. SOAP은 XML 스키마의 표시 유형 체계를 그대로 받아들이고, 행동 유형과 오퍼레이션/메소드의 개념을 추가만 했어야 했다. 하지만 XML 스키마는 유형화된 참조나 배열 같은 통합적인 유형에 대한 지원이 부족했다(현재도 그렇다). 유형화된 참조와 배열처럼 보이는 것을 스키마 언어로 정의할 수는 있으나, 이 구조는 XML 스키마에만 있는 것은 아니다. 게다가 이러한 참조와 배열 유형을 미리 정의하고자 할 때, 자바 클래스와 XML 스키마 유형의 경우, 그 둘 사이에서 동일 구조로 변환하기 어렵다. 그래서 SOAP에서는 soap:reference와 soar:Array처럼 유형 체계를 확장해야 했던 것이다. Schemas Working Group이 유형화된 참조에 대해 다루긴 했지만, 대부분의 프로그램 유형 체계에서 나타나는 유형화된 참조를 지원하는 솔루션은 개발하지 못했다. 1999년 4분기 SOAP 규약의 대부분은 유형화된 참조와 배열을 W3C XML 스키마 유형 체계로 모델하는 방법을 단순히 설명하는 것이었다. 또한 선택적이거나 필수적인 프로토콜 헤더를 추가하는 모델(코바의 서비스 컨텍스트나 DCOM의 ORPCTHIS/THAT)이 있었지만, 모두 비슷했다. 솔직히 스키마 규약은 1999년 4분기에 완전한 권고안이 되긴 했지만, 그 당시 SOAP 규약은 많아야 3-4 페이지 밖에 되지 않았다. 그 이후 XML 스키마 규약은 계속되는 작업마다 급속도로 변화해서, 필자처럼 SOAP을 연구하는 사람들은 일을 진척시키기 위해, 1999에서 2000년 사이의 W3C XML 스키마라는 하나의 흐름에서 빠져나와야 했던 것이다. 개인적으로 1999년과 2000년에 SOAP이 직면한 가장 큰 기술적인 이슈는 메타데이터의 부족이었다. DevelopMentor는 XML 스키마 유형 체계와 동일구조인 간단한 메타데이터 포맷(CDL)을 도입하려 했으나, 보다 유동적인 스키마 언어는 아직 나오지 않았다. 데이브 위너는 인간이 읽을 수 있는 설명이 필요한 것의 전부라고 암시하면서, 메타데이터의 개념을 포기했다. 확실히 에릭 레이몬드와 같은 사람은 이에 동의하는 것 같았다. 그러나 우리가 CDL을 포기한 이유는 MS의 고팔(Gopal)과 논쟁한 것 때문이었다. 그는 XML 스키마에 SOAP에만 해당되는 설명을 덧붙여 주기만 하면 된다는 점을 우리에게 납득시켰다. 그리고 스키마 규약으로 이러한 설명이 가능하다고 했다. 이 시점에서 DevelopMentor가 Schemas WG에 동참했고, 우리는 XML 스키마 지원 쪽으로 무게 중심을 옮겼다. 내부에서는 C++ 용 XSD 컴파일러를 탑재한 DM과 관련해 XML 스키마를 사용한다. 1999년과 2000년에 SOAP이 직면한 비기술적 이슈는 벤더 전쟁의 끔찍한 본성이다. 통상 압력과 업체들의 웹사이트 주변에 돌다다니던 FUD는 매우 곤란했다. 필자는 최근 썬 사의 Reality Check을 발견했는데, 이 때문에 기분이 많이 상했다. 다음에 인용해 놓은 것은 특히 심하다. SOAP 은 많이 변해왔다. MS가 초기에 확립한 그저 그런 규약에 IBM이 추가하면서 흥미롭게 변했다. 만약 SOAP/1.0(IBM 이전 최후 버전)이 좋지 않은 개념이었다면, SOAP/1.1(W3C에 제출한 IBM 이후 최초 버전)도 마찬가지였다. SOAP 1.1에는 1.0과 크게 달라진 점이 없었다. 규약은 SOAP의 모듈적 디자인을 보다 명백하기 위해 재구성되었다. 그러나 우리가 만든 기술적 변화들은 분명히 후퇴하고 있었다(사실 나는 새로운 SOAPActor로 무언가 의미 있는 것을 하는 SOAP 구현이 없다는 것이 시대에 뒤떨어진다고 생각한다). SOAP 이후 시기: 2001년 이후 그래서 우리는 지금 어느 곳에 있는가? 어려운 질문이다. 지금부터는 현재 진행 중인 상태에 대해 살펴보자. XML 스키마 규약은 안정적이고 이제는 확정된 권고안이다. XML 프로토콜과 메시징, 특히 SOAP에 관심이 많은 필자와 같은 사람에게 이것은 가장 중요한 개선점이다. 완전한 W3C 권고안으로 발전하기 전에 더 이상의 변화는 없을 것이라는 사실은, 전체 산업계가 XML에 유형을 적용해야 할 때 그들이 무엇을 다루고 있는지를 안다는 뜻이다. 위에서도 언급했지만, 필자는 스키마 없이는 XML은 조각난 표준일 뿐이며, 소프트웨어, 컴포넌트, 서비스 통합에서 XML의 활용은 매우 미미하다고 생각한다. 스키마 규약은 SOAP을 가장 무겁게 떠받치고 있으며, 새로운 스키마 언어를 발표하기 위해서 SOAP/1.2를 우리가 작업할 수 없다는 사실은 필자를 괴롭힌다. 이에서 다음과 같은 사실을 알 수 있다. 이제 W3C에는 XML Protocol Working Group이 있다. SOAP은 이제 제대로 된 위치에 있다. W3C가 SOAP을 인수하기 전까지, 업체들은 변덕스럽게 행동했다. 이제 SOAP이 XML Protocol Working Group에 포함되었으므로, 대형 벤더들은 대체적으로 SOAP에 대해 논쟁을 그만두었고, 우리는 꽤 열린 과정으로 프로토콜을 다듬어서 모양새를 갖추게 되었다. 필자의 의견으로는, WG이 행한 가장 현명한 작업 중의 하나는 XML 스키마 유형 체계에 대한 WG의 관계를 정의한 것이다. 우리는 SOAP의 표준화된 메타데이터 포맷에 어느 정도 근접해 있다. 완전하지는 않지만, WSDL은 잘 동작하는 메타데이터 표준에 근접했다. 이 표준은 한 번에 일주일 이상의 기간에 세 사람 이상이 동의할 수 있다. WSDL은 긴 관점에서 보면 완벽하지 않다. 대부분의 경우에는 이용할 수 있다. 그러나 WSDL과 같은 것이 없으면 SOAP/XML 메시징은 의미가 없다. 필자는 WSDL이 XML 스키마에 이상하게 관련되어 있다고 생각한다(사실 WSDL과 XML 스키마는 여러 군데에서 전혀 호환되지 않는다). 이것이 WSDL에 대한 필자의 유일한 비판이다. 이러한 필자의 비판에도 불구하고, WSDL은 최근 3년 간 다뤄 본 모든 SOAP 환경이나 애플리케이션에서 매우 잘 작동했다. 다소 장황하고 우회적이기는 하지만 말이다. XML Protocol Activity는 WSDL 규약을 마무리하는 데 초점을 둘 것이고, 설명, 비준 그리고 XML 기반 서비스의 자동화를 적절한 방식으로 발표할 것이다. 사람들은 SOAP에 대한 논쟁을 멈추었다. 대부분의 사람은 SOAP이 성공했다고 평한다. 벤더들은 SOAP을 지원하기 시작했다. 상호운용이 가능한 구현(확실치 않은)에 대한 보고도 있었지만, 솔직히 말해서, 상호운용이 가능한 메타데이터 없이는 유선에서의 상호운용성이 별로 중요하지 않은 것 같다. W3C에서 더 좋은 것을 내놓기 전까지 사람들은 WSDL을 지지할 것이다. 그래서 2001년 3분기 말까지는 아마도 상호운용성을 실제로 볼 수 있을 것이다. 후기 SOAP의 원래 의도는 상당히 소박하다. 즉 임시적인 XML 문서를 전송하여 원격 호스트가 작동하거나 반응하게 만드는 과정을 성문화하는 것이다. 다소 늦게 개발에 참여했기 때문에, Schema WG가 벌써 해결한 문제에 부딪혀야 했고, 이 때문에 Simple Object Access Protocol의 줄임말인 "SOAP"이 전혀 단순하지(Simple) 않다. 이 시점에서 필자는 중장기적으로 다음의 두 가지만을 수렴해야 한다고 확신한다.
- XML Schema Working Group은 형이 결정된 참조와 배열의 결과를 발표해야 한다. 이러한 두 가지 합성적인 유형에 대해 지원을 추가하면 SOAP section 5는 불필요하게 될 것이다. 이러한 구조는 메시징과 RPC 응용프로그램의 범위 밖에서도 유용하므로, Schema WG에서는 이를 발표해야 한다.
- XML 스키마를 오퍼레이션 및 WSDL 스타일의 portType의 표현 형태로 묶는 데 필요한 추가적인 구조를 정의해야 한다.
서성용님은 한빛 리포터 1기로 활동 중이며, 서울대학교 컴퓨터공학부 3학년에 재학중입니다. 현재 학부 체계 관리자 그룹 ACCESS의 UNIX Team Chief이며, Linux, kernel, network, computer architecture에 관심이 많다고 합니다.
TAG :
이전 글 : PDA에 리눅스를
다음 글 : PHP: 세션 추적- 1부
최신 콘텐츠