IT/모바일
저자: 켄달 그랜트 클라크(Kendall Grant Clark), 역 전순재
그 동안의 생각이...
1년 반 전부터 지금까지 향후 웹이 나아갈 방향이 "웹 서비스(Web Services)"와 "의미구조 웹(Semantic Web)" 사이의 싸움으로 비쳐지기 시작했다. "웹 서비스(Web Services)"는 W3C와 학계(academia)에서 연유한 것으로 생각되었고, "의미구조 웹(Semantic Web)"은 IBM-마이크로소프트-썬을 비롯한 업계에서 기원하는 것으로 간주된다. "어떤 것(X)의 미래"를 둘러싼 그 모습에 대한 토론의 의미는 거의 전적으로 어떤 것(X)의 현재 가치에 달려있다. 웹의 미래에 관한 토론은 주로 현재의 웹이 너무 높은 평가를 받고 있어 종종 과열되므로 적당히 평가하기에는 너무 위험하다.
서비스와 의미구조 사이의 논쟁을 살펴보면 웹이 상업상 가치가 있는 것인지 아니면 그 내용상 가치가 있는 것인지로 웹을 흥미로운 곳으로 만드는 요인을 찾아볼 수 있다. 전통적으로 웹에서 서비스는 웹의 상업적 측면을 나타내는 반면, 의미구조는 그의 내용을 대표한다.
대부분의 경우 이러한 맥락의 가정과 관심은 그동안 간접적으로도 언급되지 않았다. 그렇지만 심리학자 프로이드라면 알았다고 할지라도 놀라진 않았을 것이란 예를 들어 은근히 이에 대해 언급하기도 하였다. 서비스를 지지하는 대중들에게, 이를 가장 전형적으로 보여주는 예는 복잡하지만 정확한 상업적 거래를 들 수 있다. 어떤 이유인지는 잘 모르겠지만 항공 좌석예약과 주식 시장이 그 예로 상당히 자주 인용된다. 반면 의미구조를 지지하는 대중에게 이를 가장 전형적으로 보여주는 예는 부담스러운 작업을 정확하게 처리하는 일종의 중개자나 자율 처리과정이다. 자주 인용되는 예 하나는 회합을 갖기를 원하는 대단히 바쁜 어떤 집단에게 일정 조정을 자동으로 고지하는 것이다(그리고, 우리는 이것을 아주 중요하게 생각한다).
...가끔 틀리기도 한다
전통적이라 여겨졌던 사실이 틀렸다는 것은 시간이 지나자 명백해졌다. 그러나 나는 실제로 "서비스 대 의미구조"가 도대체 어떻게 다른지 이해하지 못했다. DAML-S에 익숙해지기 시작하기 전까지는 말이다. DAML-S(현재 버전은 0.6)는 현재 DAML+OIL 위에 구축되고 있는 웹 서비스의 개념규격(ontology)[1]이다. (이 서비스는 W3C의 프로젝트인 WebOnt 안으로 구체화되고 있는 중이다). 그 아이디어는 웹 자원의 고수준 존재가 아주 유용한 것일 수 있고, 한 마디로 말해(here"s the kicker), 웹 서비스는 그냥 일종의 웹 자원이라는 것이다. 웹 서비스란, DAML 서비스 연합(DAML Services Coalition)이 기술하듯이, "예를 들어 제품의 판매나 물리적인 장치의 통제와 같은, 세계에 변경이나 어떤 행위의 효력을 미치도록 허용하는" 웹 자원이다 ("DAML-S: 웹 서비스를 위한 의미구조적 마크업(Semantic Markup For Web Services)").
그래서 DAML-S는 관례적인 지혜를 최대한 겸손하게 반박한다. "대(versus)"라는 것만이 유일하게 "의미구조(semantics)"와 "서비스(services)"를 연결하는 방법은 아니라는 것이다. 만약 DAML-S가 기껏해야 상상속의 실험일 뿐이라면, 이미 웹의 미래를 바라볼 수 있는 흥미로운 대안적인 방법을 제공하였을 것이다. 그러나 DAML-S는 상상속의 실험 그 이상이다.
왜 DAML-S인가?
첫 번째로 DAML-S에 대하여 이해해야 할 것은 이것이 고수준(high-level) 존재로서 애플리케이션 수준 위에 올라앉아서 웹 서비스의 무엇(what)에 대한 질문과 왜(why)에 대한 질문들에 대하여 응답을 한다는 것을 의미한다. WSDL의 주 영역인 어떻게(how)-질문과 대조적으로 말이다(자세한 것은 리치 살쯔(Rich Salz)의 탁월한 기사 "Examining WSDL" 참조). 더 자세한 것은 아래에 기술하겠다. 웹 서비스의 어떻게(how)-질문에 대하여 머신이 소화할만한 답변을 가진다는 가치는 이제 XML.com 독자라면 분명히 알고 있을 것이다. 그러나 무엇(what)-질문과 왜(why)-질문에 대하여 머신이 소화가능한 답변을 어떻게 처리할 것인가?
DAML-S를 만들어 내려고 하는 동기에는 발견(discovery), 요청(invocation), 상호운용(interoperation), 합성(composition), 검증(verification), 관제(monitoring)가 포함된다. "의미구조(semantic)"라고 라벨이 붙은 어떤 웹 테크놀러지도 실제적인 금전적 가치를 지니려면 웹이 최종 사용자로부터의 애매하거나 심지어 비밀스럽기도 한 입력에 반응하여 상대적으로 유용한 어떤 것을 제공하여야 하는 것이다. 최종 사용자가 "항공 좌석예매"를 자율적인 웹 중개자에 입력하면, 예를 들어 그 최종 사용자를 비행기 노선 예매를 하도록 안내할 웹 서비스의 시작점이 반드시 그 출력결과 중에 있어야 한다.
그런 종류 그리고 다른 종류로 최종 사용자가 미치는 영향력을 지원하려면, 똑똑한 서비스 발견(smart service discovery)이 필요하다. 중개자가 제약조건의 모둠을 만족하는 웹 서비스를 찾도록 프로그램을 할 수 있어야 한다. 그러나 똑똑한 발견 (smart discovery)은 똑같이 똑똑한 요청(smart invocation)이 없다면 아무 쓸모가 없다. 중개자가 예약을 할 수 있는 방법을 찾아 냈지만, 그 처리과정에 요청을 할 수 없다면, 최종 사용자는 몹시 실망할 것이기 때문이다. 중개자가 항공 좌석예매 서비스를 찾아내서 거기에 요청한 후에도, 최종 사용자에게 각 단계에서 요긴한 피드백을 제공하고 문제 발생시나 실패했을 때 우아하게 원래대로 복구하여 줌으로써 그 처리과정을 통제할 수 없다면, 최종 사용자는 똑같이 실망할 것이다. 이 때문에 발견 그리고 요청과 더불어 똑같이 똑똑한 실행 관제(smart execution monitoring)도 역시 필요하다.
개발자와 최종사용자는 똑같이, 서로 다른 방식으로 그리고 서로 다른 이유로, 간단한 웹 서비스로부터 복잡한 웹 서비스를 구축하고 싶어할 수도 있지만, 이는 머신이 소화할 수 있는 기술, 무엇보다도 입력, 출력, 선조건, 더 간단한 서비스 영향력에 관한 기술을 확보하지 않는 한 그 때까지는 불가능한 일이다. 지능적으로 서비스들을 조합하려면 전제 조건으로 그 서비스들이 상호운용되어야 하며, 특히 자동으로 변환되거나 클라이언트와 서비스 사이에 맵핑이 이루어져야 한다. 마지막으로, 발견이 제대로 작동하려면, 서비스의 특성들은 반드시 머신 확인할 수 있어야 한다. 서비스의 특성 중 한 가지 기능은 한 서비스가 적절한 제약 조건 모둠을 만족하는가 아닌가를 확인하는 것이다.
물론 앞의 내용 중에는 어떤 것은 마치 공상과학 소설처럼 들리지만, 중개자 이론과 다른 분야의 컴퓨터 과학에서 엄격한 연구로 지지를 얻고 있다. 세속적으로 DAML-S를 이해하려면 그것을 자율적인 중개자 이론과 XML-RDF, WSDL-SOAP의 결합으로 생각하는 것이다.
by Kendall Grant Clark
DAML-S에는 무엇이 포함되어 있는가?
DAML-S에는 이미 많은 것이 있으며 앞으로 더 많은 것들이 추가될 것이다. 그 모든 것을 기술할 수는 없다. 범위를 좁힐수록 더 자세하게 기술할 수 있다. 남아 있는 것 중에서, 지적하고 싶은 것이 있다면 DAML-S는 엄청나게 크다는 것이며 추가로 필요한 정보는 소스(sources)를 가리켜 주겠다.
Service Profiles, Models, 그리고 Groundings
서비스 존재구조의 최상부는 Service 클래스를 감싸고 있다. Service는 일종의 웹 자원이다. 사람들은 Service에 대해 적어도 세 가지 사실은 알아 두어야 한다. Service가 하는 일, Service가 움직이는 방법, 그리고 Service에 접근하는 방법이 바로 그 세 가지이다. 이러한 질문에 상응하여 각각, DAML-S는 ServiceProfile, ServiceModel, ServiceGrounding과 같은 세 가지 클래스를 제공한다. DAML-S는 세 가지 특성으로 presents, describedBy, supports을 선언하는데, 이들은 각각 이러한 세 가지 클래스들을 자신들의 범위로 가진다. 추상적으로 살펴 보면, DAML-S를 사용하면 머신-소화가능한 형태로 Service가 ServiceProfile을 표현하고(presents), ServiceModel에 의해서 기술되며(describedBy), 그리고 ServiceGrounding을 지원하도록(supports) 선언할 수 있다. 실제로 Service의 자손 클래스들은 ServiceProfile, ServiceModel, ServiceGrounding의 자손 클래스들에 각각 상응하게 될 것이다.
프로세스 모델(Process Models)
서비스가 어떻게 작동할지 선언하거나 기술하려고 한다면, 반드시 처리방법, 행위, 그리고 실행 모드에 관하여 말해줄 방법이 있어야 한다. 그래서 DAML-S는 처리부라는 것을 제공하는데, ProcessModel 클래스인 ServiceModel의 자손 클래스에 의해서 모델링 되며, 이것은 처리 개념규격(ontology)과 처리 통제 개념규격(ontology)으로 구성된다. 앞의 것으로 입력, 출력, 선조건, 그리고 서비스의 효과를 기술할 수 있다. 뒤의 것으로 처리의 상황을 기술할 수 있는데, 여기에는 요청하는 법, 실행 경로, 완성 조건이 포함된다. DAML-S에는 또한 간단한 자원 개념규격(ontology)와 시간 개념규격(ontology)이 포함되어 있다.
Process 클래스는 DAML-S의 처리 개념규격(ontology)의 기본 요소이다. Process는 입력(inputs), 출력(outputs), 선조건(preconditions), 그리고 효과(effects)를 가질 수 있다.[2]DAML-S에서 Process는 세 가지 종류로 분할된다. AtomicProcess는 요청 시간에 모든 입력을 취해서 실행하고, 완성시간에 모든 결과를 반환하는데, 이것은 반드시 ServiceGrounding의 실체 하나를 가져야 한다. CompositeProcess는 원자적이거나 혹은 다른 조합 처리과정으로 구성되는 처리과정으로서, 여러 DAML-S 제어 구조를 사용하는 각 구성 부분들로 분해할 수 있다(Sequence, Concurrent, Split, Split+Join, Unordered, Choice, If-Then-Else, Repeat-Until, Repeat-While). 여기에서 SimpleProcess는 대안적으로 AtomicProcess를 볼 수 있게 해주고 CompositeProcess의 추상층을 제공하는 추상화 처리과정이다. 그리고 이것은 AtomicProcess에 의해서 실현(realizedBy)되거나, 또는 CompositeProcess로 연장(expands) 된다.
DAML-S, WSDL, 그리고 "진짜 세계"
물론, 결국 이 모든 개념규격의 선언과 고-수준의 분류는 실제로 작동하는 코드로 실현되어야 한다. DAML-S는 이것을 "구체화(grounding)"[3]라고 부르는데, DAML-S에서 ServiceGrounding 클래스로 표현된다. DAML-S의 ServiceModel과 ServiceProfile 부분은 이런 구체적인 서비스를 추상적으로 표현한 것이다. 그리고 이 두 개를 하나로 묶는 것은 ServiceGrounding이다. 특히 흥미로운 사실은 DAML-S의 ServiceGrounding과 WSDL 사이의 관계이다. DAML-S의 골격구조(architects)에서 DAML-S와 WSDL 사이를 연결하는 여러 중요한 경로가 발견된다. 먼저 DAML-S가 실현(grounding)으로 개념화한 것은 WSDL이 이해하는 바인딩(binding)에 깔끔하게 상응한다. 둘째, AtomicProcess의 여러 부분이 WSDL의 연산처리에 상응한다(다시 말해 AtomicResponse의 변형들은 각각 WSDL 연산처리의 변형인 요구-응답(request-response), 일방(one-way), 고지(notification), 그리고 간청-응답(solicit-response)에 상응). 셋째, XML 스키마에 지정된 WSDL의 추상적 형은 DAML-S의 입력과 출력 서비스 선언과 겹쳐지는데, 이는 기술-로직인 DAML+OIL 클래스로 지정할 수 있다.
미래를 서비스하기
내가 보기에 DAML-S의 근간을 이루는 아이디어를 비롯해 이와 유사한 아이디어는 WSDL에 의해서 광범위하게 실현되었다. 이 덕분에 DAML-S는 "흥미로운 학구적인 호기심"의 범주로부터 "무언가 나의 도구모둠의 일부가 될 만한 것"으로 나아간다. 그렇지만 흥미롭게도, DAML-S에 웹 종속적인 부분은 그렇게 많지 않다. 이것을 나는 그의 또 다른 장점이라고 생각한다. 그래서 WSDL의 바탕이 가장 중요한 것이라고 증명된다고 할지라도, 아직 Perl, Python, Lisp, Smalltalk 등등의 고수준 프로그래밍 언어에 기반한 기본토대가 있을 수 없다고 생각할 이유를 찾지 못했다. 그리고 상황이 그렇다면, DAML-S가 가지는 장점들을 웹 서비스에 적용하여 이러한 언어들로 당연히 컴포넌트 프로그래밍을 할 수 있을 것이다. 예를 들어 올바른 기반구조를 가지고 있다면 DAML-S를 사용하여 웹 서버 플러그인을 기술할 수 있으며 사람들에게 이러한 플러그인들의 상호운용성과, 관제, 작성, 검증, 요청, 발견하도록 하는 것이 가능한 것 같다. XML-RPC가 인트라-컴포넌트 서버 프로토콜로 아주 효과적으로 사용되고 있는 세계라면, DAML-S의 크랙이 넘쳐나는 CPAN이나 아파치(Apache) 모듈 저장고에 관해서 고려해 보면 재미있을 것이다.
DAML-S가 증명한 한가지 사실은 거의 모든 통속 소설에서 그런 것처럼, 알고보니 "서비스 대 의미구조" 논쟁이 커다란 거짓말이라는 것이다. 자 좋다, 거짓말이 아닐 수도 있지만 그 논쟁은 아주 엄밀하지도 않고 별로 교훈을 주지도 않는다. 우리는 그것에 관해 믿는 것을 그리고 그것을 놓고 다투는 것을 관두는 편이 좋을 것이다. 비록 우리가 그것을 대체할 만큼 극적으로 또는 완전하게 또 다른 이야기를 가지고 있지는 않지만, 우리 개발자들은 최선을 다해 그러한 이야기 없이 살아가는 법을 배워야 할 것이다. 나는 웹의 미래가 오늘날과 조금만 다를 뿐 거의 똑같을 것이라고 예상한다. DAML-S와 같은 것들이 성공하기만 한다면 그 차이가 나는 부분을 우리는 마음에 들어하고 기뻐하게 될 것이다.
DAML-S 자원들
[1] 원래 철학에서 존재론(ontology)이라는 어휘에서 유래하는데, 존재론이란 한 존재를 둘러싸고 존재하는 이해관계에 대한 체계적인 지식을 의미한다. 이와 비슷하게 웹에서 개념규격(ontology)은 (한 프로그램에 대해 공식적으로 규격을 설명하는 것처럼) 한 중개자에 대하여 존재가 가능한 개념들과 그 관계들에 대한 설명이다 (Genesereth & Nilsson, 1987).
[2] IOPE로 나타냄.
[3] 추상적 클래스가 실체화되듯이 추상적 개념규격이 구체화되는 것을 의미.
그 동안의 생각이...
1년 반 전부터 지금까지 향후 웹이 나아갈 방향이 "웹 서비스(Web Services)"와 "의미구조 웹(Semantic Web)" 사이의 싸움으로 비쳐지기 시작했다. "웹 서비스(Web Services)"는 W3C와 학계(academia)에서 연유한 것으로 생각되었고, "의미구조 웹(Semantic Web)"은 IBM-마이크로소프트-썬을 비롯한 업계에서 기원하는 것으로 간주된다. "어떤 것(X)의 미래"를 둘러싼 그 모습에 대한 토론의 의미는 거의 전적으로 어떤 것(X)의 현재 가치에 달려있다. 웹의 미래에 관한 토론은 주로 현재의 웹이 너무 높은 평가를 받고 있어 종종 과열되므로 적당히 평가하기에는 너무 위험하다.
서비스와 의미구조 사이의 논쟁을 살펴보면 웹이 상업상 가치가 있는 것인지 아니면 그 내용상 가치가 있는 것인지로 웹을 흥미로운 곳으로 만드는 요인을 찾아볼 수 있다. 전통적으로 웹에서 서비스는 웹의 상업적 측면을 나타내는 반면, 의미구조는 그의 내용을 대표한다.
대부분의 경우 이러한 맥락의 가정과 관심은 그동안 간접적으로도 언급되지 않았다. 그렇지만 심리학자 프로이드라면 알았다고 할지라도 놀라진 않았을 것이란 예를 들어 은근히 이에 대해 언급하기도 하였다. 서비스를 지지하는 대중들에게, 이를 가장 전형적으로 보여주는 예는 복잡하지만 정확한 상업적 거래를 들 수 있다. 어떤 이유인지는 잘 모르겠지만 항공 좌석예약과 주식 시장이 그 예로 상당히 자주 인용된다. 반면 의미구조를 지지하는 대중에게 이를 가장 전형적으로 보여주는 예는 부담스러운 작업을 정확하게 처리하는 일종의 중개자나 자율 처리과정이다. 자주 인용되는 예 하나는 회합을 갖기를 원하는 대단히 바쁜 어떤 집단에게 일정 조정을 자동으로 고지하는 것이다(그리고, 우리는 이것을 아주 중요하게 생각한다).
...가끔 틀리기도 한다
전통적이라 여겨졌던 사실이 틀렸다는 것은 시간이 지나자 명백해졌다. 그러나 나는 실제로 "서비스 대 의미구조"가 도대체 어떻게 다른지 이해하지 못했다. DAML-S에 익숙해지기 시작하기 전까지는 말이다. DAML-S(현재 버전은 0.6)는 현재 DAML+OIL 위에 구축되고 있는 웹 서비스의 개념규격(ontology)[1]이다. (이 서비스는 W3C의 프로젝트인 WebOnt 안으로 구체화되고 있는 중이다). 그 아이디어는 웹 자원의 고수준 존재가 아주 유용한 것일 수 있고, 한 마디로 말해(here"s the kicker), 웹 서비스는 그냥 일종의 웹 자원이라는 것이다. 웹 서비스란, DAML 서비스 연합(DAML Services Coalition)이 기술하듯이, "예를 들어 제품의 판매나 물리적인 장치의 통제와 같은, 세계에 변경이나 어떤 행위의 효력을 미치도록 허용하는" 웹 자원이다 ("DAML-S: 웹 서비스를 위한 의미구조적 마크업(Semantic Markup For Web Services)").
그래서 DAML-S는 관례적인 지혜를 최대한 겸손하게 반박한다. "대(versus)"라는 것만이 유일하게 "의미구조(semantics)"와 "서비스(services)"를 연결하는 방법은 아니라는 것이다. 만약 DAML-S가 기껏해야 상상속의 실험일 뿐이라면, 이미 웹의 미래를 바라볼 수 있는 흥미로운 대안적인 방법을 제공하였을 것이다. 그러나 DAML-S는 상상속의 실험 그 이상이다.
왜 DAML-S인가?
첫 번째로 DAML-S에 대하여 이해해야 할 것은 이것이 고수준(high-level) 존재로서 애플리케이션 수준 위에 올라앉아서 웹 서비스의 무엇(what)에 대한 질문과 왜(why)에 대한 질문들에 대하여 응답을 한다는 것을 의미한다. WSDL의 주 영역인 어떻게(how)-질문과 대조적으로 말이다(자세한 것은 리치 살쯔(Rich Salz)의 탁월한 기사 "Examining WSDL" 참조). 더 자세한 것은 아래에 기술하겠다. 웹 서비스의 어떻게(how)-질문에 대하여 머신이 소화할만한 답변을 가진다는 가치는 이제 XML.com 독자라면 분명히 알고 있을 것이다. 그러나 무엇(what)-질문과 왜(why)-질문에 대하여 머신이 소화가능한 답변을 어떻게 처리할 것인가?
DAML-S를 만들어 내려고 하는 동기에는 발견(discovery), 요청(invocation), 상호운용(interoperation), 합성(composition), 검증(verification), 관제(monitoring)가 포함된다. "의미구조(semantic)"라고 라벨이 붙은 어떤 웹 테크놀러지도 실제적인 금전적 가치를 지니려면 웹이 최종 사용자로부터의 애매하거나 심지어 비밀스럽기도 한 입력에 반응하여 상대적으로 유용한 어떤 것을 제공하여야 하는 것이다. 최종 사용자가 "항공 좌석예매"를 자율적인 웹 중개자에 입력하면, 예를 들어 그 최종 사용자를 비행기 노선 예매를 하도록 안내할 웹 서비스의 시작점이 반드시 그 출력결과 중에 있어야 한다.
그런 종류 그리고 다른 종류로 최종 사용자가 미치는 영향력을 지원하려면, 똑똑한 서비스 발견(smart service discovery)이 필요하다. 중개자가 제약조건의 모둠을 만족하는 웹 서비스를 찾도록 프로그램을 할 수 있어야 한다. 그러나 똑똑한 발견 (smart discovery)은 똑같이 똑똑한 요청(smart invocation)이 없다면 아무 쓸모가 없다. 중개자가 예약을 할 수 있는 방법을 찾아 냈지만, 그 처리과정에 요청을 할 수 없다면, 최종 사용자는 몹시 실망할 것이기 때문이다. 중개자가 항공 좌석예매 서비스를 찾아내서 거기에 요청한 후에도, 최종 사용자에게 각 단계에서 요긴한 피드백을 제공하고 문제 발생시나 실패했을 때 우아하게 원래대로 복구하여 줌으로써 그 처리과정을 통제할 수 없다면, 최종 사용자는 똑같이 실망할 것이다. 이 때문에 발견 그리고 요청과 더불어 똑같이 똑똑한 실행 관제(smart execution monitoring)도 역시 필요하다.
개발자와 최종사용자는 똑같이, 서로 다른 방식으로 그리고 서로 다른 이유로, 간단한 웹 서비스로부터 복잡한 웹 서비스를 구축하고 싶어할 수도 있지만, 이는 머신이 소화할 수 있는 기술, 무엇보다도 입력, 출력, 선조건, 더 간단한 서비스 영향력에 관한 기술을 확보하지 않는 한 그 때까지는 불가능한 일이다. 지능적으로 서비스들을 조합하려면 전제 조건으로 그 서비스들이 상호운용되어야 하며, 특히 자동으로 변환되거나 클라이언트와 서비스 사이에 맵핑이 이루어져야 한다. 마지막으로, 발견이 제대로 작동하려면, 서비스의 특성들은 반드시 머신 확인할 수 있어야 한다. 서비스의 특성 중 한 가지 기능은 한 서비스가 적절한 제약 조건 모둠을 만족하는가 아닌가를 확인하는 것이다.
물론 앞의 내용 중에는 어떤 것은 마치 공상과학 소설처럼 들리지만, 중개자 이론과 다른 분야의 컴퓨터 과학에서 엄격한 연구로 지지를 얻고 있다. 세속적으로 DAML-S를 이해하려면 그것을 자율적인 중개자 이론과 XML-RDF, WSDL-SOAP의 결합으로 생각하는 것이다.
by Kendall Grant Clark
|
참고 도서 XML in a Nutshell, 2nd Edition |
DAML-S에는 무엇이 포함되어 있는가?
DAML-S에는 이미 많은 것이 있으며 앞으로 더 많은 것들이 추가될 것이다. 그 모든 것을 기술할 수는 없다. 범위를 좁힐수록 더 자세하게 기술할 수 있다. 남아 있는 것 중에서, 지적하고 싶은 것이 있다면 DAML-S는 엄청나게 크다는 것이며 추가로 필요한 정보는 소스(sources)를 가리켜 주겠다.
Service Profiles, Models, 그리고 Groundings
서비스 존재구조의 최상부는 Service 클래스를 감싸고 있다. Service는 일종의 웹 자원이다. 사람들은 Service에 대해 적어도 세 가지 사실은 알아 두어야 한다. Service가 하는 일, Service가 움직이는 방법, 그리고 Service에 접근하는 방법이 바로 그 세 가지이다. 이러한 질문에 상응하여 각각, DAML-S는 ServiceProfile, ServiceModel, ServiceGrounding과 같은 세 가지 클래스를 제공한다. DAML-S는 세 가지 특성으로 presents, describedBy, supports을 선언하는데, 이들은 각각 이러한 세 가지 클래스들을 자신들의 범위로 가진다. 추상적으로 살펴 보면, DAML-S를 사용하면 머신-소화가능한 형태로 Service가 ServiceProfile을 표현하고(presents), ServiceModel에 의해서 기술되며(describedBy), 그리고 ServiceGrounding을 지원하도록(supports) 선언할 수 있다. 실제로 Service의 자손 클래스들은 ServiceProfile, ServiceModel, ServiceGrounding의 자손 클래스들에 각각 상응하게 될 것이다.
프로세스 모델(Process Models)
서비스가 어떻게 작동할지 선언하거나 기술하려고 한다면, 반드시 처리방법, 행위, 그리고 실행 모드에 관하여 말해줄 방법이 있어야 한다. 그래서 DAML-S는 처리부라는 것을 제공하는데, ProcessModel 클래스인 ServiceModel의 자손 클래스에 의해서 모델링 되며, 이것은 처리 개념규격(ontology)과 처리 통제 개념규격(ontology)으로 구성된다. 앞의 것으로 입력, 출력, 선조건, 그리고 서비스의 효과를 기술할 수 있다. 뒤의 것으로 처리의 상황을 기술할 수 있는데, 여기에는 요청하는 법, 실행 경로, 완성 조건이 포함된다. DAML-S에는 또한 간단한 자원 개념규격(ontology)와 시간 개념규격(ontology)이 포함되어 있다.
Process 클래스는 DAML-S의 처리 개념규격(ontology)의 기본 요소이다. Process는 입력(inputs), 출력(outputs), 선조건(preconditions), 그리고 효과(effects)를 가질 수 있다.[2]DAML-S에서 Process는 세 가지 종류로 분할된다. AtomicProcess는 요청 시간에 모든 입력을 취해서 실행하고, 완성시간에 모든 결과를 반환하는데, 이것은 반드시 ServiceGrounding의 실체 하나를 가져야 한다. CompositeProcess는 원자적이거나 혹은 다른 조합 처리과정으로 구성되는 처리과정으로서, 여러 DAML-S 제어 구조를 사용하는 각 구성 부분들로 분해할 수 있다(Sequence, Concurrent, Split, Split+Join, Unordered, Choice, If-Then-Else, Repeat-Until, Repeat-While). 여기에서 SimpleProcess는 대안적으로 AtomicProcess를 볼 수 있게 해주고 CompositeProcess의 추상층을 제공하는 추상화 처리과정이다. 그리고 이것은 AtomicProcess에 의해서 실현(realizedBy)되거나, 또는 CompositeProcess로 연장(expands) 된다.
DAML-S, WSDL, 그리고 "진짜 세계"
물론, 결국 이 모든 개념규격의 선언과 고-수준의 분류는 실제로 작동하는 코드로 실현되어야 한다. DAML-S는 이것을 "구체화(grounding)"[3]라고 부르는데, DAML-S에서 ServiceGrounding 클래스로 표현된다. DAML-S의 ServiceModel과 ServiceProfile 부분은 이런 구체적인 서비스를 추상적으로 표현한 것이다. 그리고 이 두 개를 하나로 묶는 것은 ServiceGrounding이다. 특히 흥미로운 사실은 DAML-S의 ServiceGrounding과 WSDL 사이의 관계이다. DAML-S의 골격구조(architects)에서 DAML-S와 WSDL 사이를 연결하는 여러 중요한 경로가 발견된다. 먼저 DAML-S가 실현(grounding)으로 개념화한 것은 WSDL이 이해하는 바인딩(binding)에 깔끔하게 상응한다. 둘째, AtomicProcess의 여러 부분이 WSDL의 연산처리에 상응한다(다시 말해 AtomicResponse의 변형들은 각각 WSDL 연산처리의 변형인 요구-응답(request-response), 일방(one-way), 고지(notification), 그리고 간청-응답(solicit-response)에 상응). 셋째, XML 스키마에 지정된 WSDL의 추상적 형은 DAML-S의 입력과 출력 서비스 선언과 겹쳐지는데, 이는 기술-로직인 DAML+OIL 클래스로 지정할 수 있다.
미래를 서비스하기
내가 보기에 DAML-S의 근간을 이루는 아이디어를 비롯해 이와 유사한 아이디어는 WSDL에 의해서 광범위하게 실현되었다. 이 덕분에 DAML-S는 "흥미로운 학구적인 호기심"의 범주로부터 "무언가 나의 도구모둠의 일부가 될 만한 것"으로 나아간다. 그렇지만 흥미롭게도, DAML-S에 웹 종속적인 부분은 그렇게 많지 않다. 이것을 나는 그의 또 다른 장점이라고 생각한다. 그래서 WSDL의 바탕이 가장 중요한 것이라고 증명된다고 할지라도, 아직 Perl, Python, Lisp, Smalltalk 등등의 고수준 프로그래밍 언어에 기반한 기본토대가 있을 수 없다고 생각할 이유를 찾지 못했다. 그리고 상황이 그렇다면, DAML-S가 가지는 장점들을 웹 서비스에 적용하여 이러한 언어들로 당연히 컴포넌트 프로그래밍을 할 수 있을 것이다. 예를 들어 올바른 기반구조를 가지고 있다면 DAML-S를 사용하여 웹 서버 플러그인을 기술할 수 있으며 사람들에게 이러한 플러그인들의 상호운용성과, 관제, 작성, 검증, 요청, 발견하도록 하는 것이 가능한 것 같다. XML-RPC가 인트라-컴포넌트 서버 프로토콜로 아주 효과적으로 사용되고 있는 세계라면, DAML-S의 크랙이 넘쳐나는 CPAN이나 아파치(Apache) 모듈 저장고에 관해서 고려해 보면 재미있을 것이다.
DAML-S가 증명한 한가지 사실은 거의 모든 통속 소설에서 그런 것처럼, 알고보니 "서비스 대 의미구조" 논쟁이 커다란 거짓말이라는 것이다. 자 좋다, 거짓말이 아닐 수도 있지만 그 논쟁은 아주 엄밀하지도 않고 별로 교훈을 주지도 않는다. 우리는 그것에 관해 믿는 것을 그리고 그것을 놓고 다투는 것을 관두는 편이 좋을 것이다. 비록 우리가 그것을 대체할 만큼 극적으로 또는 완전하게 또 다른 이야기를 가지고 있지는 않지만, 우리 개발자들은 최선을 다해 그러한 이야기 없이 살아가는 법을 배워야 할 것이다. 나는 웹의 미래가 오늘날과 조금만 다를 뿐 거의 똑같을 것이라고 예상한다. DAML-S와 같은 것들이 성공하기만 한다면 그 차이가 나는 부분을 우리는 마음에 들어하고 기뻐하게 될 것이다.
DAML-S 자원들
- DAML-S 사이트
- W3C의 웹 서비스 리스트: DAML-S는 여기에서 자주 논의되는 주제이다.
- DAML-S의 구성요소들:
[1] 원래 철학에서 존재론(ontology)이라는 어휘에서 유래하는데, 존재론이란 한 존재를 둘러싸고 존재하는 이해관계에 대한 체계적인 지식을 의미한다. 이와 비슷하게 웹에서 개념규격(ontology)은 (한 프로그램에 대해 공식적으로 규격을 설명하는 것처럼) 한 중개자에 대하여 존재가 가능한 개념들과 그 관계들에 대한 설명이다 (Genesereth & Nilsson, 1987).
[2] IOPE로 나타냄.
[3] 추상적 클래스가 실체화되듯이 추상적 개념규격이 구체화되는 것을 의미.
TAG :
이전 글 : "PetStore Revisited"(J2EE와 .NET 어플리케이션 서버 성능 벤치마크 테스트)에 관한 다른 견해
다음 글 : 자바로 FTP 클라이언트 프로그램 작성하기
최신 콘텐츠