Embed Size (px)
Citation preview
NCA Ⅳ-RER-03077 / 2003. 12
지능형 웹 서비스 표 기술 동향
국내 도입 방안 연구
A Study on Technological Trend of Semantic
Web Services and Adoption Strategy
2003. 12.
80
지능형 웹 서비스 표 기술 동향
국내 도입 방안 연구
A Study on Technological Trend of Semantic
Web Services and Adoption Strategy
2003. 12.
序 文
고속 네트워크와 인터넷 서비스의 발달로 정보화 사회에서는 수
없이 많은 정보들이 존재하게 되었고, 이러한 환경 속에서 필요한 정보를
찾아서 히 활용하는 것은 매우 요한 기술로 인식되고 있습니다. 특히,
개방형 환경에서 사용자의 요청에 따라 필요한 작업을 수행한 후 그 결과를
제공하는 웹 서비스는 웹 환경에서 필요한 정보를 제공할 뿐만 아니라 기존
의 컴포 트 기술의 폐쇄성을 지양한 진일보한 기술로 평가받고 있습니다.
나아가, 웹 서비스는 정 인 문서로 가득 차 있던 웹을 실시간으로 상호운
이 가능한 소 트웨어 컴포 트들의 방 한 도서 으로 변화시킬 수 있는
원동력을 가지고 있습니다.
그럼에도 불구하고 재의 웹 서비스 근방법은 이상 으로 생각되는
완 한 상호운 성과 자동화를 기 하기는 어려우며, 이에 한 안으로서
웹 서비스 기술에 시맨틱 웹 기술을 목시켜 지능형 웹 서비스 혹은 시맨
틱 웹 서비스라는 안이 제시되고 있습니다. 그러나 표 언어, 조합 언어
수 에서의 표 화뿐만 아니라 자동 웹 서비스 검색, 자동 웹 서비스 조합
계획, 자동 감시 복구, 그리고 보안 등 지능형 웹 서비스 련 표 은 아
직 수많은 해결해야할 과제들을 안고 있는 것이 한 사실입니다.
본 연구에서는 지능형 웹 서비스의 반 개념과 아키텍쳐, 지능형 웹
서비스의 기반기술, 지능형 웹 서비스 구 을 한 아키텍쳐, 지능형 웹 서
비스에 한 최신 연구 동향, 지능형 웹 서비스에 한 국내에서의 응 방
향과 기술 도입 방안을 살펴보았습니다. 본 연구결과가 지능형 웹 서비스
기술의 수용을 한 참고자료로서 활용되고, 나아가 정보화 사업에의 용
과 도입에 도움이 되기를 바랍니다.
2003년 12월 31일
한 국 산 원
원 장 서 삼
제 출 문
정보통신부장 귀하
본 보고서를 웹 응용기술 표 화 연구 사업 “지능형 웹 서비스 표 기술
동향 국내 도입 방안 연구” 과제의 최종 연구보고서로 제출합니다.
2003년 12월
주 연구기 : 한국 산원
연구 책임자 : 한국 산원 허정회 (정보화표 장)
참여 연구원 : 한국 산원 김은주 (정보화표 )
북 학교 김우주 (산업정보시스템공학과)
연세 학교 송용욱 (경 정보공학 공)
배재 학교 이병엽 ( 자상거래학부)
- i -
요 약 문
1. 제목
지능형 웹 서비스 표 기술 동향 국내 도입 방안 연구
2. 연구개발의 목 요성
인터넷 환경과 WWW(World Wide Web) 기술의 발달로, 정보화
사회에서는 구든 웹 라우 를 통하여 통제할 수 없을 정도로 수많은 정
보들을 근하고 이용할 수 있게 되었다. 이러한 변화에도 불구하고 웹은
아직은 HTML을 기반으로 하는 인간 심의 환경을 구축하고 있는 것이다.
이러한 상황은 필연 으로 두 가지 발명의 필요성을 발생시키게 되었는데
첫째는 바로 인간의 처리 능력이상으로 존재하는 웹상의 정보에 한 인간
의 욕구를 인간 신 컴퓨터가 처리해주었으면 하는 필요성이며, 둘째는
개방 환경인 웹상으로 이 되고 있는 서비스 역시 인간의 간섭 없이
컴퓨터 간에 서로 서비스를 요청하고 이용할 수 환경의 필요성이다.
첫 번째 필요성은 재의 Tim Berners Lee에 의해 주창된 시맨틱 웹
(Semantic Web)이라는 근 방법으로서 해결하고자 하고 있으며, 두 번째
필요성의 안으로서는 W3C, OASIS, WS-I(Web Service Interoperability)등
에 의해 표 화되고 있는 웹 서비스(Web Service) 근 방법이라 하겠다.
재의 이와 같은 시맨틱 웹과 웹 서비스의 큰 흐름은 다시 하나의 더
도 인 필요성을 낳게 되었다. 웹 서비스의 발 단계에서 산 한 문제
들이 도출되고 있으며 이러한 문제 들의 해답으로서 시맨틱 웹과 웹 서비
스 기술의 통합 이 제시되고 있는 것이다. 이러한 분야를 우리는 지
능형 웹 서비스(Intelligent Web Service)라 명명하고자 하며, Semantic Web
Service, Advanced Web Service, DAML-enabled Web Service, Semantic
Web-Enabled Web Service 등의 많은 통일되지 않은 다른 이름들로도 불려
지고 있다.
- ii -
3. 연구개발의 내용 범
지능형 웹 서비스는 에이 트 기술을 기반으로 보다 실 인 기업간,
부서간, 나아가 모든 독립 단 들 간의 업무 연계 구 을 웹을 통하여
보다 높은 자동화 수 에서 해결하고 구체 으로 실 하고자 하는 주제로서
그 표 과 실 안이 마련된다면 그 효과는 기업을 넘어 국가
견지에서도 매우 크다 할 수 있다. 본 보고서에서는 지능형 웹 서비스 기술
표 동향 조사 국내 도입 방안 도출을 목 으로 지능형 웹 서비스 기술
에 한 국제 인 연구 개발 추세 활용 사례를 분석하고, 이를 토 로
국내 정부 산업계에서의 지능형 웹 서비스를 도입하고 활용하는 방안과
략 제시하고자 한다.
본 보고서의 주요 내용은 다음과 같다.
□ 지능형 웹 서비스의 개요
□ 지능형 웹 서비스 구 을 한 기반 기술
□ 지능형 웹 서비스 구축을 한 아키텍쳐
□ 해외 선진국에서의 지능형 웹 서비스에 한 연구 사례의 분석 비교
□ 지능형 웹 서비스 기술의 국내 도입 략
4. 연구결과
4.1 지능형 웹 서비스 구 을 한 기반 기술
지능형 웹 서비스 구 을 해 필요한 재의 기술을 살펴보고 표 화
황을 기술한다.
- 시맨틱 웹 기반 기술
. DAML+OIL: DARPA Agent Markup Language
+ Ontology representation and Inference Language
. OWL: Web Ontology Language
- iii -
- 웹 서비스 기반 기술
. SOAP: Simple Object Access Protocol
. WSDL: Web Services Description Language
. UDDI: Repository for Universal Description,
Discovery and Integration
- 시맨틱 웹 서비스 기반 기술
. DAML-S: a DARPA Agent Markup Languages for Services
. SWMF: Web Service Modeling Framework
4.2 지능형 웹 서비스 구축을 한 아키텍쳐
시맨틱 웹 서비스는 자동화된 웹 서비스 찾기, 선택, 실행을 일련의 비즈
니스 로직에 근거하여 실행할 수 있는 기반구조이다. 이 장에서는 이를 지
원하기 한 시맨틱 웹 서비스 아키텍쳐 기반기술과 련하여 기술한다.
본 보고서에서 제시하는 아키텍쳐에 한 설명을 개하기 해 아래의
세 가지 내용을 차례 로 제시할 것이다.
- 아키텍쳐 요구사항
- 시맨틱 웹 서비스 모델링 임워크 제시
- 시맨틱 웹 서비스 개념 아키텍쳐 제시
4.3 해외 선진국에서의 지능형 웹 서비스에 한 연구 사례의 분석 비교
지능형 웹 서비스의 여러 기능 웹 서비스에 한 지능형 검색에 련
된 최신 연구 결과들을 살펴 으로써 재 이 분야의 State of the Art를 알
아보고 그 표 화 방향과 국내에서의 응 방안 도출에 기반을 제공한다.
- iv -
- 지능형 웹 서비스 검색 서비스 연구 사례
.CMU의 ATLAS 로젝트
.MIT의 Process Ontology 기반 서비스 검색
- 에이 트 기반 지능형 웹 서비스 컴포지션 (Composition) 연구 사례
.DAML-Enabled Web Services Research Project
- 개인화된 지능형 웹 서비스 연구 사례
4.4 지능형 웹 서비스 기술의 국내 도입 략
지능형 웹 서비스의 국내 도입 략을 도출한다. 이를 하여 먼 지능
형 웹 서비스 도입 략 분석 틀을 마련한 후 이를 바탕으로 민간부문
공공부문에서의 지능형 웹 서비스 도입 략을 분석하고 수립한다. 각 부문
의 구체 인 조직들의 도입 략 분석은 별도의 개별 연구에 맡기고 본 연
구에서는 부문별 일반 략의 도출에만 을 맞추도록 한다.
- 지능형 웹 서비스 도입 략 분석 틀
- 민간부문 지능형 웹 서비스 도입 략
- 공공부문 지능형 웹 서비스 도입 략
5. 기 효과
기 효과로서는 정부 산업계의 정보화 담당자가 지능형 웹 서비스 기
술 표 에 한 동향을 정확히 악하며, 다가올 미래 웹 기반 기술 표 에
해 최 의 응을 할 수 있는 기반을 제공하며, 선발 선진국의 최신 지능형
웹 서비스 기술을 확보하고 나아가 고유한 부가가치 서비스를 개발을 유도함
으로써 정보통신 산업의 외 경쟁력 제고에 기여를 목표로 하고 있다.
- v -
SUMMARY
As the Internet and World Wide Web(WWW) advance, almost all
people in the current information society have to access and make use of
enormously uncontrollable information through Web Browsers. In spite of
its advancement, Web is still based on human-centered environment
using HTML. This situation inevitably leads to two sorts of necessity:
one is the necessity for the computer to process on behalf of a human
enormous information on the Web of which amount is over the
processing capability of the human, and the other is the necessity for the
Web services to inquire and use each other without the human
intervention on the Web environment of which openness is growing
more and more.
Current main stream of the necessity for Semantic Web and Web
Services leads to another more challengeable necessity of Web-based
information technology. Lots of problems are exposed as the Web
services are advanced, and the integration of Semantic Web and Web
Services are suggested as a solution for the problems. We name the
integration technology as Intelligent Web Services, and the technology
also has lots of unstandardized synonyms such as Semantic Web
Services, Advanced Web Services, DAML-enabled Web Services, and
Semantic Web-Enabled Web Services.
Intelligent Web Services, based on agent technology, focus their topic
on resolution and implementation of the problem to connect services of
actual enterprises, departments, and even all the independent
organizational units to each other by using Web and on the more
automatic level. So, if it can be standardized and implemented actually,
- vi -
its effect on industry and even on national economy will be very large.
In this report on Intelligent Web Services, of which objectives are
examination of existing Intelligent Web Services technologies and
standards, and strategic design for the introduction of the technologies
into Korean industry, we analyze the research and development trends
and application cases of foreign countries, and, based on this analysis,
suggest a strategic plan for Korean government and industry to
introduce and make use of the Intelligent Web Services.
Main contents of this report are as following:
□ Introduction of Semantic Web Services technology
□ Analysis of Intelligent Web Services infra-technology
□ Analysis of Intelligent Web Services architecture
□ Comparative study on researches for the Intelligent Web Services
in advanced foreign countries
□ Strategy for the introduction of Intelligent Web Services into
Korean industry
- vii -
CONTENTS
Chapter 1 Introduction ····························································································1
Chapter 2 Intelligent Web Service ····································································3
2.1 Introduction ····································································································3
2.2 Framework ····································································································11
2.3 Standard ········································································································12
Chapter 3 Analysis of Intelligent Web Service Infra-technology ············13
3.1 Semantic Web Technology ········································································13
3.2 Web Service Technology ···········································································25
3.3 Semantic Web Service Technology ·························································28
Chapter 4 Architecture for Intelligent Web Service ····································73
4.1 Introduction ··································································································73
4.2 Requirements ································································································74
4.3 Semantic Web Service Modeling Framework ······································76
4.4 Semantic Web Service Concept Architecture ·······································77
Chapter 5 Case Study ····························································································82
5.1 Case Of Intelligent Web Service Search Service ································82
5.2 Case Of Software Agent-based Web Service Composition ············101
5.3 Case Of Personalized Web Service ······················································108
- viii -
Chapter 6 Introduction Strategy of Korean Industry ································110
6.1 Introduction Strategy for Technology ··················································110
6.2 Strategy ········································································································112
Chapter 7 Conclusion ··························································································126
References ················································································································128
- ix -
List of Figures
<Figure 2-1> Web Service Concept ······································································5
<Figure 2-2> Microsoft UDDI Version 3.0 Beta Service ·······························6
<Figure 2-3> Intelligent Web Service Framework ···········································11
<Figure 3-1> Logical Layer of Semantic Web ·················································14
<Figure 3-2> 3-layer of Semantic Web ······························································14
<Figure 3-3> DAML-S over Semantic Web ······················································28
<Figure 3-4> Flow Diagram of Semantic Web ················································30
<Figure 3-5> DAML-S Structure ··········································································31
<Figure 3-6> Process Type and Relationship ···················································38
<Figure 3-7> Grounding Fundamental Diagram ·············································46
<Figure 4-1> Web Service Stack and Semantic Expression ··························74
<Figure 4-2> Semantic Web Service Conceptual Architecture ·····················77
<Figure 4-3> Example of Semantic Web Service Architecture ····················81
<Figure 5-1> Upper Ontology about Service Profile ·····································85
<Figure 5-2> Example of Request Profile ·························································86
<Figure 5-3> Main Control Function of Matching Algorithm ·····················87
<Figure 5-4> Matching Algorithm of Output ··················································88
<Figure 5-5> Decision Rule of Matching Level ··············································88
<Figure 5-6> Ontology Example about Car ·····················································88
<Figure 5-7> Ranking Rule of Matching Level ···············································89
<Figure 5-8> Publication Example of Car ·························································90
<Figure 5-9> Ontology Example about Car ·····················································90
<Figure 5-10> Matchmaking Engine Structure of Semantic Match Maker ······92
<Figure 5-11> System Architecture of DAML-S/UDDI Semantic Matchmaker ·····94
<Figure 5-12> Performance Test of Process-based Service Search ·············95
<Figure 5-13> Functional Structure of Process-based Service Search ········96
- x -
<Figure 5-14> Process Model Organizational Form ·······································97
<Figure 5-15> Example of Process Model-based Service Model ·················98
<Figure 5-16> Example of Service Level Ontology ········································99
<Figure 5-17> Registrated Loaning Service Process Model ··························99
<Figure 5-18> Example of Mortgage Loaning Service Process Model ······99
<Figure 5-19> Semantic Web Service Framework (Stanford KSL) ···········102
<Figure 5-20> Example of ConGolog Program ·············································103
<Figure 5-21> Example of Agent of Web Service Coupling ·····················103
<Figure 5-22> RETSINA Planner-based Web Service Composition ··········105
<Figure 5-23> Example of Web Service Combination ·································107
<Figure 5-24> Example of Web Service Filtering ·········································108
<Figure 5-25> Architecture of Personalized Web Service ···························109
<Figure 6-1> Introduction Strategy for Information Web Service ············113
<Figure 6-2> SWOT Analysis of Korean Domestic Industry ·····················117
<Figure 6-3> Nolan's Growth Rate Model ·····················································120
<Figure 6-4> SWOT Analysis of Korean Public Service ·····························123
- xi -
List of Tables
<Table 3-1> Difference of DAML+OIL and OWL ··········································19
<Table 3-2> Service Profile Ontology ·································································33
<Table 3-3> Service Model Ontology ·································································38
<Table 3-4> Grounding Ontology ·······································································46
- xii -
목 차
제 1 장 서론 ···············································································································1
제 2 장 지능형 웹 서비스 ····················································································3
2.1 지능형 웹 서비스 개요 ·················································································3
2.2 지능형 웹 서비스 임워크 ···································································11
2.3 지능형 웹 서비스 표 화 동향 ·······························································12
제 3 장 지능형 웹 서비스 기반 기술 분석 ···················································13
3.1 시맨틱 웹 기반 기술 ···················································································13
3.2 웹 서비스 기반 기술 ···················································································25
3.3 시맨틱 웹 서비스 기반 기술 ·····································································28
제 4 장 지능형 웹 서비스를 한 아키텍쳐 분석 ······································73
4.1 개요 ·················································································································73
4.2 아키텍쳐 요구사항 ·······················································································74
4.3 Semantic Web Service Modeling Framework ······································76
4.4 Semantic Web Service Concept Architecture ·······································77
제 5 장 지능형 웹 서비스의 연구 사례 ·························································82
5.1 지능형 웹 서비스 검색 서비스 연구 사례 ·············································82
5.2 에이 트 기반 지능형 웹 서비스 컴포지션(Composition) 연구 사례 ····101
5.3 개인화된 지능형 웹 서비스 연구 사례 ·················································108
- xiii -
제 6 장 지능형 웹 서비스의 국내 도입 략 ···············································110
6.1 국내 응 방향 기술 도입 방안 ·······················································110
6.2 지능형 웹 서비스 도입 략 분석 ·························································112
제 7 장 결 론 ·········································································································126
참고문헌 ···················································································································128
- xiv -
그림 목차
<그림 2-1> 웹 서비스의 기본 구조 ········································································5
<그림 2-2> Microsoft의 UDDI Version 3.0 Beta Service ·······························6
<그림 2-3> 지능형 웹 서비스 임워크 ··························································11
<그림 3-1> 시맨틱 웹 논리계층 ············································································14
<그림 3-2> 시맨틱 웹의 3계층 ··············································································14
<그림 3-3> 시맨틱 웹 아키텍쳐상의 DAML-S ··················································28
<그림 3-4> 시맨틱 웹 서비스 흐름도 ··································································30
<그림 3-5> DAML-S의 구성요소 ··········································································31
<그림 3-6> Process의 형태와 상호 계 ······························································38
<그림 3-7> Grounding 개념도 ··············································································46
<그림 4-1> 웹 서비스 스택과 의미(Semantic) 표 ·········································74
<그림 4-2> Semantic Web Service Conceptual Architecture ························77
<그림 4-3> 시맨틱 웹 서비스 아키텍쳐 제 ····················································81
<그림 5-1> DAML-S에서의 Service Profile에 한 상 온톨로지 ·············85
<그림 5-2> 자동차 매 서비스에 한 요청 로 일 ····························86
<그림 5-3> 매칭 알고리즘의 메인 컨트롤 함수 ················································87
<그림 5-4> 출력 매칭 알고리즘 ············································································88
<그림 5-5> 항목 간의 매칭 수 결정 규칙 ······················································88
<그림 5-6> 자동차 련 온톨로지의 ······························································88
<그림 5-7> 매칭 수 에 기반 한 랭킹 규칙 ······················································89
<그림 5-8> 자동차 련 공시 서비스 ····························································90
<그림 5-9> 자동차 련 온톨로지 ··································································90
<그림 5-10> Semantic Match Maker의 Matchmaking Engine의 구조도 ······92
<그림 5-11> DAML-S/UDDI Semantic Matchmaker의 시스템 구조 ··········94
<그림 5-12> 로세스 기반 서비스 검색 방법론의 성능 평가 ······················95
<그림 5-13> 로세스 모델 기반 서비스 검색의 기능 구조도 ··················96
- xv -
<그림 5-14> 로세스 모델 구성 형식 ································································97
<그림 5-15> 로세스 모델을 기반으로 구성된 서비스 모델 ··················98
<그림 5-16> 서비스 계층 온톨로지 ································································99
<그림 5-17> 기 등록된 부 서비스 로세스 모델 ········································99
<그림 5-18> 수정을 통해 생성한 당 출 서비스 로세스 모델 ······99
<그림 5-19> 시맨틱 웹 서비스의 임워크 (스탠포드 KSL) ····················102
<그림 5-20> ConGolog 로그램의 ·····························································103
<그림 5-21> 웹 서비스 조합을 수행시키는 에이 트 제 화면 ················103
<그림 5-22> RETSINA Planner 기반의 웹 서비스 컴포지션 ······················105
<그림 5-23> 웹 서비스 조합기의 주 화면 ··················································107
<그림 5-24> 웹 서비스 필터링 시연 ····························································108
<그림 5-25> 개인화된 지능형 웹 서비스 구조 ················································109
<그림 6-1> 지능형 웹 서비스 도입 략 분석 차 ······································113
<그림 6-2> 지능형 웹 서비스에 한 국내 기업의 SWOT 분석 ················117
<그림 6-3> Nolan의 성장단계 모형 ···································································120
<그림 6-4> 지능형 웹 서비스에 한 우리나라 공공부문의 SWOT 분석 ····123
- xvi -
표 목차
<표 3-1> DAML+OIL과 OWL의 변경사항 ························································19
<표 3-2> Service Profile Ontology ······································································33
<표 3-3> Service Model Ontology ·······································································38
<표 3-4> Grounding Ontology ·············································································46
- 1 -
제 1 장 서론
인터넷 환경과 WWW(World Wide Web) 기술의 발달로, 정보화
사회에서는 구든 웹 라우 를 통하여 통제할 수 없을 정도로 수많은 정
보들을 근하고 이용할 수 있게 되었다. 이러한 변화에도 불구하고 웹은
아직은 HTML을 기반으로 하는 인간 심의 환경을 구축하고 있는 것이다.
이러한 상황은 필연 으로 두 가지 발명의 필요성을 발생시키게 되었는데
첫째는 바로 인간의 처리 능력이상으로 존재하는 웹상의 정보에 한 인간
의 욕구를 인간 신 컴퓨터가 처리해주었으면 하는 필요성이며, 둘째는
개방 환경인 웹상으로 이 되고 있는 서비스 역시 인간의 간섭 없이
컴퓨터 간에 서로 서비스를 요청하고 이용할 수 환경의 필요성이다.
첫 번째 필요성은 재의 Tim Berners Lee에 의해 주창된 시맨틱 웹
(Semantic Web)이라는 근 방법으로서 해결하고자 하고 있으며, 두 번째
필요성의 안으로서는 W3C, OASIS, WS-I(Web Service Interoperability)등
에 의해 표 화되고 있는 웹 서비스(Web Service) 근 방법이라 하겠다.
HTML을 기반으로 하는 재의 웹 기술은 하나의 표 과 인터넷이라는 공
개 기반 하에 구라도 정보를 제공하고 수집할 수 있는 거 한 정보 공
동 창고를 제공하 으나 정 (static)이며 한 인간 심 (human-oriented)
제한 을 가지고 있었다. 이제 시맨틱 웹은 이러한 기존의 웹에 의미
(semantics)를 부여함으로써 웹에서의 에이 트 즉 자율 컴퓨터 로그램
들이 보다 활발하게 사람을 신해서 정보의 수집을 비롯한 많은 분석
상행 활동까지도 할 수 있는 길을 보여주고 있으며 따라서 우리는 이를
에이 트 심 (agent-oriented) 방향이라고 말하고 싶다.
한편으로 웹 서비스는 클라이언트-서버 형식의 정 웹 구조를 보다
극 (active)이고 동 (dynamic)인 환경으로 바꿀 수 있는 환경을 제공함으
로써 인터넷을 통하여 정보의 흐름뿐만이 아니라 활동(action)의 흐름까지
가능하도록 만들고 있는 것이다. 기업 내부의 부서간, 기업간, 기업 개인
에이 트 간의 끊김 없는 업무가 인터넷을 바탕으로 이루어 질 수 있게 되
는 것이다.
재의 이와 같은 시맨틱 웹과 웹 서비스의 큰 흐름은 다시 하나의 더
- 2 -
도 인 필요성을 낳게 되었다. 웹 서비스의 발 단계에서 산 한 문제
들이 도출되고 있으며 이러한 문제 들의 해답으로서 시맨틱 웹과 웹 서비
스 기술의 통합 이 제시되고 있는 것이다. 이러한 분야를 우리는 지
능형 웹 서비스(Intelligent Web Service)라 명명하고자 하며, Semantic Web
Service, Advanced Web Service, DAML-enabled Web Service, Semantic
Web-Enabled Web Service 등의 많은 통일되지 않은 다른 이름들로도 불려
지고 있다.
지능형 웹 서비스는 에이 트 기술을 기반으로 보다 실 인 기업간,
부서간, 나아가 모든 독립 단 들 간의 업무 연계 구 을 웹을 통하여
보다 높은 자동화 수 에서 해결하고 구체 으로 실 하고자 하는 주제로서
그 표 과 실 안이 마련된다면 그 효과는 기업을 넘어 국가
견지에서도 매우 크다 할 수 있다. 본 보고서에서는 지능형 웹 서비스 기술
표 동향 조사 국내 도입 방안 도출을 목 으로 지능형 웹 서비스 기술
에 한 국제 인 연구 개발 추세 활용 사례를 분석하고, 이를 토 로
국내 정부 산업계에서의 지능형 웹 서비스를 도입하고 활용하는 방안과
략 제시하고자 한다.
그 기 효과로서는 정부 산업계의 정보화 담당자가 지능형 웹 서비
스 기술 표 에 한 동향을 정확히 악하며, 다가올 미래 웹 기반 기술
표 에 해 최 의 응을 할 수 있는 기반을 제공하며, 선발 선진국의 최
신 지능형 웹 서비스 기술을 확보하고 나아가 고유한 부가가치 서비스를 개
발을 유도함으로써 정보통신 산업의 외 경쟁력 제고에 기여를 목표로 하
고 있다.
이를 한 본 보고서의 구성은 다음과 같다. 제 2장에서는 지능형 웹 서
비스의 개요에 해 소개한다. 제 3장에서는 지능형 웹 서비스 구 을 한
기반 기술에 해 설명하며, 제 4장에서는 지능형 웹 서비스 구축을 한
아키텍쳐를 분석할 것이다. 제 5장에서는 해외 선진국에서의 지능형 웹 서
비스에 한 연구 사례를 분석 비교하며, 제 6장에서는 지능형 웹 서비스
기술의 국내 도입 략을 제안하고자 한다.
- 3 -
제 2 장 지능형 웹 서비스
2.1 지능형 웹 서비스 개요
본 에서는 지능형 웹 서비스의 개요를 설명하기에 앞서 재의 웹 서
비스 기술의 개요를 살펴보고, 이어 재 상태의 웹 서비스 기술의 문제
을 악하고자 한다. 마지막으로 이를 바탕으로 시맨틱 웹 기술이 어떻게
웹 서비스 기술과 목되어 악된 문제 들을 해결할 수 있는 지에 해서
설명함으로써 지능형 웹 서비스의 개요를 논하고자 한다.
2.1.1 웹 서비스 개요
웹 서비스는 랫폼 독립 으로 시스템 간의 연계, 통합 자원공유를
가능하게 하는 표 화된 XML 기반 웹 기술이다. 웹 서비스는 연계, 통합
뿐만 아니라, 서비스 지향 아키텍처(Service Oriented Architecture :
SOA)를 실 시키는 실 인 기술로서 주목받고 있다. 표 인 표 으로
는 SOAP(Simple Object Access Protocol), WSDL(Web Services Description
Language), UDDI(Universal Description, Discovery and Integration of
Business for Web) 등이 있으며, 이외에도 비즈니스 활용을 지원하기 한
상 표 들의 표 화 작업이 국제표 화 기구들(W3C, OASIS, WS-I 등)에서
활발하게 진행 에 있다.
웹 서비스는 그간 정보기술의 발 과정에서 많은 심을 모았던 분산처
리기술, 컴포 트기술, ASP(Application Service Provider), EAI(Enterprise
Application Integration), EDI(Electronic Data Interchange) 등의 기술이 만
나는 수렴하는 기술이다. 다시 말해, 이러한 정보 기술들이 출 하고 발
하고, 문제 에 직면하고, 쇠퇴하면서 지 되었던 문제 들을 극복한 진화
기술인 것이다. 이들 정보 기술들이 그간 발 하다가 그 성장이 멎거나 둔
화된 주된 원인은 기술 인 측면 이상으로 벤더들 간의 치열한 배타 경쟁
에 있었다. 웹 서비스가 오늘날 많은 심을 모으면서 발 하고 있는 이유
- 4 -
는 바로 이 기술이 벤더들 간의 합의에 의해서 폭 으로 지지받고 있으
며, 이 과정에서 국제 표 화기구를 통하여 착실하게 표 을 생성해 가고
있기 때문이다.
웹 서비스의 활용 시나리오는 매우 다양하며 새로운 시나리오 혹은 비즈
니스 모델이 창출되어 가고 있다. 기업이나 조직은 웹 서비스를 내부 인
자원의 통합 연계에 활용할 수 있으며, 한 외 인 통합 즉 기업과 기
업간, 정부와 기업간, 정부와 정부간의 업무 연계나 업에도 사용할 수 있다.
향후 웹 서비스의 응용 범 는 애 리 이션 간의 연계나 통합의 수 을 넘
어서, 인터넷을 통한 비즈니스 연계 업에 까지 확 될 것이며, 종국에
는 동 인 비즈니스 모델의 창출로까지 이어질 것으로 기 되고 있다.
웹 서비스는 발 하고 있는 기술이니만큼, 이에 해서는 다양한 정의와
해석들이 존재한다. 한 웹 서비스에 련된 표 화 작업은 활발하게 진행
에 있으며 이러한 표 들의 개발은 웹 서비스의 응용 분야를 더욱 다양하
게 확장시키고 있다. 특히 웹 서비스는 유비쿼터스 정보기술 환경이나 모바
일 환경 등 최근 많은 주목을 받고 있는 정보기술 분야를 지원하기 한 실
질 인 소 트웨어 기술로서도 주목받고 있다.
2.1.2 웹 서비스의 한계
재의 웹 서비스는 아래의 <그림 2-1>에 볼 수 있는 바와 같이 크게 웹
서비스의 제공자인 Service Provider, 웹 서비스 이용자인 Service Requester
와 웹 서비스에 한 정보 제공자로서의 Service Registry의 세 가지 역할이
필요하다. 먼 Service Provider는 재 표 으로는 WSDL을 이용하여 자
기 자신의 서비스 내역과 이용 방식을 공시하며, 자신의 서비스의 존재를
UDDI와 같은 Service Registry를 통하여 고하게 되는 것이다. 한편 서비
스 이용자인 Service Requester는 UDDI와 같은 Service Registry를 통해 필
요한 웹 서비스 제공자를 검색 발견하게 되며, 서비스 제공자의 WSDL을
분석함으로써 서비스를 실질 으로 호출하고 이용할 수 있게 되는 것이다.
- 5 -
<그림 2-1> 웹 서비스의 기본 구조
Find
Publish Bind
Description Client
Service
ServiceRegistry
ServiceProvider
ServiceRequesterFind
Publish Bind
Description Client
Service
ServiceRegistry
ServiceProvider
ServiceRequester
이와 같은 웹 서비스의 구조에서 발 단계로의 이동 경로 상에 도출
될 수 있는 문제 을 정리해 본다면 아래와 같다.
□ 재의 UDDI의 키워드 기반의 서비스 검색에서의 문제
키워드 기반 검색 부수 분류 체계 자체로는 웹 서비스가
제공하는 실질 서비스의 내용에 한 유효한 검색이 사람을
통해서도 매우 어려운 실정이다. <그림 2-2>의 UDDI 버 3.0의
베타 서비스 화면 를 통해서도 이를 확인할 수 있다.
에이 트를 기반으로 하는 로그램 자체가 실질 으로 필요한
웹 서비스를 UDDI에서 찾아낼 수 있기 해서는 에이 트 자신
이 필요한 기능을 기술하고, 한 이에 하여 가장 한 웹
서비스를 찾을 수 있는 즉 비교 검색될 수 있는 수 의 웹 서비
스 자체에 한 높은 수 에서의 기능 표 기법이 필요하나
UDDI는 이러한 수 에 미치고 있지 못하다.
UDDI와 구색을 이루고 있는 WSDL마 도 구문 (syntactic) 상호
운용성을 보장할 뿐 의미 상호 운 성을 보장하고 있지 못하다.
- 6 -
<그림 2-2> Microsoft의 UDDI Version 3.0 Beta Service
□ 단 웹 서비스 이용 심 구조에서의 문제
<그림 2-1>에서의 구조는 단 웹 서비스의 이용에 그 을
맞추고 있다. 반면 기업이나 일반 서비스에서는 단 서비스들의
조합과 구성을 통하여 보다 높은 수 의 부가가치 서비스를 제
공하는 경우가 비일비재하며, 특히 기업의 경우 내부 업무 로세
스는 본질 으로 여러 단 서비스들의 조합과 배치를 통해 이
루어짐으로써 구조만으로는 이러한 상황을 지원하는데 매우
취약하다.
- 7 -
□ 웹 서비스 조합 언어(Web Service Composition Language) 에서의 문제
이러한 단 웹 서비스 심 구조를 해결하기 해 복잡한 즉
메시지를 기반으로 한 단 웹 서비스들을 조합할 수 있는 웹
서비스 조합 언어 즉 Web Service Composition Language들이
등장하 다. 이들은 Microsoft에 의해 제안된 XLANG, IBM에 의해
제안된 WSFL (Web Service Flow Language), IBM과 Microsoft의 합
의에 의해 제안된 BPEL4WS (Business Process Execution Language
for Web Services), BEA Systems, Intalio, SAP AG 와 Sun
Microsystems 등에 의해 제안된 WSCI (Web Services Choreography
Interface) 등 표 웹 서비스 조합 언어 이외에도 PDL (Process
Definition Language), XPDL (XML Process Definition Language),
BPSS (Business Process Schema Specification), BPML (Business
Process Modeling Language), ebXML (Electronic Business Using
Extensible Markup Language) 등 다수의 웹 서비스 조합 언어로 분
류될 수 있는 수많은 표 들이 존재한다. 이러한 다수의 표 제안들
은 오히려 웹 서비스의 조합이 보다 효과 으로 수행될 수 있는 환경
을 방해하고 있으며, 지 시 히 통일된 하나의 표 을 얻는 것이 매
우 요하다.
나아가 재의 Web Service Composition Language들이 하나의 표
으로 통합된다 하더라도 재의 Web Service Composition
Language들은 단지 서비스들의 정 (static) 바인딩만을 지원할 뿐
명확한 의미 달 이해 체계를 갖추지 못하고 있다. 이는 사람들로
하여 많은 수작업과 의사 교환을 필요로 하게 만들며 에이 트 기
술을 바탕으로 한 자동화된 웹 서비스의 조합은 불가능한 상태인 것
이다.
2.1.3 지능형 웹 서비스 개요
지능형 웹 서비스는 웹 서비스의 정 이고 구문 근 방법의 문제 을
해결하고자 시맨틱 웹 에이 트 기술을 웹 서비스 기술에 목시키고자
- 8 -
하는 시도이다. 지능형 웹 서비스의 출발 은 DAML(DARPA Agent
Markup Language)에서 생된 DAML-S라는 웹 서비스의 역량과 성격을 명
료하고 컴퓨터 인식 가능한 형태로 기술할 수 있는 상 온톨로지(ontology)
를 제공하기 한 언어의 제안이라 할 수 있다. 이러한 DAML-S의 개발은
Stanford, SRI, CMU Nokia의 업으로 이루어졌으며, 많은 후속 연구들
이 이를 바탕으로 지능형 웹 서비스를 지향하여 이루어지고 있다.
표 으로는 유럽의 IST 로젝트의 일환으로 진행 인 SWWS
(Semantic Web Enabled Web Services)를 들 수 있으며, 궁극 인 목 으로
는 웹 서비스 표 , 웹 서비스 발견, 웹 서비스 재 미들웨어를 제공하
는 것으로 하고 있으며, 재의 성과로는 소 단 웹 서비스 복합 웹
서비스를 표 하고 개발할 수 있는 개념 모델을 지원하는 임워크로서
WSMF (Web Service Modelling Framework)를 제안하고 있다.
한편 DAML-S를 기반으로 하는 지능형 웹 서비스에서 제안하는 주요 기
능들을 정리해 본다면 다음과 같다.
자동 웹 서비스 발견 기능(Automatic Web Service Discovery)
자동 웹 서비스 발견 기능은 먼 특정한 서비스를 제공하고 요청한
제약을 만족하는 웹 서비스에 한 자동화된 포착 기능을 포함한다.
를 들어 한 사용자가 두 개의 주어진 도시 간을 이동하는 비행기표
를 특정 신용 카드를 이용하여 구매할 수 있는 서비스를 찾고 있다고
가정하자. 재는 이를 해서는 일련의 정보 수집 과정, 서비스 요청
과정 구매 의사 결정이 모두 사람의 수작업을 통해 이루어질 수밖
에 없는 실정이다. 따라서 이러한 과정의 자동화를 해서는 먼 필
요한 웹 서비스에 한 정보가 컴퓨터가 인식 가능한 형태로 표 되어
있어야 하며, 역시 온톨로지를 기반으로 사용자의 요구 사항을 서비스
의 역량과 정확히 비교 검색할 수 있는 서비스 검색 엔진이 필요하다.
자동 웹 서비스 호출(Automatic Web Service Invocation)
자동 웹 서비스 호출 기능은 컴퓨터 로그램이나 에이 트에 의해
인식된 웹 서비스를 자동으로 수행시키는 기능을 말한다. 를 들어
사용자가 특정 사이트로부터 특정 비행기 편에 한 표 구입을 요청
하고자 할 경우, 역시 재의 기술로는 사용자가 어떻게든 구매 과정
- 9 -
에 수작업으로 참여하여야만 한다. 이를 자동화하기 해서는 이러한
기능들을 수행시킬 수 있는 선언 이며(declarative), 컴퓨터 인식 가능
한 API를 제공할 수 있는 표 방법이 마련되어야 하며, 동시에 소
트웨어 에이 트는 서비스 요청을 해 필요한 정보가 무엇인지, 그
결과로 어떠한 정보가 획득되는지, 어떻게 서비스를 자동을 수행시킬
수 있는지에 해 표 된 정보를 이해할 수 있어야 하는 것이다.
자동 웹 서비스 조합 상호 운 기능(Automatic Web Service
Composition and Inter-operation)
이 기능은 사용자에 의해 주어진 임의의 목 에 한 상 수 의 표
에 해 그 목 을 달성하기 하여 일단의 과업들을 수행하기
하여 자동 으로 웹 서비스를 선택하고, 조합하며, 상호 운 시키는
기능을 말한다. 를 들어 사용자가 학회에 참석하기 해 필요한 모
든 여행 련 비를 하기를 원한다고 가정하자. 재는 사용자가 일
일이 필요한 웹 서비스들을 선택하고, 수작업으로 이들에 한 조합과
순서를 결정하여야 하며, 이들 웹 서비스간의 상호 운 에 필요한 임
의 소 트웨어도 직 마련하야야 하는 형편이다. 이를 해결하기 해
서는 웹 서비스의 선정과 조합에 필요한 정보들이 개별 서비스 사이
트에 의해 제공되어야 하며, 에이 트 소 트웨어는 이러한 정보를 해
석하고, 주어진 목 달성을 해 필요한 과업에의 정성을 단하여
자동 으로 목 을 달성할 수 있는 계획을 작성하고 실행할 수 있어
야 한다. 이를 해서는 개별 웹 서비스 실행을 한 제 조건과 그
실제 상황에서의 효과도 선언 으로 표 될 수 있어야만 하는
것이다.
자동 웹 서비스 실행 감시와 복구 기능(Automatic Web Service
Execution Monitoring and Recovery)
단 서비스 나아가 복합 서비스에서는 많은 경우 체 인 로세스
가 완 히 수행되었는지를 확인할 수 있어야 한다. 한 사용자들은
그들의 요청에 한 재 서비스 수행 상황을 서비스 종료 에 확인
하고자 하는 욕구가 있으며, 경우에 따라서는 재 에이 트에 의해
수행 인 로세스를 바꾸고자하는 경우도 있다. 를 들어, 호텔에
한 약을 하고자 했던 사용자는 그 약에 한 확인을 하고 싶어
- 10 -
할 지도 모르는 것이다. 이를 해서는 기 요청에 해 재 로세
스가 어디까지 진행 인지를 모니터링 할 수 있는 기능과 생각하지
못했던 오류가 발생했는지의 여부에 해 확인할 수 있는 능력이 필
요하다. 이러한 목 에 응하고자 하는 기능이 바로 자동 웹 서비스
실행 감시와 복구 기능인 것이다.
웹 서비스 개발 단계에서의 시뮬 이션과 검증 기능(Simulation and
Verification in Web Services Development Stage)
웹 서비스의 개발 생명주기 (Development Life Cycle) 측면에서 볼 때,
웹 서비스를 제공하고자하는 웹 서비스 제공자는 완벽하게 모든 서비
스의 컴포 트들을 모두 개발하는 것이 아니라 다른 웹 서비스들을 바
탕으로 새로운 부가 가치 서비스를 제공할 수도 있는 것이다. 이를
해서는 웹 서비스의 조합 기능 외에도 조합된 웹 서비스를 시뮬 이션
해보고, 결과를 검증하는 기능이 필요한 것이다. 앞에서의 기능들과는
달리 본 기능은 웹 서비스의 개발 단계에서 필요한 기능인 것이다.
에이 트 기반 개인화된 웹 서비스 기능(Agent-Based Personalized
Web Services)
웹 서비스의 검색(discovery), 호출(invocation), 조합(composition)
에 있어 사용자가 요구한 목 에 부가 으로 사용자의 상황(context)
정보와 로 일( , 선호 성향 등)을 바탕으로 다양한 웹 서비스 조
합 안들 보다 사용자에게 합한 서비스가 수행되도록 지원하는
아키텍쳐 기능을 의미한다. 특히 모바일(mobile) 환경이나 치 기
반 서비스의 경우 더욱 이와 같은 선도 인 기능은 부가 가치를 높일
수 있을 것으로 기 된다.
이상에서의 기능들 시맨틱 웹 분야에서도 Semantic Web Service
Discovery와 Semantic Web Service Choreography는 매우 요한 응용 분
야로 인식하고 있다(TopQuadrant Technology Briefing about Semantic
Technology, September 2003). 이제 다음 에서는 이와 같은 기능들을 심으로
지능형 웹 서비스의 구조 측면을 조망해 보고자 한다.
- 11 -
2.2 지능형 웹 서비스 임워크
<그림 2-3> 지능형 웹 서비스 임워크
Locating atWeb services
Selection ofWeb services
Interaction withWeb services
Composition ofWeb services
Monitoring ofWeb services
Agent Technology(Planning)
Request, Confirm,and Modification
Initial and ReactiveComposition of Web Services
Web ServiceDiscovery
Evaluating Web Services
InvocatingWeb Services
Request and Reporting
Locating atWeb services
Selection ofWeb services
Interaction withWeb services
Composition ofWeb services
Monitoring ofWeb services
Agent Technology(Planning)
Request, Confirm,and Modification
Initial and ReactiveComposition of Web Services
Web ServiceDiscovery
Evaluating Web Services
InvocatingWeb Services
Request and Reporting
재의 지능형 웹 서비스 표 화 활동과 그 연구 방향을 종합해 볼 때
지능형 웹 서비스의 임워크를 <그림 2-3>과 같이 구성해 볼 수 있다.
그림에서 볼 수 있는 바와 같이 지능형 웹 서비스 임워크는 크게 여섯
가지의 구성 요소를 가지고 있다. 가장 상 에는 사용자로부터 과업 요청,
업무 상태 확인 수정 요청을 받아 목 을 달성하기 해서 웹 서비스를
조합하는 역할을 하는 에이 트 기술에 바탕을 둔 계획(planning) 방법론
구성 요소가 존재한다.
이와 같은 에이 트 컴포 트는 하부 단 웹 서비스들을 정의하고 조합
하며, 실행시킬 수 있는 웹 서비스 조합 언어 조작 컴포 트를 통하여
목 을 달성하는데 필요한 구체 단 웹 서비스들을 구성할 수 있게 된
다. 이러한 복합 웹 서비스의 구성은 다시 각각의 하부 과업에 합한 단
웹 서비스의 검색과 검색된 안 웹 서비스들에 한 평가 선정, 나아가
선정된 웹 서비스들을 구체 으로 호출하고 다양한 웹 서비스들이 상호 운
용될 수 있도록 통제하는 컴포 트들이 하부 구조를 구성하게 된다.
마지막으로 웹 서비스 모니터링 컴포 트는 복합 웹 서비스의 각 수행
- 12 -
로세스를 감시하며 그 실행 상태를 에이 트에 보고하게 되며, 문제가 발
생할 경우 이에 한 미리 정의된 복구 차를 실행하며 최종 으로 체
업무가 종료되는지를 확인하는 역할을 수행하게 된다.
2.3 지능형 웹 서비스의 표 화 동향
재 지능형 웹 서비스와 련된 표 화 동향은 이제 막 시작 단계에 있
다고 볼 수 있다. 가장 표 인 표 화 동향은 역시 웹 서비스에 한 시
맨틱 표 을 목 으로 하는 DAML-Based Web Service Ontology
(DAML-S)라 볼 수 있으며, 미국 DARPA (Defense Advanced Research
Projects Agency)에 의해 지원되는 DAML 로그램에서 제안되고 있다.
DAML-S에 련된 릴리즈는 2001년 5월의 DAML-S 0.5를 출발로 해서
2003년 DAML-S 0.9 베타까지 제안된 상태이다.
이후부터의 버 은 W3C (World Wide Web Consortium)의 웹 온톨로지
워킹 그룹 (Web-Ontology Working Group)에 의해 개발된 OWL (Ontology
Web Language)를 기반으로 제안될 정이며, 소 OWL-S로 불리어지게
될 것이다. 이외에도 W3C의 Web Service Activity에 속한 Semantic Web
Service Interest Group이 2003년 말 발족하여 활동을 시작하고 있다.
지능형 웹 서비스에 있어서의 하나의 축은 보다 극 의미의 지능
형 웹 서비스를 한 규칙(rule)의 표 과 추론에 련된 표 이다. 이와
련해서는 RuleML (Rule Markup Language Initiative)을 그 시 로 하여
재는 DAML 로그램에서 SWRL (A Semantic Web Rule Language
Combining OWL and RuleML)의 드래 트 버 이 2003년 11월에 제출된
상태이다. 한 2003년 W3C 주 의 Semantic Web Architecture
Meeting에서도 규칙의 표 에 한 표 제정에 해 심도 있는 논의가 이
루어진 바 있다. 웹 서비스에 한 상 수 에서의 구체 표 에 보다
극 으로 규칙 형태의 표 이 이용될 수 있는 가능성이 있다.
그러나 앞에서도 다룬 바 있지만 웹 서비스 조합 언어 (Web Service
Composition Language) 에서는 세계 표 화의 움직임은 아직도 서로
이니셔티 를 가지려는 기업들의 힘겨루기에 의해 요원한 상태에 있다.
- 13 -
제 3 장 지능형 웹서비스 기반 기술 분석
3.1 시맨틱 웹 기반 기술
3.1.1 DAML+OIL (DARPA Agent Markup Language + Ontology
representation and Inference Language)
DAML+OIL은 미국의 DARPA와 유럽의 IST(Information Society
Technologies)가 공동으로 개발한 언어로 DAML의 문법 특성을 상속받고
있다. DARPA 로젝트가 XML에서 의미 상호운용성을 지원하는 반면
DAML+OIL은 OIL의 같은 객체들을 공유하고 있다. DAML+OIL은 RDF(S)
를 기반으로 표 될 수 있으며, DAML-ONT라 불리는 기 스펙을 체하
고 있다.
DAML+OIL은 Web Page에 존재하는 정보를 기계가 읽고 이해할 수 있도
록 하기 해 XML기술을 기반으로 하여 고안된 의미론 언어이다. 키워드
를 이용하지 않고 Web의 Resource에 직 컨텐츠를 바탕으로 근할 수 있
도록 해주는 가장 가까운 방법을 제공한다. 평범한 Metadata와 구별되는
은 서로 련 있는 웹 페이지라도 서로 다른 의미(Semantic)를 사용하기 때문
에 발생하는 의미론 장벽을 해결하기 한 수단으로 Ontology Connection
을 제공한다. DAML에서 Ontology를 표 하기 해 OIL를 사용한다.
아래 버 스리가 제안한 시맨틱 웹의 논리계층 그림에서 DAML+OIL
은 논리계층(Logic)에 해당한다.
- 14 -
<그림 3-1> 시맨틱 웹 논리계층
시맨틱 웹 기술언어인 DAML+OIL, OWL과 RDF, XML간의 계층 계는
다음 그림에서 표 된 바와 같이 연 된다.
<그림 3-2> 시맨틱 웹의 3계층
DARPA DAML Program에서 발표된 DAML+OIL 버 히스토리는
다음과 같다.
- 15 -
- 2000-08: DAML 0.5
- 2000-10: DAML-ONT
- 2000-12: DAML+OIL (December 2000)
- 2001-03: DAML+OIL (March 2001)
W3C의 Submission으로 추진된 DAML+OIL의 스펙정의서는 다음
URI에서 찾아볼 수 있다.
- http://www.w3.org/Submission/2001/12/
- http://www.w3.org/2001/10/daml+oil
DAML-OIL 언어는 XML, RDF기반의 일련의 온톨로지를 사용한 구조이
며, 온톨로지에 한 정의는 에 보인 URI에서 찾아볼 수 있다
□ Language structure
DAML-OIL의 언어구조는 크게 Header, Objects와 자료형, Class
elements, Class expressions, 속성제약(Property restriction),
Property elements, Instances, Datatype Value 등으로 이루어져 있
다. 뒤에 살펴볼 OWL도 마찬가지 이지만, Header부분에 이 문서에
서 사용된 온톨로지는 어디에 근거해있는지 URI가 표 된다.
o Header
- daml:Ontology element로 표 되며, 버 정보와 임포트 항목으로
구성된다.
- 제
<Ontology rdf:about="">
<versionInfo>$Id: NOTE-daml+oil-reference-20011218.html,v 1.6 2001/12/18
22:12:09 connolly Exp $</versionInfo>
<rdfs:comment>An example ontology</rdfs:comment>
<imports rdf:resource="http://www.w3.org/2001/10/daml+oil"/>
</Ontology>
- 16 -
o Objects와 자료형
- 표 될 수 있는 자료형은 Datatype과 Object의 두 가지가 있다.
- Datatype Domain: XML Schema 자료형
- Object Domain: DAML+OIL 는 RDF로 기술한 클래스 자료형
o Class elements
- daml:Class로 표 되며 객체 클래스의 정의를 포함한다.
- Ontology: rdfs:subClassOf, daml:disjointWith, daml:disjointUnio
nOf, daml:sameClassAs, daml:equivalentTo, boolean combinatio
ns, enumeration
o Class expressions
- 클래스명, URI 등을 표 한다.
- 열거형
- 클래스의 열거형을 표 한다. 단순한 union부터 클래스들
간의 집합 계 까지도 표 이 가능하다.
- daml:oneOf로 표 , 객체의 리스트를 포함
- 제
<daml:oneOf parseType="daml:collection">
<daml:Thing rdf:about="#Eurasia"/>
<daml:Thing rdf:about="#Africa"/>
<daml:Thing rdf:about="#North_America"/>
<daml:Thing rdf:about="#South_America "/>
<daml:Thing rdf:about="#Australia"/>
<daml:Thing rdf:about="#Antarctica"/>
</oneOf>
- 17 -
- 속성제약(Property restriction): 특별한 종류의 Class expression 으
로 제약을 만족하는 모든 객체의 클래스를 정의하는데 사용된다.
. ObjectRestriction: 객체에 한 속성제약
. DatatypeRestriction: 자료형에 한 속성제약
- Class expression간의 boolean expression: daml:intersectionOf, a
daml:unionOf, a daml:complementOf 등의 ontology로 표
o Property elements
- rdf:Property로 표 한다.
- 속성제약에서 사용된다.
o Instances
- RDF, RDF Schema 문법으로 표 된 Class 는 Property의 인스
턴스를 표 한다.
- 제
<continent rdf:ID="Asia"/>
<rdf:Description rdf:ID="Asia">
<rdf:type>
<rdfs:Class rdf:about="#continent"/>
</rdf:type>
</rdf:Description>
<rdf:Description rdf:ID="India">
<is_part_of rdf:resource="#Asia"/>
</rdf:Description>
- 18 -
o Datatype Values
- 데이터의 값은 RDF 문법을 수하는 어떤 것이든 가능하다.
- 제
<xsd:decimal rdf:value="10.5">
3.1.2 OWL (Web Ontology Language)
OWL 웹 온톨로지 언어는 웹에 표 된 콘텐츠를 이해하기 해 요구되
는 애 리 이션이 사용할 수 있는 시맨틱 웹 언어를 제공하기 해 W3C
웹 온톨로지 워킹그룹에 의해 설계된 온톨로지의 공유와 출 을 한 시맨
틱마크업 언어이다. 가장 최근에 언 되고 있는 언어이다.
OWL은 DAML+OIL 웹 온톨로지 언어를 기반으로 하고 있다. OWL의
지식 베이스는 RDF/XML 구문 명세서에서 정의된 RDF 트리 의 집합으로
구성되었으며, OWL에 정의한 어휘를 사용하여 트리 을 한 특정한 의미
를 기술한다.
W4C 웹 온톨로지 워킹그룹에서 발표된 DAML+OIL 가장 최근의 문
서는 다음과 같다.
- 2003.9: Cadidate Recommendation
OWL Web Ontology Language Overview
(http://www.w3.org/TR/owl-features/)
OWL Web Ontology Language Guide
(http://www.w3.org/TR/owl-guide/)
OWL Web Ontology Language Reference
(http://www.w3.org/TR/owl-ref/)
OWL Web Ontology Language Semantics and Abstract Syntax
(http://www.w3.org/TR/owl-semantics/)
- 19 -
OWL Web Ontology Language Test Cases
(http://www.w3.org/TR/owl-test/)
OWL Web Ontology Language Use Cases and Requirements
(http://www.w3.org/TR/webont-req/)
OWL은 DAML+OIL의 언어 특성을 상속받았지만 다음과 같은 특성은
서로 상이한 을 갖고 있다.
o 네임스페이스 수정
o RDF 코어 워킹그룹에 의해 오류가 수정된 공식 인 RDF 구문을 사용
- rdfs:subClassOf와 rdf:subPropertyOf를 이용하여 클래스와 로
퍼티의 순환 삽입가능
- 복수의 rdfs:domain과 rdfs:range 특성을 지원
- 컬 션타입지원 : rdf:parseType="Collection"
o 새로운 로퍼티타입(owl:SymmetricProperty)추가 : 칭 계 특성표
o DAML+OIL의 몇 가지 로퍼티는 이름이 변경되었음
<표 3-1> DAML+OIL과 OWL의 변경사항
DAML+OIL OWL
daml:hasClass owl:someValueFrom
daml:toClass owl:allValuesFrom
daml:UnambiguousProperty owl:InverseFunctionalProperty
daml:UniqueProperty owl:FunctionalProperty
OWL 언어도 DAMl+OIL과 마찬가지로 XML, RDF기반의 일련의 온톨로
지를 사용한 구조를 가지고 있다.
- 20 -
□ Language structure
OWL의 언어구조는 크게 Namespace, 클래스 계층 계 정의, 클
래스의 구성원(Individuals) 정의, 속성 (Properties) 정의, 속성의 특성
부가, 속성 값에 한 제약, 온톨로지 맵핑 (Ontology Mapping),
Complex Classes 등으로 이루어져 있다. 세부 인 언어는 DAML+OIL
과 상당히 유사하지만 표 이 더 다양하고 복잡한 형태로 발 한 것임
을 알 수 있다.
o Namespace
- 즉 OWL은 XML 스키마, RDF, RDF 스키마 등에 기 한 언어이
므로 이들의 네임스페이스가 우선 으로 있어야 하고, 동시에 O
WL 네임스페이스 온톨로지에 요구되는 데이터유형을 XML
스키마로 정의한 'dte' 네임스페이스 등이 나타나야 한다.
- 제
<rdf:RDF
xmlns ="http://www.example.org/wine#"
xmlns:vin ="http://www.example.org/wine#"
xmlns:food="http://www.example.org/food#"
xmlns:owl ="http://www.w3.org/2002/07/owl#"
xmlns:rdf ="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:xsd ="http://www.w3.org/2000/10/XMLSchema#"
xmlns:dte ="http://www.example.org/wine-dt#" >
o 클래스 계층 계 정의: class, subClassOf
- 제
- 21 -
<owl:Class rdf:ID="Winery"/>
<owl:Class rdf:ID="Region"/>
<owl:Class rdf:ID="ConsumableThing"/>
<owl:Class rdf:ID="PotableLiquid">
<rdfs:subclassOf rdf:resource="#ConsumableThing" />
</owl:Class>
<owl:Class rdf:ID="Wine">
<rdfs:subClassOf rdf:resource="#PotableLiquid"/>
<rdfs:label xml:lang="en">wine</rdfs:label>
<rdfs:label xml:lang="fr">vin</rdfs:label>
</owl:Class>
o 클래스의 구성원(Individuals) 정의
- 제
<Region rdf:ID="CentralCoastRegion" />
<owl:Thing rdf:ID="#CentralCostRegion">
<rdf:type rdf:resource="#Region">
</owl:Thing>
o 속성 (Properties) 정의
- OWL 속성은 크게 두 종류로 구분된다. 그 객체형속성(Object
Property)은 클래스 요소들 간의 계를, 데이터형속성(Datatype
Property)은 클래스 요소가 취해야 하는 데이터의 형식과 값을
기술한다. 한 원칙 으로 모든 OWL 속성의 용 도메인에
한 표기에는 rdf:domain을, 속성값이 취할 수 있는 범 의 표기
에는 rdf:range를 쓴다.
- 22 -
- 제
. 객체속성
<owl:ObjectProperty rdf:ID="madeFromGrape">
<rdfs:domain rdf:resource="#Wine"/>
<rdfs:range rdf:resource="#WineGrape"/>
</owl:ObjectProperty>
. 데이터속성
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns=
"http://www.example.org/wine-dt.xsd">
<xsd:simpleType name="year">
<xsd:restriction base="xsd:decimal"/>
</xsd:simpleType>
<xsd:simpleType name="wineYear">
<xsd:restriction base="year">
<xsd:minInclusive value="1700"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
o 속성의 특성 부가
- OWL에서는 객체형, 데이터형으로 속성을 구분해서 정의하는 단
계 이외에 속성의 특성을 이용한 보다 정교한 정의가 가능하다.
즉 어떤 객체형 속성 는 데이터형 속성에 'Transitive(추이 )'
는 'Functional(기능 )' 이라는 특성을 부가할 수 있기 때문이다.
- 23 -
- 제
. 추이 속성: 추이 속성 계는 P(x,y), P(y,z) 이면 P(x,z)가 만족
되는 경우에 성립한다.
<owl:ObjectProperty rdf:ID="locatedIn">
<rdf:type rdf:resource="&owl;TransitiveProperty" />
<rdfs:domain rdf:resource="&owl;Thing" />
<rdfs:range rdf:resource="#Region" />
</owl:ObjectProperty>
<Region rdf:ID="SantaCruzMountainsRegion">
<locatedIn rdf:resource="#CaliforniaRegion" />
</Region>
<Region rdf:ID="CaliforniaRegion">
<locatedIn rdf:resource="#UsRegion" />
</Region>
. 기능 속성: 기능 속성은 속성의 값을 유일하게 하는 제약이 필요
한 상황에서 사용한다. P(x,y), P(x,z)라는 여건에서 y=z 라는 공식이
성립되는 경우인 기능 속성은 DAML+OIL의 유일속성
(UniqueProperty)과 동일하다.
<owl:Class rdf:ID="WineYear" />
<owl:ObjectProperty rdf:ID="hasVintage Year">
<rdf:type rdf:resource="&owl;FunctionalProperty" />
<rdfs:domain rdf:resource="#Vintage" />
<rdfs:range rdf:resource="#WineYear" />
</owl:ObjectProperty>
- 24 -
o 속성값에 한 제약
- 속성값의 제한: allValuesFrom, someValuesFrom
- 카디날리티(Cardinality): cardinality 이외에도 minCardinality (최
소의 인스턴스)와 maxCardinality (최 의 인스턴스)
- 취할값의 명시(hasValue): hasValue 속성을 사용하여 속성값을
제한하는 경우, 제약을 받는 속성은 반드시 hasValue에 명시된
값만 허용
o 온톨로지 맵핑 (Ontology Mapping)
- 분산형으로 개발되는 온톨로지들 사이에 최 한의 공유가 가능한
하부구조가 구 되어야 한다.
- RDF 구문을 활용한 triple은 바로 이러한 하부구조의 핵심 기반
을 형성한다.
- 클래스와 속성들의 계를 연결시키는 다양한 온톨로지의 병합을
돕는 역할을 한다.
- sameClassAs, samePropertyAs: 상이한 온톨로지 요소들의 병합
에 요구되는 동일 클래스와 동일 속성의 표
- sameIndividualAs, differentInfividualFrom: 한 클래스에 속한 두
구성원이 동일한지 아닌지 표
- 제
<owl:Class rdf:ID="Wine">
<owl:sameClassAs rdf:resource="http://www.example.org/wine#Wine"/>
</owl:Class>
o Complex Classes
- OWL은 이미 정의된 클래스를 바탕으로 새로운 클래스를 생성할
수 있도록 set operator를 지원하고 있는데, 이에 해당하는 것에
는 intersectionOf, unionOf, complementOf 등이 있다.
- 25 -
- 더하여 oneOf(열거형), disjointWith(한 클래스의 구성원이 다른
클래스의 구성원이 될 수 없음)도 지원한다.
- 제
<owl:Class rdf:ID="WhiteWine">
<owl:intersectionOf rdf:parseType="Collection">
<owl:Class rdf:about="#Wine" />
<owl:Restriction>
<owl:onProperty rdf:resource="#hasColor" />
<owl:hasValue rdf:resource="#White" />
</owl:Restriction>
</owl:intersectionOf>
</owl:Class>
3.2 웹 서비스 기반 기술
가. 비
웹 서비스는 인터넷을 이용하여 새로운 방식으로 데이터를 교환하고 데
이터를 조합할 수 있도록 컴퓨터와 장치들을 서로 연결해 다. 웹 서비스
는 특정한 기능을 수행하고 비즈니스 로세스를 실행하기 해 표 로
토콜들을 이용하여 인터넷상에서 조합될 수 있는 소 트웨어 객체로 정의될
수 있다. 웹 서비스의 핵심은 느슨하게 결합된 재사용 가능한 소 트웨어
컴포 트들을 사용한 소 트웨어의 동 인 창출에 있다. 웹 서비스를 이용
하면 비즈니스 업무를 수행하기 한 시스템들 간에 자동 이고 즉각 인
상호운 성을 달성하는 것이 가능하다. 비즈니스 서비스는 인터넷상에 완
히 분산될 수 있으며, 매우 다양한 커뮤니 이션 장치들에 의해 근될 수
있다. 비즈니스는 복잡하고, 느리면서도 비싼 소 트웨어 통합의 짐을 벗어
버리는 신에 그 생산품의 가치와 핵심 업무에 집 할 수 있다. 이때 인터
- 26 -
넷은 조직과 개인이 여러 가지 상업 인 활동을 수행하고 부가 가치 서비스
를 제공하기 하여 서로 의사소통하는 총체 으로 공통된 랫폼이 된다.
새로운 상품을 제공하고 새로운 시장에 진입하는 데 방해가 되는 장벽은 낮
아져서 소기업의 근성을 높일 것이다. 동 기업과 동 가치 사슬이
가능하게 됨으로써 경쟁 우 를 한 필수 조건이 될 것이다.
웹은 URI, HTML, HTTP 등을 바탕으로 만들어졌다. URI는 웹상의 요소
들을 참조하기 하여 정의된 ID를 제공하고, HTML은 문서의 구조를 기술
하기 한 표 화된 방법을 제공하며, HTTP는 웹으로부터 정보를 검색하기
한 로토콜이다. 마찬가지로, 웹 서비스도 UDDI, WSDL, SOAP를 바탕
으로 한 비슷한 기반구조를 필요로 한다.
나. SOAP
SOAP는 XML로 인코드된 데이터를 달하기 한 표 인 방법을 정
의한 메시지 구조에 한 명세이다. 이것을 한 메시지를 주고받는 양 끝
단 간에 SOAP 메시지를 달하기 한 기반 커뮤니 이션 로토콜로서
HTTP에 바인딩하는 방법을 정의한다. 자동화된 B2B 상호 작용은 문서에
기반하기보다는 로세스의 통합을 요구한다. DCOM, RMI, CORBA 등과
같은 기술들은 지역 네트워크에서는 성공 이었던 데 반해, 웹 환경에서는
크게 실패하 다. 그것들은 다루기 힘들고 컴포 트 간에 무 단단한 결합
(coupling)을 필요로 하며, 무엇보다도 기존의 방화벽 기술과 상충된다. 이
것을 단순하고 가벼운 RPC 비슷한 메카니즘으로 체하는 것이 SOAP의
목표이다. SOAP는 단순 HTTP 에 XML 메시지를 보내는 방식을 사용함
으로써, 방화벽 문제를 해결하 다. 따라서, SOAP는 기본 으로 요청/응답
외에도 아주 단순한 일방 메카니즘을 제공하는 “웹 기반 PC"를 허용하는
기술이다.
다. WSDL
WSDL은 서비스를 네트워크 단말 즉 포트의 집합으로 정의한다. WSDL
에서 네트워크 단말과 메시지의 추상 인 정의는 그것의 구체 인 네트워크
- 27 -
상의 배치나 데이터 형태의 바인딩과 별도로 분리된다. 이것은 메시지의 추
상 정의를 재사용할 수 있도록 하며, 메시지의 추상 정의란 교환되는
데이터와 포트 타입에 한 추상 인 기술을 말한다. 그리고 포트 타입이란
작업들의 추상 인 모임이다. 특정 포트 타입에 한 구체 인 로토콜과
데이터 형태의 명세는 바인딩을 구성한다. 포트는 네트워크 주소를 바인딩
과 연결지음으로써 정의된다. 그리고 포트의 모임은 하나의 웹 서비스를 정
의한다.
라. UDDI
UDDI는 클라이언트가 웹 서비스를 발견할 수 있는 메카니즘을 제공한
다. UDDI 인터페이스를 사용함으로써 비즈니스는 외부의 사업 트 가 제
공하는 서비스를 동 으로 찾아서 발견할 수 있다. UDDI 지스트리는
CORBA 트 이더와 유사하다. 혹은 UDDI는 비즈니스 응용에 한 DNS
서비스로 생각할 수도 있다. UDDI 지스트리는 두 종류의 클라이언트를
갖는다. 하나는 서비스에 한 기술과 인터페이스에 한 명세를 공포하기
원하는 비즈니스이고, 다른 하나는 특정한 종류의 서비스에 한 기술을 얻
어서 로그램 으로 바인딩 하려는 클라이언트이다. UDDI 자체는 SOAP
의 상 계층에 존재하며 요청과 응답이 SOAP 메시지로 달되는 UDDI
객체라고 가정한다. UDDI 정보는 4개의 벨을 포함한다. 최상 벨은
비즈니스 개체로서, 이것은 회사의 주소, 회사에 한 간단한 설명, 연락 정
보, 식별자 등과 같은 회사에 한 일반 인 정보를 제공한다. 이 정보는
UDDI의 화이트 페이지로 볼 수 있다. 비즈니스 개체와 련하여 비즈니스
서비스 목록이 있다. 이것은 서비스에 한 기술과 그 서비스를 표시하는
일련의 카테고리(구매, 배송 등)를 포함한다. 이것은 UDDI의 로우 페이지
로 생각될 수 있다. 비즈니스 서비스 내에서 하나 이상의 바인딩 템 이
트는 그린 페이지를 정의한다. 그린 페이지는 웹 서비스에 한 좀 더 기술
인 정보를 제공한다.
- 28 -
3.3 시맨틱 웹 서비스 기반 기술
3.3.1 DAML-S (a DARPA Agent Markup Languages for Services)
앞장에서 언 된 DARPA의 DAML은 월드와이드웹(WWW)의 HTML
는 XML문서간의 의미 상 을 표 하는 RDF의 확장이라고 정의했다.
W3C에서 웹 서비스 표 이 발표된 이후 기존에 연구되어왔던 시맨틱
웹은 새로운 변화를 모색하게 되는데, 단순한 정 인 웹문서가 아닌 웹
서비스를 리소스로한 시맨틱 웹을 구 하고자 하는 노력이 그것이다.
DAML진 에선 웹 서비스간의 의미 상 을 표 하고자 시맨틱 웹
기술언어의 새로운 확장인 DAML-S의 첫 번째 버 (0.5)을 2001년 5월에
발표한다.
DAML-S는 “Sematic Markup For Web Service” 즉, Semantic Web상의
Web Service를 한 DAML의 확장이라고 정의 할 수 있다.
<그림 3-3> 시맨틱 웹 아키텍쳐상의 DAML-S
D AM L-S (Services)
XM L (Extensible M arkup Language)
R DF (R esource D escription Fram ew ork)
RD FS (R D F Schem a)
D AM L+OIL (Ontology)
XM L (Extensible M arkup Language)
R DF (R esource D escription Fram ew ork)
RD FS (R D F Schem a)
D AM L+OIL (Ontology)
DARPA DAML Program에서 발표된 DAML-S 버 히스토리는 다음
과 같다.
- 2003-05: DAML-S 0.9
- 29 -
- 2002-10: DAML-S 0.7
- 2001-12: DAML-S 0.6
- 2001-05: DAML-S 0.5
□ 시맨틱 웹 서비스 시나리오
DAML-S에서 설계한 시맨틱 웹 서비스의 시나리오 상에서의 서비
스의 종류와 참여구성원, 서비스 과정을 표 하면 다음과 같다.
o 웹 서비스의 종류
- Primitive Service: 분리될 수 없는 웹 서비스의 최소단 (기존의
웹서비스 단 와 동일)
- Complex Service: 여러 개의 웹 서비스들로 구성된 복잡한 웹서
비스 (Primitive, Complex서비스들로 구성됨)
o 참여 구성원
- Requester: 웹 서비스 요청자 (소 트웨어 에이 트 는 사람)
- Provider: 웹 서비스 제공자
- Registry: 제공자의 치를 리하고 제공자와 요청자간의 의사소
통을 돕는 인 라 컴포 트
- 30 -
o 서비스 과정
<그림 3-4> 시맨틱 웹 서비스 흐름도
- Location Of Providers: 웹 서비스 제공자를 찾음
- Selection Of Provider: 웹 서비스 제공자를 선택
- Interaction With Provider: 웹 서비스 제공자로부터 서비스를 제
공받음
- 31 -
□ 시맨틱 웹 서비스 기능 요구사항
언 한 시맨틱 웹 서비스의 가정을 지원하는 기능 요구사항을 도
출하면 다음과 같다.
o Automatic Web Service Discovery
- 자동 웹서비스 자동검색, 웹서비스에 한 정보 기술, 서비스
지스트리 등록, 지스트리 검색, 온톨로지 기반 검색
o Automatic Web Service Invocation
- 웹서비스 자동실행, 웹서비스 실행에 한 정보 기술
o Automatic Web Service Composition And Interaction
- 웹서비스 자동구성, 상호운용, 서비스를 선택하고 조합하는데 필
요한 정보 기술
이러한 기능들을 지원하기 해 DAML-S가 정의, 발표 되었다.
DAML-S에 해서 좀 더 자세히 세부 내용을 살펴보겠다.
□ DAML-S의 구성
DAML-S는 Resource들로부터 제공되는 Service는 서비스의 개요를
기술한 Service Profile, 서비스의 기능을 묘사한 Service Model, 서비스
의 실체화(실제 웹 서비스의 WSDL과의 매핑)를 담당하는 Grounding
으로 구성되어 있다.
<그림 3-5> DAML-S의 구성요소
- 32 -
각각의 온톨로지는 daml.org에 정의되어 있다.
- Service
http://www.daml.org/services/daml-s/0.9/Service.daml
http://www.daml.org/services/daml-s/0.9/Service.owl
- Service Profile
http://www.daml.org/services/daml-s/0.9/Profile.daml
http://www.daml.org/services/daml-s/0.9/Profile.owl
- Service Model
http://www.daml.org/services/daml-s/0.9/Process.daml
http://www.daml.org/services/daml-s/0.9/Process.owl
- Grounding
http://www.daml.org/services/daml-s/0.9/Grounding.daml
http://www.daml.org/services/daml-s/0.9/Grounding.owl
□ Service Profile
Service Profile는 웹서비스의 능력을 표 하고, 웹서비스 설명을
한 추가 인 특징 기술한다. Profile은 UDDI 지스트리의 UDDI
entry와 유사한 개념이다.
o 웹서비스의 능력을 표
- information level : 요구되는 입력과 얻어지는 출력을 표
- state level : 웹서비스가 실행되기 에 필요한 처리조건, 실행
결과로 얻어지는 effect를 표
o 웹서비스의 분류, 서비스의 질에 한 수 등의 정보 표
o Service Profile Ontology
Service Profile는 웹서비스의 능력을 표 하고, 웹서비스 설명을
- 33 -
항목 Ontology
Service Profile presents, presentedby
Service Name, Contacts,
DescriptionserviceName, textDescription, contactInformation
Actor : Provider, Requester
의 정보title, phone, fax, email.physicalAdress, webURL
Functional Description input, output, precondition, effect
Parameter Description parameterName, restrictedto, refersto
Profile Attributes serviceParameter, serviceCategory, qualityRating
Service Parameter serviceParameterName, sParameter
Quality Rating ratingName, rating
Service Category categoryName, taxonomy, value, code
한 Service Profile는 표 하는 온톨로지는 크게 Service Profile, Service
Name, Contacts, Description, Actor, Functional Description, Parameter
Description, Profile Attributes, Service Parameter, Quality Rating, Ser
vice Category를 설명하기 한 온톨로지로 구성되어 있다.
<표 3-2> Service Profile Ontology
o 제
- congoService의 ExpressCongoService부분에서 서비스에 한 내
역이 표기되어있다. service name은 Congo Book Buying Agent
이고, 이어서 구체 인 contact information이 이어져 나온다.
- 34 -
<profileHierarchy:BookSelling rdf:ID="Profile_Congo_BookBuying_Service">
<service:presentedBy rdf:resource="&congoService;#ExpressCongoBuyService"/>
<profile:serviceName>Congo_BookBuying_Agent</profile:serviceName>
<profile:textDescription>
This agentified service provides the opportunity to browse a
book selling site and buy books there
</profile:textDescription>
<profile:contactInformation>
<profile:Actor rdf:ID="CongoBuy_contacts">
<profile:name>ExpressCongoBuy</profile:name>
<profile:title> Service Representative </profile:title>
<profile:phone>412 268 8780 </profile:phone>
<profile:fax>412 268 5569 </profile:fax>
<profile:email>[email protected]</profile:email>
<profile:physicalAddress> somewhere 2,OnWeb,Montana 52321,USA
</profile:physicalAddress>
<profile:webURL>http://www.daml.org/services/daml-s/0.9/ExpressCongoBuy.html
</profile:webURL>
</profile:Actor>
</profile:contactInformation>
- qualityRating에 한 제이다. 'concept'의 'GoodRating'부분에
서 참고되는 변수값인 SomeRating을 사용한다고 선언되어있다.
(&, #은 다른 섹션의 역을 참조하는 데 사용되는 기호로 서비
- 35 -
스를 선언하고 있는 체 daml-s문서에서 참조된다.)
<profile:qualityRating>
<profile:QualityRating rdf:ID="Congo-Rating">
<profile:ratingName>SomeRating</profile:ratingName>
<profile:rating rdf:resource="&concepts;#GoodRating"/>
</profile:QualityRating>
</profile:qualityRating>
- input을 선언하고 있는 제이다. 이름은 bookTitle로 xsd에 선언
된 string형을 사용하며, 'congoProcess'에 선언된 라메터타입 '
bookName'을 참조한다.
<profile:input>
<profile:ParameterDescription rdf:ID="BookTitle">
<profile:parameterName> bookTitle </profile:parameterName>
<profile:restrictedTo rdf:resource="&xsd;#string"/>
<profile:refersTo rdf:resource="&congoProcess;#bookName"/>
</profile:ParameterDescription>
</profile:input>
- output을 선언하고 있는 제이다. 이름은 EReceipt로 'congoPro
cess'에 선언된 'EReceipt'형을 사용하며, 'congoProcess'에 선언된
라메터타입 'congoBuyReceipt'을 참조한다.
- 36 -
<profile:output>
<profile:ParameterDescription rdf:ID="EReceipt">
<profile:parameterName> EReceipt </profile:parameterName>
<profile:restrictedTo rdf:resource="&congoProcess;#EReceipt"/>
<profile:refersTo rdf:resource="&congoProcess;#congoBuyReceipt"/>
</profile:ParameterDescription>
</profile:output>
- precondition을 선언하고 있는 제이다. 이름은 'AcctExists'로 'c
ongoProcess'에 선언된 'AcctExists'형을 사용하며, 'congoProcess'
에 선언된 라메터타입 'congoBuyAcctExistsPrecondition'을 참
조한다.
<profile:precondition>
<profile:ParameterDescription rdf:ID="AcctExists">
<profile:parameterName> AcctExists </profile:parameterName>
<profile:restrictedTo rdf:resource="&congoProcess;#AcctExists"/>
<profile:refersTo rdf:resource="&congoProcess;#congoBuyAcctExistsPrecondition"/>
</profile:ParameterDescription>
</profile:precondition>
- effect를 선언하고 있는 제이다. 이름은 BuyEffectType로 'cong
oProcess'에 선언된 'BuyEffectType'형을 사용하며, 'congoProcess
'에 선언된 라메터타입 'congoBuyEffect'를 참조한다.
- 37 -
<profile:effect>
<profile:ParameterDescription rdf:ID="BuyEffectType">
<profile:parameterName> BuyEffectType </profile:parameterName>
<profile:restrictedTo rdf:resource="&congoProcess;#BuyEffectType"/>
<profile:refersTo rdf:resource="&congoProcess;#congoBuyEffect"/>
</profile:ParameterDescription>
</profile:effect>
- 일련의 모든 선언을 마치게 되면 BookSelling에 한 기술이 종
료한다.
</profileHierarchy:BookSelling>
□ Service Model
웹 서비스의 기능을 묘사한 Service Model은 웹 서비스의 형태와
실행순서를 표 하는 Process Model과 이를 모니터링 하기 한
Process Control Model로 구성되어 있다.
o Process model
- inputs, outputs, preconditions, effects를 가지고 서비스를 설명
- 웹 서비스의 composition을 수행하고 소 트웨어 에이 트와 웹
서비스간의 상호운용을 해 subprocess도 포함
o Process의 형태
- Atomic Process: 실행최소단
- Simple Process: 실행되지 않음, Grounding 없음, Atomic
/Composite Process의 추상화에 사용
- 38 -
- Composite Process: Atomic, Simple 등의 로세스 열거. 실행순
서는 Sequence, split, split+join. Choice, Unordered, Condition,
If-then-Else,Repeat-While, and Repeat-Until 등으로 기술됨
<그림 3-6> Process의 형태와 상호 계
o Service Profile Ontology
웹 서비스의 기능을 묘사한 Service Model을 표 하는 온톨로지는
크게 Process, Simple Process, Composite Process, Data Flow를 설명
하기 한 온톨로지로 구성되어있다.
<표 3-3> Service Model Ontology
항목 Ontology
Processprecondition, parameter(input, output, effect, partici
pant)
Simple Process realizedBy, expandTo
Composite Process
composedOf, ControlConstruct(Sequence, split, split+join.
Choice, Unordered, Condition, If-then-Else,Repeat-While,
and Repeat-Until ), components, ProcessComponent
Data Flow valueOf, atClass, theProperty
- 39 -
o 제
- Data Type: CreditCardType이라는 DataType을 선언하고 있는
제이다. collection형으로 선언되어있으며, 일련의 카드 종류가
선언되어 있다.
<daml:Class rdf:ID="CreditCardType">
<daml:oneOf rdf:parseType="daml:collection">
<CreditCardType rdf:ID="MasterCard"/>
<CreditCardType rdf:ID="VISA"/>
<CreditCardType rdf:ID="AmericanExpress"/>
<CreditCardType rdf:ID="DiscoverCard"/>
</daml:oneOf>
</daml:Class>
- Conditions: ‘process'에 선언된 클래스 ’Condition'의 서 클래스
인 BookInStock을 선언하고 있는 제이다.
<daml:Class rdf:ID="BookInStock">
<rdfs:subClassOf rdf:resource="&process;#Condition"/>
</daml:Class>
- Process Model 인스턴스: 아래 제는 Process Model인 ‘Express
CongoBuyProcessModel'이 선언되고 있다. 술된 Service Profil
e에 선언되었던 'ExpressCongoBuyService'의 서비스를 설명하고
있다는 것을 표기하고 있으며, 상세한 Process는 ExpressCongoB
uy를 가지고 있다는 것을 보여 다.
- 40 -
<process:ProcessModel rdf:ID="ExpressCongoBuyProcessModel">
<service:describes rdf:resource="&congo;#ExpressCongoBuyService"/>
<process:hasProcess rdf:resource="#ExpressCongoBuy"/>
</process:ProcessModel>
- Atomic Process: 이 제는 술된 ‘ExpressCongoBuy’에 한
상세 내용으로 Input으로 'congoBuyBookISBN', Precondition으
로 ‘CreditExists'이 필요하며, 실행 이후 ’congoOrderShippedEffe
t'를 Effect로 발생시킨다. Output은 ‘congoOrderShippedOutput’이
출력된다.
<daml:Class rdf:ID="ExpressCongoBuy">
<rdfs:subClassOf rdf:resource="&process;#AtomicProcess"/>
</daml:Class>
<!-- Inputs -->
<rdf:Property rdf:ID="congoBuyBookISBN">
<rdfs:subPropertyOf rdf:resource="&process;#input"/>
<rdfs:domain rdf:resource="#ExpressCongoBuy"/>
<rdfs:range rdf:resource="&xsd;#string"/>
</rdf:Property>
…
<!-- Precondition -->
<daml:Class rdf:ID="CreditExists">
<rdfs:subClassOf rdf:resource="&process;#Condition"/>
</daml:Class>
…
- 41 -
<!-- Effect -->
<daml:Property rdf:ID="congoOrderShippedEffect">
<rdfs:subPropertyOf rdf:resource="&process;#effect"/>
<rdfs:domain rdf:resource="#ExpressCongoBuy"/>
<rdfs:range>
<daml:Class>
<rdfs:subClassOf rdf:resource="&process;#ConditionalEffect"/>
<rdfs:subClassOf>
<daml:Restriction>
<daml:onProperty rdf:resource="&process;#ceCondition"/>
<daml:toClass rdf:resource="#BookInStock"/>
</daml:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<daml:Restriction>
<daml:onProperty rdf:resource="&process;#ceEffect"/>
<daml:toClass rdf:resource="#OrderShippedEffect"/>
</daml:Restriction>
</rdfs:subClassOf>
</daml:Class>
</rdfs:range>
</daml:Property>
<!-- Output -->
<daml:Property rdf:ID="congoOrderShippedOutput">
<rdfs:subPropertyOf rdf:resource="&process;#output"/>
- 42 -
<rdfs:domain rdf:resource="#ExpressCongoBuy"/>
<rdfs:range>
<daml:Class>
<rdfs:subClassOf rdf:resource="&process;#ConditionalOutput"/>
<rdfs:subClassOf>
<daml:Restriction>
<daml:onProperty rdf:resource="&process;#coCondition"/>
<daml:toClass rdf:resource="#BookInStock"/>
</daml:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<daml:Restriction>
<daml:onProperty rdf:resource="&process;#coOutput"/>
<daml:toClass rdf:resource="#OrderShippedOutput"/>
</daml:Restriction>
</rdfs:subClassOf>
</daml:Class>
</rdfs:range>
</daml:Property>
- Simple Process: ‘AbstractCongoBuy'라는 Simple Process의 제
이다. ’AbstractCongoBuy'는 'FullCongoBuy'로 확장되고,
’FullCongoBuy'는 'AbstractCongoBuy'로 간소화된다고 표시되어
있다. 이 게 선언된 Simple Process는 Composite Process선언에
사용된다.
- 43 -
<daml:Class rdf:ID="AbstractCongoBuy">
<rdfs:subClassOf rdf:resource="&process;#SimpleProcess"/>
</daml:Class>
<!-- AbstractCongoBuy expands to FullCongoBuy -->
<daml:Class rdf:about="#AbstractCongoBuy">
<rdfs:subClassOf>
<daml:Restriction>
<daml:onProperty rdf:resource="&process;#expandsTo"/>
<daml:toClass rdf:resource="#FullCongoBuy"/>
</daml:Restriction>
</rdfs:subClassOf>
</daml:Class>
<!-- Likewise, FullCongoBuy collapsesTo AbstractCongoBuy -->
<daml:Class rdf:about="#FullCongoBuy">
<rdfs:subClassOf>
<daml:Restriction>
<daml:onProperty rdf:resource="&process;#collapsesTo"/>
<daml:toClass rdf:resource="#AbstractCongoBuy"/>
</daml:Restriction>
</rdfs:subClassOf>
</daml:Class>
- Composite Process: 보다 복잡한 Process를 설명하는 Composite
Process는 선언자체는 Atomic/Simple Process와 동일하나
- 44 -
Control Statement등의 일련의 서비스 과정이 포함되어있다. 여기
선 ‘CongoBuyBook'로 명명된 Composite Process에 해 보이고
있다. Sequence로 Control타입이 정해진 일련의 로세스를 실행
하는데, 'BuySequence', 'SpecifyDeliveryDetails', 'FinalizeBuy'의
일련의 Process들을 순서 로 실행함을 보이고 있다.
<!– Control Statement -->
<daml:Class rdf:ID="CongoBuyBook">
<rdfs:subClassOf rdf:resource="&process;#CompositeProcess"/>
<rdfs:subClassOf>
<daml:Restriction>
<daml:onProperty rdf:resource="&process;#composedOf"/>
<daml:toClass>
<daml:Class>
<daml:intersectionOf rdf:parseType="daml:collection">
<daml:Class rdf:about="&process;#Sequence"/>
<daml:Restriction>
<daml:onProperty rdf:resource="&process;#components"/>
<daml:toClass>
<daml:Class>
<process:listOfInstancesOf rdf:parseType="daml:collection">
<daml:Class rdf:about="#BuySequence"/>
<daml:Class rdf:about="#SpecifyDeliveryDetails"/>
<daml:Class rdf:about="#FinalizeBuy"/>
</process:listOfInstancesOf>
</daml:Class>
</daml:toClass>
</daml:Restriction>
- 45 -
</daml:intersectionOf>
</daml:Class>
</daml:toClass>
</daml:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<daml:Restriction daml:cardinality="1">
<daml:onProperty rdf:resource="#congoBuyBookBookISBN"/>
</daml:Restriction>
</rdfs:subClassOf>…
</daml:Class>
o Process Control Model
- 서비스 요청의 실행을 모니터링 하는 것을 허용하는 기능을 제공
한다.
- 재 정의되지 않았고, 연구 인 부분이다.
□ Grounding
서비스의 실체화(실제 웹 서비스의 WSDL과의 매핑)를 담당하는
Grounding은 DAML-S의 Process Model에서 표 된 웹 서비스와 실제
존재하는 WSDL로 표 된 웹 서비스간의 계를 기술하고 있다.
- 46 -
<그림 3-7> Grounding 개념도
DAML-S와 WSDL과의 계를 보면, Atomic Process가 WSDL에
기술된 웹서비스에 응된다.
- input, output을 가진 Atomic Process : WSDL request-response
operation
- inputs 만을 가진 Atomic Process : WSDL one-way operation
- input, output을 가진 Composite Process : WSDL solicit-response
operation
o Grounding Ontology
- 서비스의 실 을 담당하는 Grounding에 한 온톨로지는 wsdl
에 한 매핑 정보를 나타내는 일련의 Grounding Class들로 구
성된다.
<표 3-4> Grounding Ontology
항목 Ontology
Grounding ClasswsdlVersion, wsdlDocument, wsdlOperation, wsdlInput
Message, wsdlInputs, wsdlOutputMessage, wsdlOutputs
- 47 -
재의 WSDL1.1에선 conditional output을 표 할 수 없으므로 완
한 Grounding은 불가능하다.
o 제
- Grounding: 아래의 제는 ‘CongoBuyGrounding'을 선언하고
있다. Atomic Process인 'ExpressCongoBuy'의 Grounding정보를
보인다. 각각의 wsdl에 한 선언에 daml-s서비스 정보의 선언
부분을 매칭 시키고 있다.
<grounding:WsdlAtomicProcessGrounding rdf:ID="CongoBuyGrounding">
<grounding:damlsProcess rdf:resource="&congo_process;#ExpressCongoBuy"/>
<grounding:wsdlOperation>
<grounding:WsdlOperationRef>
<grounding:portType>
<xsd:anyURI rdf:value="&congo_wsdl_grounding;#CongoBuy_PortType"/>
</grounding:portType>
<grounding:operation>
<xsd:anyURI rdf:value="&congo_wsdl_grounding;#CongoBuy_operation"/>
</grounding:operation>
</grounding:WsdlOperationRef>
</grounding:wsdlOperation>
<grounding:wsdlInputMessage>
<xsd:anyURI rdf:value="&congo_wsdl_grounding;#CongoBuy_Input"/>
</grounding:wsdlInputMessage>
<grounding:wsdlInputs rdf:parseType="daml:collection">
<grounding:WsdlInputMessageMap>
<grounding:damlsParameter rdf:resource="&congo_process;#congoBuyBookName"/>
<grounding:wsdlMessagePart>
- 48 -
<xsd:anyURI rdf:value="&congo_wsdl_grounding;#bookName"/>
</grounding:wsdlMessagePart>
</grounding:WsdlInputMessageMap>
<grounding:WsdlInputMessageMap>
<grounding:damlsParameter rdf:resource="&congo_process;#congoBuySignInInfo"/>
<grounding:wsdlMessagePart>
<xsd:anyURI rdf:value="&congo_wsdl_grounding;#signInInfo"/>
</grounding:wsdlMessagePart>
</grounding:WsdlInputMessageMap>
</grounding:wsdlInputs>
…
3.3.2 SWMF (Web Service Modeling Framework)
(1) 개요
재의 웹은 정보의 집합이기는 하지만, 아직 이러한 정보를 처리하는
것을 지원하지는 못하고 있다. 다시 말하면, 컴퓨터를 웹상의 정보를 처리하
는 장치로써 활용하지는 못하고 있다. UDDI, WSDL, SOAP 등과 련한 최
근의 노력들은 웹이 새로운 수 의 서비스를 제공할 수 있도록 하고자 하는
것이다. 웹 서비스(Web Services)라는 아이디어에 기반한 웹에서는 소 트웨
어 로그램들이 상호 근되고 수행될 수 있다. 하나의 서비스는 를 들
어 기상 보 서비스와 같은 순수 정보를 제공하거나 온라인 비행기표 매
서비스와 같은 실세계에 향을 미치는 작업을 할 수도 있다. 웹 서비스는
로그램 간 자동 통신, 서비스의 발견 등과 같은 기능을 제공함으로써 웹
아키텍쳐의 잠재력을 하게 증가시킬 수 있다. 이에 따라, 재 웹 서비
스는 여러 소 트웨어 개발 회사들의 심의 이 되고 있다.
웹 서비스의 궁극 인 비 은 어떤 결과를 얻기 해 수행된 로그램이
- 49 -
일부의 계산이나 처리를 웹 서비스의 지원을 받아 수행할 수 있도록 하는
것이다. 그 로그램은 해당 웹 서비스를 발견하고 그것을 완 자동으로
수행할 수 있어야 한다. 이때, 그 로그램은 서비스 요청자가 된다. 만약
웹 서비스를 사용하기 하여 수수료를 내야 한다면 로그램은 언제 더 값
싼 서비스를 검색해야 하는지와 가능한 모든 지불 방법들을 알아야 한
다. 나아가, 로그램은 특정한 요구와 그 요구에 유사하게 합치하는 웹 서
비스 간의 차이 을 조정하여 일치시켜야 한다.
비즈니스 환경 측면에서 보면 이것은 기업 간 자동 제휴와 비슷한 개념
이다. 다른 기업과의 사업 계를 필요로 하는 기업은 한 최 웹 서비
스를 자동 으로 발견한 후 미리 정의된 선택 정책에 따라 그것을 선택할
수 있다. 이어서 웹 서비스는 자동으로 수행되고, 필요한 결제 처리도 시작
된다. 데이터와 로세스 온톨로지 온톨로지에 한 자동 해석에 기반하
여 필요한 조정 차도 이루어진다. 소모품을 생산하는 기업이 수시로 구매
자와 원재료 공 자를 찾아야 하는 상황에서의 공 망 계가 그 가 될
수 있다. 종업원들이 지속 으로 공 자와 구매자를 찾는 신에 웹 서비스
기반 구조가 미리 정의된 제약조건 내에서 자동 으로 공 자와 구매자를
찾아주는 것이 그것이다.
웹 서비스 기반 구조가 이러한 비 을 실화시키기 해서는 아직도 더
많은 작업이 이루어져야 한다. UDDI, WSDL, SOAP 등과 련된 재의 기
술은 서비스의 인식, 서비스의 구성 조합(즉, 복잡한 워크 로우와 비즈
니스 로직의 실화), 서비스의 비교, 자동 상 등을 기계화(자동화)시키는
데 있어서 제한 인 기능만을 지원하고 있다. 이에 따라, 복잡한 웹 서비스
를 기술할 수 있는 언어를 제공하기 한 BPEL4WS이나 서비스의 기술을
해 시맨틱 웹 기술을 채용한 DAML-S 등과 같은 것들이 제안된 바 있다.
Web Service Modeling Framework(WSMF)도 이러한 노력의 연장선상에 있
다. WSMF는 웹 서비스와 련된 다양한 측면을 기술하기 한 완벽한 모
델링 임워크이다. 자상거래가 작동 가능한 웹 서비스에 기반하여 완
벽하게 작동하기 해서는 다음의 상호보완 인 원칙에 입각한 모델링
임워크를 필요로 한다.
- 50 -
□ 자상거래 응용을 실화하기 한 다양한 컴포 트들 간의 강한 디
커 링(de-coupling)
□ 어느 구와도 연결될 수 있는 강력한 조정 서비스(mediation
service)
(2) 성공 인 웹 서비스를 한 필요 기능
UDDSI, WSDL, SOAP 등이 웹 서비스의 구 에 요한 요소이기는 하
지만, 느슨하게 결합된(loosely coupled) 재사용 가능한 소 트웨어 컴포
트들 간의 자동 인 상호운 성(interoperability) 확보라는 비 을 완벽하게
달성하기에는 부족하다. 웹 서비스의 발견, 선택, 조정 조합을 완벽하게
달성하기 해서는 다음과 같은 사항들이 필요하다.
□ 문서 유형(Document Types)
문서 유형은 구매 주문이나 송장 등과 같은 비즈니스 문서의 내용을
기술한다. 문서의 내용은 주문 번호, 개별 주문 상품의 가격 등과 같
은 요소들에 의해 정의된다. 문서 유형은 서비스 요청자와 서비스 제
공자가 데이터를 주고받을 때 실제 비즈니스 데이터로 구 된다.
□ 의미(Semantics)
문서 유형의 요소들은 의미 상 올바르고, 서비스 요청자와 제공자에
의해 올바르게 해석될 수 있도록 올바른 값을 가져야 한다. 이것은
요소가 가질 수 있는 정당한 값을 나열하거나 설명하는 어휘 사 을
정의하는 것을 필요로 한다. 를 들어, 생산자가 주문할 수 있는 상
품 이름의 목록이 여기에 해당한다. 다른 로서 국가 코드나 척
도의 단 등을 들 수 있다. 온톨로지는 교환되는 데이터에 한 개
념을 정의하는 수단을 제공한다. 온톨로지가 제공되는 경우 문서 유
형은 온톨로지 개념을 참조한다. 이것은 교환되는 개념의 원래 의미
와 그것의 문자 표 간의 일치성을 보장하고 계된 모든 거래 당
사자들이 그 개념을 모두 동일하게 해석할 수 있도록 한다. 마지막으
로, 교환되는 문서의 의도가 정의되어야 한다. 를 들어, 한 구매 주
문이 보내졌다면 그것이 그 구매 주문의 생성, 삭제, 는 경신
- 51 -
어느 것을 요구하는 것인지에 한 의미가 명확하지 않다. 달된 문
서를 어떻게 해석해야 할지에 한 의도가 의미론 으로 명확하게
정의되어야 한다.
□ 송 바인딩(Transport binding)
HTTP(/S), (S/)MIME, FTP, EDIINT 등 여러 가지 송 메카니즘들
이 이용 가능하다. 따라서 서비스 제공자뿐만 아니라 서비스 요청자
도 서비스 요청이 수행될 때 사용될 송 메카니즘에 합의해야 한다.
각 이용 가능한 송 메카니즘에 하여 메시지의 구조가 합의되어
야 하고, 송될 문서가 송 메시지 내에서 어떻게 표 될지에 해
서도 합의되어야 한다. 를 들어, SOAP는 메시지의 구조와 함께 메
시지 구조 내에서 문서가 발견될 치를 정의한다. 한, SOAP 메시
지 처리를 해 필요한 헤더 데이터도 정의한다.
□ 교환 순서 정의(Exchange sequence definition)
네트워크를 통한 통신은 재 본질 으로 신뢰할 수 없다. 따라서
로토콜을 통해 메시지가 정확히 한번만 송되는 것을 서비스 요청
자와 서비스 제공자가 확신할 수 있어야 하는 것이 필요하다. 교환
순서 정의는 타임아웃, 재시도 로직, 최 재시도 횟수 등과 함께 확
인 응답 메시지의 순서를 정의함으로써 와 같은 문제를 해결한다.
□ 로세스 정의(Process definition)
서비스 요청자와 서비스 제공자 간에 메시지가 정확히 한번만 교환
될 수 있다는 가정 하에 비즈니스 메시지 교환 순서의 에서 비
즈니스 로직이 정의되어야 한다. 를 들어, 구매 주문은 구매 주문
확인 응답에 의해 확인될 수 있다. 는, 견 요청이 하나 는 그
이상의 견 서에 의해 응답되어질 수 있다. 이러한 로세스들은 일
치된 비즈니스 상태를 끌어내기 해 필요한 비즈니스 메시지 로직
을 정의한다. 를 들어, 구매 주문에 의해 물품이 주문되고 구매 주
문 확인 응답에 의해 확인되면 물품들은 배송되고 결제되어야 한다.
□ 보안(Security)
기본 으로 모든 메시지 교환은 서비스 요청자와 서비스 제공자 간
- 52 -
에 비 스러워야 하고 제 3 자에 의해 훼손되지 않아야 하며 한
송신이나 수신 사실이 부인될 수 없어야 한다. 자서명과 암호화는
훼손 방지와 비 을 보장하고 서비스 요청자나 제공자에 의한 메시
지 송 사실에 한 부인을 방지한다.
□ 구문(Syntax)
문서들은 여러 가지 다양한 구문으로 표 될 수 있다. 비 XML 구문
이 사용되기도 하지만 ( , EDI) XML이 가장 리 쓰이는 구문이다.
□ 거래 당사자 고유의 구성(Trading partner specific configuration)
서비스 요청자와 서비스 제공자는 그들의 비즈니스 로직을 서로 다
르게 구 한다. 이것은 서비스 요청 제공이라는 력을 하기 에
이미 그들 자신만의 비즈니스 로직을 확립해 놓았기 때문이다. 이 경
우 거래 상 가 발견되고 웹 서비스에 의한 상호 교류가 공식화되면
상호 조정이 필요하게 된다. 수정이 필요한 경우 거래 상 별 변경
내용이 표 되어야 한다.
재의 웹 서비스 기술은 이러한 요구 사항들을 충족시키지 못하고 있
다. SOAP의 경우 정보 바인딩(Information binding)을 지원할 뿐이고,
UDDI나 WSDL 모두 에 나열된 항목들을 지원하고 있지 못하다. 많은 조
직들이 메시지 정의와 메시지 교환만으로는 표 력이 뛰어난 웹 서비스 기
반구조를 마련하는 데는 충분하지 못하다고 생각하고 있다. UDDI, WSDL,
SOAP 외에도 BPEL4WS, WSFL, XLANG, ebXML, BPSS, BPML, WSCL 등
과 같은 교환 순서 정의 로세스 정의를 한 표 들이 제안되었다.
에 언 한 임워크들 외에도 아직도 요한 특징들이 많이 요구되어진
다. 요한 은 한 모델링 임워크에 웹 서비스의 느슨한 결합
(loose coupling) 조정 (scalable mediation) 능력을 반 하는 것이다. 이
것은 공개된 워크 로우(공개 로세스)와 복잡한 웹 서비스의 내부 비즈니
스 로직(사설 로세스) 간의 차이를 표 할 수 있는 능력뿐만 아니라 서로
다른 문서 구조와 서로 다른 비즈니스 로직 간을 매핑(mapping)할 수 있는
조정자(mediator)를 필요로 한다. 이를 하여 Web Service Modeling
Framework(WSMF)가 개발되었다. WSMF는 웹 서비스 기술이 그 잠재력을
최 한 끌어낼 수 있는 웹 서비스의 개발 기술을 한 풍부한 개념 모
- 53 -
형이다. 다음 에서는 WSMF와 다른 제안 기술들을 자세히 비교해 보도록
하겠다.
(3) WSMF의 기본 원리
웹 서비스와 완벽한 기능을 가진 자상거래를 실화하기 해서는 거
쳐야할 몇 가지 요한 차가 있다. 자상거래가 그 잠재력을 최 한 발
휘할 수 있도록 하기 해서는 Peer-to-Peer (P2P) 근이 필요하다. 구든지
어떤 다른 사람과도 거래와 상을 할 수 있어야 한다. 그 지만 그러한 개
방 이고 유연한 자상거래가 실화 되는 데는 몇 가지 장애물이 있다.
□ 매자 그들의 매 조건을 검색하고 비교하기 한 기계화된(자
동화된) 지원이 필요하다. 재 이러한 작업의 거의 부분은 수동으
로 이루어지며, 이것은 자상거래의 확산에 심각한 방해가 되고 있
다. 시맨틱 웹 기술은 이것을 다르게 할 수 있다. 기계에 의한 정보의
의미 처리는 이러한 작업들의 기계화(자동화)를 가능하게 한다. 이것
은 다음 에서 상세히 다루도록 하겠다.
□ 수많은 그리고 서로 다른 데이터 형태를 다루기 한 기계화된(자동
화된) 지원이 필요하다. 제품과 용역, 제품 카탈로그, 상업 문서 등을
기술하기 한 수많은 표 들이 존재한다. 그러한 표 들을 더 잘 정
의하고 그들 간의 변환(mapping) 서비스를 제공하기 해 온톨로지
기술이 필요하다. 서로 다른 용어 간의 효율 인 연결이 개방성과 확
장성을 해 꼭 필요하다. 이러한 문제에 해서는 다음 에서 다루
도록 하겠다.
□ 수많은 그리고 서로 다른 비즈니스 로직을 다루기 한 기계화된(자
동화된) 지원이 필요하다. 거래 당사자의 비즈니스 로직을 정의하기
한 수많은 표 들이 한 존재한다. 거래 트 들 간에 력이
히 이루어질 수 있도록 비즈니스 로직의 차이 들을 메울 수 있도
록 조정하는 것이 필요하다. 이러한 문제에 해서도 다음 에서 다
루도록 하겠다.
상기 요구 조건들은 WSMF의 개발의 근거가 된다. 작동 가능한 웹 서비
- 54 -
스에 기반한 완 한 형태의 자상거래는 다음의 두 가지 상호 보완 인 원
리에 을 둔 모델링 임워크를 필요로 한다.
□ 자상거래 어 리 이션을 실화할 수 있는 많은 컴포 트들의 강
한 디커 링(Strong de-coupling)
이 디커 링은 내부 비즈니스 인텔리 스와 공개 메시지 교환 로
토콜 인터페이스 기술 간의 차이에 바탕을 둔 정보 숨기기
(information hiding)를 포함한다. 로세스의 결합(coupling)은 상호
작용의 횟수를 확 시킬 수 있는 인터페이스를 통해서만 달성될 수
있다.
□ 그 수에 구애받지 않고 어느 구나 다른 모든 사람과 이야기할 수
있는 강한 조정(mediation) 서비스
이 조정 서비스는 서로 다른 상호작용 스타일의 조정뿐만 아니라 서
로 다른 용어의 조정도 포함한다.
WSMF의 설계는 상기 두 가지 원리를 바탕으로 수행되었다. 웹 서비스
를 이용한 자상거래의 여러 가지 측면들을 최 한 느슨하게 조합시켰고
(de-couple), 공개 인터페이스와 조정 서비스에 기반한 확장 가능한 상호작
용을 제공하고자 하 다.
(4) Web Service Modeling Framework
WSMF는 다음의 네 가지 서로 다른 요소들로 이루어져 있다: 다른 요소
에 의해 사용되는 용어를 제공하는 온톨로지, 웹 서비스에 의해 해결되어야
할 문제들을 정의하는 기능 장소, 웹 서비스의 여러 가지 측면들을 정의
하는 웹 서비스 기술, 상호 연동성(interoperability) 문제를 해결한 조정자.
(가) 온톨로지
온톨로지는 시맨틱 웹을 가능하게 하는 핵심 기술이다. 온톨로지는 심벌
에 한 인간의 이해와 그 이해를 기계가 처리 가능하게 하는 것을 서로 연
- 55 -
결시킨다. 온톨로지는 지식의 공유와 재사용을 진하기 하여 인공지능
분야에서 개발되었다. 1990년 반 이후 온톨로지는 인공지능 분야의 인
기 있는 연구 주제 다. 최근에는 온톨로지의 개념이 지능형 정보 통합,
업 정보시스템, 정보 검색, 자상거래, 지식 경 등의 다양한 분야에서
사용되고 있다. 온톨로지가 이 게 리 퍼지게 된 이유는 “사람과 응용 시
스템 간에 상호 달될 수 있는, 특정 분야에 한 공통 인 이해”에 한
가능성에 주로 기인한다. 따라서 온톨로지는 웹이 그 가능성을 최 한 발휘
할 수 있도록 하는 두 가지 본질 인 측면을 하나로 묶었다:
□ 온톨로지는 정보의 의미에 해 공식 인 정의를 할 수 있게 함으로
써 컴퓨터에 의한 정보처리를 가능하게 한다.
□ 온톨로지는 실세계의 의미를 정의할 수 있게 함으로써 합의된 용어를
바탕으로 기계 처리가 가능한 정보 내용과 그것의 인간에 있어서의
의미 간에 연결을 맺는 것을 가능하게 한다.
본 임워크에서 온톨로지는 다른 WSMF의 요소들에 의해 사용되는
용어를 정의하는 데 사용된다. 그리하여 온톨로지는 동일한 는 련된 용
어를 참조하는 컴포 트들 간의 상호운 성뿐만 아니라 용어의 재사용도 가
능하게 한다.
(나) 기능 장소
기능 명세란 클라이언트가 웹 서비스의 서비스를 요청할 때 가질 수 있
는 목표를 기술하는 것을 말한다. 기능 명세는 다음 두 가지 요소로 이루어
져 있다.
□ 사 조건(Pre-conditions)은 웹 서비스가 그 서비스를 제공하는 것을
가능하게 하기 해 기 하는 것들을 말한다. ‘가장 가까운’ 쿠바식
식당을 찾아주기를 요청하는 것은 웹 서비스가 이해하는 방식으로 내
가 어디에 있는지를 웹 서비스에게 말해 수 있을 때만 의미가 있
다. 마찬가지로, 한 도시의 ‘가장 좋은’ 호텔을 찾아주기를 요청하는
것은 내가 ‘가장 좋은’이라는 말에 해 내가 이해하는 바를 설명한
연후에 가능하다.
- 56 -
□ 사후 조건(Post-condition)은 입력에 한 응답으로 웹 서비스가 돌려
주는 것들을 말한다. 지리 정보에 한 응답으로 웹 서비스는 ‘가장
가까운’ 쿠바식 식당을 알려 주거나, 클라이언트의 선호에 기반하여
‘가장 좋은’ 호텔을 알려 것이다.
n개의 웹 서비스와 m개의 기능 간에는 n*m개의 매핑이 존재하기 때문
에 기능 명세는 실제 웹 서비스와 별도로 만들어져야 한다. 즉, 한 개의 웹
서비스가 복수개의 서로 다른 기능을 가질 수 있고, 서로 다른 웹 서비
스가 동일한 기능을 제공할 수도 있기 때문이다. 이 경우 웹 서비스 별로
각각 m개의 기능을 명시하게 된다면 동일한 m개의 기능이 n개의 웹 서비
스에 복 명시됨으로써 결과 으로 m개의 명시로 가능한 기능들이 n*m개
명시되게 되기 때문이다.
기능을 설명하는 용어를 추가 으로 정의할 수 있도록 하기 하여 기능
명세에는 어도 한개 이상의 온톨로지가 우선 도입되어야 한다. 를 들어
“가장 가까운(nearest)”이라는 용어는 다음과 같은 특성을 만족시켜야 한다.
□ nearest(x)는 nearer(y, x)인 y(즉, x보다 더 가까운 y)가 존재하지 않
는 것을 내포한다.
□ nearer(x, x)는 거짓이다. 즉, x는 x보다 더 가깝지 않다.
□ nearer(x, y)이고 nearer(y, z)이면 nearer(x, z)이다.
□ nearer(x, y)가 만족한다는 것은 nearer(y, x)가 만족하지 않음을 의미
한다.
□ nearer(x, y)와 nearer(y, x) 하나는 반드시 만족한다.
온톨로지는 정확하게 특성을 정의하는 재사용 가능한 어휘집을 제공한다.
(다) 웹 서비스
많은 웹 서비스 기술 언어들은 기본 웹 서비스와 복합 웹 서비스를 구분
한다. 기본 웹 서비스는 단순히 입력과 출력으로만 이루어진 박스이고, 복합
웹 서비스는 그 로세스가 다른 웹 서비스를 부르는 하 작업들로 나
어질 수 있다. 엄 하게 말해서 그러한 구분은 틀린 것으로 웹 서비스 모
- 57 -
델링 임워크에서는 잘못된 개념화로 이어질 수 있다. 구분의 기 은 웹
서비스 자체의 복합성에 있지 않다. 구분의 기 은 오히려 웹 서비스에 한
기술 는 웹 서비스의 인터페이스의 복합성에 있어야 한다. 를 들어 한
개의 웹 인터페이스를 갖는 추론 엔진과 같은 복잡한 웹 서비스는 사실상
하나의 기본 웹 서비스로 기술될 수 있다. 추론 엔진 웹 서비스는 몇 가지
공식을 입력 받아서 한 묶음의 결론들을 도출한다. 이와 반 로, 단순 여행
정보 시스템과 같은 훨씬 단순한 로그램은 호텔 정보, 항공기 정보, 특정
지역의 일반 정보 등과 련된 여러 개의 웹 서비스로 나 어질 수 있다. 그
러므로 우리의 에서 그 구분의 기 은 웹 서비스의 내재 인 복잡성에
있는 것이 아니라 외형을 기술하는데 있어서의 복잡성에 있다. 그 지만, 일
견 자명해 보이는 이러한 통찰은 다음과 같은 요한 결론에 도달한다.
□ 웹 서비스 기술을 한 많은 근 방법들이 웹 서비스의 내부 기술
과 외형 기술 간에 명확한 구분을 하지 않는다. 그 근 방법들은
웹 서비스에 근하기 한 인터페이스 기술로 이해되어야 할지, 아
니면 웹 서비스의 실 을 한 내부 기술로 이해되어야 할지에 한
명확한 구분도 없이 자료 흐름도나 제어 흐름 기술과 같은 기술 수단
을 제공한다. 본 임워크는 웹 서비스의 외형 측면(즉, 네트워크
를 통해 근될 수 있는 인터페이스 부분)만을 기술하는 것으로 한정
된다. 요컨 , WSMF는 웹 서비스를 기술하는 것이 아니고 네트워크
를 통해 근 가능한 웹 서비스 인터페이스를 기술한다.
□ 기본 웹 서비스와 복합 웹 서비스의 이분법은 무 단순하다. 웹 서
비스 기술의 복잡성에 해 이야기 하는 것은 동시에 복잡성의 정도
도 이야기하는 것이다. 즉, 몇 가지 기술 요소로부터 시작하여 웹 서
비스의 다양한 측면을 기술하기 한 추가 인 수단을 덧붙임으로써
기술 요소들은 차 복잡해진다.
본 에서는 특정 벨의 복잡성을 갖는 웹 서비스를 기술하기 하여
사용할 수 있는 다양한 기술 요소들을 설명하도록 하겠다. 이를 하여 다
음과 같은 질문으로부터 시작하도록 한다. “웹 서비스는 무엇인가?” 웹 서
비스는 웹을 통해 근 가능하며 특정한 목표를 달성하는 것을 도와주는 도
구이다. 이 답은 한 웹 서비스를 기술하는 데 필요한 몇몇 요소들을 악
할 수 있도록 해 다. 어떤 경우든, 웹 서비스는 블랙박스로 표 된다. 즉,
- 58 -
웹 서비스가 어떻게 달성되는지에 한 내부 처리 측면은 모델링의 상이
아니다.
(a) 블랙박스
첫째, 웹 서비스는 이름(name)을 갖고 있다. 즉, 그것을 참조하기 한
단일 식별자를 갖고 있다. 이것은 기본 인 요구조건이다.
둘째, 웹 서비스는 특정 목 을 달성해야 한다. 즉, 웹 서비스는 특정한
기능에 한 참조를 갖고 있어야 한다. 이 기능은 웹 서비스가 달성하여야
할 목 이다.
셋째, 기능의 경우와 마찬가지로 웹 서비스는 사 조건(pre-conditions)
와 사후 조건(post-conditions)에 한 기술을 포함해야 한다. 사 조건이란
웹 서비스가 성공 으로 실행될 수 있기 하여 입력이 만족하여야 할 조건
들이다. 사후 조건이란 복잡한 웹 서비스가 성공 으로 실행 된 후 만족하
여야 할 조건들이다. 이것은 출력에 한 제약조건을 정의한다. 이러한 조건
들은 기능(capability) 조건들과 직 으로 연결될 수도 있고 간 으로 연
결될 수도 있다. 이러한 WSMF 구조의 유연성은 두 가지 주요한 이 을 갖
는다. 첫째, 기능(capability)과 웹 서비스가 서로 다른 용어를 사용할 수 있
다. 둘째, 웹 서비스가 기능의 사 조건을 강화하거나, 기능의 사후 조건을
약화할 수 있다. 를 들어 우리의 목표가 우리의 재 치에서 가장 가까
운 식당을 찾는 것이라고 하자. 이 기능을 달성하기 한 어떤 웹 서비스는
지리 정보를 표 하기 한 특정한 표 에 의거하여 재의 치를 질문한
후 자신에게 등록된 는 고료를 지불하는 식당만을 상으로 가장 가까
운 식당을 찾아 수 있다. 이 경우 이 서비스는 원래의 기능 명세 측면에
서는 완벽하지 않으나 그래도 우리의 재 욕구를 만족시켜 주며 상태에
서 찾을 수 있는 가장 좋은 웹 서비스일 수 있다.
넷째, 웹 서비스 기술은 그 웹 서비스의 입력 데이터와 출력 데이터의
구조를 기술한다. 데이터가 복합 서비스에 달되는 통로 역할을 하는 요소
가 입력 포트(input ports)이다. 입력 포트는 데이터의 값을 달하는 공식
인 라메터의 역할을 한다. 입력 포트를 통해 달되는 입력 데이터와
- 59 -
유사하게 출력 데이터가 출력 포트(output ports)를 통해 웹 서비스로부터
출력될 수 있다.
다섯째, 문제 상황이나 오류 상황을 나타내기 해 언제라도 오류 데이
터가 오류 포트(error ports)를 통해 복합 서비스로부터 출력될 수 있다. 수
행 여러 지 으로부터 오류 데이터를 출력받기 하여 여러 개의 오류
포트가 정의될 수 있다.
(b) 회색 박스
지 까지 설명한 기술 요소들은 웹 서비스를 블랙박스로 간주한 경우이
다. 그러나 많은 경우에 웹 서비스 인터페이스의 좀 더 복잡한 기술이 필요
한 경우가 있다.
□ 실패(failure)
웹 서비스의 실행 요소 하나가 실패하면 그 웹 서비스는 실패 상
태가 된다. 웹 서비스가 스스로 그 실패 상황으로부터 복구될 수 없
으면 서비스 요청자가 그것을 처리할 수 있도록 실패 상황을 알려
주어야 한다. 실패 상황을 처리할 수 있도록 서비스 요청자가 실행된
요소들 어느 것이 성공했고 어느 것이 실패했는지 정확히 아는
것은 매우 요하다. 그러한 성공과 실패가 분간이 안 되면 요청자는
실패 상황을 발견할 방법이 없다. 를 들어, “여행 약”이라는 서
비스가 호텔, 카 탈, 항공기를 약할 경우 “여행 약” 서비스가
성공하기 해서는 세 약 모두 성공하여야 한다. 만약 “여행 약”
서비스가 실패한다면 서비스 요청자가 성공한 약들을 취소시키기
해서 어느 약이 일어났고 어느 약이 일어나지 않았는지를 아
는 것이 요하다.
□ 동시 실행(concurrent execution)
한 웹 서비스가 여러 개의 다른 웹 서비스를 부를 수 있으므로 그것
이 완료되기 해서 시간이 걸릴 수가 있다. 자원과 체 인 수행
시간을 최 화하기 하여 몇몇 서비스들이 동시에 실행되도록 설정
할 수 있다.
- 60 -
□ 데이터의 동시 입력 출력 (concurrent data input and output)
한 웹 서비스가 다른 서비스를 시간에 따라 수행시킬 수 있다. 각 서
비스가 수행될 때마다 입력 데이터가 그 서비스에 입력되어야 하고
출력 데이터가 그 서비스로부터 받아들여져야 한다. 어떤 서비스에
한 입력 데이터가 무엇인지 웹 서비스를 시작시키는 시 에서는
모를 수도 있다. 이것은 웹 서비스가 수행되고 있는 간에 그 웹 서
비스가 수행시키려고 하는 서비스에 입력 데이터를 달할 수 있도
록 웹 서비스에게 입력 데이터를 입력할 수 있어야 함을 의미한다.
를 들어 “여행 약” 서비스에서 요청한 호텔이 약 불가능하면
“여행 약” 서비스는 요청자에게 다른 호텔들의 목록을 출력한 후
선택을 요구할 수도 있다.
□ 동 서비스 바인딩
한 웹 서비스는 다른 서비스를 부른다. 이것은 그 웹 서비스가 구
될 때 어느 서비스를 부를 것인지에 한 선택이 이루어져야 함을
의미한다. 즉, 웹 서비스의 요청자는 불려진 서비스를 바꾸거나 요청
자의 선호에 따라 체하는 것이 불가능하다는 것을 의미한다. 를
들어, “여행 약” 웹 서비스는 다른 여행 서비스를 고르지 못하고
원래의 항공사로부터만 여행을 약하려 할 것이다. 서비스 요청자는
이러한 상황을 수정하여, 신에 다른 비행기표 매 서비스를 이용
하려 할 수 있다.
상기 상황의 에서 요구되는 웹 서비스의 특징을 기술하기 한 다음
과 같은 추가 인 요소들이 필요하다.
여섯째, 한 웹 서비스에 의해 불려진 웹 서비스는 자신의 서비스를 제공
하기 하여 다시 다른 웹 서비스를 부를 수 있다. 각각의 불려진 웹 서
비스에 하여 실행 웹 서비스 락시(invoked web service proxy)라고 불
리는 락시가 선언되어야 한다. 한 락시는 단순히 기능 정의만으로 이루
어질 수도 있고, 이름, 사 조건, 사후 조건, 입력 포트, 출력 포트, 오류 포
트, 실행 시 구체 인 웹 서비스를 결정하기 한 바인딩 등으로 이루어질
수도 있다. 락시는 추후에 복잡한 체 서비스의 어느 지 에서 어느 서
비스가 실행되어야 할지를 정의하는 복잡한 순서 정의 규칙에 의해 사용된
- 61 -
다. 락시는 나 에 구체 으로 어느 서비스가 바인딩 될지 모르는 상태에
서 서비스를 정의하여 탁시키는 것을 가능하게 한다. 를 들어, “여행
약” 복합 웹 서비스에 “항공기 약”이라는 락시가 있을 수 있으며, 이
락시에는 출발지와 도착지에 한 입력 포트와 여행 일정을 돌려주는 출
력 포트만 정의하면 된다. “여행 약” 웹 서비스는 항공기를 먼 약하
고, 다음에 호텔을 약하고, 마지막으로 트 카를 약한다. 따라서 “항공
기 약”이 먼 수행된다. 그 지만 “항공기 약” 락시의 정의 시 에
구체 으로 어느 서비스가 사용될지가 결정되지 않았다. 를 들어 항공사
와 직 연락할 것인지, 여행사와 연락할 것인지, 아니면 최종 마감 비행기
표 매 서비스를 이용할 것인지 등이 결정되지 않았다. 이에 한 바인딩
은 락시에 정의된 바인딩 규칙에 근거하여 실행 에 이루어진다. 이 바
인딩은 한 서비스로 고정될 수도 있고, UDDI 같은 것을 찾아보는 것으로
정의될 수도 있고, 입력 포트에 입력된 입력 자료에 따라 달라질 수도 있다.
일곱째, 웹 서비스는 입력 포트와 출력 포트를 공개할 수 있다. 각 실행
웹 서비스 락시 한 입력 출력 포트를 공개할 수 있다. 웹 서비스의
각 입력 포트에 하여 데이터 값이 어느 실행 웹 서비스 락시의 입력 포
트로 달되어야 할지에 한 결정이 이루어져야 한다. 이러한 달은 0개,
1개, 는 복수개의 실행 웹 서비스 락시의 입력 포트에 해 이루어질
수 있다. 복합 웹 서비스의 입력 포트와 실행 웹 서비스 락시의 입력 포
트 간의 연결이 바로 자료 흐름(data flow)이다. 자료 흐름은 실행 웹 서비
스 락시의 출력 포트와 복합 웹 서비스의 출력 포트 간에도 정의되어야
한다. 나아가, 실행 웹 서비스 락시의 출력 포트는 다른 실행 웹 서비스
락시의 입력 포트에 연결될 수 있다. 이것이 한 실행 웹 서비스의 결과가
다음 단계의 하나 는 그 이상의 실행 웹 서비스의 입력이 되는 방법이다.
□ 자료 흐름은 웹 서비스의 한 입력 포트로부터 실행 웹 서비스 락시
의 둘 이상의 서로 다른 입력 포트 달될 때 조건이 붙을 수 있다.
이 조건은 입력 포트의 데이터 값에 한 부울 수식(Boolean
expression)을 포함한다. 부울 수식의 결과에 따라 다음 단계의 자료
흐름이 실행 에 정해진다. 이것은 자료 흐름이 다른 실행 서비스에
해 조건부로 처리되는 것을 가능하게 한다. 를 들어, 퍼스트 클래
스 항공권을 요청되었을 때는 퍼스트 클래스 항공권을 처리하는 여행
- 62 -
웹 서비스가 실행되어야 한다.
□ 다른 구성 요소는 분리(split)이다. 를 들어 값들이 하나의 웹 서
비스 입력 포트로부터 다음 단계의 여러 개의 입력 포트로 동시에
달될 수 있다. 이 경우 복수 개의 실행 웹 서비스는 동일한 입력 값
을 요구한다. 분리는 "값“에 의할 수도 있고, ”참조“에 의할 수도 있
다. ”값“에 의한 분리는 다음 단계의 입력 포트의 값이 복사본인 것
을 의미한다. ”참조“에 의한 분리는 입력 포트의 값이 동일한 메모리
역에 한 모사본인 것을 의미한다.
□ 자료 흐름의 끝에 있는 입력 자료는 서로 맞지 않을 수 있다. 이러한
경우 포트 간에 달된 자료의 형이 서로 맞아떨어질 수 있도록 형변
환(typecasting)이 필요하다.
□ 분리가 구 하기에 쉬운 것과 반 로 결합(join)은 더 어렵다. 이것은
여러 개의 자료 값이 하나로 병합되어야 하기 때문이다. 이를 하여
단계(step)이라는 개념이 도입되었다. 단계는 실행 웹 서비스 락시
와 비슷하게 정의된다. 단계는 여러 개의 데이터 값을 올바르게 결합
하는 결합 기능을 가능하게 한다.
여덟째, 자료 흐름은 한 복합 웹 서비스의 구 에서 단계뿐만 아니라 실
행 웹 서비스 락시의 실행 순서도 함축 으로 결정한다. 그 지만 자료
흐름이 모든 필요한 실행 순서를 다룰 수 있는 것은 아니다. 를 들어 자
료 흐름이 두 개의 실행 웹 서비스가 동시에 수행되는 것을 허용하도록 하
면서 두 실행 웹 서비스의 수행 순서가 지켜져야 한다면 자료 흐름은 이것
을 직 으로 표 할 방법이 없다. 유일한 방법은 두 개의 실행 웹 서비스
사이에 가공의 자료 흐름을 집어넣는 것이다. 이 게 하는 것이 가능하기는
하지만 결코 좋은 모델링 방법은 아니다. 신에 올바른 수행 순서를 정의
하는 제어 흐름(control flow) 순서가 두 실행 웹 서비스 사이에 도입되어야
한다. 이 경운 가공의 자료가 흐르지 않아도 된다. 순차(sequence)외에 다른
제어 흐름 구성 요소로는 분기(branch), for 루 , while 루 , 동시 수행 등
이 있다. 이 모든 구성 요소들은 수행 웹 서비스와 단계의 한 수행 순
서를 정의하기 해 사용될 수 있다.
제어 흐름과 자료 흐름은 웹 서비스의 비즈니스 로직에 한 외부로부터
- 63 -
의 근 부분을 구 할 수 있도록 한다. 제어 흐름과 자료 흐름에 의해 웹
서비스는 원하는 결과를 얻을 수 있도록 실행되는 것이 보장된다.
아홉째, 웹 서비스는 외 처리(exception handling)를 필요로 할 수 있
다. 실행 웹 서비스는 실패하여 오류나 외 코드를 돌려 수 있다. 이 경
우 에러 코드에 따라 오류 상황을 처리하기 하여 외 처리가 이루어져야
한다. 복잡 서비스에 의해 계획된 로 실행 웹 서비스 락시가 올바르게
수행될 수 없었기 때문에 웹 서비스는 에러 상태에 있게 된다. 실행 웹 서
비스 락시는 실행 웹 서비스가 에러 코드를 돌려주면 실행 에 그것을
감지하는 외 처리 부분을 포함하고 있다. 이런 경우 재시도를 정의하는
것이 가능하다. 재시도가 정의되어 있으면 실패한 실행 웹 서비스는 이번에
는 잘 실행될 것이라는 기 하에 다시 실행된다. 재시도에서 성공하면 웹
서비스의 실행은 계속된다. 실패할 경우에는 실행 웹 서비스의 오류 포트로
에로 코드가 달되어 보상 로직(compensation logic; 다음에 설명됨)에 의
해 처리된다.
열 번째, 실행 웹 서비스가 결국 실패하면 실행 인 웹 서비스는 에러
상태가 된다. 한 가지 가능한 방법은 오류 포트를 통하여 서비스 요청자에
게 오류 코드를 보내어 오류 상태를 통지하는 것이다. 이 경우 서비스 요청
자는 오류 상태를 처리하고 그것에 다시 응하여야 한다. 를 들어 호텔
약이 실패하면, 서비스 요청자는 다른 호텔을 어떻게 찾을 수 있는지를
알아내야 한다. 만약 이것이 실패하면 서비스 요청자는 이미 약된 비행기
를 취소하여야 한다. 이에 한 안으로, 복합 서비스 자신이 실패한 실행
웹 서비스에 한 보상(compensation) 략을 구 할 수 있다. 실행 웹 서
비스가 실패했을 때 웹 서비스는 실패에 한 보상 략을 정의할 수 있다.
보상 구성 요소는 실행 웹 서비스가 결국 실패한 후에 무엇이 일어나야 할
지를 정의하는 것을 가능하게 한다. 기본 으로 보상 구성 요소는 다른 웹
서비스(= 보상)를 표 한다. 보상 내에서 실행 웹 서비스 락시는 단계와
웹 서비스를 실행시키는데 사용될 수 있다. 를 들어, 호텔 약이 실패하
면, 해당 보상 로직은 원래 호텔의 반경 5마일 이내에서 다른 호텔을 검색
할 수 있다. 이 검색을 수행하기 하여 “호텔 검색” 서비스가 실행된다. 호
텔들이 발견되면 약 시도가 한개 성공하거나 모든 시도가 실패할 때까지
각 호텔들에 하여 방을 약하는 시도가 계속된다. 시도가 하나 성공하여
- 64 -
방이 약되면 복합 웹 서비스는 계획된 로 트 카를 약하는 것을 계
속한다. 그 지만, 모든 약시도가 실패하면 비행기 약이 취소된다. 취소
가 성공한 후 웹 서비스는 호텔을 찾을 수 없었다는 것을 알려주는 에런 코
드를 요청자에게 돌려 다. 모든 부작용(이 경우는 비행기 약)이 깨끗하게
정리된다. 물론 보상은 매우 정교하게도 만들어질 수 있다. 를 들어, 다른
호텔을 약하는 시도가 실패하 을 때 비행기가 취소되어야 할지에 한
질문이 요청자에게 보내어질 수도 있다.
(c) 커뮤니 이션 지향 기술 요소
커뮤니 이션에 있어서 사람들은 다음 세 개의 서로 다른 벨로 신호를
교환할 수 있다.
□ 메시지를 들었다.
□ 메시지를 이해했다.
□ 메시지의 내용에 동의한다.
여기서 두 종류의 메시지 확인을 구분해야 한다. 첫째, 메시지 서비스의
벨에서 보장된 배송은 수신자 측 메시징 서비스가 메시지를 받았다는 것
을 의미한다. 둘째, 그러나, 비즈니스 벨에서 보장된 배송은 충분하지 않
다. 수신자 측은 메시지가 보 된 후 무슨 일이 있어도 처리될 수 있도록
무결성 검사를 거쳤다는 보장을 필요로 한다. ebXML은 두 번째 형태의 확
인 응답을 표 할 수 있는 비즈니스 신호를 도입했다. WSMF도 이러한 다
른 벨의 확인 응답을 반 하 다. 비즈니스 계층에서 확인 응답은 메시지
의 내용에 동의하는 합법 인 바인딩 단계를 반 한다. 비즈니스 계층에
해서는 이미 논의했으므로, 남은 것은 메시지 이해 계층(message
understanding layer)과 메시지 교환 계층(message exchange layer)을 정의
하는 것이다.
열한 번째, 웹 서비스는 메시지 이해에 한 확인 응답과 련한 기술
방법을 필요로 한다. 이 계층의 확인 응답은 수신자가 메시지를 올바르게
분석하고 그것을 제 로 이해했다는 것을 나타낸다. 이것은 수신자가 메시
지를 처리하고 이해할 수 있었다는 것을 나타내지 그 내용에 동의한다는 것
- 65 -
을 나타내지는 않는다.
열두 번째, 웹 서비스는 메시지 교환 로토콜과 련한 기술 방법을 필
요로 한다. 웹 서비스 요청자로부터 웹 서비스 제공자에게 가는 는 그 반
경우의 메시지는 인터넷과 같은 네트워크를 통해 달된다. 네트워크는
신뢰할 수 있는 것도 있고 신뢰할 수 없는 것도 있다. 신뢰할 수 있는 네
트워크는 송된 메시지가 배달되는 것을 보장한다. 신뢰할 수 없는 네트워
크는 이것을 보장하지 않는다. 웹 서비스는 메시지의 달이 오직 한번만
일어나는 것을 가정한다. 신뢰할 수 있는 네트워크의 경우 복 감지에 의
해 메시지가 오직 한번만 달되도록 할 수 있다. 네트워크가 메시지의 배
달을 보장하기 때문에 복 달만이 감지되고 복 처리를 피하기 해
복 메시지는 제거된다. 신뢰할 수 없는 네트워크의 경우에는 좀 더 많은 일
을 해야 한다. 먼 , 배달이 보장되어야 한다. 이것은 메시지의 재시도와 재
시도 최 횟수를 이용한 타임아웃에 의해 달성할 수 있다. 메시지가 보내
진 후 주어진 시간 내에 확인응답이 없으면 메시지는 손실된 것으로 가정된
다. 그러면, 메시지를 다시 보내게 되고 타임아웃이 다시 시작된다. 이 과정
은 재시도 최 횟수만큼 반복되고, 반복하는 동안 계속하여 실패하면 메시
지 송은 실패한다. 복 감지는 작업 에 구 된다. 메시지를 오직 한
번만 송되도록 하는 구 을 메시지 교환 로토콜이라고 부른다.
(d) 보안과 신뢰
열세 번째, 보안과 신뢰는 웹 서비스의 두 가지 기본 인 특징이다. 보안
은 부인 쇄(non-repudiation)를 포함하여 메시지 교환을 안 하게 보장하
는 것을 말한다. 메시지 교환을 안정하게 보장하기 하여 다음 사항들이
만족되어야 한다.
□ 메시지는 훼손되지 말아야 한다.
메시지가 네트워크의 한쪽 끝에서 다른 쪽 끝으로 송되는 도 에
메시지의 내용을 변경하려는 시도는 감지되어야 한다. 이것은 메시지
의 자서명에 의해 달성된다.
- 66 -
□ 메시지는 도청되어 해석되지 말아야 한다.
네트워크 상의 도청자가 메시지를 해석하는 것을 막기 하여 송
되는 메시지는 암호화되어야 한다. 공개키 기반 구조(PKI)가 이를
해 사용될 수 있다.
□ 메시지는 송신자로부터 온 것이어야 한다.
메시지의 헤더 부분에 주장되어 있는 메시지 송신자의 이름은 수신
자가 송신자를 유일하게 식별할 수 있는 토큰을 갖고 있지 않는 한
메시지 송신자가 그 이름의 사람이라는 보장이 되지 못한다. 이것은
메시지의 자서명에 의해 해결된다.
□ 메시지는 손실되지 않아야 한다.
메시지는 감지되지 않은 상태에서 손실되어서는 안 된다. 순차 으로
부여되는 메시지 번호는 이것을 해결하기 한 수단이 된다.
□ 메시지는 임의로 추가되어서는 안 된다.
순차 으로 부여되는 메시지 번호는 메시지가 임의로 추가되는 것도
방지한다.
부인 쇄는 송신자 는 수신자가 상 편이 메시지를 받았거나 보냈다
는 것을 확인하기 한 보안 메커니즘이다. 메시지는 암호화되어 달된 상
태 그 로 장되었다가 나 에 송신자를 증명하는 데 사용된다.
신뢰는 보안과는 완 히 다른 측면이다. 비록 메시지의 보안과 부인
쇄가 이루어졌다고 하더라도, 그것이 메시지를 주고받는 당사자 간의 신뢰
를 의미하지는 않는다. 공 자는 특정한 시간에 정해지 품질의 상품을 배달
할 것을 약속할 수 있다. 그러나 이것이 항상 지켜진다고 보장될 수는 없다.
거래 당사자는 거래 경험을 바탕으로 신뢰를 구축해 나가야 한다.
(e) 기타 사항
열네 번째, 웹 서비스를 특징짓는 기능 외 인 요한 특성들도 있다. 그
로는 서비스의 지리 근 가능성( , 웹 기반 꽃 가게), 서비스 사용료,
웹 서비스가 결과를 출력할 때까지의 평균 는 최장 시간 등을 들 수 있다.
- 67 -
(라) 조정자(Mediator)
개작자(adaptor)는 컴포 트 기반 소 트웨어 개발에서 매우 요하다.
개작자는 개체를 재사용 가능하게 기술할 수 있게 하며, 입력과 출력 구문
이 서로 다른 객체들을 조합하는 것을 가능하게 한다. 웹 기반 컴퓨 과 같
은 개방형의 유연한 환경에서 개작자는 고유의 이종성(heterogeneity)을 극
복할 수 있는 필수 인 수단이다. 이 이종성은 여러 형태로 나타날 수 있다.
□ 자료 구조의 조정
웹 서비스는 다른 웹 서비스에 해 입력을 제공할 수 있으나, 그것
이 원하는 형태의 자료가 아닐 수 있다.
□ 비즈니스 로직의 조정
두 개의 웹 서비스는 보완 인 기능을 제공하고, 본질 으로 함께 연
결될 수 있으나, 그들의 상호작용 형태가 서로 맞지 않을 수 있다.
□ 메시지 교환 로토콜의 조정
HTTP 에 구 된 SOAP는 신뢰할 수 없는 네트워크이므로 메시지
가 단 한번만 송되도록 복 감지, 타임아웃, 재시도, 재시도 최
횟수 등을 포함한 거래 당사자간의 확인 응답이 필요하다. 웹 서비스
는 그러한 송의 신뢰를 확보하기 한 방법이 다를 수 있다.
□ 동 인 서비스 실행의 조정
웹 서비스는 자신의 기능을 수행하기 해 다른 웹 서비스를 실행시
킬 수 있다. 이것은 미리 정해진 시나리오에 의해 수행될 수도 있지
만, 한 다른 하 목표를 참조하게 함으로써 좀 더 유연하게 수행
될 수도 있다. 이러한 유연한 수행 에는 다른 웹 서비스가 동 으
로 실행될 수 있다.
(a) 데이터 구조의 조정
Microsoft BizTalk Server를 포함한 몇몇 B2B 통합 임워크는 여러
가지 XML 기반 표 들을 자상거래와 통합하기 한 지원을 제공한다. 그
- 68 -
지만, 그러한 평면 이고 직 인 근 방법은 확장성을 제공하지 못한
다. cXML, xCBL 등과 같은 XML 표 에서 주소 표기를 매핑하는 단순한
통합작업도 복잡한 XSL-T 규칙을 필요로 한다. 결과 으로, 이러한 통합
근법은 비용이 많이 들면서도 확장성이 없다. 이러한 직 매핑 근법의
어려움은 아래와 같은 데이터 할당 로세스의 개념 으로 다른 측면을 한
군데에 꼬아 넣었기 때문이다.
□ 구문으로부터의 정보 추출
원본 XML 사투리는 한 조각의 정보에 해 자신만의 구문 표 을
정의한다.
□ 서로 다른 정보의 개념 표 간의 매핑
XML 표 은 한 조각의 정보를 모델링하기 하여 서로 다른 개념,
서로 다름 개념 구조, 서로 다른 자료형, 서로 다른 자연어 표기를
사용할 수 있다.
□ 정보를 정해진 구문으로 표 하는 방법
목표가 되는 XML 사투리 한 한 조각의 정보에 해 자신만의 구
문 표 을 정의한다.
그러므로 서로 다른 표 으로부터 정보를 실제로 조정하는데 있어서 실
제 정보와 세 개의 하 단계들을 기술하기 한 간 데이터 모형을 사용
하는 계층 통합 아키텍쳐를 도입하 다.
(b) 비즈니스 메시지 이해 로직의 조정
비즈니스 로직 벨에서 구매 주문, 송장 등과 같은 사업 내용을 갖는
메시지가 처리된다. 두 거래 당사자는 각각의 역할( 매자, 구매자)에 한
자신만의 공개 업무 로세스를 구 해 놓았을 수 있다. 그 지만, 그 두 공
개 업무 로세스는 서로 일치하지 않을 수가 있다.
비즈니스 로직 조정은 공개 로세스에 있어서의 불일치를 보정해야한
다. 데이터 불일치(data mismatches)와 로세스 순서 불일치(process
sequencing mismatches)의 두 종류의 불일치가 존재할 수 있다. 데이터 불
- 69 -
일치에는 다음과 같은 경우가 있을 수 있다.
□ 데이터 완비 일치(data-complete match)
이 경우에 요청자에 의해 보내지는 메시지와 제공자가 기 하는 메
시지는 서로 정확하게 일치한다. 조정에 필요한 유일한 작업은 서로
간에 메시지를 변환해주기만 하면 된다. 이것은 조정자가 거의 할 일
이 없는 자명한 경우이다.
□ 데이터 완비 불일치(data-complete mismatch)
데이터 완비 불일치는 메시지의 재배열에 의해 불일치가 해결될 수
있는 것을 의미한다. 모든 데이터가 주어진 메시지 내에서 획득 가능
하므로, 그 데이터들은 단지 재구성되고 재배열되기만 하면 된다.
□ 데이터 과다 불일치(data-over-complete mismatch)
데이터 과다 불일치는 제공자가 요구하는 것보다 더 많은 데이터를
요청자가 보낼 때 일어난다. 그 지만, 요청자에게 돌아가는 메시지
가 이 여분의 데이터를 요구할 수도 있으므로 조정자가 여분의 데이
터를 제거할 수는 없다. 이 경우 조정자는 여분의 데이터를 장하
다가 나 에 요청자에게 돌아가는 메시지에 포함시켜 완 하게 하여
야 한다.
□ 데이터 부족 불일치(data-incomplete mismatch)
이 경우는 요청자가 제공자에게 충분한 데이터를 보내지 않을 때 일
어난다. 이것은 제공자에 한 메시지에 일부 데이터가 빠짐으로써
제공자를 실패하게 하는 경우를 의미한다.
두 번째로 비즈니스 로직 조정자는 로세스 순서 불일치를 해결해야 한
다. 기본 으로 각 공개 로세스는 어떤 순서로 메시지를 보내야 하는지와
메시지를 요청하여야 하는지를 정의한다. 이와 련하여 다음과 같은 불일
치 상황들이 존재할 수 있다.
□ 정확한 일치
각 공개 로세스는 다른 공개 로세스가 요구하는 정확한 순서
로 메시지를 보낸다. 이 경우 불일치가 존재하지 않으므로 조정자는
- 70 -
순서 불일치를 보정할 필요가 없다.
□ 해결 불가능한 메시지 불일치
이것은 요청자가 보내지 않은 메시지를 제공자가 기 하는 경우이다.
이것은 필요한 메시지가 빠져있음을 의미한다. 조정자가 의미 있는
메시지를 생성하는 조정 로직을 제공할 수 없으면 해결 불가능한 불
일치가 존재한다.
□ 해결 가능한 메시지 불일치
이것은 요청자가 보내온 각각의 메시지를 조합하여 제공자가 요구하
는 모든 데이터를 마련하여 보내 수 있는 경우이다.
□ 해결 불가능한 순서 불일치
제공자가 기 하는 처리 순서와 요청자가 요구하는 처리 순서가 불
일치 하는 경우이다.
□ 해결 가능한 순서 불일치
제공자가 어떤 순서로도 처리할 수 있는 경우 조정자는 요청자가 메
시지를 보내는 순서 로 제공자에게 달함으로써 순서 불일치를 해
결할 수 있다.
(c) 교환 로토콜의 조정
메시지 교환 로토콜의 조정과 비즈니스 로직의 교환을 구분하는 것은
요하다. 웹 서비스는 HTTP에 기반한 SOAP를 이용하고 있다. 이 경우
송 채 (HTTP)에 암호화가 이루어질 수도 있고, SOAP 메시지 자체가 암호
화될 수도 있다. 자서명도 마찬가지로 일어날 수 있다. 따라서 요청자와
제공자는 어떻게 암호화하고 어떻게 자서명할 것인가에 하여 합의하여
야 한다. HTTP 상의 SOAP는 신뢰할 수 없다. 이것은 거래 당사자들이 타
임아웃, 재시도, 재시도 최 횟수, 복 감지 외에 송층 수 의 확인 응
답을 구 해야 하는 것을 의미한다. 이것은 교환 로토콜이다. 제공자가 제
공하지 않는 특정 행동을 요청자가 기 할 경우 교환 로토콜을 조정할 필
요가 있다. 를 들어 제공자 P는 그가 생각하기에 교환이 실패하 다는 사
- 71 -
실을 통지하는 오류 메시지를 보낼 수 있다. 그 지만 요청자 R은 에 그
러한 행동을 만나본 이 없어서 조정을 필요로 하게 된다. 즉, R은 명확한
오류 통지 메시지를 처리할 필요가 있는 것이다. 이 조정은 구매 주문이나
송장과 같은 비즈니스 메시지를 처리하는 비즈니스 로직의 조정과는 다른
것이다.
(d) 웹 서비스 조합을 한 시나리오
다음과 같은 상황을 가정하자.
1) 웹 서비스 제공자 P와 요청자 R이 있다.
2) P는 웹 서비스 w1, w2, w3를 제공한다.
3) R은 w1, w2, w3를 조합한 로직을 서비스 받기를 원한다.
그러면 복합 웹 서비스를 정의하기 한 다음과 같은 방법들이 있을 수
있다.
1) 단순 상황: 제공자 기반 조합
P 자신이 w1, w2, w3를 하나의 새로운 웹 서비스 w4로 조합한다. 따
라서 w4는 복합 서비스가 된다. 그러나 R에 있어 w4는 단일 웹 서비
스로 제공되므로 이러한 상황을 R이 알 필요는 없다. 이 조합은 R에
게는 보이지 않는다.
2) 간 상황: 클라이언트 기반 조합
P는 w1, w2, w3를 조합하지 않는다. 신에 R이 이들을 정해진 순서
로 부름으로써 이들을 조합한다. 이 경우 R은 w1, w2, w3로부터
새로운 웹 서비스 w4를 구축한다. 이 경우 P는 R이 그 게 하는 것
을 모른다. P는 독립 으로 불리는 웹 서비스들을 각각 제공하
는 것일 뿐이다.
c) 발 상황: 웹 서비스 조합에 한 선언 명시
P는 w1, w2, w3를 조합하지 않는다. 그 지만, P는 제약 조건을 통하
여 세 서비스의 수행 순서를 정의할 수 있다. 따라서 한 묶음의 제약
- 72 -
조건들을 조합된 웹 서비스 w4로 간주할 수 있다.
(마) 결론
지 까지 Web Service Modeling Framework(WSMF)라고 불리는 모델링
임워크에 하여 설명하 다. WSMF의 주요 요소는 온톨로지, 기능 명
세, 단순 복합 웹 서비스, 그리고 조정자이다. WSMF의 목 은 성숙되고
확장 가능한 웹 서비스에 기반한 자상거래를 가능하게 하는 것이다. 이것
은 다음의 두 가지 보완 인 원리에 기반한 구조에 의하여 달성될 수 있었
다.
□ 자상거래 응용을 실화하기 한 다양한 컴포 트들 간의 강한 디
커 링(de-coupling)
□ 어느 구와도 연결될 수 있는 강력한 조정 서비스(mediation
service)
- 73 -
제 4 장 지능형 웹 서비스를 한 아키텍쳐 분석
시맨틱 웹 서비스는 자동화된 웹 서비스 찾기, 선택, 실행을 일련의 비즈
니스 로직에 근거하여 실행할 수 있는 기반구조이다. 이번 장에서는 이를
지원하기 한 시맨틱 웹 서비스 아키텍쳐 기반기술과 련하여 기술한다.
본 보고서에서 제시하는 아키텍쳐에 한 설명을 개하기 해 아래의
세 가지 내용을 차례 로 제시할 것이다.
- 아키텍쳐 요구사항
- 시맨틱 웹 서비스 모델링 임워크 제시
- 시맨틱 웹 서비스 개념 아키텍쳐 제시
4.1 개요
시맨틱 웹 서비스는 정 인 기존의 웹을 기계가 인식 가능한 형태로 표
한 기존의 시맨틱 웹 표 을 웹 서비스로 발 시킨 것이다.
웹 서비스 기술이 발 해 오면서 의미(Semantic) 표 이 연계되어 나타
나게 되었다. 다음 그림에서 웹 서비스 스택상의 의미 표 이 연계되는 부
분을 보이고 있다.
- Service Description: WSDL (서비스 명세)
- Service Publication: UDDI (서비스 공개)
- Service Discovery: UDDI/WS Inspection (서비스 찾기)
- Service Flow & Composition: BPEL (서비스 흐름과 조합)
- 74 -
<그림 4-1> 웹 서비스 스택과 의미(Semantic) 표
웹 서비스 근간의 e-Commerce의 비 은 참여하는 구든 모든 이들과
거래, 상이 가능하다는데 있다.
개방형의 유연한 구조를 가진 e-Commerce의 근간은 다양한 데이터포맷
과 비즈니스로직을 다룰 수 있어야 한다.
o 웹 서비스 기반의 e-Commerce 아키텍쳐 요구사항
- e-Commerce 어 리 이션의 다양한 컴포 트간의 강력한 de-coupling
지원
- 상호간의 일반 인 규칙에 근거한 강력한 개능력
4.2 아키텍쳐 요구사항
웹 서비스 근간의 e-Commerce의 비 을 실 할 아키텍쳐는 다음의 항
목들을 만족해야 한다.
- 75 -
o Document Type
- 서비스 요청자와 서비스 제공자간의 실질 인 비즈니스 데이터를 표
o Syntax
- XML 는 그 외의 다양한 데이터 표 양식
o Semantics
- 의미 으로 정확한, 서비스 제공자와 요청자간의 정확한 의사소통 지원
- "rules"는 항시 인 결과를 제공
- 교환되는 문서의 의미가 규정되어야 함
o Transport Binding
- 서비스 요청자와 서비스 제공자간의 상호교환을 해 동의된 일련의
로토콜 지원
- HTTP/S, S/MIME, FTP, EDIINT
o Exchange sequence definition
- 서비스 요청자와 서비스 제공자간의 메세지 교환에 한 보증
o Process definition
- 정의된 비즈니스로직에 따라 서비스 요청자와 서비스 제공자간의 일
련의 의사소통 순서를 지원
o Security
- 개별 메세지에 한 안 보증
이상에서 제시된 요구사항을 만족하는 시맨틱 웹 서비스 아키텍쳐를 본
보고서에서는 Semantic Web Service Modeling Framework, Semantic Web
Service Conceptual Architecture로 제안할 것이다.
- 76 -
4.3 Semantic Web Service Modeling Framework
이 장에서는 시맨틱 웹 서비스 모델링 임워크를 소개한다. 시맨틱
웹 서비스 모델링 임워크를 설계함에 있어 기본 으로 두 가지 - (1)
maximal de-coupling, (2) scalable mediation service -를 고려하 다.
제시하는 모델링 임워크의 주요 구성요소는,
- Ontologies: 다른 요소들에 어휘제공
- Goal repositories: 목표 정의
- Web services descriptions: 웹 서비스의 다양한 요소 정의
- Mediators: 상호 운용에 한 진
온톨로지는 시맨틱 웹의 핵심 기술이며, 기계가 이해할 수 있는 표 을
제공한다. 모델링 임워크에서의 온톨로지는 다른 구성요소들에 한 표
어휘를 제공한다.
목표에 한 정의는 서비스 요청자가 요구하는 서비스를 표 한다. 실제
인 웹 서비스의 표 과는 상이한데, 그 이유는 목표에 한 정의와 웹 서
비스의 정의는 N:M 의 계를 가지기 때문이다.
많은 웹 서비스 기술언어는 단순한 것부터 복잡한 것 까지 많은 종류가
있다. 단순한 것은 입/출력만을 가지는 형태이지만, 복잡한 것은 로세스
와 다른 웹 서비스와의 연동을 한 추가 인 내용을 가진다.
재자는 요소들간의 의미 설명을 사용하여 입, 출력을 연결하며, 지식
기반 시스템의 아키텍쳐 상의 재자를 설명하면,
(1) 상이한 요소간의 de-coupling
(2) 세 가지 서로 다른 요소간의 캡슐화
(3) 요소간 명시 상호작용
요한 은 요소들 간의 상이한 의사소통 유형을 재하여야 한다는 것이다.
- 77 -
4.4 Semantic Web Service Conceptual Architecture
앞 에서 제시한 모델링 임워크 기반 하에 e-Commerce를 한 이
상 인 시맨틱 웹 서비스의 아키텍쳐를 실 하기 하여 개념 아키텍쳐를
설계하 고 이를 본 에서 제시한다.
체 으로 개념 아키텍쳐는 세 가지 단계의 이어로 규정된다.
□ front-end tool: 시맨틱 웹 서비스 콤포 트를 리하기 한 툴
□ components: 시맨틱 웹 서비스의 주요 서버 콤포 트
□ storage, external components: 온톨로지 기반 하에 근 가능한 주
요 데이터, 외부 엔진에 근하기 한 기능
<그림 4-2> Semantic Web Service Conceptual Architecture
- 78 -
4.4.1 Components
콤포 트는 시맨틱 웹 서비스를 가능하게 하는 기능을 제공한다.
□ Centralized coordinal and manager
콤포 트 이어의 모든 기능을 리하는 앙 집 화된 역할을 담
당. 들어오는 메세지를 모델링 임워크에서 정의된 내용에 따라
실행하기 해서 콤포 트들 간에 소통시키는 역할을 한다.
□ Semantic transformation
세 가지 벨(Data, Business Logic, Message Protocol로 지원된다.
□ Discovery
discovery기능을 제공하는 콤포 트이며, 단순한 형태로는 UDDI에
속하는 형태가 될 것이다.
□ Audit/tracking
신뢰성은 웹 서비스 기술에 있어 요한 부분이다. 이 콤포 트는 서
로 다른 서비스 제공자/요청자간의 추 /감시 기능을 제공한다.
□ Trading partner manager
거래 트 의 정보(identification, name, address, security keys,
endpoint)를 유지, 리하는 콤포 트이다.
□ Negotiation
아키텍쳐 상의 거래 당사자들끼리의 negotiation과 agreement를 지원
하는 콤포 트 이다. match-making도 기능의 일부로 포함된다.
□ Security
권한과 인증을 해 사용자 정보를 유지, 리하는 기능을 제공한다.
나아가서 메시지의 보안 한 담당한다.
□ Workflow, Web service, Ontology, Goal Manager
내부 장 공간에서 리되는 여러 모델링 임워크의 정보를 호
- 79 -
출하는 역할을 수행하는 콤포 트 이다.
□ B2B Protocol engine
B2B 로토콜의 각 계층과 호출의 순서를 제어하는 기능을 한다. 일반
으로 B2B 로토콜(ex. RosettaNet, OAGIS, ebXML)은 다계층으로
되어있으며, 문서포맷, 호출순서, 패키징, 달바인딩 등을 포함한다.
□ Deployment
웹 서비스를 서비스 요청자들이 사용할 수 있게 상이한 랫폼에 손
쉽게 개하는 기능을 담당한다.
□ Adapters
구성요소에 한 정보를 참조하여 요소간의 의미 입/출력 연결을
가능하게 한다. 다음에 제시되는 세 가지 구별되는 기능을 제공한다.
- 존재하는 로토콜의 구 을 통한 연결(ex, RosettaNet, EDI)
- 리거시 시스템, 직 개발한 시스템과의 연결
- 인터페이스 표 (ex. WSDL, J2EE JCA)을 지원
□ Transport
네트워크 로토콜(ex. HTTP, FTP, SMTP, VANs, SWIFT)을 구 하
여 네트워크상의 데이터 달을 담당한다.
4.4.2 Ontology and Mediation Components
여기서는 세부 으로 시맨틱 웹 서비스 아키텍쳐의 온톨로지 콤포 트와
개 컴포 트의 기능에 해서 세부 으로 설명한다.
□ Ontology Support
앞서 설명한 모델링 임워크에서 제시된 온톨로지 련 2가지 요
소인 document type과 semantics에 해 살펴보았다. 술한 로
document type은 거래 당사자 간 비즈니스 데이터의 구조를 정의한
- 80 -
다. document type은 concept, concept의 속성(attribute), concept간의
계를 온톨로지로 표 한다. 온톨로지는 이러한 표 에 있어 매우
정확한 표 을 제공한다.
의미(semantics)는 정확한 도메인 값을 사용하여 정확하게 생성된 속
성을 통해 정의되어야 한다. 속성의 모든 값이 의미 으로 정확한 것
은 아니다. 를 들면 구매의뢰서가 특정 모델번호를 참조한다면
상이 되는 특정 제품을 상으로 하여야 한다. 여기서 모델번호는 구
문 으로 문제는 없지만 의미 표 은 아니다.
아키텍쳐 상에서 온톨로지 서버와 련된 장소는 온톨로지로 표
된 도메인 개념(concept), 어 리 이션 개념을 장, 리한다. 여기
서의 온톨로지표 은 RDF에 근거한 DAML-S 는 OWL을 사용한다.
□ Mediation Support
본 보고서에서 제시한 시맨틱 웹 서비스 아키텍쳐는 거래 당사자간
의 통신방식이 Peer-to-Peer 통신 구조기반하에 동작한다고 가정하
다. 이 것은 거래 당사자들이 어떤 개 없이 직 통신한다는 것을
뜻한다. 아키텍쳐는 거래 참여자들간의 ‘연결’을 지원한다. 물론 ‘
개’를 하지 못한다는 것은 아니다. 이 경우에는 거래 참여자와 아키
텍쳐간의 Peer-to-Peer통신이 이루어진다.
Peer-to-Peer구조에서의 순서(consequence)는 다양한 ‘ 개’(document
type, semantics, business process간의)를 제공해야 한다. 구매의뢰서
같은 문서는 거래 당사자간 정확히 같은 형태를 가지진 않을 것이다.
모든 가능한 ‘불일치’가 존재 할 수 있다.
더하여 비즈니스 로세스에서도 ‘불일치’가 존재 할 수 있는데, 한쪽
은 내부 으로 ‘승인’을 사용하는데 다른 한쪽은 사용하지 않을 수
있다.
아키텍쳐는 semantic transformation 콤포 트간의 ‘ 개’를 포함한다.
각각의 의미들의 불일치를 일련의 ‘rule set'을 이용하여 변형한다. 동
일한 온톨로지라도 서로 다르게 의미 으로 변형되지 않을 수 있기
때문이다.
- 81 -
4.4.3 Conceptual Architecture의 사용
이번 장에서는 제시된 시맨틱 웹 서비스 아키텍쳐를 사용하여 하나의
제를 제시해 보인다. 제는 컴퓨터에 한 구매주문(PO; Purchase Order),
구매주문계약(POA; Purchase Order Agreement) 사례를 용한 것이다.
구매주문에 한 의사결정이 내려지면, ERP 시스템에서 구매주문서(PO)
가 Adapter로 송된다. Adapter로 PO가 입력되면 Audit 콤포 트에 기록
이 되어 후에 PO의 수여부를 단하는데 사용 할 수 있다. PO를 수받
은 Coordinator는 계속해서 수행될 로세스를 조정한다. PO를 통지받은
Workflow Manager는 기 비즈니스 로세스를 수행시킨다. 여기서의 비
즈니스 로세스는 단순이 PO를 송하는 작업만 수행된다.
이어서 B2B Protocol Engine은 PO를 달받아 메시지를 포매 하여
Trading Partner Management에 넘기고 Trading Partner Management 콤포
트는 달할 거래 트 를 찾는다. Transport 콤포 트는 메시지를 트
에게 송한다.
POA가 도착하게 되면 Transport 계층에서 수신하여 B2B Protocol
Engine에 넘기게 된다. 그리고 Transformation 콤포 트에선 온톨로지 기반
의 메시지 변환을 거쳐 시스템이 인식 가능한 형태로 만든다. 달되는 메
시지는 Security 콤포 트에 의해 보안 련된 처리작업을 수행하게 된다.
마지막으로 Adapter 콤포 트를 통해 ERP 시스템이 POA를 수신하게 된다.
<그림 4-3> 시맨틱 웹 서비스 아키텍쳐 제
- 82 -
제 5 장 지능형 웹 서비스의 연구 사례
5.1 지능형 웹 서비스 검색 서비스 연구 사례
본 에서는 지능형 웹 서비스의 여러 기능 웹 서비스에 한 지능형
검색에 련된 최신 연구 결과들을 살펴 으로써 재 이 분야의 State of
the Art를 알아보고 그 표 화 방향과 국내에서의 응 방안 도출에 기반을
제공하고자 한다.
5.1.1 CMU의 ATLAS (Agent Transaction Language for Advertising
Services) 로젝트
5.1.1.1 로젝트 개요
카네기멜론 학의 로 연구소(Robotics Institute)에서 진행 인
ATLAS (Agent Transaction Language for Advertising Service) 로젝트는
에이 트나 임의의 장치들이 자신의 목 에 필요한 상 방을 찾고 상호 운
을 가능하게 하고자 하는 DAML 기반의 에이 트 공시 언어이다.
ATLAS의 개발 목표는 다음과 같다.
에이 트의 역량, 서비스 매개 변수, 미들 에이 트 서비스 보안
메카니즘을 표 할 수 있는 DAML 온톨로지의 개발
웹 기반 데이터 질의 포탈들과 같은 정 동 문서들에 한 온
톨로지의 개발
DAML을 기반으로 표 된 정보의 창출, 수정 응용에 련된 도구
의 개발
질의 에이 트들을 한 에이 트의 역량과 매개 변수들을 표 하는
체계 구축
언어 번역 서비스 같은 에이 트 서비스 혹은 개별 인 에이 트 커
- 83 -
뮤니티간의 상호 운 성을 한 온톨로지의 개발
DAML 기반의 에이 트 서비스들을 인식할 수 있는 매칭 알고리즘
방법론의 개발
이상과 같은 ATLAS 로젝트의 한 하부 과제로서 DAML-S Match
Maker 혹은 Semantic Match Maker가 진행 에 있는데, 이는 지능형 웹
서비스 임워크 하에서 오늘날과 같이 빠르게 서비스들이 새롭게 등장하
고, 진화해가는 상황에서 웹 서비스 요청자와 웹 서비스 제공자를 하게
매칭시켜야 하는 필요성을 그 동기로 하고 있다.
이러한 Semantic Match Maker는 먼 웹 서비스의 역량을 바탕으로 개
별 웹 서비스를 찾아내는 문제에 을 맞추고 있으며, 이를 해결하기
해서는 각 웹 서비스의 역량을 표 할 수 있는 언어와 이를 바탕으로 서비
스 공고와 서비스 요청 간에 매칭을 수행하여 요청에 해 가장 한 서
비스를 인식할 수 있는 매칭 알고리즘이 필요하다. 먼 첫 번째 목 을
해서 Semantic Match Maker는 DAML-S를 채택하고 있으며, 이를 통해 웹
서비스에 한 보다 의미 표 을 수행할 수 있으며 한 DAML-S의 기본
온톨로지 언어인 DAML+OIL을 통해 포함 계 논리 추론이나 개념 분류
체계를 이용할 수 있게 해 주고 있다.
본 과제에서는 나아가 DAML+OIL이 규칙 표 과 이에 한 추론이 불
가능한 단 을 보완하기 해 하나의 규칙 표 표 제안인 RuleML을
추가로 채택하고 있다. RuleML은 특히 웹 서비스의 조합을 해 계획 단계
에서 각 웹 서비스의 입력과 출력에 련된 제약이나 제 조건 효과 표
을 유효하게 할 수 있도록 하고 있다.
이러한 DAML-S Matchmaker는 특징 으로 서비스 역량의 표 들 간에
구문 유사도 뿐만이 아니라 의미 유사도 까지도 측정하기 하여 정보
추출 기술(information retrieval), 인공 지능(AI), 소 트웨어 공학을 활용
하고 있다. 특히 주요 컴포 트인 매치메이킹 시스템의 매칭 엔진은 네임스
페이스(name space) 비교, 온톨로지 유사도 매칭, 온톨로지 포함 계 매칭,
제약 매칭 등의 다섯 가지 필터를 동시에 활용하고 있다.
물론 사용자는 이러한 필터들에 하여 매칭의 질 수 과 성능간의 트
이드오 (trade-off)를 고려하여 설정이 가능하며 나아가 이와 같은 방법론
- 84 -
을 통하여 UDDI의 의미 매칭으로의 확장까지 제안하고 있다.
5.1.1.2 웹 서비스의 공시 (Web Service Advertisement)
Semantic Match Maker에서는 웹 서비스의 공시를 해 DAML-S에서
제공하는 Service Profile 온톨로지를 사용하고 있다. <그림 5-1>은 이와 같
은 DAML-S의 Service Profile에 한 상 온톨로지를 보여주고 있다. 이와
같은 상 온톨로지는 논리 으로 세 가지 부분으로 나뉘어 지는데, 먼
그림 하단에 보여지고 있는 Actor에 련된 부분으로서 서비스의 제공자에
한 정보를 표 하게 한다. 두 번째 부분은 그림 단에 보여 지고 있는
함수 속성 군 (Functional Attributes)으로서 를 들면 Quality Rating이
나 Geographical Radius 등이 그 것이다. Quality Rating은 해당 서비스에
부여된 임의의 수이며, Geographical Radius는 해당 서비스의 지역 서비
스 범 를 표 하고 있다. 이러한 함수 속성들을 바탕으로 서비스 요청에
포함된 제약들에 해 한 필터링이나 매칭을 수행할 수 있는 것이다.
마지막으로 그림의 최상단부에 나타나고 있는 서비스의 함수 기술
(Functional Description)은 서비스의 입력, 출력, 제 조건 사후 효과 등
에 련된 서비스의 역량(capability)을 표 해 주고 있다. input은 특정 원하
는 출력에 제공하기 해 서비스가 어떠한 입력을 필요로 하는지를 알려주
며, 를 들면, 책 구매를 한 서비스의 필요 입력은 원하는 책의 제목과
자명이 될 것이다. 한편 이에 한 출력(output)으로는 주문이 수되었으
며, 성공 으로 처리되었다는 확인 메시지 일 것이다. 한편 제 조건
(preconditions)은 이 서비스의 성공 수행을 해 제되어야 하는 실세계
에서의 조건으로서 책 구매의 에서 본다면 신용카드의 유효 기간일 것이
다. 한 서비스의 수행으로 말미암아 발생하는 실세계에서의 변화는 이 서
비스의 효과(effect)로서 역시 책 구매의 에서는 신용카드에 결제가 이루어
지며, 책의 소유주가 바 는 것이라 할 수 있다.
- 85 -
<그림 5-1> DAML-S에서의 Service Profile에 한 상 온톨로지
이상에서의 DAML-S의 서비스 로 일을 통하여 서비스를 제공하고자
하는 제공자는 자신의 서비스 역량(capability)에 하여 공시할 수 있으며,
동시에 Semantic Match Maker의 환경에서는 서비스 요청자 역시
ServiceProfile을 이용하여 자신이 원하는 서비스에 한 요구도 기술하게
된다. 아래의 <그림 5-2>는 DAML-S의 서비스 로 일을 기반으로 작성된
서비스 요청의 로서 가격(Price)을 입력으로 하며, 결과로 세단(Sedan)에
한 자료를 제공받을 수 있는 서비스를 찾는 상황을 묘사하고 있다.
- 86 -
<그림 5-2> 자동차 매 서비스에 한 요청 로 일
5.1.1.3 웹 서비스의 매칭 (Web Service Matching)
Semantic Match Maker에서는 서비스에 한 요청과 이미 공시된 웹 서
비스의 매칭에 있어 “sufficiently similar"라는 개념을 바탕으로 매칭을 수행
하고 있다. 다시 말해 매칭(exact matching)을 벗어나 좀 더 유연한 즉
유사 매칭을 포함하고자 한다는 것이다. 정리해 보면 Semantic Match
Maker는 다음과 같은 목 들을 달성하고자 한다.
매칭 엔진은 서비스 매칭 엔진에서 이용 가능한 온톨로지를 바탕으로
서비스 공시 요청 간에 유연한 의미 매칭을 목 으로 하고 있다.
매칭에 유연성을 부여함에도 불구하고 false positive false
negative 에러를 최소화하고자 한다. 나아가 사용자로 하여 매칭의
유연성 정도를 통제할 수 있게 구 하고 있다.
매칭 엔진에서는 어떠한 형태로는 서비스 제공자나 서비스 요청자로
하여 매칭이 되지 않거나 혹은 부 한 매칭이 일어남으로 인한
부담을 지게 함으로써 그들의 서비스 공시나 요청의 작성에 가능한
정직하도록 유도하여야 한다.
매칭 과정은 효율 측면에서 최 화되어야 하며, 요청자에게 서비스
검색에서의 효과를 상쇄시킬 수 있는 지나친 지연 부담을 지게 해서
는 안 된다.
- 87 -
이상의 목 을 달성하기 해 Semantic Match Maker는 매칭 알고리즘을
제안하고 있는데 특징 으로는 DAML을 이용하여 서비스 공시와 요청 간에
구문 차이나 모델링 추상화에서의 차이에서 발생하는 오류를 포함 계 논
리에 한 추론을 통하여 제거하고 궁극 으로 의미 매칭을 달성하고 있다.
나아가 매칭을 유연성으로 인해 발생하는 복수의 안 서비스들에 한 랭킹
함수까지 제안하여 매칭의 정확도 유의성을 높이고자 하는 것이다.
5.1.1.4 웹 서비스의 매칭 알고리즘 (Web Service Matching Algorithm)
Semantic Match Maker의 매칭 알고리즘은 기본 으로 요청자의 모든
출력을 서비스의 제공자가 포함하며, 반 로 서비스 제공자의 모든 입력 정
보를 서비스 요청자가 제공가능한지의 에서 매칭을 수행한다. <그림
5-3>의 이와 같은 Semantic Match Maker의 주 통제 모듈의 내용을 보여주
고 있으며, 주어진 요청(request)에 해 모든 등록된 서비스(adv)들에 해
매칭을 하고, 성공한 경우들만 모아 최종 으로 유사도 에서 랭킹을 부
여하는 구조를 가지고 있다.
<그림 5-3> 매칭 알고리즘의 메인 컨트롤 함수
앞에서 설명한 바와 같이 서비스 요청(request)과 서비스 공시(adv) 간의
매칭은 입력 매칭과 출력 매칭의 결과로 결정되는데, 다음의 <그림 5-4>는
출력 매칭 알고리즘을 간략하게 보여주고 있다. 서비스 요청에서의 모든 출
력 항목은 공시된 서비스의 출력 항목에 나타나야 하며 이때 각 항목 간의
매칭 수 (degreeMatch)은 체 항목들 최소 값을 기 으로 요청과 서비
스간의 매칭 수 으로 결정된다.
- 88 -
<그림 5-4> 출력 매칭 알고리즘
이 때 항목 간의 매칭 수 은 다음의 <그림 5-5>에서 보여주고 있는 바
와 같이 규칙에 의해 결정되는데, 이 때 <그림 5-6>에서 시 된 바와 같은
도메인 온톨로지 정보를 기반으로 매칭 수 에 한 평가가 이루어지게 되
는 것이다.
<그림 5-5> 항목 간의 매칭 수 결정 규칙
<그림 5-6> 자동차 련 온톨로지의
- 89 -
를 들어 서비스 요청자의 출력 항목이 “Sedan”이고 서비스 제공자의
출력 항목이 “Car”라면, <그림 5-6>의 온톨로지에 의해 “Car"는 ”Sedan"을
포함하는 개념이므로 “exact" 매칭 수 에 해당하며, 반 로 서비스 요청자의
출력 항목이 ”Car"이고 서비스 제공자의 출력 항목이 “Sedan"이라면 <그림
5-5>의 규칙에 의해 매칭 수 이 ”subsumes"에 해당하게 되는 것이다.
이러한 과정을 통해 서비스 요청과 공시된 서비스들과 매칭이 수행된 후
최종 으로 평가된 매칭 수 을 이용하여 성을 평가하고, 평가 결과 순
으로 요청자에게 제공하게 되는 것이다. Semantic Match Maker의 경우, 출
력 항목의 매칭 수 을 기 으로 우선 평가하며, 동일 평가가 발생할 경우,
입력 항목의 매칭 수 에 의해 타이 이킹(tie breaking)을 수행하고 있다.
이러한 과정에 한 규칙이 <그림 5-7>에 시되고 있다.
<그림 5-7> 매칭 수 에 기반 한 랭킹 규칙
5.1.1.5 Semantic Match Maker의 수행 제 구조
아래의 <그림 5-8>은 이상에서 논의된 방법론을 통하여 자동차 도메인에
서 등록된 웹 서비스들을 보여주고 있다. 를 들어 그림 우측 상단의
CarQuotingServiceWithGM이 서비스 요청이라 한다면, 좌측의 여섯 가지
등록 서비스들은 I/O에 련된 포함 계에 의해 매칭 수 이 결정되며,
앙의 는 속성 필터에 의해 제거되고, 좌측 하단의 등록 서비스는 제약 조
건에 의해 제거되는 상황이다.
- 90 -
<그림 5-8> 자동차 련 공시 서비스
<그림 5-9> 자동차 련 온톨로지
- 91 -
<그림 5-9>는 궁극 으로는 이들 추론과 필터링에 련된 온톨로지의
를 보여주고 있으며, 본 에서는 CarQuotingServiceWithGM 서비스 요청
에 가장 부합되는 서비스로 CarQuotingService와 VehicleQuotingService가
검색되는 시나리오인 것이다. 아래의 내용은 이 때 사용된 RuleML로 표
된 지식 정보의 일부로서 시된 내용은 GM이 Car의 제조업자라는 사실
(Fact)를 표 하고 있다.
--------------------------------------------------------------------------------------------------------------------------------
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE rdf:RDF (View Source for full doctype...)>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:ruleml="http://www.ruleml.org/rdf#">
<ruleml:Rulebase ruleml:label="SampleRulebase">
<ruleml:clauses>
<rdf:Seq>
<!-- QuotingServiceCarWithGM -->
<rdf:li>
<ruleml:Fact ruleml:label="GM">
<ruleml:head>
<ruleml:Atom ruleml:rel="ManufacturerOf">
<ruleml:args>
<rdf:Seq>
<rdf:li>
<ruleml:Var
ruleml:name="http://www.damlsmm.ri.cmu.edu/data/QuotingServiceCarWithGM.daml#Car/>
</rdf:li>
<rdf:li>
<ruleml:Ind
ruleml:name="http://www.damlsmm.ri.cmu.edu/data/CarMakers.daml#GM"/>
- 92 -
</rdf:li>
</rdf:Seq>
</ruleml:args>
</ruleml:Atom>
</ruleml:head>
</ruleml:Fact>
</rdf:li>
.....
--------------------------------------------------------------------------------------------------------------------------------
다음의 <그림 5-10>은 이상에서 소개한 Semantic Match Maker의 Macth
Making Engine의 구조를 보여주고 있다.
<그림 5-10> Semantic Match Maker의 Matchmaking Engine의 구조도
- 93 -
그림에서 볼 수 있듯이 Matchmaking Engine은 크게 다섯 가지 필터
를 가지고 서비스 요청과 등록 서비스간의 매칭을 수행하는 구조를 가지고
있으며, 반 으로 온톨로지 서버를 바탕으로 매칭의 유연성을 제공함과
동시에 커멘트나 텍스트 기반 디스크립션에 련해서는 정보 검색 방법론인
용어 빈도(word frequency)를 기반 한 평가 방식을 채택 함께 고려하고 있
음을 보여주고 있다.
5.1.1.6 Intelligent UDDI
이상의 논의 외에도 Semantic Match Maker를 바탕으로 기존의 UDDI
Registry를 추가 지능형 검색 기능을 부가하는 시도를 하고 있다. 앞에서
논의한 바와 같이 DAML-S WSDL로 표 된 입력, 출력, 제약 기타
속성들을 바탕으로 의미 서비스 매칭 기능을 제공하고자 한다. 이 때,
DAML-S 로 일에서 온톨로지는 DAML+OIL을 기반으로 표 되며, 규칙
은 RuleML을 기반으로 표 된다. 먼 서비스 제공자의 서비스 공시는
DAML-S/UDDI Translator에 의해 UDDI에 필요한 부분과 DAML-S
Matching Engine에 필요한 정보 부분으로 싱되어 등록 장되며, 서비스
요청자의 서비스 요청이 주어졌을 때, Semantic Matching Engine은 자체
서비스 공시 데이터베이스에서 한 서비스를 추출한 후 이에 련된
UDDI 정보를 수집 통합하여 서비스 요청자에게 제공하게 되는 구조를 가
지고 있다. 다음의 <그림 5-11>의 이러한 DAML-S/UDDI Matchmaker의
시스템 구조를 개략 으로나마 보여주고 있다.
5.1.2 MIT의 Process Ontology 기반 서비스 검색
5.1.2.1 로젝트 개요
본 로젝트는 MIT의 Process Handbook Project를 기반으로 이루어지고
있으며, Process Handbook Project는 기존의 비즈니스에 련된 지식을 공
- 94 -
유하고 리하며, 신규 비즈니스에 련된 신 인 아이디어 창출을 지원
하기 한 온라인 비즈니스 지식베이스를 개발하는 것을 목 으로 하고 있
다. 1991년부터 시작된 이 로젝트는 재 5,000개 이상의 비즈니스 활동에
한 엔트리를 보유하고 있으며 아주 기본 인 검색 소 트웨어를 장착하고
있다.
<그림 5-11> DAML-S/UDDI Semantic Matchmaker의 시스템 구조
- 95 -
이러한 배경 하에 Process Handbook project의 지식을 바탕으로 Klein과
Bernstein(2002)은 기존의 임 기반의 상용 서비스 검색 근 방법들
(e.g. Jini, eSpeak, Salutation, UDDI) 제한 으로 시맨틱을 검색에 활용
하는 LARKS, 연역 근 방법(deductive retreival approach) 등에 해 문
제 을 제기하고, 로세스 온톨로지(process ontology)를 기반으로 하는 웹
서비스 검색 방법론을 제안하고 있다. <그림 5-12>은 이와 같은 로세스
온톨로지 기반의 웹 서비스 검색 방법론의 강 을 검색 정확도와 리콜
(recall) 에서 조망해주고 있다.
<그림 5-12> 로세스 기반 서비스 검색 방법론의 성능 평가
이들의 근 방법 하에서는 각 서비스의 두드러진 행태는 로세스 모델에 의
해 포착되며, 이러한 로세스 모델들은 하부 과업, 리소스 등과 같은 각 로세
스의 컴포 트 등과 함께 로세스 온톨로지에 장되게 된다. 서비스에 한 질
의는 주어진 엔티티와 계를 포함하는 모든 서비스들을 검색하게 되는데 이때
일종의 로세스 질의 언어인 PQL을 활용하고 있다. 이러한 일련의 과정을 표
하는 기능 구조를 <그림 5-13>은 보여주고 있다.
- 96 -
<그림 5-13> 로세스 모델 기반 서비스
검색의 기능 구조도
5.1.2.2 로세스 모델링
본 로젝트에서는 모든 서비스를 하나의 로세스로 인식하며, 따라서
로세스를 모델링 할 수 있는 임워크를 제시하고 있다. 로세스를 모
델링하는 기본 단 로서 task와 subtask, resources, inputs, outputs 와
exceptions로 구성되며, 이들 간의 구성 형식은 <그림 5-14>에서 보여주고
있다. 이와 같은 구성 형식의 주요 요소들은 다음과 같다.
Attributes: 로세스들은 텍스트 설명, 형 성능 지표 등과 같
은 정보들에 련된 속성들을 가질 수 있다.
Decomposition: 단 로세스는 다시 일단의 하부 로세스들로 모
델링될 수 있다.
Resource Flows: 모든 로세스들은 리소스의 흐름에 련된 입력과
출력 포트(port)들을 가질 수 있다. 특히 각 로세스 별로 모든 세
세한 입출력 포트와 리소스를 악하기 보다는 주요 활동(activity)들
에 한 개략 기술을 통해 충분한 표 이 가능하다.
- 97 -
<그림 5-14> 로세스 모델 구성 형식
Mechanisms: 로세스들은 그들이 사용하는 리소스들에 의해 주석
을 달 수 있다.
Exceptions: 로세스들은 일반 으로 특징 인 실패 경로를 가지게
되며, 이를 회피하거나 해소할 수 있는 스킴(scheme)이 필요하다. 본
방법론에서는 개별 로세스들은 특성 외 항목을 가지게 되며,
이를 어떻게 다룰 것인지를 기술하게 되어 있다.
다음의 <그림 5-15>는 이외 같은 로세스 모델링 방법론을 이용하여 구
성된 서비스 모델의 를 보여주고 있다.
5.1.2.3 로세스 모델 인덱싱
본 방법론에서는 에서와 같이 구성된 서비스 모델을 MIT Process
Handbook Project의 온톨로지 상에 한 치에 배치시키는 것을 목 으
로 하고 있다.
- 98 -
<그림 5-15> 로세스 모델을 기반으로 구성된 서비스 모델
약간 원시 이긴 <그림 5-16>에서와 같은 기존의 로세스 모델의 계층
구조 온톨로지 상에 새로운 서비스를 당한 치에 배치시키는 과정으로서
본 방법론에서는 새로운 서비스의 추가하고자 할 때, <그림 5-17>과 같은
기존의 로세스 모델을 바탕으로 소규모의 수정을 통해 구축하며, 이는 동
시에 인덱싱의 효과도 가지게 된다고 주장하고 있다. <그림 5-18>은 그러한
과정을 통해 탄생된 새로운 로세스 모델의 를 보여주고 있다.
- 99 -
<그림 5-16> 서비스 계층 온톨로지
<그림 5-17> 기 등록된 부 서비스 로세스 모델
<그림 5-18> 수정을 통해 생성한 당 출 서비스 로세스 모델
- 100 -
5.1.2.4 서비스 질의 검색
로세스 모델에 의해 정의된 서비스에 한 검색은 기본 으로 PQL
(Process Query Language)를 기반으로 이루어지며, PQL은 다음과 같은 세
가지 기본 구 을 이용하여 작성하게 된다.
Entity 은 임의의 주어진 유형의 엔티티와 매칭되며, Relation 은 두
엔티티 간에 주어진 유형의 계 존재에 따라 매칭될 수 있다. 한편
Attribute 은 특정 값을 해당 속성에 갖는 엔티티들을 검색하게 된다. 이러
한 PQL을 바탕으로 구성된 한 서비스 질의 제는 다음과 같다.
이 제를 해석하자면 “Name" 속성에 ”sell"이라는 용어를 포함하며 이
러한 로세스의 특화된 모든 로세스들 이들 특화 로세스들이 갖는
subtask의 “Name"속성이 ”inform"이라는 말을 포함하며, 한 이 subtask의
“Description" 속성이 ”internet"이라는 말을 포함하는 그러한 로세스들을
검색하게 되는 것이다.
이와 같이 작성된 PQL을 이용한 서비스 매칭은 매우 단순하며, 변수 바
인딩 메카니즘을 통해 쉽게 이루어 질 수 있다.
- 101 -
5.2 에이 트 기반 지능형 웹 서비스 컴포지션 (Composition) 연구 사례
본 에서는 지능형 웹 서비스의 여러 기능 사용자가 부여한 목 의
달성을 하여 웹 서비스들에 한 지능형 조합 구성에 련된 최신 연
구 결과들을 살펴 으로써 재 이 분야의 State of the Art를 알아보고 그
표 화 방향과 국내에서의 응 방안 도출에 기반을 제공하고자 한다.
5.2.1 DAML-Enabled Web Services Research Project
미국 스탠포드 학의 KSL (Knowledge Systems Laboratory)은 재 지
능형 웹 서비스 분야의 한 축으로서 McIlraith박사를 리더로 하여 련 연
구를 수행하고 있다. <그림 5-19>는 KSL의 에서 바라보는 지능형 웹 서
비스의 임워크를 보여주고 있다. 그림에서도 볼 수 있듯이 웹 서비스는
DAML-S와 같은 웹 서비스를 한 Semantic Markup Language로 표 되
고, 사용자의 선호 성향이나 제약 조건과 같은 상황(context) 정보는
DAML+OIL과 같은 역시 시맨틱 마크업 언어로 표 되는 것을 제로 에이
트 기술을 바탕으로 목 지향 (goal-driven) 웹 서비스 조합을 구성하는
것을 목표로 하고 있다.
웹 서비스 조합(composition)을 해 구체 으로는 사용자들이 일반 으
로 필요로 하는 상 수 의 재사용가능한 ‘Generic Procedures'를 구축하
고, 이를 DAML-S와 같은 마크업 언어를 이용하여 표 하고, 궁극 으로 사
용자 에이 트들이 이를 이용하여 개별 사용자의 성향이나 제약을 반 하
여, 개별 사용자에게 합한 웹 서비스의 조합을 구성하고 수행시킬 수 있
는 구조를 만들고자 하는 것이다.
- 102 -
<그림 5-19> 시맨틱 웹 서비스의 임워크 (스탠포드 KSL)
에이 트 기술로서는 논리 언어(logical language)인 Situation Calculus와
에이 트 로그램 언어인 ConGolog를 기반으로 하고 있는데, Sequence,
Non-deterministic choice between actions, Non-deterministic choice of
arguments, Condition, Loop 등의 구성체(constructs)를 바탕으로 사용자가
Generic Procedure를 작성할 수 있다. <그림 5-20>은 이와 같은 기본 구성
체를 바탕으로 작성된 ConGolog 로그램 를 보여주고 있다. 이 와 같
은 로그램들은 사용자의 상황 정보에 따라 다른 형태의 웹 서비스 조합
(composition)을 가져올 수 있는 것이다.
- 103 -
<그림 5-20> ConGolog 로그램의
<그림 5-21> 웹 서비스 조합을 수행시키는 에이 트 제 화면
한편 <그림 5-21>은 이상의 방법론으로 구 된 에이 트가 사용자의 요
청 즉 'Bob Chen'이 ‘DAML'과 련해서 2000년 9월 2일 샌 란시스코에서
몬트 이(Monterey)로 가는 여정을 비해 달라는 과업이 그림에서 “1”로
- 104 -
지칭된 부분에 나타나 있다. 에이 트는 이에 응하여 “2”의 단계에서 샌
란시스코에서 몬트 이로의 운 시간이 2시간이라는 것을 웹 서비스를
통해 알아내고, 이에 단계 “3”에서는 사용자의 선호에 따라 비행기보다는
가능한 트카 회사들에 한 정보를 역시 웹 서비스를 통해 알아내고 있
다. 재로서는 매우 단순한 규칙에 의해 가장 에 나타나는 허츠(Hertz)를
상으로 선택하 으며 (단계 “4”), 단계 “5”에서는 여행 목 지인 몬트 이
에서의 숙박을 한 호텔들에 한 정보를 역시 웹 서비스를 통해 요청하고
수집하는 결과를 보여주고 있다.
5.2.2 RETSINA Planner 기반의 웹 서비스 컴포지션
미국의 카네기멜론 학에서 진행 인 RETSINA 로젝트는 이질 인 에이
트 간의 커뮤니티를 지원하기 한 복수 에이 트 시스템 (MAS)이다. 이와 같
은 RETSINA 환경에서 각 에이 트들이 각각의 주어진 목 에 따라 자발 활동
을 수행하고 업하기 해 가장 핵심 인 부분이 에이 트의 계획 혹은 입안 능
력인 것이며, RETSINA의 이러한 계획 컴포 트를 RETSINA Planner라 부르고
있다.
RETSINA Planner는 기본 으로 HTN (Hierarchical Tasks Network) 계획
라다임을 바탕으로 하고 있으며, 웹 서비스의 실 상황을 고려하기 하여
계획(planning) 단계와 실행(execution) 단계를 서로 왔다 갔다 할 수 있는 형식
으로 보완하 으며 이는 병행 업무 수행과 동시에 반응 (reactive) 재 계획 수
립을 가능하게 한다.
아래의 <그림 5-22>는 RETSINA Planner를 심으로 CMU의 Semantic
Match Maker UDDI 확장을 통한 웹 서비스 컴포지션의 B-to-B 용 사례를
보여주고 있다. 그림의 는 한 컴퓨터 생산업체를 상으로 하고 있으며, 이 업
체에 납품하는 다양한 공 자들이 그림 상단에 표시되고 있다.
- 105 -
<그림 5-22> RETSINA Planner 기반의 웹 서비스 컴포지션
컴퓨터 생산업자는 인터페이스 에이 트를 통해 생산 계획 혹은 주문 내역을
제공하면, Planning 에이 트는 공 망 (Supply Chain)에 련된 지식을 바탕으
로 필요한 부품 구매 활동들을 생성하며, 각 해당 필요 활동들에 한 정보를 바
탕으로 CMU Matchmaking Service는 등록된 공 자들 에 각 활동별로 한
공 업자들의 정보를 Planner에게 제공하게 된다. Planner는 이외에도 각 공
업자의 신용 상태나 재무 상황을 다른 웹 서비스를 통해 제공받아 종합 으로
- 106 -
각 활동에 해 합한 납품 업자를 배치하고 거래를 성사시키게 되는 시나리오
를 보여주고 있다.
5.2.3 반자동 웹 서비스 컴포지션
웹 서비스 조합기 (Web Service Composer)는 미국 매릴랜드 학의
Maryland Information and Network Dynamics Lab에서 개발한 반자동화된
지능형 웹 서비스 조합기이다. 이와 같은 Web Service Composer는 사용자
가 수동으로 GUI 환경에서 웹 서비스를 조합하는 시 에 한 웹 서비스
들을 매칭하여 추천하고, 한 추천된 웹 서비스 리스트에 한 추가 인
의미 필터링을 가능하게 해주고 있다. 한 완성된 웹 서비스 조합에
해 WSDL grounding을 기반으로 체 웹 서비스를 조합에 따라 실행시킬
수 있는 기능도 제공한다.
구조 으로 이 시스템은 크게 GUI를 바탕으로 하는 서비스 조합기와 추
론 엔진으로 구성되고 있는데, 추론 엔진은 Prolog를 기반으로 구축된
OWL Reasoner이다. DAML-S로 표 된 웹 서비스 정보는 RDF Triple 형태
로 지식베이스에 장되며, 한 추론 엔진은 OWL 추론 규칙에 한
Axiom들을 갖추고 있다.
특징 으로는 이 로토타입이 최 로 DAML-S로 표 된 서비스를
WSDL을 기반으로 실제 호출할 수 있는 기능을 구 하 으며, 따라서 서비
스 조합 에 사용자는 개별 웹 서비스를 호출 시험해 볼 수 있다.
이러한 Web Service Composer를 이용하여 웹 서비스를 조합하는 과정
은 먼 사용자가 <그림 5-23>에서와 같은 Composer 화면을 통해 지식베
이스에 등록되어 있는 임의의 서비스를 선택함으로써 출발하게 된다. 일단
선택된 서비스의 입력 항목에 한 웹 서비스들을 함수 특성 매칭을 통
하여 추출하여 사용자에게 리스 하게 된다.
- 107 -
<그림 5-23> 웹 서비스 조합기의 주 화면
이 경우 무 많은 수의 가능한 웹 서비스들이 매칭될 가능성이 매우 높
으며, 사용자는 추가 으로 DAML-S 로 일의 비함수 정보 를 들면
치, 유형 등의 정보를 바탕으로 추가 필터링을 하여 선택 폭을 좁힐 수
있게 된다. 반 로 상 서비스들이 무 을 경우도 역시 조건을 완화하
여 폭을 넓힐 수도 있는 것이다. 이와 같은 추가 필터링을 지원하는 제
화면이 <그림 5-24>를 통해 보여 지고 있다.
이외에도 MIND (Maryland Information and Network Dynamics) Lab에
서는 최근 SHOP2라는 HTN planning 기반의 planner를 이용하여 DAML-S
로 표 된 웹 서비스 정보와 웹 서비스 조합 문제를 모두 SHOP2 언어로
변환한 후 웹 서비스 조합을 자동 생성하는 로토타입도 완성한 바 있다.
- 108 -
<그림 5-24> 웹 서비스 필터링 시연
5.3 개인화된 지능형 웹 서비스 연구 사례
본 에서는 아직 활발하지는 않지만 개인화된(personalized) 지능형 웹
서비스 연구 사례를 알아보고자 한다. HP (Hewlett-Packard) 연구소를 심
으로 사용자의 정보를 바탕으로 웹 서비스와 고객과의 계를 어떻게 개인
화할 수 있는가에 하여 심을 가지고 있다. 특히 단말기나 GPS를 장착
한 PDA 혹은 자동차에 부착된 텔 매틱스 기기 등과 같은 이동 장치들을
기반으로 하는 사용자의 치 정보나 기타 상황 정보를 어떻게 웹 서비스
검색 조합에 이용하는지는 향후 매우 요한 주제로 떠오를 것이다.
이들 역시 에이 트 기술을 그 심으로 보고 있으며, <그림 5-25>와 같
은 사용자의 웹 서비스와의 상호 활동을 개인화 할 수 있는 구조를 제안하
고 있다.
- 109 -
<그림 5-25> 개인화된 지능형 웹 서비스 구조
이 연구에서는 개인화 컴포 트(Personalization Component)를 심으로
사용자의 시간 공간 정보를 추 하며 나아가 사용자의 로 일을 리
하게 된다. 다양한 디바이스를 통한 사용자의 서비스 요청은 이와 같은 개
인의 상황(context) 정보를 반 하여 웹 서비스를 검색 선정하고 조합하게
되는 것이다. 이와 같은 시나리오는 지능형 웹 서비스 기술과 LBS(Location
Based Service) 기술의 추가 목을 통하여 가능해 질 것이다.
- 110 -
제 6 장 지능형 웹 서비스 국내 도입 략
6.1 국내 응 방향 기술 도입 방안
본 에서는 지능형 웹 서비스에 한 국내에서의 응 방향과 기술의
도입 방안을 알아본다. 이를 하여 지 까지 살펴본 지능형 웹 서비스에
한 표 , 기술, 연구 동향 등을 바탕으로 정부, 기업, 연구소 학계의 입
장에서 취하여야 할 응 방향 기술 도입 방안을 알아본다.
웹 서비스는 정 인 문서로 가득 차 있던 웹(Web)을 실시간으로 상호운
이 가능한 소 트웨어 컴포 트들의 방 한 도서 으로 변화시킬 수 있는
원동력을 가지고 있다. IDC에 따르면 2002년의 웹 서비스 시장 규모는 4억
1천 6백만 달러의 규모이었으며, 2006년까지 29억 달러 규모로 성장할 것으
로 측되고 있다. 그럼에도 불구하고 재의 웹 서비스 근 방법은 이상
인 것으로 생각되는 완 한 상호운 성과 자동화를 기 하기는 어려우며,
이에 한 안으로서 웹 서비스 기술과 시맨틱 웹 기술을 목시켜 지능형
웹 서비스 혹은 시맨틱 웹 서비스라는 안을 제시하고 있는 것이다.
이와 같은 지능형 웹 서비스와 련된 표 표 으로는 DAML-S
(OWL-S)를 들 수 있으나 아직은 공식 으로 W3C의 세계 표 으로 인정받
고 있는 상태는 아니라 할 수 있다. 하나의 지능형 웹 서비스 련 분야
매우 치열한 표 공방이 벌어지고 있는 분야는 바로 웹 서비스 조합
(composition) 언어라 할 수 있으며 이 역시 재는 IBM과 Microsoft의
BPEL4WS가 표 이라 할 수 있으나 이의 표 화 역시 아직 갈 길이 먼
상태이다. 이처럼 웹 서비스에 한 표 언어 조합 언어 수 에서의 표
도 아직 완 한 상태가 아닌 상황에서 지능형 웹 서비스를 구 하기 한
다른 요소라 할 수 있는 자동 웹 서비스 검색, 자동 웹 서비스 조합 계획
(planning), 자동 감시 복구, 보안 등 지능형 웹 서비스 련 표 은
아직 수많은 해결해야할 그리고 표 화해야할 문제들을 안고 있는 실정이다.
이것은 지능형 웹 서비스가 아직 미완의 기술로서 연구 개발의 여지가
많이 남아있다는 것을 의미한다. 이것은 우리가 기존의 웹 서비스 시맨
- 111 -
틱 웹 분야의 기술 개발 표 화 활동에서 뒤쳐졌던 것과 달리 지능형 웹
서비스 분야의 경우에는 우리가 기술 개발 표 화 활동에 극 , 선도
으로 동참함으로써 기존의 기술 열세를 극복하고 웹 분야의 기술 표
을 주도할 수 있는 기회를 의미한다. 한 동시에 우리가 속하게 변화
하고 있는 지능형 웹 서비스 기술 표 에 민감하게 반응하지 못한다면
웹 분야의 기술 열세를 만회하지 못하고 계속 기술 선진국들을 따라가야
만 하는 요인을 의미하기도 한다.
따라서 우리나라의 국가 입장에서는 지능형 웹 서비스의 세계 표
화 활동에 개입 주도할 수 있는 기회를 활용할 수 있도록 산․학․연․
부문에서 지능형 웹 서비스의 발 보 에 노력을 경주하여야 한다.
기업의 입장에서는 지능형 웹 서비스의 기술 변화와 표 화 활동에 민감
하게 응하고 R&D에 지속 투자를 함으로써 지능형 웹 서비스 련 표
의 수용 도구 개발에 경쟁력을 갖출 수 있을 것으로 단된다. 그리고
연구소나 학계의 입장에서는 시맨틱 웹, 지능형 웹 서비스 분야에서 화두가
되고 있는 규칙 표 언어 표 화 등의 분야에 연구를 집 하고 극 으로
세계 표 화에 동참함으로써 기존의 열세를 극복하고 나아가 세계 표 을
선도할 수 있을 것이다. 한 정부는 이러한 산․학․연 부문에서 일어나고
있는 지능형 웹 서비스 연구 개발에 한 투자를 각종 융, 제도 지원을
통하여 극 으로 뒷받침하여야 할 것이다.
본 연구를 통해 우리는 먼 국가 입장에서는 새로운 웹의 시 를 이
끌어갈 것으로 상되는 지능형 웹 서비스 기술과 련하여 보다 극 으
로 세계 표 화 활동에 개입 주도할 수 있는 기회를 가지고 있다는 을
활용하여 기존의 웹 서비스나 시맨틱 웹 표 에서 국제 으로 낙후된 입장
을 개선할 수 있다고 단하고 있으며, 기업의 입장에서는 무나 빠른 기
술 변화와 표 화 활동에 민감하게 반응하여야만 이와 같은 속한 변화
환경에서 표 수용과 기술 도구 개발에 경쟁력을 갖출 수 있을 것으로
분석하 다. 특히 연구소나 학계에서는 시맨틱 웹 분야나 지능형 웹 서비스
분야에서 최근 화두가 되고 있는 OWL-Rule과 같은 규칙 표 언어 표 화
에 련 연구를 통해 극 으로 표 화에 동참하여 따라가는 수 을 넘어
국제 리더쉽을 갖출 수 있는 노력을 기울어야 할 것이다.
다음 에서는 지능형 웹 서비스를 정부 민간 조직에 도입, 활용, 확
- 112 -
산시키고, 그 응용 시장을 활성화시키기 한 략을 분석, 제시한다.
6.2 지능형 웹 서비스 도입 략 분석
본 에서는 지능형 웹 서비스의 국내 도입 략을 도출한다. 이를 하
여 먼 지능형 웹 서비스 도입 략 분석 틀을 마련한 후 이를 바탕으로
민간부문 공공부문에서의 지능형 웹 서비스 도입 략을 분석하고 수립
한다. 각 부문의 구체 인 조직들의 도입 략 분석은 별도의 개별 연구에
맡기고 본 연구에서는 부문별 일반 략의 도출에만 을 맞추도록 한다.
6.2.1 지능형 웹 서비스 도입 략 분석 틀
신기술의 도입 략은 그 조직의 체 략 목표와 일치하여야 한다.
따라서 지능형 웹 서비스 도입 략을 분석하기 해서는 해당 조직의 략
목표를 확인하는 작업이 우선되어야 한다. 본 장에서는 지능형 웹 서비스
도입 조직을 크게 민간부문과 공공부문으로 나 어 도입 략을 분석한다.
그러므로 각 부문별로 그 부문의 일반 인 략 목표를 도출함으로써 지능
형 웹 서비스 도입 략의 분석을 시작하도록 한다. 를 들어 민간부문의
략목표로는 경쟁우 의 확보 등을 들 수 있으며, 공공부문의 략목표로
는 복지사회의 구 등을 들 수 있다.
조직의 략 목표가 확인되면, 신기술의 도입 략이 조직의 략 목표
와 일치되도록 신기술의 략 목표를 설정하여야 한다. 지능형 웹 서비스라
는 신기술이 경쟁우 의 확보라는 민간 조직의 략목표와 일치되기 한
략목표로는 업무 로세스 효율화에 의한 업무 처리 속도 향상 비용
감 등을 들 수 있고, 복지사회의 구 이라는 공공 조직의 략목표와 일
치되기 한 략목표로는 업무 로세스 효율화에 의한 국민 서비스 향
상 비용 감 등을 들 수 있다.
신기술의 략 목표가 설정되면 조직의 황 분석을 바탕으로 신기술의
용 분야 용 방안을 탐색하게 된다. 조직의 황 분석은 조직의 장
- 113 -
단 을 바탕으로 기회 요인과 요인을 악하는 SWOT(Strength,
Weakness, Opportunity, Threat) 분석 기법을 이용한다. 본 장에서는 민간부
문 공공부문에서의 지능형 웹 서비스 련 SWOT 분석을 실시한다.
한 신기술의 용 분야 탐색은 신기술의 조직 업무에의 용 시나리오를 도
출함으로써 이루어진다. 새로운 업무 시나리오의 도출은 매우 창조 인 작
업이며 한 조직의 수많은 업무별로 구성되어야 하므로 창조 이면서도 수
많은 작업을 필요로 한다. 따라서 본 연구에서는 공공부문 민간부문 별
로 한두 가지 업무에 하여 지능형 웹 서비스를 사용하는 간단한 시나리오
를 제시하도록 하고, 구체 인 업무별 작업은 별도의 연구에 맡기도록 하겠
다. 신기술의 용 방안은 도출된 업무 시나리오를 실화하기 하여 필요
한 차를 악하는 것이다. 본 연구에서는 앞에서 도출된 시나리오만을
심으로 지능형 웹 서비스 시스템의 도입 차를 간단히 제시하도록 한다.
지 까지 설명한 지능형 웹 서비스 도입 략 분석 차를 정리한 것이
<그림 6-1>에 나타나 있다.
조직 략 목표 확인
지능형 웹 서비스 략 목표 설정
SWOT 분석
업무 시나리오 도출
지능형 웹 서비스 도입 차 도출
<그림 6-1> 지능형 웹 서비스 도입 략 분석 차
- 114 -
6.2.2 민간부문 지능형 웹 서비스 도입 략
본 에서는 민간부문 지능형 웹 서비스의 도입 략을 <그림 6-1>의 지
능형 웹 서비스 도입 략 분석 차에 따라 도출하도록 한다. 다만, 구체
인 기업을 상으로 하기보다는 일반 인 기업을 상정하여 략을 도출하도
록 한다.
가. 조직 략 목표 확인
재의 일반 인 기업이 갖는 략 목표는 “경쟁우 확보에 의한 기업
의 생존 이윤 확보”이다. 따라서 본 연구에서도 지능형 웹 서비스를 도
입하려는 민간부문 조직의 략 목표를 “경쟁우 확보”로 가정한다.
나. 지능형 웹 서비스 략 목표 설정
본 에서는 앞 에서 가정한 경쟁우 확보라는 조직의 략 목표에
일치하는 지능형 웹 서비스의 략 목표를 설정한다. 새로운 정보기술의
략 목표를 설정하기 해서는 먼 새로운 정보기술의 략 활용에
한 가능성을 타진하여야 한다. McFarlan[1984]은 경쟁우 확보를 한 정
보기술의 략 활용에 한 가능성을 타진하기 해서는 다음과 같은 다
섯 가지 질문을 던져 보는 것이 필요하다는 주장을 제시한 바 있다.[김은홍
이진주, 정문상, 1988]
첫째, 정보기술이 진입기업에 한 진입장벽의 역할을 할 수 있는가?
둘째, 정보기술이 수요자나 공 자의 교체비용에 향을 수 있는가?
셋째, 정보기술이 타사와의 경쟁기반을 바꿀 수 있는가?
넷째, 정보기술을 이용해 공 자의 향력을 일 수 있는가?
다섯째, 정보기술이 신제품 창출에 향을 수 있는가?
지능형 웹 서비스의 경우 다섯 가지 질문에 “ ”라고 답할 수 있는
- 115 -
가? 이에 해 답할 수 있으려면 지능형 웹 서비스의 략 목표가 알맞게
세워져야 한다.
첫째, 지능형 웹 서비스가 진입기업에 한 진입장벽의 역할을 할 수 있
는가? 지능형 웹 서비스가 진입기업에 한 진입장벽의 역할을 수행하기
해서는 구 된 지능형 웹 서비스가 새로운 진입기업이 쉽게 흉내 낼 수 없
는 지식과 구조를 포함하고 있어야 한다. 보통의 웹 서비스는 웹 서비스의
장 들 진입기업에게도 쉽게 허용함으로써 진입기업에 한 진입장벽을 낮
출 뿐이다. 진입기업이 쉽게 흉내 낼 수 없는 지식이나 구조는 공 체계
리(SCM, Supply Chain Management) 고객 계 리(CRM, Customer
Relationship Management)에 구 될 수 있다. 공 체계 상의 기업들이 략
제휴를 맺고 하나의 가상기업(Virtual Corporate)으로 행동하면서, 공 체
계 상의 업무 로세스를 효율화하고, 고객에 한 정보를 공유하면서 고객
의 을 효율 으로 리한다면 그것은 새로운 진입 기업이 쉽게 흉내
낼 수 없는 지식을 바탕으로 효율 인 기업 운 구조를 구 한 것이 된다.
이러한 SCM이나 CRM의 효과 인 구 기법으로 지능형 웹 서비스가 이용
될 수 있다.
둘째, 지능형 웹 서비스가 수요자나 공 자의 교체비용에 향을 수
있는가? 지능형 웹 서비스는 정보 시스템 간의 느슨한 결합(loose coupling)
을 목표로 하므로 지능형 웹 서비스가 산업 반에 일반화 된 후에는 수요
자나 공 자의 교체비용에 향을 주지 않을 것이다. 그러나 지능형 웹 서
비스가 아직 일반화 되지 않은 상태에서는 수요자 공 자의 교체비용
에 큰 향을 것이다.
셋째, 지능형 웹 서비스가 타사와의 경쟁기반을 바꿀 수 있는가? 정보
기술을 바탕으로 한 경쟁 기반은 단 업무 기능 산화, 통합 업무 산화,
조직 업무 로세스 효율화(Business Process Reengineering), 기업 간 업무
로세스 효율화(SCM, CRM 등) 등의 순으로 바 어 왔다. 기업 간 업무
로세스의 효율화는 기업 간 자상거래, 외주(Outsourcing) 등을 활용하는
방안들에 의해 구 되고 있으나, 아직까지 조직 간 시스템 통합의 어려움
때문에 완벽하게 구 되고 있지는 못한 실정이다. 이 시 에서 지능형 웹
서비스를 이용한 조직 간 시스템 통합은 타사와의 경쟁에서 비교 우 를
할 수 있는 좋은 기술 기회이다.
- 116 -
넷째, 지능형 웹 서비스를 이용해 공 자의 향력을 일 수 있는가?
지능형 웹 서비스는 정보 시스템 간의 느슨한 결합(loose coupling)을 목표
로 하므로 공 자의 교체를 용이하게 한다. 따라서 공 자에 한 교체 비
용을 임으로써 공 자의 향력을 일 수 있다.
다섯째, 지능형 웹 서비스가 신제품 창출에 향을 수 있는가? 지능
형 웹 서비스가 새로운 제품의 개발에 직 인 도움이 되지는 않을 것이
다. 다만, 효율 인 기업 간/기업 내 업무 로세스를 바탕으로 신제품의
생산 주기를 이고, 고객의 요구에 빠르게 응할 수 있도록 할 것이다.
이상으로 기업의 경쟁우 확보를 한 지능형 웹 서비스의 략 활용
가능성을 타진해 보았다. 그 과정에서 논의 되었듯이 지능형 웹 서비스는 기
업 간 기업 내 업무 로세스 효율화를 통하여 략 활용이 가능함을
알 수 있었다. 따라서 경쟁우 확보라는 기업의 략 목표에 일치하는 지능
형 웹 서비스의 략 목표를 “업무 로세스 효율화”로 설정하도록 한다.
다. SWOT 분석
본 에서는 업무 로세스 효율화를 한 지능형 웹 서비스의 용 분
야를 탐색하기 한 사 작업으로 조직의 황 분석을 시행한다. 본 연구
가 지능형 웹 서비스의 국내 도입 략이므로 황 분석은 국내 민간 기업
을 상으로 한다. 이를 하여 업무 로세스 효율성 지능형 웹 서비스
의 에서 반 인 국내 기업들에 한 SWOT 분석을 실시한다.
첫째, 국내 기업들이 갖는 강 (Strength)은 무엇보다도 인터넷 기반 구
조에 있다. 소기업진흥공단[2002]의 조사 자료에 따르면 ADSL, VDSL 등
의 신기술 서비스에 힘입어 강원지역 소기업 부분이 인터넷을 사용하고
있는 것으로 나타났다. 이것은 우리나라 체 기업에도 용될 것으로 단
되며, 나아가 우리나라 모든 소비자에게도 용되는 것으로 단할 수 있다.
이러한 네트워크 인 라를 바탕으로 각종 지능형 웹 서비스 응용의 설치
운 이 가능하다.
둘째, 국내 기업들이 갖는 약 (Weakness)으로는 네트워크 인 라에 비
해 상 으로 왜소한 통합 정보시스템이 있다. 다양한 네트워크 응용이 가
- 117 -
능한 상황에서도 이것을 실 할 기술이나 개발 운 인력이 부족한 것이
실이다. 국내 기업의 다른 약 으로는 진부한 업무 로세스의 온존
이에 한 개선 의지의 부족이다. 1990년 에 국내에 BPR(Business
Process Reengineering) 바람이 불었으나, 실제로 이것을 구 한 국내 기업
은 별로 없는 실정이다.
셋째, 국내 기업들이 갖는 기회(Opportunity)는 네트워크 인 라라는 강
을 바탕으로, BPR, SCM, CRM 등에 한 CEO들의 의지가 확고하고 충
분한 기술 지원만 이루어진다면 충분히 업무 로세스 효율화를 통한 경쟁
우 의 확보가 가능하다는 것이다. 특히, 지능형 웹 서비스 기술은 국내 민
간 기업이 이러한 기회를 실 할 수 있는 최신의 정보 기술이다.
넷째, 국내 기업들이 갖는 (Threat) 요소는 최신 기술 개발 운
경험 부족에 따른 시스템 실패의 가능성이다. 지능형 웹 서비스 기술이 업
무 효율화를 한 최상의 기회이기는 하지만 활용 여하에 따라서 크나큰 실
패로 이어질 수도 있다.
이상으로 업무 로세스 효율성 지능형 웹 서비스의 에서 반
인 국내 기업들에 한 SWOT 분석을 실시한 결과를 정리한 것이 <그림
6-2>에 나타나 있다.
강
인터넷 인 라
약
통합 정보시스템 부족
기술 인력 부족
기회
BPR, SCM, CRM 등에 의한 업무
로세스 효율화
기술 경험 부족에 따른 실패 가능
<그림 6-2> 지능형 웹 서비스에 한 국내 기업의 SWOT 분석
이상의 SWOT 분석을 바탕으로 국내 민간 기업의 경우 풍부한 인터넷 인
라를 바탕으로 지능형 웹 서비스 기술 인력만 보강되면 BPR, SCM,
CRM 등에 의한 업무 로세스 효율화가 가능하지만, 충분한 기술 인력
- 118 -
확보 없이는 실패할 수도 있음을 알 수 있다. 따라서 지능형 웹 서비스의 기
술 개발 교육에 한 기업 정부의 투자도 시 히 필요하다고 하겠다.
라. 업무 시나리오 도출
이미 지 하 듯이 일반론에 입각한 본 연구에서 구체 인 기업의 업무
시나리오를 모두 나열하는 것은 불가능하다. 따라서 본 에서는 한 가지
가능한 지능형 웹 서비스 기반 업무 시나리오만 기술함으로써 지능형 웹 서
비스에 의한 업무 효율화의 가능성을 제시하고자 한다. 여기서는 산업
을 상으로 그 시나리오를 기술한다.
일반 으로 국내 산업은 찾아오는 손님을 심으로 미리 정해진 여
행 일정을 제시하거나, 자신만의 일정을 원하는 손님의 경우에는 여행사 직
원의 경험을 바탕으로 수작업으로 일정을 잡아서 제시하는 것이 보통이다.
그러나 지능형 웹 서비스가 련 산업에 구 된다면 이러한 업무 로
세스는 다양한 형태로 효율화될 수 있다. 첫째, 고객별 개인화된 여행 일정
을 자동으로 마련할 수 있다. 지능형 웹 서비스 기반 여행 일정 에이 트는
교통업체(항공기, 철도, 버스 등), 숙박업체, 요식업체 등의 지능형 웹 서비
스 서버에 속하여 각각의 일정을 얻은 후 고객의 선호를 바탕으로 체
여행 일정을 계획하고 필요한 약을 수행하여 완성된 여행 일정을 마련할
수 있다. 둘째, 고객별로 차별화된 여행 마 이 가능하다. 고객의 과거 여
행 일정을 바탕으로 고객의 선호를 악한 후 이것을 바탕으로 해당 고객의
선호에 맞는 여행 일정을 생성하여 고객에게 극 으로 여행 상품을 제시
하고 매할 수 있다.
와 같은 지능형 웹 서비스를 이용한 여행 산업 업무 로세스의 효율
화는 완 히 디지털화 된 여행 약 서비스를 가능하게 함으로써, 인건비
매장 운 비의 감, CRM에 의한 고객 가치의 증 고객 확보 등의
경쟁우 요소를 가져오게 된다.
마. 지능형 웹 서비스 도입 차 도출
- 119 -
지능형 웹 서비스라는 새로운 정보 기술의 도입은 일조일석에 이루어질
수는 없다. 우선 으로 필요한 기술이 개발되어야 하고, 교육에 의해 기술
인력이 확보되어야 하고, 사회 인 분 기가 성숙되어야 하며, 궁극 으로는
기업의 다양한 업무 분야별 정보 시스템으로 구 되어야 한다. 이러한 정보
기술의 도입 차로는 Nolan[1979]의 성장 이론을 원용하여 지능형 웹 서비
스 도입 확산을 한 정책 지표로 활용할 수 있다.
Nolan은 조직에 컴퓨터가 도입된 이후 그 비용이 S자를 그리면서 증가
한다는 에 주목하여 그 성장과정을 네 단계로 나 고 각 단계별 특성을
제시한 바 있다.[Nolan, 1973; Gibson and Nolan, 1974] 그는 정보기술의 성
장과정을 착수, 확장( 는 ), 공식화( 는 통제) 성숙( 는 통합)의 네
단계로 구분하고 각 단계에 따른 컴퓨터 응용분야, 요원의 문화, 그리고
정보시스템 기능의 리 면에서의 특성을 제시하 다. 그 후 Nolan[1979]는
지속 인 추가연구의 결과로 다시 여섯 단계로 구성된 성장단계모형을 수
정, 발표하게 되었는데 그 주요 내용을 요약하면 <그림 6-3>과 같다.[김은
홍, 이진주, 정문상, 2002]
- 120 -
착수 통제 통합데이터의
리성숙
컴퓨터 응용분야
기능분야별 비용 감을 한 응용업무
모든 업무분야로 확
기존 응용분야의 재구성 문서화의 개선
데이터베이스 기술을 이용한 기존 응용분야의 개선
기존 응용분야의 조직 통합
조직 내에서의 정보의 흐름을 반 할 수 있는 방향으로의 통합
MIS 부서의 조직
기술습득을 한 요원 문화에
사용자 지향 인 로그래머 심
간 리자의 역할 증
조직 내 서비스 제공 기능을 수행하는 부서로 정착
데이터 리에
데이터 자원의 리에
MIS 계획 통제
느슨한 계획 통제
더욱 더 느슨한 계획 통제
공식화된 계획 통제방식 용
합하게 조정된 계획 통제방식 용
데이터의 공유 여러 응용분야에 공통으로 이용가능한 시스템 개발에
데이터 자원에 한 략계획 수립
사용자의 인식
방 자세 견지
피상 인 열정의 소유
독단 인 책임의식의 소유
책임의식의 습득
효과 인 책임의식의 소유
사용자와 시스템 요원 간의 공동책임의식 정착
<그림 6-3> Nolan의 성장단계 모형
6.2.3 공공부문 지능형 웹 서비스 도입 략
본 에서는 공공부문 지능형 웹 서비스의 도입 략을 <그림 6-1>의 지
능형 웹 서비스 도입 략 분석 차에 따라 도출하도록 한다. 다만, 구체
인 공공업무를 상으로 하기보다는 일반 인 공공업무를 상정하여 략을
도출하도록 한다.
- 121 -
가. 조직 략 목표 확인
재의 공공업무가 갖는 략 목표는 “복지사회의 구 에 의한 국민
서비스의 향상”이다. 따라서 본 연구에서도 지능형 웹 서비스를 도입하려는
공공부문 조직의 략 목표를 “복지사회의 구 ”으로 가정한다.
나. 지능형 웹 서비스 략 목표 설정
본 에서는 앞 에서 가정한 복지사회의 구 이라는 조직의 략 목표
에 일치하는 지능형 웹 서비스의 략 목표를 설정한다. 새로운 정보기술의
략 목표를 설정하기 해서는 먼 새로운 정보기술의 략 활용에
한 가능성을 타진하여야 한다. 그런데 공공업무의 략 목표는 복지사회의
구 이므로 략 목표가 경쟁우 확보인 경우에 지능형 웹 서비스 략을
도출하기 해 사용하 던 McFarlan[1984]의 모형은 사용하기가 곤란하다.
신에 리 목 으로는 사업화하기가 곤란한 서비스를 이익에 구애받지
않고 국민에게 서비스하려는 공공 서비스의 원래 목 을 고려하면 복지사회
의 구 이라는 목표는 지능형 웹 서비스를 이용한 공공 업무의 국민 서비
스 질의 향상이라는 기술 목표로 설정될 수 있다. 한, 같은 서비스를 제
공하더라도 국민의 세를 약한다는 측면에서 업무 로세스 효율화에 의
한 비용의 감이라는 목표도 설정할 수 있다.
요컨 , 국민 복지의 향상이라는 공공부문의 략 목표에 일치하는 지능
형 웹 서비스의 략 목표는 “ 국민 서비스의 향상 업무 로세스 효율
화”로 설정될 수 있다.
다. SWOT 분석
본 에서는 국민 서비스의 향상 업무 로세스 효율화를 한 지
능형 웹 서비스의 용 분야를 탐색하기 한 사 작업으로 공공 조직의
황 분석을 시행한다. 본 연구가 지능형 웹 서비스의 국내 도입 략이므
로 황 분석은 한민국 정부를 상으로 한다. 이를 하여 국민 서비
- 122 -
스의 향상, 업무 로세스 효율성 지능형 웹 서비스의 에서 반
인 공공 조직들에 한 SWOT 분석을 실시한다.
첫째, 우리나라 공공조직이 갖는 강 (Strength)은 무엇보다도 인터넷 기
반 구조에 있다. 앞 의 민간 부문에서도 강 으로 지 된 바와 같이 일반
가정에 인터넷이 충분히 보 되어 있어서 네트워크 기반 민 서비스의 구
이 용이하며 자정부 시스템이 이미 구 되어 제공되고 있다. 한, 정
부 조직 정보화에 한 꾸 한 투자를 바탕으로 일선 행정 기 까지 네트워
크로 연결되어 분산형 정보시스템을 바탕으로 한 행정정보시스템이 구비되
어 있다.
둘째, 우리나라 공공조직이 갖는 약 (Weakness)으로는 복잡한 행정체계
를 완벽하기 지원하기에는 아직은 부족한 통합 정보시스템에 있다. 주민등
록, 인감, 등기 등 공공 정보시스템의 많은 부분이 산화되어 있지만, 아직
도 공시지가, 건축물 리 등을 포함한 몇몇 행정 업무가 아직 산화되어
있지 않다. 특히 문제가 되는 것이 이러한 산화가 기존 업무의 단순 자동
화에 을 맞추고 있지 정보 기술을 고려한 새로운 효율 인 업무 로세
스의 구 과는 거리가 있다는 이다. 이런 상태에서는 정보 기술이 가져다
수 있는 민 서비스의 질 향상 업무 효율화에 의한 비용 감 등
의 기회를 살릴 수가 없다.
셋째, 우리나라 공공조직이 갖는 기회(Opportunity)는 재의 행정정보시
스템, 일반 가정에 보 된 인터넷 인 라 등의 강 을 바탕으로 공공 업무
로세스에 한 재설계가 이루어진다면 민 서비스의 질 향상 업무
효율화에 의한 비용 감을 통해 복지사회의 구 을 앞당길 수 있다는 것이
다. 특히, 지능형 웹 서비스 기술은 우리나라 공공부문이 이러한 기회를 실
할 수 있는 최신의 정보 기술이다.
넷째, 우리나라 공공조직이 갖는 (Threat) 요소는 최신 기술 개발
운 경험 부족에 따른 시스템 실패의 가능성이다. 지능형 웹 서비스 기술
이 민 서비스의 질 향상 업무 효율화를 한 최상의 기회이기는 하
지만 활용 여하에 따라서 실패로 이어질 수도 있다.
이상으로 민 서비스의 질 향상, 업무 로세스 효율성 지능형 웹
서비스의 에서 반 인 우리나라 공공부문에 한 SWOT 분석을 실시
- 123 -
한 결과를 정리한 것이 <그림 6-4>에 나타나 있다.
강
인터넷 인 라
자정부 시스템
행정 정보 시스템
약
통합 정보시스템 부족
행정 업무의 단순 자동화
기회
민 서비스의 질 향상
업무 로세스 재설계에 의한 효율화
기술 경험 부족에 따른 실패 가능
<그림 6-4> 지능형 웹 서비스에 한 우리나라 공공부문의 SWOT 분석
이상의 SWOT 분석을 바탕으로 우리나라 공공부문의 경우 풍부한 인터
넷 인 라와 행정정보시스템에 한 투자를 바탕으로 지능형 웹 서비스 기
술 인력만 보강되면 행정업무 재설계에 의한 업무 로세스 효율화
민 서비스의 질 향상이 가능하지만, 충분한 기술 인력 확보 없이는
실패할 수도 있음을 알 수 있다. 따라서 지능형 웹 서비스의 기술 개발
인력 확보에 한 정부의 투자도 시 히 필요하다고 하겠다.
라. 업무 시나리오 도출
이미 지 하 듯이 일반론에 입각한 본 연구에서 구체 인 행정 업무 시
나리오를 모두 나열하는 것은 불가능하다. 따라서 본 에서는 두 가지 가
능한 지능형 웹 서비스 기반 업무 시나리오만 기술함으로써 지능형 웹 서비
스에 의한 업무 효율화의 가능성을 제시하고자 한다. 여기서는 민 부문에
한 사례로 여권 발 업무 시나리오를, 기업 부문에 한 사례로 공장
설립 허가 업무 시나리오를 기술한다.
여권 발 을 받기 해서는 몇 가지 요구 조건을 만족시켜야 한다. 그러
한 요구 조건에는 범죄, 병역 등에 련한 조건들이 있다. 특히 병역 련
- 124 -
조건을 충족시키기 해서 병역 미필자의 경우 병무청에 별도 방문하여 국
방부 장 의 추천서를 받아야 한다. 이러한 복잡한 차는 여권 발 기간
을 증가시키며 여권 발 서비스의 질을 하시킨다. 그러나 지능형 웹 서
비스가 공공 부문에 구 된다면 복잡한 여권 발 업무 로세스는 단순화
될 수 있다. 여권 발 신청자는 자정부 사이트에서 필요한 정보를 입력
하고 여권 발 을 신청하기만 하면 된다. 그러면, 지능형 웹 서비스 기반 여
권 발 에이 트는 여권 발 에 필요한 요구 조건들을 악한 후 각 요구
조건을 만족시키기 해 해당 되는 - 경찰청, 국방부 등 - 지능형 웹 서비스
서버에 속하여 조건 만족 사실을 확인 받는다. 그리고 이러한 사실들을
바탕으로 여권 발 결정을 내리게 된다. 그리고 여권이 발 되면 여권 발
신청자에게 그 사실을 알리고 근처 구청에 가서 여권을 찾아가도록 통지
한다.
공장 설립 허가 업무도 비슷한 시나리오로 이루어진다. 일반 으로 공장
설립 허가를 받기 해서는 수 십 가지의 조건을 만족시켜야 하며, 그 조건
들은 서로 선후 계가 있으며, 어떤 조건들은 장기간에 걸친 실사를 필요
로 하기도 한다. 그러나 여기서도 공장 설립 허가 신청자는 자정부 사이
트에서 필요한 정보를 입력하고 공장 설립 허가를 신청하기만 하면 된다.
그러면 지능형 웹 서비스 기반 공장 설립 허가 에이 트는 요구 조건들 간
의 선후 계를 악하여 각 조건들을 만족시켜 가며, 실사가 필요한 경우
에는 담당 공무원의 일정에 맞추어 실사 일정을 결정한 후 민원인에게 그
사실을 통보하고 실사에 참여해 것을 요청하게 된다. 이러한 과정을 거
쳐 모든 조건이 만족되면 비로소 공장 설립 허가가 결정되게 된다.
와 같은 지능형 웹 서비스를 이용한 여권 발 , 공장 설립 허가 등 공공
업무 로세스는 분산된(loosely coupled) 공공 기 의 정보시스템들을 효과
으로 연결하여 과 동시에 민원인에게는 원 클릭 서비스를 제공함으로써
민 서비스의 질 향상과 행정 업무 로세스의 효율화를 가져올 수 있다.
마. 지능형 웹 서비스 도입 차 도출
지능형 웹 서비스라는 새로운 정보 기술의 도입은 일조일석에 이루어질
수는 없다. 우선 으로 필요한 기술이 개발되어야 하고, 교육에 의해 기술
- 125 -
인력이 확보되어야 하고, 사회 인 분 기가 성숙되어야 하며, 궁극 으로는
공공부문의 다양한 업무별 정보 시스템으로 구 되어야 한다. 이러한 정보
기술의 도입 차로는 민간부문의 경우와 마찬가지로 Nolan[1979]의 성장
이론을 원용하여 지능형 웹 서비스 도입 확산을 한 정책 지표로 활용
할 수 있다.
- 126 -
제 7 장 결론
웹 서비스는 정 인 문서로 가득 차 있던 웹(Web)을 실시간으로 상호운
이 가능한 소 트웨어 컴포 트들의 방 한 도서 으로 변화시킬 수 있는
원동력을 가지고 있다. IDC에 따르면 2002년의 웹 서비스 시장 규모는 4억
1천 6백만 달러의 규모이었으며, 2006년까지 29억 달러 규모로 성장할 것으
로 측하고 있다. 그럼에도 불구하고 재의 웹 서비스 근 방법은 이상
으로 기 하는 완 한 상호운 성과 자동화를 기 하기는 어려우며, 이에
한 안으로서 웹 서비스 기술과 시맨틱 웹 기술을 목시켜 지능형 웹
서비스 혹은 시맨틱 웹 서비스라는 안을 제시하고 있는 것이다.
이와 같은 지능형 웹 서비스와 련된 표 표 으로는 DAML-S
(OWL-S)를 들 수 있으나 아직은 공식 으로 W3C의 세계 표 으로 인정받
고 있는 상태는 아니라 할 수 있다. 하나의 지능형 웹 서비스 련 분야
매우 치열한 표 공방이 벌어지고 있는 분야는 바로 웹 서비스 조합
(composition) 언어라 할 수 있으며 이 역시 재는 IBM과 Microsoft의
BPEL4WS가 표 이라 할 수 있으나 이의 표 화 역시 아직 갈 길이 멀은
상태이다. 이처럼 웹 서비스에 한 표 언어 조합 언어 수 에서의 표
도 아직 완 한 상태가 아닌 상황에서 지능형 웹 서비스를 구 하기 한
다른 요소라 할 수 있는 자동 웹 서비스 검색, 자동 웹 서비스 조합 계획
(planning), 자동 감시 복구, 보안 등 지능형 웹 서비스 련 표 은
아직 수많은 해결해야할 그리고 표 화해야할 문제들을 안고 있는 실정이다.
본 보고서에서는 지능형 웹 서비스의 세계 표 화 연구 동향을
반 으로 살펴보았다. 특히 제 2장에서는 지능형 웹 서비스의 반 개념
과 아키텍쳐를 살펴보았고, 제 3장에서는 지능형 웹 서비스의 기반 기술인
시맨틱 웹 기반 기술, 웹 서비스 기반 기술 시맨틱 웹 서비스 기반 기술
들을 심도 있게 다루었다. 한편 4장에서는 지능형 웹 서비스 구 을 한
아키텍쳐를 분석하 고, 제 5장에서는 지능형 웹 서비스에 련된 최신 연
구 동향을 깊이 살펴보았으며, 마지막으로 6장에서는 이상의 조사와 분석을
통해 도출될 수 있는 지능형 웹 서비스에 한 국내에서의 응 방향과 기
술의 도입 방안을 알아보았다.
- 127 -
본 연구를 통해 우리는 먼 국가 입장에서는 새로운 웹의 시 를 이
끌어갈 것으로 상되는 지능형 웹 서비스 기술에 련하여 보다 극 으
로 세계 표 화 활동에 개입 주도할 수 있는 기회를 가지고 있다는 을
활용하여 기존의 웹 서비스나 시맨틱 웹 표 에서의 국제 으로 낙후된 입
장을 개선할 수 있다고 단하고 있으며, 기업의 입장에서는 무나 빠른
기술 변화와 표 화 활동에 민감하게 반응하여야만 이와 같은 속한 변
화 환경에서 표 수용과 기술 도구 개발에 경쟁력을 갖출 수 있을 것으
로 분석하 다. 특히 연구소나 학계에서는 시맨틱 웹 분야나 지능형 웹 서
비스 분야에서 최근 화두가 되고 있는 OWL-Rule과 같은 규칙 표 언어
표 화에 련 연구를 통해 극 으로 표 화에 동참하여 따라가는 수 을
넘어 국제 리더쉽을 갖출 수 있는 노력을 기울어야 할 것이다.
- 128 -
참고문헌
[1] 김은홍, 이진주, 정문상, 사용자 심의 경 정보시스템, 다산출 사, 1998.
[2] 소기업진흥공단, 자상거래 련 주요통계조사 EC 정책연구 결과
보고서, 2002.9.
[3] Dan Connolly, Frank van Harmelen, Ian Horrocks, Deborah L. McGuin
ness, Peter F. Patel-Schneider, Lynn Andrea Stein, "DAML+OIL (March
2001) Reference Description", http://www.w3.org/TR/daml+oil-reference
[4] Deborah L. McGuinness, Frank van Harmelen, OWL Web Ontology L
anguage Overview, http://www.w3.org/TR/2003/CR-owl-features-2003
0818
[5] Eric Miller, Ralph Swick, Dan Brickley, "W3C; Resource Description Fr
amework (RDF)", http://www.w3.org/RDF
[6] Gibson, C. F. and R. L. Nolan, "Managing the Four Stages of EDP
Growth," Harvard Business Review, Jan./Feb., 1974, pp. 76-88.
[7] McFarlan, F. W., "Information Technology Changes the Way You
Compete," Harvard Business Review, May/June, 1984.
[8] Nolan, R. L., "Managing the Computer Resources: A Stage Hypothesis,
" Communications of the ACM, 16(7), 1973, pp. 399-405.
[9] Nolan, R. L., "Managing the Crises in Data Processing," Harvard Busines
s Review, March/April, 1979, pp. 115-126.
[10] Tim Berners-Lee, James Hendler, Ora Lassila, "W3C; Semantic Web",
http://www.w3.org/2001/sw
- 129 -
연구 책임자 : 허 정회
(정보화표 장, 02-2131-0210, [email protected])
지능형 웹 서비스 표 기술 동향 국내 도입 방안 연구
2003년 12월 인쇄
2003년 12월 발행
● 발행인 : 서 삼 영
● 발행처 : 한국전산원
경기도 용인시 수지읍 죽전리 168
전화 : 031-260-2114
● 인쇄처 : 한올
전화: 02-2279-8494 <비매품>
1. 본 연구보고서는 정보통신부의 출연 으로 수행한 정보통신
연구개발사업의 연구결과입니다.
2. 본 연구보고서의 내용을 발표할 때에는 반드시 정보통신부
정보통신연구개발사업의 연구결과임을 밝 야 합니다.
