웹 서비스 품질 모델 및 테스트 가이드라인...

80

NCA Ⅳ-RER-04052 / 2004. 12

웹 서비스 품질 모델

테스트 가이드라인 연구

Quality Models and Test Guidelines

for Web Services Management

2004년 12월

80

웹 서비스 품질 모델

테스트 가이드라인 연구

Quality Models and Test Guidelines

for Web Services Management

2004년 12월

- 3 -

序文

인터넷을 많은 사람들이 보편 으로 사용함에 따라 창기의 단순한 HTML 형태로

정보를 교환하는 형태에서 B2C를 거쳐서 요즘은 기업과 기업간 거래인 B2B에 이르

고 있다. 최근에는 웹 서비스를 통하여 기업과 기업간 동 인 비즈니스를 수행하고

있으며 정부에서도 정부 내의 각 조직 간의 동 인 데이터 통합이나 로세스 통합

을 한 자 정부 로젝트를 수행하고 있다.

웹 서비스의 특징인 XML 기반 메시지를 통한 느슨한 결합 형태의 비즈니스 통

합은 많은 장 을 가지고 있지만 웹 서비스를 수용하는 하는 것이 그리 쉬운 일은

아니다. 첫째 각 웹 서비스 표 기술들의 성숙도가 다르기 때문에 웹 서비스 품질

을 향상하기 한 체계 인 웹 서비스 품질 수용 략이 존재하지 않으며 둘째는

서비스에 한 품질을 보장하기 한 품질 리 모델이 존재 하지 않는다.

따라서 본 연구에서는 품질 리를 해 표 화된 웹 서비스 품질 모델과 각 품

질을 테스트하기 한 가이드라인을 제시하고자 한다. 본 보고서에서 제시하는 품

질 모델은 웹 서비스 로젝트 개발자, 로젝트 발주자 등을 비롯한 웹 서비스 사

업에 계된 계자들이 공통된 기 으로 사용될 수 있을 것이다. 한 품질 테스

트 가이드라인은 로젝트 발주자 입장에서 개발되거나 사용되는 웹 서비스에 한

품질 테스트 검수 차에 활용될 수 있다.

- 4 -

제 출 문

정보통신부 장 귀하

본 보고서를 웹 응용기술 표 화 연구 “웹 서비스 품질 모델 테스트 가이

드라인 연구”의 최종보고서로 제출합니다.

2004년 12월

연 구 책 임 자 : 한국 산원 이 헌 (정보화기술기획 장)

참 여 연 구 원 : 한국 산원 정 희 창 (정보화기술기획 )

한국 산원 류 택 (정보화기술기획 )

한국 산원 문 재 형 (정보화기술기획 )

한국 산원 장 주 호 (정보화기술기획 )

한국 산원 김 은 주 (정보화기술기획 )

한국 산원 이 호 경 (정보화기술기획 )

자 문 원 : 국민 최 은 미 (비즈니스 IT학부)

LG CNS 안 무 정 (웹서비스/BPM )

포스데이타 이 곤 (e-Biz 연구소)

우정보시스템 강 병 철 (기술연구소)

삼성SDS 이 재 (웹서비스 추진 사업단)

ETRI 문 기 ( 자정부보안연구 )

요 약 문

1. 제목

웹 서비스 품질 모델 테스트 가이드라인 연구

2. 연구개발의 목 요성

웹 서비스는 어 리 이션의 통합 문제나 기업간(B2B)의 업 비즈니스를 한

표 인 방법으로 제시되고 있다. 웹 서비스는 기업 간 뿐만 아니라 기업 내부

로세스의 통합에 따른 비즈니스 민첩성과 유연성을 제공할 수 있다. 그러나 웹 서

비스가 표 스펙을 수 하더라도 바로 비즈니스에 사용하기에는 많은 어려움이

있다. 이러한 어려움 의 하나가 바로 웹 서비스의 품질이다. 같은 웹 서비스 표

스펙을 구 하 더라도 그 웹 서비스가 가지는 품질 수 이 여러 요인에 의해서 다

를 수 있다. 따라서 체계 인 웹 서비스 품질 리를 해서는 웹 서비스 품질 모델

과 품질 측정에 한 가이드라인을 제시해서 웹 서비스와 련된 이해 계자들이

웹 서비스의 품질을 정확히 이해할 수 있고 기술할 수 있도록 해야 한다.

본 연구의 목 은 첫째로 웹 서비스의 체계 이고 합리 인 품질 리를 해 웹

서비스의 이해 계자들이 공통으로 사용할 수 있는 웹 서비스 품질 모델 표 을 제

안하는 것이다. 둘째로는 웹 서비스 품질 리 표 을 용함에 있어서 단계 으로

표 화 되어야 하는 품질 도입 략을 제시하는 것이다. 마지막으로 제시한 품질

모델의 품질속성들 에서 기 도입 단계에 용되어야 할 품질속성들에 한 품

질테스트 가이드라인을 제시하는 것이다.

3. 연구개발의 내용 범

본 보고서에서는 체계 인 웹 서비스 품질 리를 해 웹 서비스 사용자, 제공자,

리자 등등 웹 서비스에 련된 계자들이 사용할 수 있는 표 화된 품질 모델과

련된 다음과 같은 내용을 연구 개발한다.

□ 웹 서비스 품질 모델

□ 웹 서비스 품질 리 표 화 도입 략

□ 웹 서비스 품질 테스트 가이드라인

4. 연구결과

4.1 웹 서비스 품질 모델

- 6 -

웹 서비스는 ‘서비스 지향 ‘이라는 특징 때문에 품질 면에서 기존의 설치 주의

소 트웨어 품질과는 다르다. 본 연구에서는 서비스라는 특징을 가지는 웹 서비스

에 한 품질 모델을 제시한다. 이러한 웹 서비스 품질 모델은 서비스 사용 시의

의 치에 따라 사용자 계층, 상호운용 계층, 리 보안 계

층의 세 계층으로 나 어지며 각 계층은 다시 세부 에 따라 다수 개의 품질요

소를 갖는다. 각 품질요소별로 품질 정의, 세부 품질 요소, 품질 계약, 품질 계자

들을 정의한다.

4.2 웹 서비스 품질 도입 략

웹 서비스 표 기술은 표 자체가 차 진화하고 있어서 그 기술에 한 도입은

물론 서비스 품질에 한 리도 단계 으로 이루어져야 한다. 본 보고서에서는 웹

서비스 품질 리 3단계 도입 략을 제시하고 각 단계별로 표 화 되어야 하는 웹

서비스 사용상의 품질에 해서 설명한다. 이 게 단계 으로 품질 리 도입을 진

행함으로써 체 품질 요한 부분부터 보다 구체 이고 체계 으로 진행할 수

있다. 이 품질 리 도입 3단계 략은 국제 웹 서비스 표 진행 상황과 국내의

형 SI 업체들을 심으로 재 국내 웹 서비스 도입 상황을 고려하여 작성한 것

이다.

4.3 웹 서비스 품질 테스트 가이드라인

웹 서비스 품질 테스트 가이드라인은 앞에서 정의한 웹 서비스 품질모델을 기반으

로 서비스 제공자가 자신이 제공하려는 웹 서비스의 품질을 자체 평가하기 한 것

이다. 한 이는 웹 서비스 사용자나 리자가 제공되는 웹 서비스의 실제 품질이

계약서상의 품질 요구사항을 제 로 만족시키는지를 확인하려고 할 때 참고할 테스

트 가이드라인으로 사용된다. 본 보고서에서는 특별히 웹 서비스 품질 도입하는

기단계에서 다루어야할 품질들에 한 테스트 가이드라인을 제시한다. 각 품질요소

별로 테스트 아키텍처, 테스트 항목, 테스트 시나리오, 테스트 방안 등에 해 다룬

다.

4.4 웹 서비스 품질 리 표 기술 동향

본 보고서의 부록으로 웹 서비스 품질과 련된 표 기술들을 요약정리 하 다. 품

질 모델과 련해서는 ISO-9126 소 트웨어 품질 표 를, 품질 리 모델과 련해

서는 표 으로는 W3C의 웹 서비스 리 모델, HP사의 웹 서비스 리 임워크,

IBM의 WS-Manageability, OASIS의 웹 서비스 분산 리(WSDM) 표 기술 동향

을 참조하 다. 품질 계약 모델과 련해서는 IBM의 웹 서비스 벨 계약을 요약하

고 테스트 가이드라인을 련해서는 ebXML Test Framework을 검토하 다.

- 7 -

5. 활용에 한 건의 기 효과

본 보고서의 활용 방안은 다음과 같다.

웹 서비스 개발 계약을 해 품질 요구사항 정의 시

웹 서비스 발주자가 웹 서비스를 개발하기 하여 개발 계약 맺을 때에 서비스

품질에 한 요구사항도 계약서 내용에 들어가야 한다. 이때 발주자와 개발자가

공통으로 받아들일 수 있는 합리 인 웹 서비스 품질 모델이 필요하다. 본 보고

서에서 제시하는 품질모델을 그 기반 모델로 사용할 수 있다.

개발된 웹 서비스를 검수 시의 품질 테스트 가이드라인

개발된 웹 서비스가 개발 계약에 정의된 품질 요구사항을 정확히 제공하고 있는

지 여부를 검수할 때에 품질 테스트가 필요하다. 본 보고서에서 제시하는 테스

트 가이드라인을 활용하면 어떤 테스트 환경이 필요하고, 어떤 항목들을 어떤

차를 사용하여 테스트 하는지 등에 한 도움을 받을 수 있다.

웹 서비스 제공자와 사용자 간의 웹 서비스 품질 수 계약에 사용

웹 서비스 제공자는 제공하려는 웹 서비스에 한 품질 수 과 품질 수 반

시 취해야 하는 보상내용을 웹 서비스 사용 계약서로 작성하게 된다. 이러한 웹

서비스 사용계약 단계에서 본 보고서가 제시하는 품질 모델이 웹 서비스 품질에

한 제공자와 사용자 사이에 공통 참조 모델로 이용할 수 있다.

제공되고 있는 웹 서비스가 계약 품질에 맞는 서비스를 제공하고 있는지 감독

는 리하고자 할 때 사용가능

본 보고서에서 제시하는 품질 모델과 테스트 가이드라인은 계약을 맺고 원격에

서 사용하고 있는 웹 서비스가 계약서에 명시된 품질 수 의 서비스를 제공하고

있는지 제3의 감독자에 의하여 감독하거나 는 제3의 리자에 의하여 리 하

고자 할 때 사용 가능하다.

SUMMARY

Since the Internet has been popular with many people, the usage has been transformed

into various forms. Starting from simple html document exchanges, the B2C was

popular, and nowadays the B2B becomes one of the trends for company-to-company

trade. Recently, the Web Service is a business solution to run the dynamic

company-to-company business. Also, the government organizes e-government project

to dynamically integrate data and process among a number of organizations.

The loosely-coupled business integration with XML-based message that is a

characteristic of the Web Servicehas lots of advantages. However, accepting the Web

Service as the general standard is not an easy decision. First of all, becausematurities of

Web Service standard technologies are all different, it is impossible to have a

systematic strategy of Web Service quality acceptance for Web Service quality

improvement. The second is that there is no quality management model to guarantee

the service quality.

Thus, this research proposes the guideline of standard Web Service quality model for

quality management and of testing quality. The quality model proposed in this report

is used for the Web Service-related associates, such as the Web Service project

developer, project ordering party, as a common standard. Also, quality testing

guideline can be developed in terms of project ordering party, and be used in quality

testing inspection of the Web Service used.

The purpose of this research is to propose the Web Service quality model standard

that can be commonly used by the Web Service-related associates for the systematic

and reasonable quality management of the Web Service. The second purpose is to

propose the quality induction strategies which need to be step-by-step standardized for

applying the Web Service quality management standards. Finally, it is to propose the

quality testing guideline about quality factors that should be considered in the initial

induction stage among a number of quality factors of quality model proposed.

- 9 -

CONTENT

Chapter 1 Introduction ········································································································1

1.1 Backgrounds and Necessity ························································································1

1.2 Purpose ·····························································································································1

1.3 Contents and Structure ································································································2

Chapter 2 Web Service Basic ··························································································4

2.1 Web Service Concepts and Characteristics ·····························································5

2.2 Web Services Architecture ···························································································5

2.3 Web Services Protocol Stack ·······················································································6

Chapter 3 Technical Standardization Trends toward WS Quality Management 9

3.1 ISO-9126 Software Quality ························································································9

3.2 W3C Web Services Management Model ·····························································10

3.3 HP WSMF Web Services Management Framework ···········································10

3.4 IBM WS-Manageability Web Services Management ···········································10

3.5 OASIS WSDM Web Services Distributed Management ····································11

3.6 IBM WSLA Web Services Quality Contract ·························································11

Chapter 4 Web Services Quality Management View ················································12

4.1 Quality Model of Web Services ··············································································13

4.1.1 Web Service Quality As a Remote Service ···················································13

4.1.2 Service Quality Model ·························································································14

4.2 Quality Associates Model of Web Services ························································15

4.2.1 Stakeholder and Developers ··············································································16

4.2.2 Providers ·················································································································16

4.2.3 Consumers ··············································································································17

4.2.4 Quality Broker ·······································································································17

4.2.5 Quality Assuror ·····································································································17

4.2.5 Quality Manager ···································································································17

4.3 Quality Contract Model of Web Services ···························································18

4.3.1 Development Quality Contract ··········································································18

4.3.2 Usage Quality Contract ·······················································································18

4.4 Quality Management Model of Web Services ···················································19

4.4.1 Distributed Monitor Model ················································································20

4.4.2 Distributed Manager Model ···············································································21

Chapter 5 Web Service Quality Model ········································································24

5.1 Service-Level Business Value Quality ····································································24

5.1.1 Definition ··············································································································24

5.1.2 Quality Sub-Factors ····························································································24

5.1.3 Quality Contracts ································································································25

5.1.4 Quality Related Associates ·················································································25

5.1.5 Related Standards ·································································································25

5.2 Service Level Measurement Quality ·······································································26

5.2.1 Definition ··············································································································26

5.2.2 Quality Sub-Factors ······························································································26

5.2.3 Quality Contracts ······························································································28



5.3 Interoperability Quality ······························································································30

5.3.1 Definition ··············································································································30


5.3.3 Quality Contracts ··································································································30



5.4 Business Processing Quality ·····················································································31

5.4.1 Definition ··············································································································32





5.5 Manageability Quality ································································································36

5.5.1 Definition ··············································································································36




5.5.5 Related Standards ·······························································································39

5.6 Security Quality ···········································································································40

5.6.1 Definition ··············································································································40




5.6.5 Related Standards ·······························································································49

5.7 Web Service Quality Priority Per Related Associates ········································50

Chapter 6 Adoption Strategy to Web Service Quality Management ····················52

6.1 Step 1 ·····························································································································52

6.2 Step 2 ·····························································································································53

6.3 St데 3 ······························································································································54

Chapter 7 Web Services Testing Guidelines ································································55

7.1 Service Level Business Value Quality Test ··························································55

7.1.1 Test Architecture ···································································································55

7.1.2 Test Items and Test Strategy ············································································55

7.2 Service Level Measurement Quality Test ······························································57


7.2.2 Test Items ···············································································································57

7.2.3 Test Scenario ··········································································································58

7.2.4 Test Strategy ··········································································································59

7.3 Interoperability Quality Test ·····················································································59


7.3.2 Test Items ···············································································································60

7.3.3 Test Scenario ··········································································································62

7.3.4 Test Strategy ··········································································································63

7.4 Business Process Quality Test ··················································································63


7.4.2 Test Items ···············································································································64

7.4.3 Test Scenario ··········································································································66

7.4.4 Test Strategy ··········································································································70

7.5 Manageability Quality Test ·······················································································71


7.5.2 Test Items ···············································································································72

7.5.3 Test Scenario ··········································································································73

7.5.4 Test Strategy ··········································································································74

7.6 Security Quality Test ··································································································74


7.6.2 Test Items ···············································································································76

7.6.3 Test Scenario ········································································································78

7.6.4 Test Strategy ··········································································································79

Chapter 8 Conclusion ···········································································································81

- 13 -

Appendix A Detailed Test Itesm Per WS-SProfile ·····················································82

Appendix B Security Terminologies ················································································86

Appendix C Web Service Management Technology Standards ·····························91

- 14 -

목 차

제 1 장 개 요 ·······················································································································1

1.1 배경 필요성 ···············································································································1

1.2 목 ···································································································································1

1.3 내용 구조 ···················································································································2

제 2 장 웹 서비스 개요 ·······································································································4

2.1 웹 서비스 개념 특징 ·····························································································5

2.2 웹 서비스 아키텍처 ·······································································································5

2.3 웹 서비스 로토콜 스택 ·····························································································6

제 3장 웹 서비스 품질 리 표 화 기술 동향 ·····························································9

3.1 ISO-9126 소 트웨어 품질 표 ···············································································9

3.2 W3C 웹 서비스 리 모델 ······················································································10

3.3 HP WSMF 웹 서비스 리 임워크 표 ·······················································10

3.4 IBM WS-Manageability 웹 서비스 리 표 ·······················································10

3.5 OASIS WSDM 웹 서비스 분산 리 표 ····························································11

3.6 IBM WSLA 웹 서비스 품질 계약 표 ································································11

제 4 장 웹 서비스 품질 리 뷰 개요 ············································································12

4.1 웹 서비스 품질 모델 ···································································································13

4.1.1 서비스로서의 웹 서비스 품질 ············································································13

4.1.2 서비스 품질 모델 ··································································································14

4.2 웹 서비스 품질 계자 모델 ·····················································································15

4.2.1 발주자와 개발자 ····································································································16

4.2.2 제공자 ······················································································································16

4.2.3 소비자 ······················································································································17

4.2.4 품질 개자 ············································································································17

4.2.5 품질 보증자 ············································································································17

4.2.5 품질 리자 ············································································································17

4.3 웹 서비스 품질 계약 모델 ·························································································18

4.3.1 개발 품질 계약 ······································································································18

4.3.2 사용 품질 계약 ······································································································18

4.4 웹 서비스 품질 리 모델 ·························································································19

4.4.1 분산 감독 모델 ······································································································20

4.4.2 분산 리 모델 ······································································································21

제 5 장 웹 서비스 품질 모델 ··························································································24

5.1 서비스 벨 비즈니스 가치(Business Value) 품질 ···············································24

5.1.1 정의 ························································································································24

5.1.2 세부 품질 요소 ····································································································24

5.1.3 품질 계약 ··············································································································25

5.1.4 품질 계자 ············································································································25

5.1.5 련 표 ················································································································25

5.2 서비스 벨 측정(Service Level Measurement) 품질 ··········································26

5.2.1 정의 ························································································································26

5.2.2 세부 품질 요소 ······································································································26

5.2.3 품질 계약 ··············································································································28

5.2.4 품질 계자 ············································································································29

5.2.5 련 표 ················································································································30

5.3 상호운용성(Interoperability) 품질 ·············································································30

5.3.1 정의 ··························································································································30

5.3.2 세부 품질 요소 ······································································································30

5.3.3 품질 계약 ················································································································30

5.3.4 품질 계자 ············································································································31

5.3.5 련표 ··················································································································31

5.4 비즈니스 처리(Business Processing) 품질 ······························································31

5.4.1 정의 ··························································································································32

5.4.2 세부 품질 요소 ····································································································32

5.4.3 품질 계약 ················································································································34

5.4.4 품질 계자 ············································································································34

5.4.5 련 표 ················································································································35

5.5 리가능성(Manageability) 품질 ···············································································36

5.5.1 정의 ························································································································36

5.5.2 세부 품질 요소 ······································································································37

5.5.3 품질 계약 ················································································································38

5.5.4 품질 계자 ············································································································38

5.5.5 련 표 ··············································································································39

5.6 보안(Security) 품질 ······································································································40

5.6.1 정의 ··························································································································40

5.6.2 세부 품질 요소 ······································································································42

5.6.3 품질 계약 ················································································································48

5.6.4 품질 계자 ············································································································48

5.6.5 련표 ··················································································································49

5.7 사용자별 웹 서비스 품질 요도 ···········································································50

제 6 장 웹 서비스 품질 리 도입 략 ·····································································52

6.1 제 1 단계 ·······················································································································52

6.2 제 2 단계 ·······················································································································53

6.3 제 3 단계 ·······················································································································54

제 7 장 웹 서비스 테스트 가이드라인 ···········································································55

7.1 서비스 벨 비즈니스 가치 품질 테스트 ·····························································55

7.1.1 테스트 아키텍처 ····································································································55

7.1.2 테스트 항목 테스트 방안 ··············································································55

7.2 서비스 벨 측정 품질 테스트 ·················································································57

7.2.1 테스트 아키텍처 ····································································································57

7.2.2 테스트 항목 ············································································································57

7.2.3 테스트 시나리오 ··································································································58

7.2.4 테스트 방안 ············································································································59

7.3 상호운용성 품질 테스트 ·····························································································59

7.3.1 테스트 아키텍처 ····································································································59

7.3.2 테스트 항목 ············································································································60

7.3.3 테스트 시나리오 ····································································································62

7.3.4 테스트 방안 ············································································································63

7.4 비즈니스 로세스 처리 품질 테스트 ·····································································63

7.4.1 테스트 아키텍처 ····································································································63

7.4.2 테스트 항목 ··········································································································64

7.4.3 테스트 시나리오 ····································································································66

7.4.4 테스트 방안 ············································································································70

7.5 리가능성 품질 테스트 ·····························································································71

7.5.1 테스트 아키텍처 ····································································································71

7.5.2 테스트 항목 ············································································································72

7.5.3 테스트 시나리오 ··································································································73

7.5.4 테스트 방안 ············································································································74

7.6 보안 품질 테스트 ·········································································································74

7.6.1 테스트 아키텍처 ····································································································74

7.6.2 테스트 항목 ··········································································································76

7.6.3 테스트 시나리오 ··································································································78

7.6.4 테스트 방안 ············································································································79

제 8 장 결론 ···························································································································81

A. 별첨 - WS-SProfile별 테스트 세부 항목 ··································································82

B. 별첨 - 보안 용어 설명 ····································································································86

C. 별첨 - 웹 서비스 리 표 화 기술 ········································································91

그림 목차

<그림 2-1> 웹 서비스 아키텍처 ····························································································4

<그림 2-2> 웹 서비스 로토콜 스택 ··················································································5

<그림 2-3> 웹 서비스 로토콜 도입 단계 ········································································7

<그림 4-1> 웹 서비스 품질 리 뷰 ··················································································11

<그림 4-2> 웹 서비스 품질 모델 ························································································13

<그림 4-3> 웹 서비스 품질 계자 모델 ··········································································15

<그림 4-4> WSDM 웹 서비스 리 모델 ·········································································19

<그림 4-5> 분산 감독 모델 ··································································································20

<그림 4-6> 분산 리 모델 ··································································································21

<그림 7-1> 서비스 벨 측정 품질 테스트 아키텍처 ····················································57

<그림 7-2> 상호운용성 품질 테스트 아키텍처 ································································60

<그림 7-3> 비즈니스 로세스 처리 품질 테스트 아키텍처 ········································64

<그림 7-4> 2PC 컨텍스트 생성 과정 ···············································································69

<그림 7-5> 리가능성 품질 테스트 아키텍처 ································································70

<그림 7-6> 보안 품질 테스트 아키텍처 ··········································································74

<그림 B-1> TLS 핸드쉐이크 로토콜 ·············································································86

<그림 B-2> 인증 헤더로 보호된 IP 페이로드의 구조 ··················································86

<그림 B-3> ESP의 구조 ·······································································································87

<그림 B-4> WS-Security가 용된 SOAP 메시지의 구조 ···········································88

<그림 B-5> WS-Security가 용된 SOAP 메시지 ·····················································89

<그림 C-1> ISO-9126 제품 품질 분류 ·············································································91

<그림 C-2> ISO-9126 사용상의 품질 분류 ···································································94

<그림 C-3> W3C 리 모델 ······························································································95

<그림 C-4> WSMF의 리 구조 ·························································································96

<그림 C-5> WS-Manageability 리 메타 모델 ······························································97

<그림 C-6> IBM의 리 명세 스택 ··················································································99

<그림 C-7> MUWS를 이용한 IT 리소스 리 ······························································101

<그림 C-8> MUWS의 개념 ································································································102

<그림 C-9> MUWS의 논리 모델 ······················································································103

<그림 C-10> MUWS의 로세싱 모델 ············································································104

<그림 C-11> 리 가능한 인터페이스 ·············································································105

<그림 C-12> 리소스 상태 ···································································································106

<그림 C-13> MOWS 아키텍처 ··························································································107

<그림 C-14> WSLA 구조 ····································································································108

표 목차

<표 5-1> 리가능성 세부 품질 요소 ··············································································37

<표 5-2> 웹 서비스 보안 요소별 련 기술 ····································································44

<표 5-3> 보안 로 일별 보안 요소 ················································································47

<표 5-4> 웹 서비스 계자별 품질 요도 ····································································49

<표 6-1> 웹 서비스 품질 리 표 화 도입 략 ··························································52

<표 7-1> WS-SProfile 0 테스트 항목 ···················································································76

<표 7-2> WS-SProfile 1 테스트 항목 ···················································································76

<표 A-1> WS-SProfile 0 테스트 세부 항목 ·········································································81

<표 A-2> WS-SProfile 1 테스트 세부 항목 ·········································································83

참조 약어

1. 참조 문서

다음의 문서는 웹 서비스 품질 모델 테스트 가이드라인을 한 참조 문서로서

본 보고서와 련된 세부사항에 해 보다 상세한 정보가 필요하다면 우선 아래의

문서들에서 련 항목을 참조해야 하며, 이 경우에는 반드시 최신의 개정 을 참조

할 것을 권고한다.

ISO 9126

URL:http://www.iso.org/iso/en/CatalogueDetailPage.CatalogueDetail?CSNUMBER

=39752

WS-I Basic Profile 1.1

URL: http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html

WS-I Basic Security Profile Version 1.0

URL: http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0-2004-05-12.html

WS-I Simple SOAP Binding Profile Version 1.0

URL: http://www.ws-i.org/Profiles/SimpleSoapBindingProfile-1.0-2004-08-

24.html

OASIS WS-Reliable Messaging

URL: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrm

OASIS BPEL4WS(Business Process Execution Language For Web Service)

URL: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel

OASIS WS-CAF(Composite Appliction Framework)

URL: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-caf

W3C WS-CDL (Web Service Choreography Description Language)

URL: http://www.w3.org/TR/2004/WD-ws-cdl-10-20040427/

OASIS WSDM

URL: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsdm

W3C XML Encryption

URL: http://www.w3c.org/Encryption/2001

W3C XML Digital Signature

URL: http://www.w3c.org/Signature

OASIS SAML

URL: http://www.oasis-open.org/home/index.php

OASIS XACML

URL: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml

OASIS의 WS-Security Specification

URL:http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message

-security-1.0.pdf

OASIS ebXML Test Framework

URL: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev

=ebxml-iic

WS-I Profile Development Model

URL: http://www.ws-i.org/archive/Profiles/Basic/2003-08/BasicProfile-1.0a.htm

2. 어 약어

ISO: International Standard Organization

BLA: Business Level Agreement

SLA: Service Level Agreement

SOAP: Simple Object Access Protocol

WSDL: Web Service Description Language

UDDI: Universal Description Discovery Interface

XML: eXtensible Markup Lanuage

2PC: 2 Phase Commit

ACID: Atomicity, Consistency, Isolation and Durability

WSDM: Web Service Distributed Management

HTTP: Hyper Text Transfer Protocol

SSL: Secure Socket Layer

TLS: Transport Layer Security

IPSec: IP Security

DOS: Denial of Service

IDS: Intrusion Detection Service

IPS: Internet Protocol Security

S/MIME: Secure / Multipurpose Internet Mail Extensions

PGP: Pretty Good Privacy

MIME: Multipurpose Internet Mail Extensions

XML-DSIG: XML Digital Signature Standard

PKI: Public Key Infrastructure

XKMS: XML Key Management Service

SAML: Security Assertion Markup Language

XACML: Extensible Access Control Markup Language

- 1 -

제 1 장 개 요

1.1 배경 필요성

비즈니스 모델이 B2B나 EAI로 변해가는 재 인터넷 비즈니스 환경에서 기업 혹은

기업간의 다양한 통합 요구에 부응하기 해 많은 방법을 시도하고 있다. 웹 서비

스는 변하는 비즈니스 환경에 응 각종 어 리 이션 통합 문제 다양한

이 기종 랫폼에 따른 기업간 업문제를 해결할 수 있는 방안을 제시하고 있다.

한 기업간(B2B) 뿐 아니라 기업 내부 로세스의 통합에 따른 비즈니스 민첩성과

유연성을 제공할 수 있다. 이러한 웹 서비스가 이상 인 모델로 향후 확산될 것이

라고 확신 하지만 재의 IT환경에서 웹 서비스를 비즈니스로 만들기 해서는 과

, 보안, 표 , 품질 등 선결해야 할 많은 문제가 남아있다. 그 에서 가장 시 한

부분이 표 화이다. 재 웹 서비스 표 화 작업은 WSDL, SOAP, UDDI 기본 로

토콜에 해서는 완성되었으며 나머지 웹 서비스 각 분야 별로 표 화 작업을 진행

에 있다.

모든 웹 서비스가 표 스펙을 그 로 구 하고 수 하더라도 바로 비즈니스

에 사용하기에는 많은 어려움이 있다. 이러한 어려움 에 하나가 바로 웹 서비스

의 품질이다. 같은 웹 서비스 표 스펙을 구 하더라도 그 웹 서비스가 가지는 품

질 수 은 여러 요인에 의해서 다를 수 있다. 그리고 웹 서비스는 새로운 시스템을

처음부터 개발하거나 혹은 컴포 트를 만들거나 구매해서 개발하는 방식이 아니라

시스템 변경이 요구될 때 언제라도 새로운 서비스로 교체, 새로운 기능을 서비스로

받을 수 있는 SOA(Service Oriented Architecture)기반의 시스템 체제이다. 따라서

하나의 웹 서비스는 다른 웹 서비스 시스템에 통합되어 질 수 있으며 체의 웹 서

비스 통합 시스템이 좋은 품질을 유지하기 해서는 각각의 웹 서비스들이 좋은 품

질 수 을 유지해야 한다. 웹 서비스를 통한 시스템 통합의 단계에서 좋은 품질의

서비스를 제공하는 것이 웹 서비스 제공자 입장에서 비즈니스 성공에 요한 요인

이 된다. 이러한 체계 인 웹 서비스 품질 리를 해서는 웹 서비스와 련된 이

해 계자들이 웹 서비스의 품질을 정확히 이해할 수 있고 기술할 수 있는 웹 서비

스 품질 모델이 필요하다.

1.2 목

본 연구의 목 은 크게 세 가지이다.

첫째, 웹 서비스의 체계 이고 합리 인 품질 리를 해 웹 서비스의 이해 계

자들이 공통으로 사용할 수 있는 웹 서비스 품질 모델 표 을 제안하는 것이다.

둘째, 웹 서비스 품질 리 표 을 용함에 있어서 단계 으로 표 화 되어야

- 2 -

하는 품질 도입 략을 제시하는 것이다.

셋째, 제시한 품질 모델의 품질속성들 에서 기 도입 단계에 용되어야 할

품질속성들에 한 품질테스트 가이드라인을 제시하는 것이다.

1.3 내용 구조

본 보고서에서 다루고 있는 내용은 다음과 같다

제 2 장 웹 서비스 개요

제 2장에서는 웹 서비스의 개념과 특징과 서비스 지향 인 웹 서비스 아키

텍처를 살펴본 후, 웹 서비스 표 화 진행정도를 알 수 있는 로토콜 스

택과 로토콜 도입 단계를 설명한다.

제 3 장 웹 서비스 품질 리 표 화 기술 동향

제 3장에서는 웹 서비스 품질을 리하기 한 리 기술 표 화 동향에

해서 표 단체나 외국 기업에서 제안한 기술표 을 통하여 알아본다. 이

러한 웹 서비스 품질 리 련 표 화 기술에는 ISO-9126 소 트웨어 품

질 표 , W3C 웹 서비스 리 모델, HP WSMF 웹 서비스 리 임워

크 표 , IBM WS-Manageability 웹 서비스 리 표 , OASIS WSDM 웹

서비스 분산 리 표 , IBM WSLA 웹 서비스 품질 계약 표 이 있다.

제 4 장 웹 서비스 품질 리 뷰 개요

제 4장에서는 웹 서비스 품질 리를 바라보는 , 즉 뷰(View)를 설명한

다. 이 품질 리 뷰는 웹 서비스 품질 리를 해 필수 인 네 가지 기본

모델로 구성된다. 품질 리의 상이 되는 웹 서비스 품질을 인식하는 기

모델인 웹 서비스 품질 모델, 웹 서비스 생명주기 동안 웹 서비스와

련된 계자들에 한 기 모델인 웹 서비스 계자 모델, 웹 서비스 이해

계자들이 필요에 따라 맺게 되는 계약들에 한 기 모델인 웹 서비스

계약 모델, 마지막으로 제 3자에 의한 웹 서비스 원격 리를 하여 서비

스 제공자가 제공하여야 할 웹 서비스 리 인터페이스에 한 기 모델인

웹 서비스 리모델이 포함된다. 4장에서는 이 4개의 모델에 해서 설명

한다. 본 연구는 이들 모델 에서 첫 번째 모델인 웹 서비스 품질 모델에

한 연구이다.

제 5 장 웹 서비스 품질 모델

- 3 -

제 5장에서는 4장에서 제시한 원격 서비스로서의 웹 서비스의 품질 모델에

해서 크게 3개의 계층과 6개의 품질 속성으로 나 어서 설명한다. 3개의

계층은 사용자 계층, 상호운용 계층, 리 보안 계층이

있다. 6개의 품질 속성에는 서비스 벨 비즈니스 가치 품질, 서비스 벨

측정 품질, 상호운용성 품질, 비즈니스 처리 품질, 리가능성 품질, 보안

품질이 속한다.

제 6 장 웹 서비스 품질 리 도입 략

제 6장에서는 5장에서 제시한 품질 모델을 바탕으로 웹 서비스 품질 리

도입 3 단계 략에 하여 소개한다. 이 3단계 략은 국제 웹 서비스 표

진행 상황과 국내의 형 SI 업체들을 심으로 재 국내 웹 서비스

도입 상황을 고려하여 작성한 것이다. 제 1단계는 기업 내의 통합이나

트 계에 있는 두개 기업 간의 업무를 일 일로 통합해 웹 서비스를 사

용하는 단계이고, 제 2단계는 웹 서비스를 기업 간의 정 인 비즈니스

로세스 통합에 이용할 경우이다. 마지막 단계는 2단계에서와 같은 정 인

비즈니스 로세스의 통합은 더욱 다양해지고 서비스 이용시 에 필요한

서비스를 찾아 연결시키는 동 인 비즈니스 로세스 통합도 등장하는 단

계이다.

제 7 장 웹 서비스 테스트 가이드라인

제 7장에서는 웹 서비스 제공자가 자신이 제공하려는 웹 서비스의 품질을

자체 평가하거나 웹 서비스 사용자 혹은 리자가 제공되는 웹 서비스의

품질이 계약서상의 품질 수 을 수하는지에 한 감독 는 리 작업

시 참고할 품질 테스트 가이드라인을 제시한다. 본 장에서 다루는 품질 속

성은 6장에서 제시한 도입 단계의 1단계의 품질 속성만을 고려한다. 하지

만 제시한 테스트 아키텍처나 테스트 로세스는 재사용 가능하다.

- 4 -

제 2 장 웹 서비스 개요

웹 서비스는 기업 내 혹은 기업간 통합서비스 환경의 여러 가지 문제를 해결해 주

는 차세 e-비즈니스 기술로써 재 많은 기업들이 표 화 기술 개발에 참여하

고 있다. 웹 서비스 품질 모델에 해서 언 하기 이 에 본장에서는 웹 서비스의

개념, 특징 표 기술 동향에 해서 살펴본다. 웹 서비스 품질 리 표 화 동

향은 다음 장에서 소개한다.

2.1 웹 서비스 개념 특징

웹 서비스란 인터넷과 같이 공개 인 네트워크와 련 표 을 통하여 단일한 기업

내부 는 다수의 기업 간에 기존의 어 리 이션을 운 체제 로그램 언어에

계없이 상호운 이 가능하도록 해주는 표 화된 소 트웨어 기술이다. 한 비즈

니스 거래 업체간의 필요한 서비스를 발견, 제공하여 다양한 비즈니스를 가능 해

주는 기술도 포함한다. 이러한 웹 서비스의 특징은 아래와 같다.

웹 서비스는 랫폼에 독립 이다. 웹 서비스는 느슨히 결합되어진(Loosely

Coupled) 소 트웨어 구조를 가지고 있기 때문에 서비스 제공자, 사용자가 특별

한 기능을 추가하기 해 추가되는 기능에 따른 새로운 랫폼을 사용하지 않아

도 되며, 랫폼 선택도 매우 자유롭다.

웹 서비스는 시스템 디바이스 치 독립 이다. 웹 서비스를 통해 PC, PDA,

핸드폰 등 다양한 유·무선 디바이스를 통해 시간 장소에 상 없이 서비스에

근 가능하다.

웹 서비스는 동 인 기능을 가지고 있다. 기업에서 요구되는 다양한 기능들을

한 서비스 제공자로부터 찾을 수 있고, 실시간으로 연계될 수 있으며, 서비

스 제공자와 고객의 역할이 고정되어 있지 않다.

웹 서비스를 통해 비용이 감된다. 웹 서비스는 분산시스템의 소 트웨어간의

통합을 자동화함으로서 각 기업의 IT 개발비용이나 운 비용을 감시켜 다.

웹 서비스를 이용하여 기존(legacy) 시스템의 통합 환경을 제공한다. 기존에 투

자되었던 IT 어 리 이션 인 라 등 기존의 시스템에 새로운 시스템을 구축

하는 것이 아니라 이미 존재하고 있는 시스템을 통합하여 운 함으로써 기업에

다양한 이 을 제공해 다.

다음 에서는 웹 서비스 아키텍처와 웹 서비스 표 기술의 계와 표 화 정도를

볼 수 있는 로토콜 스택에 해서 설명한다.

- 5 -

2.2 웹 서비스 아키텍처

웹 서비스 아키텍처는 웹 서비스 사용에 있어서 동 이며 자동 인 서비스의 발견

과 사용을 제공하기 해서 웹 서비스의 컴포 트들을 어떻게 구성하며 한 어떻

게 기술할지를 설명한다. 웹 서비스 아키텍처에 속하는 컴포 트로는 서비스 제공

자, 서비스 소비자, 서비스 등록기인 세 개의 컴포 트가 있다. 웹 서비스 아키텍처

는 아래 <그림 2-1>과 같으며 각 컴포 트는 웹 서비스 표 기술인 SOAP(Simple

Object Access Protocol), WSDL(Web Service Description Language),

UDDI(Universal Discription, Discovery and Integration)를 사용한다. 각 컴포 트간

의 계는 다음과 같다.

<그림 2-1> 웹 서비스 아키텍처

서비스 제공자는 WSDL을 이용해서 웹 서비스를 정의하며 UDDI를 통해서 서비스

개자에 서비스를 등록(Publish)한다. 서비스 개자인 서비스 개자는 웹 서비스

를 장소에 등록하고 서비스 제공자를 분류하며 검색(Search)하는 서비스를 제공한

다. 그리고 서비스 사용자는 UDDI를 통해서 서비스를 찾고(Find) 서비스 제공자에

SOAP으로 연결(Bind)해서 서비스에 한 정보인 WSDL을 찾아서 실제 서비스를

사용하게 된다. 다음 은 웹 서비스 아키텍처에서 사용한 웹 서비스 표 기술

로토콜에 한 설명이다.

2.3 웹 서비스 로토콜 스택

웹 서비스 로토콜 스택은 웹 서비스의 정의, 발견, 실행을 해 사용되는 로토

콜들의 집합이다. 핵심 로토콜 스택은 <그림 2-2>와 같이 가장 하부 계층인 송

계층(Transport Layer)부터 시작하여 표 계층(Description Layer), 발견계층

- 6 -

(Discovery Layer), 보안계층(Security Layer), 그리고 가장 상 계층인 리계층

(Management Layer)까지 총 5개의 계층으로 구성된다. 아래는 각 계층에 속하는

웹 서비스 로토콜에 한 간략한 소개이다. 본 보고서에서 언 하는 품질 리와

한 계가 있는 리 계층 품질 리 스펙에 해서는 3장에서 보다 자세히 설

명한다.

*출처: CBDI Web Service Roadmap

<그림 2-2> 웹 서비스 로토콜 스택

Transport 계층: 네트워크 로토콜 단계로서 SOAP 메시지는 내부에 웹 서비스

를 패키징하여 HTTP, TCP, SMTP 등의 인터넷 로토콜을 사용해서 송한다.

재 W3C 표 기 에서는 메세징과 어드 싱에 한 연구가 진행되고 있으며

WS-ReliableMessaging, WS-Reliability, 그리고 WS-Addressing의 표 이 그것이

다. WS-ReliabileMessaging은 SOAP 메시지가 네트워크 상의 오류 없이 송되

는 것을 보장하고, WS-Reliability SOAP 메시지가 복 없이 보낸 순서 로

송되는 것을 보장한다. WS-Addressing은 웹 서비스 SOAP 메시지의 주소를

지정할 수 있는 송 립 메커니즘을 제공하고 웹 서비스가 참조될 수 있는

엔티티(Entity)의 종단(Endpoint)과 서비스 종단(Endpoint)을 식별하기 한

SOAP 메시지의 헤더를 확장한다.

- 7 -

Description 계층: 웹 서비스를 정의하고 호출하는 방법을 제공하는 계층이다.

Description에는 다음과 같은 로토콜이 존재한다. WSDL과 웹 서비스의 정책

에 한 요구사항을 표 하기 한 임워크인 WS-Policy가 존재하며 웹 서

비스 에서의 비즈니스 로세스를 기술하는 명세인 BPEL4WS(Business

Process Execution Language for Web Service)가 존재한다. 그 외에도

WS-Transaction은 웹 서비스의 실행 단 인 액티비티(Activity)를 AT(Atomic

Transaction)와 BA(Business Activity)의 두 가지 타입으로 정의하는 로토콜이

다. AT는 실행시간이 짧은 액티비티를 조정(Coordination)하는데 사용되고 BA는

실행시간이 긴 액티비티를 조정(Coordination)하는데 사용된다. 그리고

WS-Coordination은 이러한 WS-Transaction 로토콜을 한 임워크를 정의

한다.

Discovery 계층: 서비스 공개를 한 단계로서 서비스 제공자는 제공할 서비스

를 UDDI Broker에 등록(Publication)하며 이러한 서비스를 사용할 사용자는

UDDI Broker를 사용하여 원하는 서비스를 발견(Discovery)하기 한 로토콜

을 정의한다.

Security 계층: 웹 서비스의 보안에 한 심이 높아지면서 더욱 요시되고 있

는 보안 계층은 WS-Federation, WS-Trust, WS-SecureConversation,

WS-SecurityPolicy 그리고 WS-Security와 같은 련 표 로토콜이 있다.

WS-Federation은 연합된 Identities, 속성 공유와 같은 이종의 연합된 환경에서

신뢰 인 계를 리하는 방법을 기술하며 WS-Trust는 웹 서비스들이 안 한

토큰(Secure Tokens)을 요청, 발행, 교환할 때 안 하게 상호작용을 하기

한 신뢰성 있는 모델에 한 임워크를 기술하는 표 이다.

WS-SecureConversation는 메시지를 주고받을 때 메시지에 한 보안 련 인

증을 정의하는 표 이며 WS-Security는 SOAP 메시지의 헤더부분을 암호화하고

서명을 함으로써 SOAP 메시지 자체의 보안에 을 둔 표 이다.

Management 계층: 분산 환경에서 웹 서비스의 리에 한 모델을 정의한 계층

으로서 련 표 으로는 WS-Manageability가 있으며 재 OASIS에서

WSDM(Web Service Distributed Management)으로 표 화 작업 이다.

이상의 웹 서비스 로토콜들은 표 화 진행 정도가 다르기 때문에 실제 비즈니스

환경에 용을 할 때에 바로 용하기 힘들며 단계별로 도입되어야 한다. 이 도입

단계는 명세(Specification) 단계, 실험(Experimentation) 단계 , 기 도입(Early

Adoption) 단계, 성기(MainStream) 단계 그리고 미정(Uncertain) 단계로 크게 다

섯 단계로 나 어진다. 다음은 각 단계에 한 간략한 설명이다.

명세(Specification) 단계: 표 명세 작업의 단계이다.

실험(Experimentation) 단계: 벤더들에 의해서 구 하여 테스트하는 단계로써 명

- 8 -

세화된 표 을 이해하고 구 하는 방법을 습득한다.

기 도입(Early Adoption) 단계: 실험 단계에서 습득한 표 기술을 바탕으로

실제 도메인에 용해보는 단계로서 실제 제품이 만들어진다.

성기(Mainstream) 단계: 상업 제품이 실제 비즈니스 환경에 용되어 리

사용되며 표 을 따르지 않는다면 더 이상의 비즈니스가 어려워지는 단계이다.

아래의 <그림 2-3>은 이상의 웹 서비스 도입 5단계를 각 로토콜별 상황에 맞추어

용한 그림이며 크게 두 가지로 분류한다. SOAP, WSDL, 그리고 UDDI 로토콜

과 같이 이미 표 화 명세 단계가 끝나고 벤더들에 의하여 랫폼 제품들이 제공되

어 재 많은 기업들이 자신의 비즈니스 업무에 용한 형태로서 이러한 로토콜

은 2004년도에 활발히 사용될 망이다. 다른 형태는 앞의 세 로토콜을 제외한

부분의 로토콜들이 해당되는 경우로서 2003년도 말까지 표 명세 작업이 완료

될 정이고 2004년도 에 실험단계를 거쳐서 2004년도 후반에는 실제 업무에 실

험 으로 용되고 있으며 2005년도에는 다양한 업무분야에 사용되어질 것이다.

*출처: CBDI Web Service Roadmap

<그림 2-3> 웹 서비스 로토콜 도입 단계

- 9 -

제 3장 웹 서비스 품질 리 표 기술 동향

본 장에서는 다음 장에서 설명할 웹 서비스 품질 리 뷰에 포함된 여러 모델들과

련된 표 기술동향에 하여 살펴본다. 먼 , 웹 서비스 품질모델에 련된 표

을 다룬다. 웹 서비스 품질 모델은 웹 서비스가 가지는 특징인 서비스 기반 아키텍

처라는 특징을 반 한 모델이어야 한다. 그러나 이러한 특성을 반 한 웹 서비스

품질 모델에 한 표 은 존재하지 않는다. 따라서 본 장에서는 먼 기존에 존재

하는 설치 주의 소 트웨어 제품에 한 품질표 인 ISO-9126에 해서 살펴본다.

다음으로, 웹 서비스 품질 리를 해서는 품질에 한 모델뿐만 아니라 웹 서비

스 리를 한 모델도 살펴보아야 한다. 웹 서비스 품질을 감독하거나 리하기

해서는 웹 서비스에 한 모니터링이나 제어가 가능해야 하기 때문이다. 웹 서비

스 품질 리 모델에 련한 표 으로는 재 안단계인 표 이기는 하지만 국제

표 단체인 OASIS에서 주도하는 WSDM 표 을 포함하여 랫폼 벤더들이 만든

리모델도 검토해 본다. 한 웹 서비스와 련된 계자들이 계약을 맺을 때에

품질요구사항을 반 하기 하여 사용하는 웹 서비스 품질 계약 모델에 하여 살

펴본다. 이 품질 계약 모델은 각 품질속성에 하여 어떠한 수 을 제공해야 하는

지에 해서 기술할 수 있어야 하고 품질 보장을 한 여러 가지 제한사항에 하

여도 기록할 수 있어야 한다. 마지막으로 품질 테스트 가이드라인을 하여 OASIS

의 ebXML Test Framework을 살펴본다.

본 장에서 다룰 표 들의 순서는 다음과 같다. 첫째로 품질표 과 련 하여

ISO의 소 트웨어 제품 품질인 ISO-9126 표 을 살펴본다. 둘째로 웹 서비스 리

모델에 해서는 W3C의 웹 서비스 리 모델과 기업에서 웹 서비스 리 모델로

제시되고 있는 HP사의 WSMF, IBM사의 WS-Manageability 모델과 향후 웹 서비스

리 표 으로 유력시 되고 있는 OASIS 단체의 WSDM 표 을 다룬다. 다음으로

웹 서비스 품질 계약 모델로는 IBM의 WSLA 계약 표 에 해서 살펴본다. 마지막

으로 OASIS의 ebXML Test Framework를 다룬다. 본 장에서 언 하는 각 표 들에

한 세부 인 정보는 별첨 C에 보다 자세한 설명이 있다. 여기서는 각 표 에

한 간략한 설명과 표 화 동향 품질 리 모델과의 연 성에 해서만 언 하기

로 한다.

3.1 ISO-9126 소 트웨어 품질 표

ISO-9126은 국제 표 화 기구인 ISO에서 정의한 소 트웨어 품질 표 이다. ISO

9126은 소 트웨어 라이 사이클 동안에 소 트웨어 요구사항을 구체화하고 소 트

웨어 제품의 품질을 평가할 때 사용되는 품질평가 로세스와 특성을 크게 2가지로

나 어서 제품 품질과 사용상의 품질로 정의한다. 제품 품질 속성에는 기능성, 신뢰

성, 사용성, 효율성, 유지보수성, 이식성이 있으며 사용상의 품질 속성에는 효율성,

생산성, 안정성, 만족성이 있다. ISO 9126은 소 트웨어 제품에 한 품질 요구사항

- 10 -

을 기술하는 데 사용할 수 있으며, 개발 에 있거나 는 개발 완료된 소 트웨어

의 품질을 측정하는 데 척도로 사용할 수도 있다. 이 표 은 1991년에 제정된 후

1994년부터 품질특성과 내․외부 메트릭을 조정하고 품질측정 차를 별도의

ISO/IEC 14598 표 으로 분리하는 등의 개정작업이 진행되고 있다

웹 서비스 한 하나의 소 트웨어 제품이고 서비스의 이용이라는 측면에서 볼

때 ISO-9126에서 정의한 사용상의 품질과 비슷한 면이 있다. 그러나 사용상의 품질

에서 정의하고 있는 품질 표 을 그 로 웹 서비스에 용하기에는 부 합하다(제

4장 참조). 따라서 원격 서비스의 에서 웹 서비스 품질에 한 모델을 재정립해

야 한다.

3.2 W3C 웹 서비스 리 모델

W3C의 리 모델은 W3C에서 작성한 웹 서비스 아키텍처 표 문서에 포함된 모델

로써 웹 서비스 리 아키텍처 측면에서의 여러 가지 개념에 한 계를 보여주고

있다. 웹 서비스 리 모델에서는 웹 서비스를 하나의 리 가능한 리소스로 표

하고 웹 서비스에서 발생하는 이벤트 메시지, 웹 서비스의 상태 변화, 리 인터페

이스, 웹 서비스 생명주기 웹 서비스 리 시스템에 한 개념 인 계 모델을

묘사하고 있다.

W3C 웹 서비스 아키텍처는 W3C내의 4개의 워킹그룹(WS Architecture WG,

WSD WG, WSC WG, XMLP WG) WS 아키텍처 그룹에서 표 화작업을 진행

에 있으며 2002년에 기 버 작성 후 2004.2.11 이후 재까지 워킹 드래 트 단

계이다.

3.3 HP WSMF 웹 서비스 리 임워크 표

HP는 웹 서비스 기반의 웹 서비스 리 임워크를 정의한다. 이 임워크는

기존의 웹 서비스를 바탕으로 웹 서비스를 사용한 웹 서비스 리에 을 둔다.

WSMF(Web Service Management Framework)의 구성은 WS-Events,

WSMF-Foundation, WSMF-WSM 이 게 3부분으로 되어 있으며 WS-Events는 웹

서비스 리의 기본인 XML구조의 웹 서비스 이벤트를 정의하고 WSMF

Foundation에서는 리 가능한 자원을 정의하며 웹 서비스를 통한 리가 어떻게

표 되는지를 정의한다. 한 WSMF WSM에서는 WSMF Foundation을 웹 서비스

에 용한 사례를 보여주고 있다. HP가 2003년 7월에 WSMF(Web Services

Management Framework) Ver 2.0을 OASIS WSDM 기술 원회에 제출하 다.

2004년 12월 재 OASIS의 WSDM 1.0 안 안에 WSMF가 흡수 되었다.

- 11 -

3.4 IBM WS-Manageability 웹 서비스 리 표

WS-Manageability는 2003년 9월 IBM에 의해서 명세화 되었으며 웹 서비스를 사용

하는 모델에 근 하는 방법과 웹 서비스를 한 리 가능성 모델을 정의한다.

WS-Manageability는 WS-Manageability-Concepts, WS-Manageability-Specification,

WS-Manageability-Representation 3개의 문서로 구성되어 있다. 한 웹 서비스 리

편리성에 필요한 속성, 운용 이벤트를 비롯하여 최소한의 리 편리성 요구사항

을 정의합니다. IBM 사는 최근 OASIS 의 WSDM 기술 원회에 웹 서비스 리 가

능성(WS-Manageability)에 한 표 로토콜을 제출했다. WS-Manageability 한

2004년 12월 재 WSDM 1.0 안에 흡수 되었다.

3.5 OASIS WSDM 웹 서비스 분산 리 표

OSAIS 표 화 단체에서 기존의 WSMF와 WS-Managebility를 통합해서 WSDM 표

을 2004년 1월부터 2004년 12월까지 진행하여 재 1.0 버 의 표 안을 완성

하 다. WSDM 표 은 원격에서 웹 서비스를 이용해 리소스를 리하는 표 인

MUWS(Management Using Web Services)와 웹 서비스를 통해 웹 서비스를 리하

는 표 인 MOWS (Management Of Web Services)를 정의하고 있다. MUWS가 웹

서비스를 이용해 다양한 리소스를 리하는 일반 인 표 이라면 MOWS는 MUWS

를 기반으로 다른 웹 서비스를 리하기 한 웹 서비스 리를 한 표 이라

볼 수 있다. 웹 서비스 분산 리 표 으로 향후 WSDM으로 될 것이며 이미 CA와

같은 일부 기업체에서는 WSDM을 사용한 웹 서비스 분산 리 도구를 개발하 다.

3.6 IBM WSLA 웹 서비스 품질 계약 표

WSLA(Web Service Language Agreement)는 웹 서비스 품질 계약에 한 표 으로

2001년 IBM 사가 제안하 다. WSLA는 웹 서비스 사용에 있어서 웹 서비스 제공자

와 사용자들의 의무사항(Obligations)들을 정의한 합의(Agreement)문서이다. WSLA

에서 주로 명세화한 품질은 웹 서비스에 한 IT- 벨의 서비스 라미터들( 를 들

면 이용가능성, 응답시간, 처리량 등)과 서비스 라미터를 수하기 한 서비스 제

공자의 의무사항(Obligations)을 명시하고 있다. 그러나 WSLA는 웹 서비스의 품질

효율성과 이용가능성과 같은 성능 측면에 한 품질만 고려되어 있고 그밖에 다

른 웹 서비스 품질 리에 한 품질 계약 시에는 부족한 실정이다. 따라서 성능뿐

만 아니라 웹 서비스 모든 품질에 한 계약을 할 수 있는 품질 계약 표 이 필요

- 12 -

하다.

3.7 OASIS ebXML 테스트 임워크 표

ebXML 테스트 임워크는 OASIS가 발표한 ebXML 표 합성 상호운용성

시험인증의 표 기술로 여러 시험인증 기 에서 활용되고 있다. 이것은 ebXML 표

명세서에 기반한 표 합성 상호운용성 테스트 방법을 정의하고 있고, 테스

트 임워크는 테스트 드라이버와 테스트 서비스로 구성된 컴포 트와 테스트

이스를 정의한 테스트 슈트문서( 로 일 문서, 요구문서, 테스트 이스 문서)로 구

성되어 있다. 테스트 드라이버는 테스트 이스의 각 단계를 실행하는 컴포 트이다.

테스트베드에 따라 컴포 트 구성이 다르지만 다른 컴포 트와 상호작용함으로써

테스트 이스를 구동한다. 테스트 서비스는 MSH(Messaging Service Handler)에 의

해 수신된 메시지를 받아서 메시지의 서비스와 액션에 한 정보를 추출하고, 추출

된 정보를 통해 특정 역할을 수행한다. 한, 미리 정의된 액션에 따라 MSH가 기

능을 수행하게 한다. 테스트슈트는 테스트 드라이버 설정 데이터, 사용되는 문서,

테스트 이스들을 모아놓은 것으로, XML로 작성된 테스트 슈트의 구성은 로

일 문서, 요구사항 문서, 테스트 이스 문서로 나 어진다.

- 13 -

제 4 장 웹 서비스 품질 리 뷰 개요

본 장에서는 웹 서비스 품질 리를 바라보는 뷰(View)를 제시한다. 웹 서비스

품질 리 뷰란 웹 서비스 품질 리를 하여 웹 서비스를 바라보는 을 말한다.

<그림 4-1>에서와 같이 웹 서비스 품질 리 뷰는 품질모델, 품질 계자 모델, 품질

계약 모델 품질 리 모델의 4가지 모델로 구성되어 있다. 웹 서비스 품질모델은

품질 리의 상이 되는 웹 서비스 품질을 인식하는 기 모델로서 나머지 모델들이

웹 서비스 품질을 다룰 때 이 품질모델을 기반으로 한다. 품질 계자 모델은 웹 서

비스 발주, 개발, 운 , 사용 리 등 웹 서비스 개발 운 되는 동안 웹 서비

스와 련된 계자의 모델을 말한다. 이들 웹 서비스 이해 계자들은 필요에 따

라 서로 상호작용을 하며 상호작용 시 필요한 품질 계약을 맺는다. 품질 계약에

한 모델을 제시하는 것이 웹 서비스 품질계약 모델이다. 품질 리 모델은 제 3 자

에 의한 웹 서비스 원격 리를 하여 서비스 제공자가 제공하여야 할 웹 서비스

리 인터페이스에 한 모델을 정의한다. <그림 4-1>은 품질 리 뷰 내의 모델들

간의 계를 그림으로 나타낸 것이다. 화살표는 서로간의 이용 계를 나타내고 있

다.

<그림 4-1> 웹 서비스 품질 리 뷰

<그림 4-1>에서 품질 모델은 웹 서비스 품질에 한 분류 세부 품질 요소 등 품

질 자체에 한 모델을 말한다. 웹 서비스는 그 자체가 원격에서 사용되어지는 서

비스로서의 제품이므로 그 품질도 원격에서 사용되어질 때의 품질이 의미를 갖는

다.

품질 계자 모델은 웹 서비스 발주, 검수, 재, 제공, 사용에 련된 일련의 웹

서비스 생명주기에 여하는 이해 계자들에 한 모델을 의미한다. 이들 이해 계

자들에는 발주자, 개발자, 제공자, 사용자, 리자 등이 있다. 이들은 심도에 따라

웹 서비스 품질을 바라보는 이 다르다. 이들 계자 상호간의 품질계약은 각

자 자신들의 에 따른 품질 모델 인스턴스를 기반으로 상과정을 통하여 맺게

된다.

- 14 -

품질계약 모델이란 품질 모델을 기반으로 품질 계자 상호 간에 필요에 의해 맺

게되는 품질계약의 모델을 말한다. 이에는 웹 서비스 개발 시 발주자와 개발자 사

이에 행하여지는 개발 계약 모델과 이미 제공되고 있는 웹 서비스에 하여 서비스

사용자가 서비스 제공자와 서비스 사용과 련하여 맺는 이용 계약 모델이 있다.

품질 리 모델이란 제공되는 웹 서비스의 품질을 리하는데 필요한 모델을 말

한다. 이 리 모델은 웹 서비스 사용자와 제공자 사이에 맺은 웹 서비스 사용 계

약이 잘 지켜지고 있는지를 제 3자 입장에서의 감독할 때 사용하는 분산 감독 모델

과 제공자의 서비스 리 업무를 제 3자에게 의탁하여 원격으로 리할 수 있게 하

는 분산 리 모델이 있다. 다음 소 에서는 웹 서비스 품질 리 뷰의 4개의 모델

에 하여 좀 더 자세히 살펴본다.

4.1 웹 서비스 품질 모델

웹 서비스는 그 자체가 원격에서 사용되어지는 서비스로서의 제품이다. 따라서 그

품질도 원격에서 사용되어질 때의 품질을 고려하여야 한다.

4.1.1 서비스로서의 웹 서비스 품질

웹 서비스 품질은 ISO-9126에서 제시하는 소 트웨어 품질모델의 에서 바라보

면 두 가지 품질로 나뉘어 질 수 있다. 하나는 웹 서비스를 하나의 응용 소 트웨

어, 즉 제품으로 보았을 때 고려되는 제품 자체로서의 품질이다. 다른 하나는 이 제

품으로서의 웹 서비스를 사용자가 이용할 때 느끼게 되는 사용상의 품질이다. 일반

으로 설치하여 사용하는 소 트웨어의 경우에는 잘 맞는 품질 모델이기는 하지만

원격에서 사용하는 서비스로서 웹 서비스의 품질을 표 하기에는 부 당한 모델이

다.

웹 서비스는 ‘서비스 지향 ‘이라는 특징을 가진다. 웹 서비스 자체가 가지는 서

비스 지향 이라는 특징은 기존의 설치 주의 소 트웨어를 필요한 시 에 사용하

는 분산 서비스로 환시키는 새로운 소 트웨어 패러다임을 제시하고 있다. 웹 서

비스는 웹 서버가 존재하는 곳이면 어디에나 재되어 서비스를 제공할 수 있다.

즉, 웹 서비스는 제품 그 자체를 매하기 보다는 서비스로 제공되어지는 것이다.

이러한 웹 서비스의 서비스 지향 인 특징에 의해서 웹 서비스의 품질은 ISO-9126

에서 제시하는 제품으로서의 품질 이 아닌 서비스로서의 품질 에서 그 모

델을 정립하여야 한다.

4.1.2 서비스 품질 모델

서비스로서의 웹 서비스 품질은 웹 서비스를 사용함에 있어서의 품질로써 서비스

사용 시의 의 치에 따라 1) 사용자 계층, 2) 상호운용 계층, 3)

리 보안 계층의 세 계층으로 크게 나 어 생각할 수 있다. 각 계층은 다시

- 15 -

세부 에 따라 한개 는 여러 개의 품질요소를 갖는다.

<그림 4-2>은 앞서 설명한 세 계층에 속하는 웹 서비스의 품질인 6개의 품질에

한 개념도이다. 아래는 각 계층에 한 간략한 설명이다. 각 계층에 속하는 세부

품질에 해서는 5장 웹 서비스 품질 모델에서 자세히 다룬다.

<그림 4-2> 웹 서비스 품질 모델

첫 번째 계층인 사용자 벨 계층은 사용자의 에서, 즉 서비스 벨

(Service-Level)에서, 서비스를 이용하면서 느끼는 품질들을 다룬다. 사용자의 심도

에 따라 사용자 벨 계층은 다시 두 가지의 품질로 나뉜다. 하나는 사용자 에

서 느끼는 웹 서비스의 비즈니스 가치를 나타내는 품질로서 비즈니스 가치 품질

(Business Value Quality)이라 부른다. 다른 하나는 사용자 에서 느끼는 웹 서

비스의 측정 가능한 웹 서비스의 성능 품질로서 서비스 벨의 측정 품질

(Service-Level Measurement Quality)이라 부른다. 이 품질은 응답시간과 같은 성능

요소 뿐만 아니라 안정성, 확장성과 같은 요소들도 포함한다. 사용자 벨 계층의

품질요소들은 사용자의 입장에서 웹 서비스를 이용하며 느끼는 서비스의 품질을

On-Line 혹은 Off-Line으로 측정하여 얻어진다.

두 번째 계층은 상호운용 계층이다. 이것은 상이한 시스템 환경에서 서로

다른 개발자에 의하여 서로 다른 시 에 만들어진 웹 서비스들이 서로 상호작용을

할 때에 제 로 상호작용을 할 수 있는가, 즉 상호운용의 에서 바라보는 품질

계층이다. 이 계층의 품질은 심도에 따라 다시 두 가지 품질로 나 어진다. 하나

는 주고받는 메시지의 양식이 서로 이해할 수 있도록 되어 있는가, 즉 표 화 기구

들이 정해 놓은 표 가이드라인을 잘 수하고 있는가를 나타내는 품질로서 상

호운용성 품질(Interoperability Quality)이라 부른다. 다른 하나는 주고받는 메시지

- 16 -

의 상호작용이 원하는 비즈니스 로직(Business Logic)을 제 로 수행을 하는가를 나

타내는 품질로서 비즈니스 처리 품질(Business Processing Quality)이라 부른다. 이

는 불안 한 네트워크 상황에서도 안정 으로 메시지를 달하는지를 단하는 안

정 메시징(Reliable Messaging)과 원하는 비즈니스 컨텍스트(Business Context)를

제 로 수행하는지를 나타내는 품질요소로 세분화 될 수 있다. 상호운용 의 품

질들은 주고받는 메시지를 간에서 가로채서 장한 메시지 로그정보와 메시지 처

리 시의 상태를 장한 메시지 처리 상태 로그정보를 분석 평가를 통하여 얻어진

다.

세 번째 계층은 제공하는 웹 서비스의 리 보안 에서의 품질을 나타내는

계층이다. 이 리 보안 계층은 이름이 나타내듯이 리 품질과 보안 품질

로 나 수 있다. 리 품질(Management Quality)이란 웹 서비스의 리를 시스템

내부 는 외부에서 제 로 할 수 있는가를 나타는 품질이다. 보안품질(Security

Quality)이란 웹 서비스가 외부의 불법 인 근이나 공격을 안 하게 처할 수

있는가를 나타내는 품질이다. 이 리 보안 계층 품질은 리 기능이나 보

안 련 기능을 테스트함으로써 확인할 수 있다.

4.2 웹 서비스 품질 계자 모델

웹 서비스 품질 계자는 웹 서비스 발주, 검수, 재, 제공, 사용의 웹 서비스 생명

주기의 각 단계와 련된 이해당사자 련 시스템이다. 웹 서비스 품질 계자

모델이란 본 안에서 제시하는 웹 서비스 품질 모델을 사용하는 이들 계자에

한 모델을 말한다. <그림 4-3>은 웹 서비스 품질과 련된 계자들과 이들 사이에

필요에 의해 맺는 품질계약의 계를 보여주고 있다. 아래는 각 계자들에 한

설명이다.

<그림 4-3> 웹 서비스 품질 계자 모델

- 17 -

4.2.1 발주자와 개발자

웹 서비스 발주자는 웹 서비스 개발을 웹 서비스 개발자에게 의뢰하는 주체자이면

서 웹 서비스 개발에 련된 발주의 권한을 가진 사용자이다. 발주자는 웹 서비스

개발을 의뢰할 때 웹 서비스 품질에 해 어떤 벨의 품질 수 에 맞는 웹 서비스

를 개발해주기를 개발자에게 달하게 된다. 이러한 품질에 한 요구사항은 개발

에 작성해야 하는 품질 요구사항이다. 개발자는 웹 서비스의 품질 요구 사항을

고려하여 이 품질을 만족시키는 방향의 아키텍처를 설계하게 된다. 발주자는 한

개발자가 만들어낸 웹 서비스에 해서 품질 요구사항에 명세 된 품질 수 을 수

하는지에 한 테스트를 하는 과정에서 품질 모델을 사용하게 된다. 품질에 한

테스트를 하는 것을 품질 검수 작업이라고 한다.

4.2.2 제공자

웹 서비스 제공자는 개발된 웹 서비스 혹은 자체 으로 웹 서비스를 개발해서 웹을

통해서 서비스 제공을 하는 사용자다. 제공자 입장에서 웹 서비스 품질은 요한

의미를 갖는다. 다른 기업체의 웹 서비스가 더 나은 품질의 서비스를 제공한다면

기업 서비스 경쟁력을 약화 시킬 것이다. 따라서 웹 서비스 제공자의 입장에서 보

다 정확한 품질 측정 방법을 통해서 보다 높은 품질을 제공할 수 있는 웹 서비스

개발 리에 더욱 을 맞추어야한다.

4.2.3 소비자

웹 서비스 소비자는 웹 서비스를 사용하는 사용자이다. 소비자는 웹 서비스 품질에

가장 하게 여하고 있다. 왜냐하면 사용자 즉, 고객의 입장에서는 여러 웹 서

비스가 있을 경우 그 에 제일 품질 수 이 높은 웹 서비스를 선택하기 때문이다.

따라서 소비자에게 웹 서비스 품질에 한 정확한 품질 분류와 수 을 정의할 수

있는 방법을 제공해야 한다. 결과 으로 웹 서비스 사용의 에서의 품질과 웹

서비스 사용 여부와 하게 련되어 있다.

4.2.4 품질 개자

웹 서비스 사용자 입장은 보다 좋은 품질의 웹 서비스를 찾기를 원한다. 품질 개

자는 웹 서비스 품질에 한 정보를 웹 서비스 정보와 같이 장한다. 차후에 소비

자가 품질에 련된 정보를 요구할 때 등록된 웹 서비스들 에 품질정보를 검색해

서 사용자가 원하는 조건의 웹 서비스를 제공해 다. 이 게 품질 개자는 웹 서

비스 등록 시 본 안에서 제시하는 웹 서비스 품질 모델을 사용해서 웹 서비스 품

질 속성을 등록한다. 한 품질 개자는 한번 등록된 웹 서비스에 해서 등록된

품질 수 을 제공하고 있는지 모니터링을 수행한다. 품질 속성에 한 모니터링 작

- 18 -

업 시에 품질 모델을 사용한다.

4.2.5 품질 보증자

품질 보증자는 웹 서비스 제공자와 웹 서비스 사용자가 맺었던 계약서 상의 품질

수 을 제공자가 잘 제공하고 있는지에 해 모니터링을 수행한다. 이러한 품질에

한 계약을 웹 서비스의 사용 품질 계약이라 하고 웹 서비스 생성, 재, 사용단계

에서 웹 서비스 품질 모델을 사용한다. 한 품질 보증자는 웹 서비스 이용 시 품

질 수 을 유지하는가에 한 모니터링과 웹 서비스 품질 계약을 수하고 있는지

를 모니터 품질 수 반 시 웹 서비스 제공자와 웹 서비스 사용자에게 반

사항을 모니터링을 하는 역할도 담당한다.

4.2.6 품질 리자

품질 리자는 웹 서비스 제공자의 리 업무를 행하는 역할을 한다. 품질 리

자는 제공자가 요구한 품질 수 을 보장하기 해서 외부에서 시스템을 모니터링

하고 웹 서비스 품질에 한 리 작업을 하게 된다. 이러한 품질 리 작업에는

웹 서비스 제공에 시스템 자원이 부족할 경우 보유하고 있는 기 자원으로 웹 서

비스 제공에 문제가 생기지 않게 리하는 웹 서비스 자원 리도 포함된다. 품질

리자는 다수개의 웹 서비스를 리할 수 있는 시스템을 보유하고 있어야 하며 웹

서비스 제공자가 리 업무를 행할 수 있도록 믿을 만한 공신력을 가지는 단체

혹은 공기업이어야 한다.

4.3 웹 서비스 품질 계약 모델

품질 계약 모델은 웹 서비스 품질과 련된 계약에 포함되어야 하는 항목 명세

에 해서 정의한다. 웹 서비스 품질과 련된 계약에는 2개의 계약이 있다. 하나는

웹 서비스를 개발하는 개발자와 개발을 의뢰하는 발주자간에 웹 서비스 개발에

한 품질 개발 품질 계약이며 다른 하나는 웹 서비스 제공자와 웹 서비스 사용자 간

의 사용 에서의 사용 품질 계약이다.

4.3.1 개발 품질 계약

개발 품질 계약이란 웹 서비스 개발 단계에서의 품질 계약을 의미한다. 웹 서비스

개발 시의 작업에는 서비스 설계, 서비스 구 , 서비스 단 품질 테스트, 서비스

통합 테스트와 같은 작업들을 포함한다. 이러한 각 작업마다 서비스 품질에 향을

미치는 많은 요인이 존재한다. 웹 서비스가 원하는 품질수 에 맞추어 개발이 완료

되기 해서는 개발자는 웹 서비스 개발 단계의 각 작업마다 품질을 고려하여 이루

어져야 하고 완성된 웹 서비스에 한 품질 테스트를 하여야 한다. 발주자는 개발

- 19 -

자가 개발한 웹 서비스에 한 품질을 평가하여 검수를 수행하여야 한다. 따라서

웹 서비스 개발 품질 계약에서는 개발자가 웹 서비스를 개발함에 있어서 달성해야

할 품질에 한 정확한 명세와 발주자가 완성된 웹 서비스에 하여 수행하여야 할

평가에 한 검수항목이 포함되어야 한다.

4.3.2 사용 품질 계약

웹 서비스 사용 품질 계약은 이미 제공되고 있는 웹 서비스를 사용하려는 시 에서

웹 서비스 사용자와 제공자사이에 맺어야 하는 것이다. 사용 계약은 품질 리를

수행할 제 3 자의 입회 하에 웹 서비스 기능 품질 등에 한 상을 통해 웹 서

비스 품질 계약서를 작성하는 것을 의미한다. 웹 서비스 사용 품질 계약서는 웹 서

비스가 제공자에게 제공하여야 할 기능명세 사용 시 에서의 제공되어야 할 품

질 항목, 보장 수 , 반 시의 조치사항에 한 내용이 기술된다. 이 계약서는 계

약 당사자가 보 하기 해 서면으로 작성하는 비즈니스 벨 계약서

(Business-Level Agreement 는 비즈니스 계약서(Business Contract))와 웹 서비스

리 랫폼이 이해하여 품질 리를 해 사용하는 XML 자문서인 서비스 벨

계약서(Service-Level Agreement or 약자로 SLA)가 있다. 후자인 서비스 벨 계약

서는 웹 서비스 품질 계약서(WS Quality Contract) 는 더 간단히 웹 서비스 계약

서(WS-Contract)라고도 부른다. 이 서비스 벨 계약서는 작성 후 서비스 제공자,

소비자 품질 리자의 랫폼에 배포되어 서비스 사용단계에서 이용된다. 따라

서 사용 품질 계약에서는 웹 서비스 품질에 해서 사용상의 측면에 한 항목을

계약에 포함하게 된다.

4.4 웹 서비스 품질 리 모델

웹 서비스 품질 리 모델은 제 3의 품질 감독자 품질 리자가 원격에서 웹 서

비스를 감독 는 리하기 해 사용하는 모델이다. 웹 서비스를 리함에 있어서

실제 웹 서비스가 존재하는 곳과 같은 치에서 웹 서비스를 리하는 것이 아니라

원격에서 다수의 웹 서비스를 리하는 제 3의 기 을 이용하게 된다. 이 게 원격

에서 리하기 해서는 기존의 분산 시스템을 리하는 방법과 비슷한 방법을 사

용하게 된다. 따라서 분산 리를 해서는 웹 서비스 자체가 표 화된 리 인터

페이스를 제공해야 한다. 즉 웹 서비스 리기능을 제공하기 해서는 웹 서비스가

일반 으로 제공하는 서비스 기능용 인터페이스 외에 원격 리 용도로 필요한

리용 인터페이스를 추가로 제공해야 하는 것이다.

리용 인터페이스도 서비스용 인터페이스와 유사하게 WSDL 상에 작성된다. 하

지만 리기능을 정의하기 해서는 국제표 화단체에서 정의한 리용 표 에 따

라 정의하여야 제3자에 의한 원격 리가 인간의 개입 없이 가능하다.

재 국제표 으로 자리잡아가고 있는 리용 표 은 OASIS 표 단체에서 재

- 20 -

Draft 1.0 버 으로 출시한 WSDM(Web Service Distributed Management)이다.

WSDM의 리용 인터페이스는 WS-Properties 표 을 따라 정의한 정체성 타입

(Identity Property Type), 자원 상태성 타입(Resource State Property Type), 측정성

타입(Metric Property Type)을 포함하는 리성 타입과 그에 한 기능정의로 구성

된다. 정체성 타입은 리 제공 이 리하고자 하는 리소스에 한 Id, 이름, 버

등의 정보를 가지고, 자원 상태성 타입은 리소스의 여러 상태 정보를 나타내고

리제공 이 리하는 리소스를 시작하고 단하는 기능을 제공한다. 측정성 타입은

리소스의 여러 측정 정보를 나타내 다. 측정성은 크게 두 종류가 있는데, 기간으로

표 되는 기간 측정과 단순 수치로 표 되는 정수 측정이 있다. <그림 4-4>는

WSDM에서 제시하는 웹 서비스 리 모델이다.

*출처: OASIS WSDM

<그림 4-4> WSDM 웹 서비스 리 모델

와 같은 WSDM을 기반으로 개자를 한 분산 감독 모델과 보증자 는 리

자를 한 분산 리 모델을 정의한다.

분산 감독 모델은 웹 서비스 사용자에게 자신이 원하는 품질의 웹 서비스를 찾아

주는 UDDI와 비슷한 역할을 하는 모델이다. 분산 리 모델은 웹 서비스 제공자와

- 21 -

<그림 4-5> 분산 감독 모델

사용자 사이에 맺은 품질 계약서를 바탕으로 품질을 모니터링하며 리하는 것이

다. 분산 감독 모델은 각 웹 서비스가 제공하는 품질 벨을 UDDI를 통해서 등록

해 놓은 후에 서비스 사용자가 원하는 품질의 웹 서비스 찾아서 바인딩 하도록 도

와주는 역할을 하는 반면에 분산 리 모델은 서비스 제공자가 작성한 웹 서비스

품질 계약서를 바탕으로 품질 계약에 명시된 품질을 유지하도록 리하는 것을 목

으로 한다. 다음은 각 모델에 한 상세한 설명이다.

4.4.1 분산 감독 모델

분산 감독 모델이란 원격에 존재하는 품질 감독자가 웹 서비스 제공자의 웹 서비스

품질이 웹 서비스 사용 계약에 명시된 데로 유지 되고 있는지를 감독할 때 사용하

는 모델이다. 분산 감독 모델의 특징은 웹 서비스 제공자와 서비스 개자간의

계와 서비스 개자와 웹 서비스 사용자간의 계에 을 맞춘다. 서비스 개자

는 기존의 UDDI를 확장한 모델로써 기존의 UDDI처럼 웹 서비스에 한 정보를

제공하는 것, 뿐만 아니라 등록된 웹 서비스의 품질 수 을 사용자에게 알려주는

역할을 한다. 서비스 제공자는 서비스 개자에 웹 서비스를 등록할 때 웹 서비스

의 품질 수 도 등록을 하게 되며 서비스 개자는 등록된 웹 서비스의 품질 수

을 감독하게 된다. 서비스 사용자가 특정 웹 서비스에 한 정보를 얻기 해서

개자를 통할 경우 서비스 개자는 웹 서비스의 정보에 품질에 한 정보도 함께

달하는 역할을 한다. <그림 4-5>는 웹 서비스 분산 감독 모델을 나타낸다.

웹 서비스 분산 감독 모델에서의 품질 리 차는 다음과 같다. 서비스 제공자는

- 22 -

웹 서비스를 서비스 개자와 UDDI에 등록한다. 서비스 개자(Service Broker)는

등록된 웹 서비스의 품질을 모니터링 한다. 품질 모니터링 단계에서 WSDM에서 정

의한 리가능성 인터페이스를 통해서 웹 서비스의 품질을 측정하게 된다. 그 후

웹 서비스 사용자가 특정 품질을 갖는 웹 서비스를 서비스 UDDI를 통해서 찾을 경

우 서비스 개자는 등록된 웹 서비스 에서 사용자가 원하는 벨의 품질을 제공

하여 웹 서비스의 정보를 알려주게 된다. 사용자는 서비스 개자가 달하는 정보

를 바탕으로 그 웹 서비스를 바인딩해서 사용하게 된다. 분산 감독 모델에는 기존

UDDI에 품질을 보증하는 기능이 확장된 서비스 개자가 존재하며 분산 리 모델

과는 다르게 서비스 사용자 혹은 서비스 제공자간의 품질에 한 계약은 이루어지

지 않는다.

4.4.2 분산 리 모델

분산 리 모델이란 웹 서비스 제공자로부터 웹 서비스에 한 품질 리를 임

받은 제 3의 품질 리자가 사용하기 한 것이다. 이 모델은 웹 서비스 품질을 사

용 계약에 명시된 데로 유지하기 해 웹 서비스는 물론 웹 서비스 랫폼에 한

정보를 얻어내거나 제어하기도 한다. 한 서비스 제공자와 사용자간의 품질 계약

을 리하는 역할도 포함된다. <그림 4-6>은 웹 서비스 사용자와 서비스 제공자 간

의 품질 계약과 품질 리를 한 분산 리 모델을 나타낸다. 그림에서와 같이 분

산 리 모델은 크게 서비스 제공자와 서비스 요청자간에 서비스에 한 계약을 하

는 단계와 웹 서비스를 리하는 단계로 나 수 있다.

- 23 -

<그림 4-6> 분산 리 모델

웹 서비스 계약은 4.3.2에서 설명한 바와같이 비즈니스 벨 계약서(Business-Level

Agreement or 는 비즈니스 계약서(Business Contract))와 웹 서비스 리 랫폼

이 이해하여 품질 리를 해 사용하는 XML 자문서인 서비스 벨 계약서

(Service-Level Agreement or 약자로 SLA)로 이루어 진다. 다음으로 웹 서비스를

리하는 단계에서는 XML로 작성된 서비스 벨 계약서를 바탕으로 웹 서비스 제공

자가 계약에 명시된 품질을 보장하고 있는지를 감시하며 리하게 된다. 이러한

리는 웹 서비스 사용에 련된 당사자가 아닌 품질 리자에 의하여 이루어야 한

다. 즉, 품질 리자가 리자의 역할을 수행하게 되고 웹 서비스 제공자는 리를

당하는 리 상이 된다. 기단계에서는 품질 리자는 서비스 제공자의 품질계약

반만을 감시하는 정도의 수동 리로 시작한다. 하지만 웹 서비스 환경이 좀

더 일반화되고 Win-Win하기 하여 서비스 제공자, 사용자, 리자간에 서로 력

하는 상황이 되면 품질 리자는 품질 반 감시뿐만 아니라 문제 발생시에 제공자

의 시스템 리에 많은 도움을 주는 정보를 제공하거나 더 나아가서 직 리하여

주는 능동 리가 이루어질 것이다. 이러한 능동 리를 해서는 웹 서비스

서비스 랫폼에 한 분산 리를 해야 하며 이를 한 표 리가능성 인터

페이스로 WSDM을 사용할 것이다.

- 24 -

제 5 장 웹 서비스 품질 모델

앞장에서 설명하 듯이 웹 서비스 품질 모델은 웹 서비스를 사용함에 있어서의 품

질로써 서비스 사용 시의 의 치에 따라 1) 사용자 계층, 2) 상호운용

계층, 3) 리 보안 계층의 세 계층으로 크게 나 어 생각할 수 있다.

각 계층은 다시 세부 에 따라 한개 는 여러 개의 품질속성을 나 어져 체

으로 여섯 개의 품질속성을 가진다. (그림 4-2 참조). 본 장에서는 이 여섯 개의 품

질 속성에 하여 품질의 정의, 세부 품질 요소, 품질 계약, 품질 계자 련

표 을 자세히 설명한다. 한 각 품질에 한 테스트 아키텍처, 테스트 시나리오

테스트 항목에 해서는 8장에서 설명하도록 한다.

5.1 서비스 벨 비즈니스 가치(Business Value) 품질

5.1.1 정의

서비스 벨 비즈니스 가치 품질이란 웹 서비스를 사용하는 즉, 웹 서비스의

서비스 벨에서의 비즈니스 가치를 의미한다. 비즈니스 가치란 웹 서비스를 활용

해 기업의 이윤을 창출하거나 국민 서비스 고도화를 실 할 수 있는 가치를 의미

한다

5.1.2 세부 품질 요소

비즈니스 가치 품질에는 다음과 같은 4가지 세부 품질 요소가 있다.

비용(Cost) / 약 (Penalty)

비용은(Cost는) 웹 서비스를 사용하는 사용자가 서비스의 크기, 종류 서비스의

질 등에 따라 정해진 이용가격을 말한다. 이는 단순히 서비스 사용/운 측면 뿐만

아니라 서비스를 이용함으로써 얻게 되는 비즈니스 측면의 효용측면까지 고려된 가

치를 말한다. 약 은(Penalty는) 사용자가 사용계약을 기하거나 품질을 유지하

지 못함으로써 발생되는 비즈니스 측면의 손실까지 고려하여 사용자에게 부여되는

약 을 말한다.

미터링(Metering) / 과 (Billing)

소비자가 실제로 사용한 웹 서비스의 사용량을 실제 사용한 컨텐츠의 종류, 횟수

등에 따라 측정하는 방식을 미터링(Metering)이라고 한다. 과 (Billing)은 미터링

- 25 -

(Metering)한 사용량을 서비스 이용 시 , 할인정책 비용(Cost)과 약 (Penalty)

등을 고려하여 사용요 을 산정하는 방식을 말한다.

평 (Reputation)

웹 서비스에 한 소비자들의 평 이다. 이는 서비스 품질 만족도, 신뢰성 등에

의하여 만들어진다. 설문조사나 투표 등 여러 가지 방법을 통하여 측정할 수 있다.

합성(Suitability)

웹 서비스를 제공하는 제공자의 서비스가 사용하기 좋도록 잘 만들어져 있는지를

평가하는 평가 요소이다. 같은 기능을 제공한다 하더라도 쓰기 좋도록 만들어져있

는 서비스가 더 높은 합성(Suitability) 평가를 받는다.

5.1.3 품질 계약

서비스 벨 비즈니스 가치 품질에 련된 품질 계약은 아래와 같다.

사용 품질 계약

소비자가 웹 서비스를 사용하고자 할 경우 BLA or WSLA에 표시된 비용(Cost)/

약 (Penalty)/미터링(Metering)/과 (Billing)을 검토할 수 있어야 한다. 한 품질

개자는 비즈니스 가치 품질의 모든 세부 품질 요소에 하여 On-line/Off-line 테

스트를 수행하여 품질을 표시할 수 있어야 한다.

5.1.4 품질 계자

발주자: 비즈니스 가치 품질과 련된 모든 품질요소에 심이 있다.

개발자: 신규 서비스 합성,미터링(Metering)/과 (Billing) 부분과 련이 있다.

소비자: 비즈니스 가치 품질과 련된 모든 품질요소에 심이 있다.

제공자: 좋은 비즈니스 가치 품질을 인정받기 하여 노력해야 한다.

개자: 소비자에게 정보를 제공하기 하여 오 라인 설문이나 온라인 투표 등

의 방법을 통하여 비즈니스 가치 품질 정보를 수집 제공해야 한다.

보증자: 계없음

리자: 계없음

5.1.5 련 표

없음

- 26 -

5.2 서비스 벨 측정(Service Level Measurement) 품질

5.2.1 정의

서비스 벨 측정 품질은 서비스 사용자가 웹 서비스 이용 차원에서 느끼는 품질을

의미한다. 이러한 품질에는 얼마나 빠르게 웹 서비스를 제공하는지 혹은 얼마나 안

정 으로 제공하는 등등의 측정 가능한 품질을 의미한다.


서비스 벨 측정 품질에는 응답시간, 처리량, 최 처리량과 같은 성능 측면 세부

품질과 이용가능성, 신뢰성, 근가능성을 포함하는 안정성 측면 세부 품질 요소가

있다. 아래는 각 세부 품질 요소에 한 정의다.

5.2.2.1 성능(Performance)

서비스 벨 측정 품질 성능 측면의 속성은 웹 서비스 사용자가 요청한 서비스

요청에 해서 웹 서비스 제공자가 응답을 하는 속도, 즉 얼마나 빠르게 작동하는

가에 한 속성이다. 이러한 성능 속성은 속도라는 개념으로 표 될 수 있으며 응

답시간, 최 처리량이라는 세부 품질로 표 될 수 있다.

응답시간(Response Time)

요청(Request)을 보내고 응답(Response)을 받는데 걸리는 시간을 의미한다. 이러한

응답 시간은 실제 웹 서비스 호출에서 시간을 측정하며 아래의 공식을 용하여 산

출한다. 시스템응답 완료시간은 시스템의 응답이 사용자에게 도착한 시간이며 사용

자 요청 시간은 사용자가 요청을 보낸 시간을 의미한다. 개의 경우 응답시간은

일정 시간동안의 평균값으로 구한다.

응답시간 시스템응답완료시간 사용자요청시간

최 처리량(Maximum Throughput)

웹 서비스 제공 랫폼이 단 시간 동안에 처리할 수 있는 서비스의 최 요청 수

를 의미한다. 이러한 처리량은 웹 서비스 제공자에 한 성능 지표로 사용될 수 있

- 27 -

다. 얼마만큼의 처리를 할 수 있는가는 웹 이라는 환경에 있어서 얼마나 많은 사용

자를 처리할 수 있는가를 의미하기도 한다. 최 처리량은 아래의 공식에 의해서

구해진다.

최대처리량 완료된최대요청수단위시간

5.2.2.2 안정성(Stability)

안정성 품질은 제공되는 웹 서비스가 어느 정도 안정하게 서비스를 제공하는지에

한 품질이다. 즉, 처리량의 증가, 폭주, 시스템의 고장, 자연 재해 그리고 사람에

의한 고의 공격에도 지속 이고 일 성 있으며 원래의 상태로 회복 가능한 서비

스를 제공할 수 있는 능력에 한 품질이다. 안정성 품질의 속성에는 이용가능성,

신뢰성, 근성이 있다. 각각은 아래와 같다.

이용가능성(Availability)

웹 서비스가 존재하는지 혹은 즉시 사용가능한 상태인지의 측면에서의 품질, 즉, 단

시간동안 에 웹 서비스가 다운되지 않고 있는 시간의 비율을 의미한다. 시스

템이 사용가능하지 않는 시간을 가동불가시간(Down Time), 시스템이 사용가능한

시간을 가동가능시간(Up Time)이라고 할 때 이용가능성이란 가동가능시간의 평균

시간을 의미한다. 이용가능성을 구하기 해서는 가동가능시간을 계속 모니터링 하

는 방법 신에 가동불가시간을 구해서 역으로 구하는 방법을 사용한다. 가동불가

시간은 시스템에서 발생한 시스템다운 이벤트를 모니터링 해서 시스템다운 시간을

얻어낸다. 공식은 아래와 같다. 아래에서 시스템다운 시간을 가동불가시간이라고 하

고 단 시간은 측정하는 단 시간을 의미한다.

이용가능성 가동불가시간단위시간

신뢰성(Reliability)

주어진 기간 동안 약속된 서비스를 제 로 수행한 정도를 의미한다. 일별, 주별, 월

별 는 년별로 서비스 사용에 해서 얼마만큼 신뢰할 수 있는지를 나타낸다. 신

뢰성 품질을 측정하기 해서는 단 시간 동안에서 시스템다운 뿐만 아니라 서비

- 28 -

스 요청이 실패에 한 로그 분석을 통해서 에러 간의 시간을 통해서 구해진다. 공

식은 아래와 같다. 에러간 평균시간(Mean Time Between Error)은 발생한 에러간의

평균 시간을 의미하며 단 시간은 측정하는 단 시간을 의미한다.

신뢰성 에러간평균시간단위시간

근성(Accessibility)

이용가능성이 보장되는 상황에서 서비스의 근 가능한 정도를 나타낸다. 즉, 한 시

에서 하나 이상의 서비스 요청에 해서 성공 으로 응답할 수 있는지에 한 정

도를 의미한다. 어떤 경우에는 웹 서비스 해서 사용가능(Available)은 하지만 근

(Accessilble)은 되지 않는 경우가 있다. 웹 서비스의 높은 근성(High

Accessibility)에 한 보장은 확장성이 뛰어난(High Scalable) 시스템을 구축함으로

서 가능하다. 이러한 높은 확장성이란 볼륨량이 가변 인 요구에 해서 일 되게

서비스를 수행할 수 있는 시스템의 확장 능력을 말한다. 근성은 동시에 보내지는

요청 메시지 수에 해서 반환되는 응답 메시지의 수의 비율로 나타낸다. 아래의

공식에서 요청 메시지 수(Request Message Count)는 동시에 보내진 요청 메시지

수를 응답 메시지 수(Normal Response Message Count)는 정상 으로 처리되고 나

서 반환된 응답 메시지 수를 의미한다.

접근성 응답메시지수요청메시지수

5.2.3 품질 계약

개발 품질 계약

개발을 의뢰하는 차인 발주 시의 BLA(Business Level Agreement) 계약서와

SLA(Service Level Agreement)계약서에 각 품질 요소별로 품질 수 이 명시 되어야

한다. SLA는 서비스 벨의 계약서 즉, 제공되는 웹 서비스의 품질 수 과 품질 보

장에 련된 제반사항 품질 수 반에 한 조치사항을 명세 하는 계약서이

다.

- 29 -


사용 시의 BLA 계약서와 SLA 계약서에 각 품질 요소별로 품질 수 이 명시 되어

야 한다. 품질 개자, 보증인, 리자 모두 품질 계약서나 보증서의 품질이 제 로

유지되는지 모니터링하고 확인하여야 한다.

5.2.4 품질 계자

소비자

웹 서비스 소비자는 보다 높은 성능과 안정성을 갖는 웹 서비스를 사용하기를 원하

기 때문에 소비자는 웹 서비스 사용상의 품질 에서 서비스 벨 측정 품질에 높

은 심을 가진다.

발주자

발주자 역시 웹 서비스 개발을 의뢰할 때 서비스 벨 측정 품질 수 의 웹 서비스

를 개발을 원한다. 개발된 웹 서비스를 사용하는 사용자들이 심을 가지는 이유와

동일하게 발주자 역시 더 많은 사용자가 사용할 수 있는 고품질의 웹 서비스 제작

을 추구한다.

개발자

발주자가 서비스 벨 측정 품질에 심을 가지는 이유와 마찬가지로 개발자도 발

주자가 지정한 품질 수 을 수하는 웹 서비스를 개발해야 한다. 개발자의 입장에

서 보면 발주자가 정한 서비스 품질을 수할 수 있는 웹 서비스를 개발해야 하며

발주자가 개발된 웹 서비스를 검수할 때 개발 계약서에 명시된 서비스 품질 수 의

수 여부 테스트에 통과되어야한다.

제공자

제공자는 개발자가 개발한 웹 서비스를 역시 발주자가 제시한 품질 수 을 유지하

면서 웹 서비스를 제공할 수 있는 제공 시스템을 보유해야 하며 웹 서비스 제공 시

스템을 리해야 한다. 제공자의 입장에서 서비스 벨 측정 품질을 과거의 웹 호

스 에서와 마찬가지로 서비스 품질 요한 요소로 작용된다. 어떤 사용자라도

성능이 느린 웹 서비스를 사용하려 하지 않기 때문이다.

개자

사용상의 웹 서비스 품질 가장 객 인 측정이 가능하며 객 인 기 을 제시

할 수 있다. 개자는 제공되는 웹 서비스에 한 서비스 벨 측정 품질을 다른

품질에 비해서 정확히 측정할 수 있으며 사용자가 자신이 맞는 벨의 품질 수 을

제공하는 웹 서비스 검색 시 보다 쉽게 웹 서비스를 검색할 수 있다.

- 30 -

보증자

개자와 같음

리자

개자와 같음

5.2.5 련 표

없음

5.3 상호운용성 품질

5.3.1 정의

상호운용성 품질은 웹 서비스들 간에 서로 호환되는 수 을 정의한다. 웹 서비스를

구성하는 기술들은 표 화 되어 있지만 서로 다른 랫폼 간에 정의된 웹 서비스가

각 표 스펙별로 개별 으로 확장 정의하고 있는 부분들이 존재하여, 웹서비스들

간에 호환을 한 부가 인 개발이 필요한 경우가 있다. 따라서 상호운용성 품질은

이러한 웹 서비스들 간에 상호운 을 해 요구되는 호환성 수 을 특정 기 을 두

어 평가한 결과를 의미한다.


표 수성 (Conformability)

표 화 수성은 웹 서비스를 구성하는 표 기술들의 수 정도를 평가하는 속성

이다. 표 화 수성 에서의 상호운용성 품질 평가는 해당 웹 서비스를 구성하

는 실제 구 들이 웹 서비스가 제시하는 표 스펙들을 얼마나 제 로 반 하고 있

는지를 검사한다.

상호운용성 (Interoperability)

상호운용성은 WS-I에서 정의한 상호운용성 로 일의 수 정도를 평가하는 속성

이다. WS-I는 웹 서비스의 상호운용성을 정의하는 단체로 주로 웹 서비스의 스펙들

에 한 로 일을 제시하고 있다. 로 일은 웹 서비스 표 용 시 용 지침

을 제시한다.

- 31 -

5.3.3 품질 계약


개발 시의 상호운용성 품질 계약은 비즈니스 벨 계약인 BLA에 요구하는 품질요

소가 명시되어야 한다. 아래서 제시한 상호운용성 테스트를 통해 상호운용성 품질

에 한 수 을 평가 받을 수 있다.


제 3의 공인된 품질 인증기 을 통해 서비스의 품질을 평가 받은 뒤 품질 인증서를

부여 받아 UDDI 장소를 통해 서비스 사용자들에게 서비스를 제공한다.

5.3.4 품질 계자

발주자(Stakeholder)

발주자는 여러 개의 웹 서비스를 여러 기업에 나 어서 발주하려고 할 경우에 서로

다른 기업에서 개발한 웹 서비스에 해 상호운용성에 한 품질을 고려하여 제공

해야 한다.

서비스 소비자(Service Consumer)

서비스 소비자는 상호운용성 품질이 보장되는 웹 서비스를 사용해야만 한다.

품질 개자(QoS Broker)

품질 개자는 웹 서비스 상호운용성 품질에 한 정보를 웹 서비스 정보와 같이

장하고 있다가 품질에 련된 요구사항이 있을 때 등록된 웹 서비스들의 상호운

용성 품질정보를 검색해서 사용자가 원하는 조건의 웹 서비스를 제공해야 한다.

5.3.5 련표

WS-I Basic Profile 1.1: SOAP, WSDL, UDDI 표 의 상호운용성을 한 로

일로 WS-I에서 주 하는 표 이다.

URL: http://www.ws-i.org/Profiles/BasicProfile-1.1-2004-08-24.html

WS-I Basic Security Profile Version 1.0 : 웹 서비스 보안의 상호운용성을 한

로 일로 WS-I에서 주 하는 표 이다.

URL: http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0-2004-05-12.html

WS-I Simple SOAP Binding Profile Version 1.0 : SOAP 바인딩의 상호운용성을

한 로 일로 WS-I가 주 하는 표 이다.

URL: http://www.ws-i.org/Profiles/SimpleSoapBindingProfile-1.0-2004-08-24.html

- 32 -

5.4 비즈니스 처리 품질

5.4.1 정의

비즈니스 처리 품질이란 비즈니스 트 들 간에 웹 서비스로 업무 로세스를 실

행시킬 때 최 화된 비즈니스를 제공하기 한 다양한 지표를 의미하며 최 화된

비즈니스를 제공하기 해서는 비즈니스 로세스의 정확한 정의, 실행, 자동화, 신

뢰성 있는 메시징, 트랜잭션 처리, 코디네이션, 그리고 통합 리 임워크와 같

은 능력들이 요구된다.


비즈니스 로세싱 품질에 한 세부 품질 요소는 크게 두 가지로 분류할 수 있다.

첫째는 다양하게 분산된 비즈니스 로세스를 모델링하고 조정하기 한 임워

크를 구성하는 것이며, 둘째는 로세스의 사 정의된 차 수 여부 신뢰성

있는 로세스 처리와 외처리 황을 모니터링 하는 것이다. 따라서 비즈니스

로세스 처리를 해서는 비즈니스 메시지에 한 신뢰성 보장과 트랜잭션, 로세

스 리에 한 메시지 컨텍스트 속성이 만족되어야 한다. 아래는 각 요소에 한

정의다.

신뢰성 메시징(Reliable Messaging)

신뢰성 메시징이란 비즈니스 처리를 한 가장 기본 인 신뢰성 있는 메시지 지원

여부에 한 속성을 의미한다. 신뢰성 있는 메시지를 해서는 같은 메시지가 복

으로 송되었을 경우 메시지에 한 복처리와 보낸 메시지가 송 도 에 실패

한 경우에 재 송을 지원함으로써 비즈니스 로세싱 품질을 보장한다. 일반 으로

신뢰성 메시징은 AtMostOnce, AtLeastOnce, ExactlyOnce, InOrder의 성질을 보장

하여야 하며, 이를 해 웹 서비스에서는 WS-ReliableMessaging 표 을 이용하여

신뢰성 메시징을 구 할 수 있다. 다음은 신뢰성 메시징의 세부 품질을 나열한 것

이다.

AtMostOnce: 송된 메시지는 최 한번 달되어야 한다.

AtLeastOnce: 송된 메시지는 최소 한번 달되어야 한다.

ExactlyOnce: 송된 메시지는 정확하게 한번 달되어야 한다.

InOrder: 송된 메시지는 송 시의 메시지 순서와 같은 순서로 달되어야 한

다.

- 33 -

메시지 컨텍스트 (Message Context)

서비스 기반 환경에서 구성되는 비즈니스 로세스는 여러 분산되어 있는 웹 서비

스를 이용하여 로세스를 진행하게 된다. 이러한 과정에서 분산되어 있는 서비스

간의 코디네이션 트랜잭션 처리를 해서는 생성되는 트랜잭션에 해 트랜잭션

시작부터 종료까지 공유되는 이력 정보가 필요하게 된다. 메시지 컨텍스트는 트랜

잭션 시작 시 생성되어 트랜잭션에 참여하는 모든 리소스가 공유하는 정보를 담고

있으며 트랜잭션 종료 시 삭제된다.

트랜잭션

트랜잭션이란 업무 로세스 상의 여러 작업을 하나의 단 로 수행되어야 하는 작

업 세트를 말한다. 일반 으로 트랜잭션은 다음의 4가지의 기능을 만족하여야 한다.

- 원자성(Atomicity): 성공 일 경우 모든 작동이 발생하고 실패라면 어떤 작동

도 발생하지 않는다.

- 일 성(Consistency): 애 리 이션은 완료 시 유효한 상태 변환을 수행한다.

- 고립성(Isolated): 작동 결과는 성공 으로 끝나기 까지 트랜잭션 외부에서는

공유되지 않는다.

- 속성(Durability): 일단 트랜잭션이 성공 으로 완료되면 변경으로 실패를 다

시 복구할 수 있다.

웹 서비스 트랜잭션은 일반 인 컴퓨 환경에서의 트랜잭션과 동일한 처리 방식을

가지고 있는 원자 트랜잭션 (Atomic Transaction)과 보다 복잡한 이해 계를 가지며

트랜잭션 기간이 긴 비즈니스 액티비티(Business Activity)로 구분된다. 자는 일반

으로 많이 사용하는 2PC(2-Phase Commit)을 사용하여 트랜잭션을 처리하며, 후

자의 경우에는 보상(Compensation)을 이용하여 실패의 경우를 처리하게 된다. 웹

서비스 환경에서 트랜잭션 처리를 해서는 WS-Coordination/WS-Transaction 표

을 사용하여 구 할 수 있다. WS-Coordination은 트랜잭션 코디네이트를 한 로

토콜과 트랜잭션 처리 시나리오를 포함하고 있으며 WS-Transaction은 두 가지 형태

의 트랜잭션에 한 정의 각 경우의 시나리오를 포함한다.

1) 단기 트랜잭션 (Short-Term Atomic Transaction)

원자 트랜잭션은 가장 기본이 되는 트랜잭션을 의미하며, 트랜잭션이 일어나는 범

가 좁고, 비교 짧은 시간 안에 발생하여 종료된다. 하나의 트랜잭션이 기동되어

완료될 때 까지는 여러 참여자와 업 메시지 교환이 이루어지며, 이 과정에서

코디네이터를 통해 트랜잭션에 한 정보를 주고받으며 모니터링하고 2PC를 통해

- 34 -

트랜잭션을 최종 처리한다.

2) 장기 트랜잭션 (Long-Term Business Activity)

비즈니스 액티비티는 긴 실행 시간을 요구하는 트랜잭션으로, 원자 트랜잭션으로는

처리가 불가능한 트랜잭션 처리를 한 부분이다. 비즈니스 액티비티는 트랜잭션의

기본 요소인 ACID 성질을 항상 만족시킬 수 없다. 다시 말해서, 2PC를 이용할 경

우 최종 커 (Commit) 이 에 해당 데이터가 잠 되어 다른 서비스 사용자의

근을 방지하는데 비하여, 비즈니스 액티비티는 긴 실행 시간에 의해 데이터 잠 을

사용할 수 없는 경우이다. 그러므로 이 경우에는 보상(Compensation)이 매우 요

하게 되는데 보상(Compensation)은 작업된 결과를 이 단계로 회복하는 메커니즘

이다.

3) 앙 집 비즈니스 로세스 리 (Centralized Business Process Management)

비즈니스 로세스는 다수의 웹 서비스 제공자가 제공하는 여러 웹 서비스를 조합

하여 워크 로우(Workflow) 형태의 신규 비즈니스 로세스를 생성하고 실행 모

니터링 하는 조정(Coordination) 기능을 가진다. 그리고 신규 웹 서비스 등록, 서비

스 생성, 역할 정의(조정자, 참여자), 호출 로토콜 정의 실행 환경을 구성할 수

있는 편리한 자동화 수 을 제공해야 한다.

4) 분산 비즈니스 로세스 리 (Decentralized Business Process Management)

분산 비즈니스 로세스 리는 웹 서비스 환경에서 발생할 수 있는 분산되어 조각

으로 나 어진 비즈니스 로세스를 앙에서 리하는 신 각 로세스가 존재하

는 역에서 분산되어 리되는 것을 말한다.

5.4.3 품질 계약


개발 시의 비즈니스 처리 품질 계약은 비즈니스 벨 계약인 BLA에 품질 요소 별

로 테스트 항목들이 명시되어야 하며 각 요소별 테스트를 통해 비즈니스 처리에

한 품질 수 을 평가한다.


제 3의 공인된 품질 인증기 을 통해 비즈니스 처리의 품질을 평가받은 뒤 품질 인

증서를 부여받아 서비스 사용자들에게 서비스를 제공한다.

5.4.4 품질 계자

비즈니스 처리 품질에 한 계자별 은 다음과 같다.

- 35 -

소비자(Service Consumer)

소비자는 웹 서비스 비즈니스 처리 서비스를 사용하는 사용자이다. 소비자는 비즈

니스 처리 품질 인증서를 참고하여 품질수 이 높은 서비스를 선택해야 한다.

제공자(Service Provider)

제공자 입장에서 비즈니스 처리 품질은 기업의 경쟁력에 요한 요소가 된다. 개발

품질 계약 시에 맺은 비즈니스 처리 품질 요소 별 테스트 항목들 하나하나의 수

높은 구 에 최선을 다하여야 한다. 개발 시에 정확한 품질 테스트를 통해서 보다

높은 품질을 제공할 수 있는 서비스 개발에 을 맞추어야 한다.

품질 개자(QoS broker)

품질 개자는 웹 서비스 품질 인증서나 제공자가 등록 시 검수한 품질수 을 확인

하기 하여 비즈니스 처리 품질 테스트를 수행한다. 이 비즈니스 처리 품질 테스

트 결과를 토 로 소비자의 웹 서비스 검색 요청 시 자신이 테스트한 결과를 토

로 품질 수 에 한 등 을 부여한다.

발주자(Stakeholder)

발주자는 비즈니스 트 에게 서비스를 의뢰하는 주체자이면서 서비스를 발주하는

권한을 가진 사용자이다. 발주자는 서비스 개발을 의뢰할 때 웹 서비스 비즈니스

처리 품질에 한 요구사항을 달하게 되며 실제로 품질 요구사항에 명세한 품질

수 을 수하는지에 한 테스트인 품질검수작업을 한다.

5.4.5 련 표

OASIS WS-Reliable Messaging: 비즈니스 트 들간의 송되는 메시지에 한

신뢰성을 보장하기 해서 메시지 확인, 추 , 리를 한 메시징 로토콜을

정의한다.

URL: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrm

OASIS BPEL4WS(Business Process Execution Language For Web Service): 웹

서비스 환경에서 여러 개의 비즈니스 로세스에 한 실행순서를 정의하는

XML 언어이다.

URL: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel

IBM WS-Transaction:두 가지 코디네이션 타입인 원자 트랜잭션(AT: Atomic

Transaction)과 비즈니스 액티비티(BA: Business Activity)를 정의하고 있다.

URL: http://www-128.ibm.com/developerworks/library/specification/ws-tx/

IBM WS-Coordination: 확장성 있고 상호 운용 인 방식으로 자동화된 장기 실

- 36 -

행 비즈니스 트랜잭션을 향상시키기 한 웹 서비스 기반 근방식을 제공한다.

URL: http://www-106.ibm.com/developerworks/library/specification/ws-tx/

OASIS WS-CAF(Composite Appliction Framework): 웹 서비스 비즈니스 로세

스를 통합하는데 필요한 서비스를 지원하기 한 표 이다.

URL: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ws-caf

W3C WS-CDL (Web Service Choreography Description Language): XML 기반

의 웹 서비스들 간의 업을 기술하기 한 언어로 분산 비즈니스 로세스

리를 한 표 이다.

URL: http://www.w3.org/TR/2004/WD-ws-cdl-10-20040427/

5.5 리가능성(Manageability) 품질

5.5.1 정의

리가능성 품질은 웹 서비스 리자 는 웹 서비스 리 도구 개발자가 느끼는

품질이다. 즉, 웹 서비스 시스템의 체계 인 리를 해서 시스템의 객체들 간의

계, 식별자(Identification), 상태, 구성 정보 등의 객체에 한 속성, 오퍼 이션,

이벤트 등을 이용해 리할 수 있도록 하는 품질을 의미하기도 한다.

5.5.1.1 리 기능 종류

리가능성 품질은 리 기능 에서 보았을 때 세 가지로 분류할 수 있다. 시

스템 서비스의 내부 정보를 읽기를 의미하는 내부 찰성과 시스템 서비스 내

부 속성에 한 쓰기에 련된 제어가능성, 그리고 내부 정보가 변경되었을 때 통

지를 한 통지가능성이다. 다음은 이들에 한 좀 더 자세한 정의이다.

내부 찰(Introspection): 웹 서비스와 자원에 한 구분과 상태 정보를 얻어낼

수 있는지에 한 속성이다. 한 이 속성을 통해서 얻어내는 정보에는 웹 서비

스 처리 트랙킹 정보 즉, 웹 서비스를 어떠한 경로를 통해서 호출하게 되는지에

한 호출 과정에 한 정보를 포함한다.

제어(Control): 내부 찰성에서 얻어진 정보를 포함해서 웹 서비스와 자원에

한 제어 웹 서비스 객체와 자원에 한 리 가능여부에 한 품질이다. 내

부 찰성 속성의 경우 정보를 얻어내기만 하는데 반해서 제어가능성은 내부

찰성 속성에서 얻어낸 정보를 수정할 수 있는 경우이다.

통지(Notification): 웹 서비스 혹은 자원의 상태가 변경되었을 경우 상태 변경에

- 37 -

한 이벤트를 외부 품질 리자 혹은 이벤트를 듣고자 하는 상에 달 할 수

있는지에 한 속성이다.

5.5.1.2 리 상 종류

웹 서비스 리: 웹 서비스 자체에 한 리를 말한다. 웹 서비스가 리되기

해서는 해당 웹 서비스가 표 리 인터페이스를 구 하여 리 가능한 웹

서비스가 되어야 한다.

웹 서비스 랫폼 리: 웹 서비스가 배치되어 있는 랫폼에 한 리를 말한

다. 이것은 랫폼이 표 리 인터페이스를 제공해 주어야 가능하다

5.5.1.3 리 벨 종류

리 가능한 벨(Manageable Level): 리 가능한 벨의 웹 서비스란 리 인

터페이스를 제공하는 웹 서비스를 말한다.

리되는 벨(Managed Level): 리되는 벨의 웹 서비스란 리가능 할 뿐만

아니라 제공하는 리 인터페이스를 사용하여 제 리되고 있는 웹 서비스를

말한다. 즉, 리자를 가지고 있는 리 가능한 웹 서비스이다.


앞서 설명한 3가지 리 기능과 2가지 리 상과 2가지 리 벨을 조합하여

리 가능한 벨 6가지와 리되는 벨 2가지의 세부품질요소를 정의한다.

5.5.2.1 리 가능한 벨

웹 서비스 내부 찰 가능성(Introspectability): 내부 찰이 가능한 웹 서비스

웹 서비스 제어가능성(Control-ability): 제어가 가능한 웹 서비스

웹 서비스 통지가능성(Notifiability): 통지기능이 가능한 웹 서비스

웹 서비스 랫폼의 내부 찰 가능성(Introspectability): 내부 찰이 가능한 웹

서비스 랫폼

웹 서비스 랫폼의 제어가능성(Control-ability): 제어가 가능한 웹 서비스 랫

폼

웹 서비스 랫폼의 통지가능성(Notifiability): 통지기능이 가능한 웹 서비스

5.5.2.2 리되는 벨

리되는 웹 서비스 내부 찰 가능성: 내부 찰 리기능에 하여 리가능하

- 38 -

벨 상 내부 찰 가능성 제어가능성 통지가능성

리가능 벨

웹 서비스웹 서비스

내부 찰 가능성웹 서비스 제어가능성 웹 서비스 통지가능성

웹 서비스 랫폼웹 서비스 랫폼

내부 찰 가능성웹 서비스 랫폼 제어가능성

웹 서비스 랫폼

통지가능성

리되는 벨

웹 서비스리되는 웹서비스

찰 가능성리되는 웹 서비스 제어가능성

리되는 웹 서비스

통지가능성

웹 서비스 랫폼

리되는 웹서비스

랫폼 내부 찰

가능성


랫폼 제어가능성


랫폼 통지가능성

면서 리자가 존재하여 리되고 있는 웹 서비스

리되는 웹 서비스 제어가능성: 제어기능에 하여 리가능하면서 리자가

존재하여 리되고 있는 웹 서비스

리되는 웹 서비스 통지가능성: 통지기능에 하여 리가능하면서 리자가

존재하여 리되고 있는 웹 서비스

리되는 웹 서비스 랫폼의 내부 찰 가능성: 내부 찰기능에 하여 리가

능하면서 리자가 존재하여 리되고 있는 웹 서비스 랫폼

리되는 웹 서비스 랫폼의 제어가능성: 제어기능에 하여 리가능하면서

리자가 존재하여 리되고 있는 웹 서비스 랫폼

리되는 웹 서비스 랫폼의 통지가능성: 통지기능에 하여 리가능하면서

리자가 존재하여 리되고 있는 웹 서비스 랫폼

<표 5-1> 리가능성 세부 품질 요소

5.5.3 품질 계약


리가능성은 발주가 웹 서비스 개발을 개발자에게 의뢰할 때 개발해야 하는 하

나의 요구사항으로 포함되어진다. 즉, 개발 시에 리가능성은 개발 계약서 내에 기

능 요구사항에 포함되어 진다.


이러한 리가능성 품질은 결국 하나의 호출 할 수 있는 서비스의 형태로 리

기능을 노출하게 된다. 따라서 사용 시에 리가능성 품질은 리가능성을 한 확

장된 WSDL(Web Service Description Language)의 형태나 기존의 WSDL에 서비스

를 명시하는 형태로 정의된다. 리가능성 역시 비즈니스 웹 서비스로 같은 형태로

노출되어야 하기 때문이다. 사용 시에 품질 계약은 비즈니스 벨의 계약(Business

Level Agreement)에 포함된다.

- 39 -

5.5.4 품질 계자

소비자

심 없음

발주자

발주자는 개발자에게 리 가능한 웹 서비스 개발을 해서 리가능성 품질을 웹

서비스 개발 계약에 포함시키게 된다. 한 개발된 웹 서비스가 리가능성을 가지

는지에 한 검수 차에서 리가능성을 사용한다.

개발자

개발자는 발주자가 의뢰한 리가능성을 웹 서비스 기능에 포함시켜서 개발하게 되

며 검수 시 리가능성 품질을 보장하기 한 개발을 한다. 개발자의 입장에서

리가능성은 앞서 설명한 서비스 벨 측정 품질과는 다르게 하나의 웹 서비스

기능 요구사항으로 받아들여진다.

제공자

제공자는 웹 서비스 자체에 한 리가능성 이외에 웹 서비스를 제공하는 랫폼

에 한 리가능성을 제공하기 해서 랫폼에 한 리가능성 기능을 제공해야

한다. 이러한 랫폼에 한 리가능성에는 제공하는 웹 서비스 체에 한 실행

환경을 제어하는 기능이 있다.

개자

심 없음

보증자

심 없음

리자

웹 서비스 리를 해서 리가능성 품질을 제공하는 웹 서비스의 리 기능을 사

용한다. 리자의 입장에서 리가능성 품질은 요하며 리가능성 품질을 제공하

지 않는다면 웹 서비스에 한 리역할을 수행 할 수 없다.

5.5.5 련 표

OASIS WSDM: 웹 서비스로 제어하는 개념(Management Using Web Service)과

웹 서비스 자체의 리(Management Of Web Service)에 한 표 이다.

URL: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsdm

- 40 -

5.6 보안 품질

5.6.1 정의

웹 서비스 보안 품질이란 웹 서비스 상황에서 발생 가능한 모든 종류의 을 감

소시키거나 혹은 제거하기 해 시스템 서비스에 한 근의 법성을 별하

고 불법 인 근, 변조, 권한 행사를 막으며 법 인 근에 한 권한을 제어하

여 안정 이고 신뢰성 있으며 권한 합한 사용을 한 통합 인 보안 서비스를 제

공할 수 있는 능력을 말한다. 웹 서비스 환경에서 보안 품질은 WSDL을 통한 서비

스 인터페이스와 근 방법 공유, XML을 통한 SOAP메시지 통신 그리고 다양한

랫폼을 경유하는 고유한 특징 때문에 보안 서비스 제공 방법이 기존 보안 품질 표

명세의 그것과는 다르게 용되어야 한다.

5.6.1.1 보안 서비스 기능

웹 서비스 환경에서 제공해야 할 보안 서비스의 분류는 다음과 같다. 참고로 보안

련 문 용어에 한 설명이 별첨 B에 있으니 참조하기 바란다.

데이터 기 성 (Data Confidentiality)

데이터 기 성이란 요한 데이터를 공격자가 근해서 읽는 것을 막는 품질로서

주로 이러한 기 성을 제공하기 해서 암호화 기법을 사용한다.

데이터 무결성 (Data Integrity)

데이터 무결성이란 데이터 송 시 공격자가 데이터를 가로채서 불법 으로 삽입,

수정 그리고 변조하는 것을 탐지하는 품질을 말한다. 주로 해쉬 함수의 특징을 이

용해서 데이터 무결성을 검증하지만 자서명을 이용할 경우 자서명 자체 안에

데이터 무결성을 검증하는 속성이 들어 있다.

사용자 인증 (User Authentication)

어떤 사용자가 자신의 Identity 주장을 상 방에게 확신 시키는 과정으로 일반 으

로 사용하는 인증 방식은 요청자가 알고 있는 지식을 이용해서 인증을 수행한다.

웹 서비스 환경에서는 SOAP 메시지가 다양한 보안 도메인을 경유하기 때문에 보

안 토큰을 통한 Single Sign-On 기능이 제공되어야 할 필요가 있다.

근 제어 (Access Control)

권한이 없는 사용자가 특정 자원에 근하지 못하게 하는 보안 품질로서 웹 서비

스 환경에서 SOAP 메시지가 다양한 보안 랫폼을 경유하기 때문에 하나의 웹 서

비스 보안 토큰을 통한 근 제어가 가능해야 한다.

- 41 -

부인방지 (Non-Repudiation)

메시지의 송수신자가 송수신 사실을 부인하지 못하도록 하는 방법으로서 자서명

기법을 사용해서 이러한 부인방지 서비스를 달성할 수 있다.

근성 (Accessibility)

웹 서비스 환경에서 근성은 바로 서비스 거부 공격을 어떻게 탐지하고 방하는

가에 달려있다. 특히 서비스 기반 환경에서 특정 서비스에 한 근이 보장되지

않는 것은 웹 서비스 활성화에 부정 인 향을 끼친다.

감사 추 (Audit Trail)

특정 서비스에 공격 시도 행 에 한 로그를 남겨서 사후에 보안 감사 시에 웹

서비스 보안 취약 공격에 한 다양한 정보로 활용한다.

라이버시 보호(Privacy)

웹 서비스 사용자와 웹 서비스 제공자 양 당사자 측면에서 개인의 라이버시 보

호와 련된 서비스를 말한다.

5.6.1.2 보안 서비스 벨

웹 서비스 환경에서 앞의 보안 서비스를 제공하기 한 웹 서비스 보안 메커니즘은

크게 다음과 같이 두 가지 벨에서 제공할 수 있다.

송 벨 보안(Transport Level Security) - Non-Persistent Level Security

송 벨 보안은 웹 서비스의 로토콜인 SOAP의 하 네트워크 이어에서의 보

안을 의미한다. 이는 기존 웹 환경인 HTTP 로토콜 기반에서 사용하던 SSL, TLS

등의 보안 메커니즘을 이용한 방법이다. 이러한 송 벨에서 보안은

Point-To-Point 보안 컨텍스트 사용, 부분암호화 그리고 부분 자서명과 같은 것

들을 지원하지 않기 때문에 만일 이러한 특징을 반 하기 해서는 메시지 벨 보

안을 사용해야 한다. 특히 송 벨은 Point-To-Point 보안 컨텍스트를 사용하기

때문에 컨텍스트에 한 정보가 하나의 Point를 벗어나면 잃어버리는

Non-Persistent Level Security이다.

메시지 벨 보안 (Message Level Security) - Persistent Level Security

메시지 벨의 보안은 SOAP 메시지에 한 데이터 기 성, 무결성, 근제어와 같

은 보안 서비스를 제공하기 해서 XML기반의 SOAP메시지를 이용해서 보안 서

비스를 제공하는 방식이다. 이러한 메시지 벨 보안은 End-To-End 보안 컨텍스트

를 사용하기 때문에 SOAP 메시지 자체가 다양한 보안 도메인을 경유해도 컨텍스

- 42 -

트 정보가 유지되는 Persistent Level Security이다.


5.6.2.1 세부 품질 요소

앞서 정의한 8가지 보안 서비스 기능과 2가지 보안 서비스 벨을 조합하면 총 16

개의 세부 품질 요소를 정의 할 수 있다. 하지만 실 으로 별로 사용가능성이 없

는 송 벨의 부인방지와 송 벨의 라이버시 보호를 제외하고 웹 서비스가 지

향하는 서비스 심(SOA) 환경에서 요시 되고 있는 Single-Sign-On 서비스 기능

을 추가하여 다음과 같이 총 15가지의 세부 품질 요소를 정의 할 수 있다.

송 벨 데이터 기 성

송 채 간의 데이터 송수신 시 데이터의 기 성을 보장하기 해서 TLS 혹은

IPSEC 로토콜에서 제공하는 암호화 기능을 사용해서 체 메시지를 암호화 하는

것을 말한다.

송 벨 데이터 무결성

송 채 간의 데이터 송수신 시 데이터 무결성을 제공하기 해 TLS혹은 IPSEC

에서 제공하는 다이제스트 패킷 비교와 같은 기능을 말한다. 이를 해서 자

서명 등의 메커니즘을 이용한다.

송 벨 사용자 인증

메시지 송 계층의 송 채 에 의해 제공되는 이 인증은 단방향이나 양방향이 될

수 있다. 를 들어 Secure Network 로토콜인 TLS [RFC2246] 혹은 IPSEC

[RFC2402]는 메시지 송신자에게 TCP/IP 환경하의 목 지를 인증할 수 있는 방법을

제공한다. 자서명을 이용하여 구 할 수 있으며, 공인/사설 인증기 을 통한 인증

서를 이용할 수 있다.

송 벨 근제어

송 채 에서의 사용자의 자원(Resource)에 한 근 제한을 한 것으로 TLS 혹

은 IPSEC 로토콜을 이용하여 구성할 수 있다.

송 벨 근성

DOS(Denial of Services) 공격에 의해 해당 자원(Resource)에 한 근이 불가능하

게 되는 것을 방하기 한 것으로 방화벽(Firewall), 침입탐지시스템(IDS), 침입방

지시스템(IPS) 등을 이용한 송 벨의 패킷(Packet) 감시를 통하여 구 할 수 있

다.

- 43 -

송 벨 감사추

송 벨에서의 세션(Session) 생성 제거 혹은 데이터 송수신 시의 로그를 남기

고 이를 감사하는 것을 말한다. 여기서는, 로깅에 한 정책 즉 감사 시 활용하기

한 컨텐츠에 한 한 사 정의가 필요하다.

메시지 벨 데이터 기 성

SOAP 메시지에 한 기 성을 보장하기 해 W3C에서 표 으로 채택된

XML-Encryption OASIS의 웹 서비스 보안 표 인 WS-Security를 사용하거나 혹

은 다른 암호화 과정( 를 들어 S/MIME, PGP MIME)등에 의해서 제공될 수 있다.

특히 XML-Encryption은 메시지의 일부분만을 암/복호화하여 사용할 수 있으므로,

송 벨에서의 기 성에 비해 서비스의 성능을 어느 정도 보장할 수 있는 장 을

가지고 있다.

메시지 벨 데이터 무결성

SOAP 메시지 벨에서의 데이터 무결성을 한 부분으로 XML-DSIG나

WS-Security를 이용하여 보장할 수 있다. 한, PKI 환경 구성을 해 XKMS를 이

용할 수 있다.

메시지 벨 사용자 인증

재 W3C에서 표 으로 채택된 XML-DSIG 표 을 사용해서 SOAP Header와

Body 그리고 그의 페이로드에 자서명을 수행한다. 이러한 XML 자서명은 기존

자서명과 달리 XML 문서의 특정 부분에 선택 으로 자서명을 수행할 수 있으

며 서명의 유효성을 보장되는 한 문서에 추가될 수 있다. 특히 자서명을 사용할

경우 보안 서비스 의 인증, 데이터 무결성 그리고 부인방지와 같은 여러 개의 보

안 서비스들을 제공할 수 있다. 사용자 인증을 한 방안으로는 앞에서 언 한

XML-DSIG SAML을 이용할 수 있으며, PKI 구 을 해 XKMS 등을 이용할 수

있다.

메시지 벨 근제어

SOAP 메시지에 포함되어 있는 정보를 이용하여 자원 근에 한 제어를 가능하

게 하는 것을 말한다. SAML, XACML 등의 표 을 이용하여 구 할 수 있다. 실제

SAML에 XACML로 정의된 근 권한을 포함시켜 메시지에 동 하여 달할 수 있

으며, 이를 이용하여 실제 자원에 한 사용자의 근 권한을 제어할 수 있다.

메시지 벨 부인방지

메시지 벨의 부인방지를 해서는 XML-DSIG, WS-Security를 이용하여 구 할 수

있으며, PKI 환경 구성을 해 XKMS 등을 이용하여 구 할 수 있다.

- 44 -

메시지 벨 근성

XML 메시지에 한 XML DOS(Denial of Services) 공격에 응하기 한 것으로

웹 서비스의 근성을 확보하기 한 방안이다. 이를 해, SOAP 방화벽(Firewall)

등을 이용하여 애 리 이션 벨의 메시지를 필터링함으로써 기능을 구 할 수 있

다.

메시지 벨 감사추

서비스를 호출하는 각 request/response 메시지에 한 로깅(Logging)을 남기고 이

를 감사한다. 송 벨의 감사추 과 마찬가지로 감사를 한 로깅 컨텐츠를 정의

하는 정책 인 부분이 선행되어야 한다.

메시지 벨 라이버시보호

End-User의 라이버시를 보호하기 한 것으로, 사용자 라이버시 정보를 한

데이터 기 성, 근 제어 등은 WS-Security, XACML, SAML 등의 표 (기 성과

근 제어를 한 표 )이 있으며, 라이버시 정책을 달하고 이를 신뢰하고 정의

된 정책을 반 하기 한 웹 서비스 보안 로드맵 상의 표 은 WS-Policy,

WS-Trust, WS-Privacy가 있다. WS-Security 구조 하에서 WS-Policy 구문에

WS-Privacy를 이용하여 라이버시에 한 정책을 정의하면, 해당 메시지를 수신하

는 서비스에서 WS-Trust를 이용하여 정의된 Policy를 신뢰한 후 정의된 정책을 서

비스가 실행하게 된다.

싱 사인온(Single-Sign-On)

앞의 Non-Persistent Authentication과 마찬가지로 인증을 수행하지만 차이 은

SOAP 메시지가 다양한 보안 랫폼을 경유하는 특징 때문에 요구되는 보안 품질

이다. Single Sing-On 보안은 신뢰받는 기 에 의한 보안 토큰 발행을 통해서 수행

할 수 있다. SAML등의 Portable Trust를 구 할 수 있는 표 으로 구성할 수 있으

며, MS의 Passport, Liberty Alliance 등의 솔루션을 이용하여 구 할 수 있다.

5.6.2.2 보안 요소와 련 기술 매핑

아래 <표 5-2>은 각 보안 요소별로 보안 요소의 기능을 충족시키기 한 웹 서비스

기존의 보안 련 기술 간의 계를 보여주고 있다. 따라서 해당 보안 요소를

충족시키기 해서는 련 기술을 용해야 한다.

- 45 -

<표 5-2> 웹 서비스 보안 요소별 련 기술

보안 요소 련 기술

송 벨 데이터 기 성 TLS, SSL, IPSec

송 벨 데이터 무결성 TLS, SSL, IPSec

송 벨 사용자 인증 TLS, SSL, IPSec

송 벨 사용자 근제어 TLS, SSL, IPSec

송 벨 근성 Firewall, IDS, IPS

송 벨 감사 추 Logging, 감사추 정책

메시지 벨 데이터 기 성 XML-Encryption, WS-Security, XKMS

메시지 벨 데이터 무결성 XML-DSIG, WS-Security, XKMS

메시지 벨 사용자 인증 XML-DSIG, WS-Security, XKMS, SAML

메시지 벨 부인 방지 XML-DSIG, WS-Security, XKMS

메시지 벨 감사 추 Logging, 감사추 정책

메시지 벨 근 제어 SAML, XACML

메시지 벨 근성 SOAP Firewall

싱 사인온SAML, Liberty Alliance, .NET Passport,

WS-Federation

메시지 벨 라이버시 보호 WS-Policy, WS-Trust, WS-Privacy

5.6.2.3 보안 로 일

웹 서비스 보안의 경우 응용서비스의 특성에 따라 여러 세부 품질요소를 복합 으

로 사용할 수 있다. 본 표 에서는 이들 세부 품질 요소들 에서 많은 경우 같이

사용되는 세부 품질 요소들의 집합을 웹 서비스 보안 로 일(WS-SProfile)라고 정

의한다. 이 로 일은 상 웹 서비스 트 와의 보안 벨을 설정하는데 사용되

며 BLA(Business Level Agrement) 내에 명시된다. 보안 세부 품질요소의 수를 고려

해 볼 때 많은 웹 서비스 보안 Profile을 정의할 수 있다. 본 표 안에서는 시

에서 많이 사용될 것이라고 측되는 6개의 로 일만을 정의한다. 이것은 차후에

필요에 따라 추가 보완될 수 있다.

WS-SProfile 0

송 벨 보안 메커니즘을 사용해서 인증, 메시지 무결성, 메시지 기 성, 근제어

서비스를 제공하며 송 벨의 DOS 공격 등을 방지하여 근성을 보장한다.

TLS, 혹은 IPSec 등이 WS-SProfile 0에 합한 보안 로토콜들이다. TLS는 두 개

의 통신 응용 로그램 사이에서 코드 로토콜, 핸드쉐이크 로토콜, 공개키 기

반 인증서 생성 처리 기능, 인증 모드 지원 등의 기능으로 사용자 인증, 메시지

의 무결성, 기 성 근제어 서비스를 제공한다. IPSec은 양 종단 간의 안 한

통신을 지원하기 해 IP 계층을 기반으로 하여 보안 로토콜을 제공하는 개방 구

조의 임워크로서 IP의 취약 을 보완하기 한 보안 기능을 제공한다. 인증

- 46 -

로토콜 (AH), 암호화 로토콜 (ESP), 보안 연계 정책 데이터베이스 (SAD, SPD)

키 리 메커니즘 등이 IPSec의 주요 보안 기능들이며, 이를 통해 인증, 메시지

무결성, 메시지 기 성, 근제어 서비스를 제공한다.

WS-SProfile 1

메시지 벨에서 자서명과 암호화 기법을 도입해서 메시지 벨에서 인증, 메시

지 무결성, 부인방지, 기 성 서비스를 제공한다. 경우에 따라, 메시지 기 성이나

근제어와 같은 보안 서비스들을 송 벨에서 제공하는 보안 메커니즘을 사용할

수 있지만 명시 으로 필수 사항은 아니다.

WS-SProfile 1의 표 인 보안 규격인 WS-Security는 웹 서비스의 메시지 교환

로토콜인 SOAP을 기반으로 하며 인증, 무결성, 부인방지, 기 성 등의 보안 기능을

확장하여 제공하는 웹 서비스 보안의 핵심이 되는 표 인 메시지 벨 보안 기술

로 2004년 OASIS에서 표 으로 채택되었다.

W3C의 XML-DigitalSignature XML-Enctyption을 확장 용 보안 정보 교

환을 한 다양한 보안 토큰을 지원하며 재 송 공격(Replay Attack) 등을 방지하

기 해 타임스탬 (Time-stamp) 련 기능 멀티 홉(Multi-hop)을 거쳐 달되는

SOAP 메시지의 안 한 End-to-End 송 기능을 포함하여 메시지 벨에서 실질

인 인증, 메시지 무결성, 부인방지 기 성 서비스 등을 제공할 수 있다.

WS-SProfile 2

메시지 벨의 근제어 메커니즘을 사용해서 근제어 서비스를 제공하며, 근성

을 보장하기 해 XML DOS 공격 등을 SOAP Firewall 등을 이용하여 제공하며,

WS-SProfile 1을 포함하고 있다.

SOAP Firewall은 기존의 방화벽과는 달리 XML 형태 SOAP 메시지를 필터링하

고 이를 기반으로 근제어 서비스를 제공할 수 있는 방화벽을 의미한다. 따라서

SOAP Firewall은 SOAP 메시지를 받아 종단 URL로 보내지는 XML 바디 콘텐츠를

해독하고 이해할 수 있어야 한다.

WS-SProfile 3

WS-SProfile 2의 보안 요소를 포함하여, 보안 토큰을 이용한 Single Sign-On 메커니

즘을 제공한다.

Single Sign On을 제공할 수 있는 메커니즘은 사용자의 인증, 인가 등의 속성 정보

등을 교환하는 인증 체계인 보안정보 교환기술을 의미하여, SAML, Liberty

Alliance, .Net Passport, WS-Federation 등이 보안정보 교환기술의 표 인 기술들

이다. SAML과 Liberty Alliance에서는 XML 기반의 Assertion이라는 인증 정보를

- 47 -

교환하는 기술을 진행시키고 있으며, .Net Passport는 앙 집 식의 인증 체계를

통해 Single Sign On 기능을 제공하고 있다. WS-Federation은 개인의 신원을 나타

낼 수 있는 ID(IDentity)를 연계하여 Federated ID를 리함으로써 Signle Sign On

기능을 제공한다.

WS-SProfile 4

WS-SProfile 3의 보안 요소를 포함하며, 개인 라이버시 보호 메커니즘을 제공한

다.

재까지의 개인 라이버시 보호 매커니즘은 WS-Privacy가 표 으로 서비스 제

공자와 소비자가 각각의 라이버시 실행 구문을 서술하기 한 모델을 설명한다.

주로, WS-Security 기술을 기반으로 WS-Policy 기술 WS-Trust 기술과 더불어 신

임 신규 트 (부처) 간에 상호 작용 가능한 안 한 웹 서비스를 구축할 수 있도록

하는 기 를 제공한다. 참고로, WS-Policy는 보안, 신용, 트랜잭션, 사생활 보호 등

에 한 정책을 표 하고 달하는 웹 서비스 앤드 포인트 정책 기술이고,

WS-Trust는 보안 토큰 서비스가 보안 토큰의 발행, 교환, 유효성을 검사를 제공하

는데 사용되는 인터페이스를 제공하는 신임 모델이다. 다음의 <표 5-3>는 웹 서비

스 보안 품질 로 일별로 포함되어있는 보안요소의 계를 보여 다. (Op)는 각

보안 로 일에서 선택사항을 의미한다.

<표 5-3> 보안 로 일별 보안 요소

보안 요소 SP 0 SP 1 SP 2 SP 3 SP 4

송 벨 데이터 기 성 ✔ ✔(Op) ✔(Op) ✔(Op) ✔(Op)

송 벨 데이터 무결성 ✔ ✔(Op) ✔(Op) ✔(Op) ✔(Op)

송 벨 사용자 인증 ✔ ✔(Op) ✔(Op) ✔(Op) ✔(Op)

송 벨 근 제어 ✔ ✔(Op) ✔(Op) ✔(Op) ✔(Op)

송 벨 근성 ✔ ✔(Op) ✔(Op) ✔(Op) ✔(Op)

송 벨 감사 추 ✔ ✔(Op) ✔(Op) ✔(Op) ✔(Op)

메시지 벨 데이터 기 성 ✔ ✔ ✔ ✔

메시지 벨 데이터 무결성 ✔ ✔ ✔ ✔

메시지 벨 사용자 인증 ✔ ✔ ✔ ✔

메시지 벨 부인 방지 ✔ ✔ ✔ ✔

메시지 벨 감사 추 ✔ ✔ ✔ ✔

메시지 벨 근 제어 ✔ ✔ ✔

메시지 벨 근성 ✔ ✔ ✔

싱 사인온 ✔ ✔

메시지 벨 라이버시 보

호✔

- 48 -

5.6.3 품질 계약


보안 품질은 웹 서비스 구 시에 제공해야 할 보안 벨에 해서 BLA안에 로

일 형태로 기술한다. 한 실제 웹 서비스 구 완료시에 Test Case를 통해서 원

하는 벨의 보안 기능이 동작하는지 여부를 검사한다.


서비스를 구 해서 UDDI에 등록할 때 어떤 벨의 보안을 제공하는지를 명시하고

실제 보안 기능이 동작하는 여부를 Test Case를 통해서 확인한 후에 등록해야 한

다. 보안 품질에 련된 SLA의 명세 내용에는 실제 웹 서비스 운 시 명시된 보안

벨 품질의 제공 여부를 확인하는 방법과 함께 제공되지 못한 경우 보상 문제 그

리고 사후 조치에 련된 계약 내용을 명시해야 한다.

5.6.4 품질 계자

보안 품질과 련해서 각 계자 별 주요 심사항을 정리하면 다음과 같다.

발주자

발주자는 웹 서비스와 련해서 존재하는 들을 분석해서 이러한 을 감소시

키거나 방하기 해 필요한 보안 서비스들을 결정하고 이러한 결정에 따라서 해

당하는 보안 로 일의 종류들을 선택한다. 선택된 보안 로 일에 따라서 보안

벨을 설정 하고 비즈니스 벨 계약 안에 이를 명시한다. 한 이러한 비즈니스

벨 품질 계약서 안에는 품질 벨의 달성 수 에 한 범 와 함께 측정 방법에

한 내용도 명세해야 한다. 웹 서비스 발주자 입장에서 주요 심 사항은 들

을 감소하거나 방하기 해서 요구되는 보안 품질의 수 과 BLA에 명세하는 방

안에 한 것이다.

개발자

서비스 개발자 입장에서는 먼 BLA안에 명시된 보안 벨 품질을 달성하기 해

어떠한 메커니즘을 사용할 것인가에 해서 심이 있다. 다음으로 서비스를 개발

할 때 어떻게 보안을 고려할 것인가와 만들어진 웹 서비스가 원하는 벨의 품질을

제공하는지에 한 확신을 얻기 해 테스트를 어떻게 수행할 것인가에 심이 있

다. 결국 서비스 개발자 입장에서는 BLA에 명시된 보안 벨 품질을 보장하는 웹

서비스를 만드는 것이 주요 역할이며 심사항이다.

소비자

- 49 -

서비스 소비자 입장에서는 자신의 보안 정책을 고려하여 실제 요구되는 보안 벨

정보를 악하고 해당 보안 벨 정보를 제공하는 웹 서비스를 검색하여야 한다.

검색된 웹 서비스가 명시한 보안 정책을 검토하고 어떤 보안 메커니즘을 사용하고

어떤 보안 토큰이나 보안 클 임을 요구하는 지를 확인한 후, 한 보안 토큰을

획득하여 웹 서비스 제공자의 보안 정책에 맞는 보안 토큰을 포함하여 웹 서비스

호출을 수행한다. 한 서비스 요청자 입장에서는 서비스 제공자가 명시한 보안 품

질의 제공 여부에 한 결과를 통보 받기도 한다.

품질 리자

웹 서비스 보안 품질 리자 입장에서는 SLA에 명시되는 보안 품질 제공 여부에

한 모니터링과 분석을 통한 리에 심을 가지고 있다. 한, 보안 품질 제공이

불가할 경우의 사유를 분석하여 수정할 수 있는 시스템에 심이 있다.

5.6.5 련표

W3C XML Encryption : XML 암호화 표

URL: http://www.w3c.org/Encryption/2001

W3C XML Digital Signature: XML 자서명 표

URL: http://www.w3c.org/Signature

OASIS SAML: 보안 서비스를 제공하는 다양한 시스템간의 상호운 을 가능하게

하는 표

URL: http://www.oasis-open.org/home/index.php

OASIS XACML: XML 기반의 공개 표 인 SAML은 보안 정책을 표 하는 표

URL: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml

OASIS의 WS-Security Specification: 보안 토큰과 메시지를 결합 할 범용의 메커

니즘 표

URL : http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message

-security-1.0.pdf

5.7 사용자별 웹 서비스 품질 요도

본 에서는 앞서 설명한 웹 서비스 품질에 하여 웹 서비스 계자 별 심에

으로 맞추어서 각 계자들은 어떠한 속성을 더 요하게 여기는지에 해서 비

교 설명한다. <표 5-4>은 각 품질에 해서 웹 서비스 계자가 심을 가지는 정

도를 높음(H), 낮음(L)로 표시한 것이다. 아래는 각 사용자별로 품질에 한 요도

에 한 설명이다.

- 50 -

<표 5-4> 웹 서비스 계자별 품질 요도

품질 발주자 개발자 소비자 제공자 개자 보증자 리자

비즈니스 가치

품질H L H L L L L

서비스 벨

측정 품질H H H H H H H

상호운용성

품질H H L L H L L

비즈니스 처리

품질H L L H H L L

리가능성

품질H H L H L H H

보안 품질 H H H L L H H

발주자의 입장에서는 모든 품질에 해서 심을 가지게 된다. 보다 높은 품질 수

을 제공할 수 있는 개발자에게 웹 서비스 개발을 의뢰해야 하며 개발 완료시 개

발된 웹 서비스 품질을 측정하는 검수 작업을 해야 한다. 특히 비즈니스 가치 품질

심이 높으며 성능과 같은 서비스 벨 측정 품질도 요하게 고려한다. 서비스

벨 측정 품질의 경우 발주자를 비롯한 모든 계자가 모두 요하게 여기는 품질

이다. 한 발주자는 여러 개발자에게 하나의 웹 서비스를 나 어서 개발하게 할

경우 상호운용성을 고려해서 웹 서비스 개발 완료 시 검수해야 한다. 그리고 비즈

니스 처리 품질의 경우는 발주자가 개발자에게 웹 서비스 개발을 의뢰할 때 비즈니

스 처리가 가능하도록 의뢰해야 하고 검수 시 비즈니스 처리가 가능한지를 꼭 확인

해야 한다. 마지막으로 발주자는 웹 서비스의 리를 해서 리가능성 품질을 제

공할 수 있는 웹 서비스를 개발을 의뢰해야 하기 리가능성 품질도 고려해야한다.

개발자의 경우는 서비스 벨 측정 품질, 상호운용성 품질, 리가능성 품질, 보

안 품질에 해서 심을 갖는다. 성능과 안정성과 같은 서비스 벨 측정 품질 같

은 경우는 웹 서비스 사용자가 제일 심 있어 하는 품질이기 때문에 개발자 역시

보다 빠른 웹 서비스를 개발하는데 노력을 기울여야 한다. 그리고 상호운 성 품질

은 개발자가 상호운용 가능한 표 을 수해야만 여러 개발자가 개발한 웹 서비스

를 통합할 때 문제가 발생하지 않기 때문에 요하게 고려해야 한다. 한 개발자

는 리가능한 웹 서비스를 개발하기 해서 표 화된 리가능성 인터페이스를 보

안성이 제공하는 웹 서비스를 개발하기 해서 보안 로 일을 수해서 웹 서비

스를 구 해야 한다.

소비자가 심을 갖는 품질은 비즈니스 가치 품질과 서비스 벨 측정 품질 그리

고 보안 품질이다. 소비자가 좋은 비즈니스를 찾기 한 조건으로 그 웹 서비스가

비즈니스 에서 가치가 있는가를 따지기 때문에 비즈니스 가치 품질에 심이

있으며 소비자의 입장에서 성능 안정성 품질이 좋은 웹 서비스를 선호하게 된

- 51 -

다. 한 사용자의 개인정보나 비 을 보장할 수 있는 보안 품질이 높은 웹 서비스

를 선호하게 된다.

제공자의 입장에서는 서비스 벨 측정 품질과 비즈니스 처리 품질, 리가능성

품질에 해서 심을 갖는다. 보다 빠르고 안정 인 웹 서비스를 제공하기 해서

제공자는 보다 좋은 웹 서비스 랫폼을 제공해야 한다. 비즈니스 처리 품질의 경

우 웹 서비스 자체 보다는 웹 서비스를 제공하는 랫폼 서버 단에서 제공하게

된다. 따라서 제공자는 웹 서비스 비즈니스 처리 기능을 제공하기 해서 비즈니스

처리 품질에 심을 갖게 된다. 그리고 제공자의 웹 서비스 랫폼에 한 리를

해서 리가능성 인터페이스를 제공해야한다.

개자는 서비스 벨 측정 품질과 상호운용성 품질, 비즈니스 처리 품질에 해

서 심을 갖는다. 상호운용성의 경우 사용자에게 웹 서비스 품질 정보를 제공할

때 상호운용성에 한 정보를 웹 서비스의 정보와 같이 제공해야 하기 때문이다.

사용자가 여러 웹 서비스를 통합해서 업 웹 서비스를 구성하려고 할 때 제일

요한 품질이 상호운용성 품질이기 때문이다. 그리고 개자는 업 웹 서비스

구성을 해서 상호운용성과 마찬가지로 비즈니스 처리 품질의 제공여부도 사용자

에게 제공해야 한다.

보증자와 리자는 서비스 벨 측정 품질, 리가능성 품질, 보안 품질에 해서

심을 갖는다. 보증자와 리자의 제일 요한 역할이 웹 서비스 리이기 때문에

리가능성 품질을 제일 요하게 고려해야 한다. 제공자가 제공하는 웹 서비스

랫폼에 한 리가능성을 테스트 제어 할 수 있어야 한다. 한 보안 품질에

해서도 보증자와 리자는 사용자들의 웹 서비스를 사용함에 있어서 보안 품질에

수되고 있는지에 해서 모니터링 해야 하기 때문에 보안 품질에 해서도 심

을 갖는다.

- 52 -

제 6 장 웹 서비스 품질 리 도입 략

웹 서비스 표 기술은 표 자체가 차 진화하고 있어서 그 기술에 한 도입은

물론 서비스 품질에 한 리도 단계 으로 이루어져야 한다. 본 장에서는 웹 서

비스 품질 리 3단계 도입 략에 하여 간단히 소개하고 각 단계별로 표 화 되

어야 하는 웹 서비스 사용상의 품질에 해서 설명한다. 이 게 단계 으로 품질

리 도입을 진행함으로써 체 품질 요한 부분부터 보다 구체 이고 체계

으로 진행할 수 있다. 본 보고서에서 제시하는 품질 리 도입 3단계 략은 국제

웹 서비스 표 진행 상황과 국내의 형 SI 업체들을 심으로 재 국내 웹 서비

스 도입 상황을 고려하여 작성한 것으로 <표 6-1>과 같다. 다음은 각 단계에 따른

표 화 과정에 한 설명이다.

<표 6-1> 웹 서비스 품질 리 도입 략

1단계 2단계 3단계

용분야기업 내 A2A 통합

기 1:1 B2B 통합

기업간 정 비즈니스

로세스 통합

기업간 동 비즈니스

로세스 통합

비즈니스

가치 품질

- 비용/ 약

- 합성 - 평 - 미터링/과

서비스 벨

측정 품질

- 성능 (비 트랜잭션 서비스)

- 안정성 (이용가능성, 신뢰

성)

- 성능 (트랜잭션 서비스)

- 안정성 ( 근성) - 성능 ( 업 서비스)

리가능성

품질

- WSDM 표 권장

- 웹 서비스/ 랫폼 내부

찰 가능성

- 웹 서비스/ 랫폼 통지 가

능성

- 자체 리를 통한 리

- WSDM 표 수

- 웹 서비스/ 랫폼 제어가

능성

- 외부 리자를 통한 리

- 통합 리센터를 한

리가능성 표

- 통합 리센터를 통한

리되는 웹 서비스/ 랫

폼

상호운용성

품질

- 표 수성

- 자정부 BP 1.0 상호운용

성

- 자정부 SP 1.0 상호운용

성 - 확장

보안 품질- 보안 로 일0, 보안 로

일1 (옵션)

- 보안 로 일2, 보안 로

일3 (옵션) - 보안 로 일4

비즈니스

처리 품질

- 신뢰성 메시징

- 단기 트랜잭션

- 장기 트랜잭션

- BPEL의 정확한 사용

- 앙 집 비즈니스 로

세스 리

- 분산 비즈니스 로세

스 리

6.1 제 1 단계

품질 리 도입 1단계는 웹 서비스 기 도입 시 용될 응용분야에서 필요한 품질

속성에 한 리를 다룬다. 기에 웹 서비스는 보안이나 비즈니스 로세스가 단

순한 기업 내의 통합이나 트 계에 있는 두개 기업 간의 업무를 일 일로 통

- 53 -

합하는데 사용될 것이다. 기업 내 통합은 기업 내에 있는 어 리 이션들을 연계

통합하는 것으로 성능, 상호운용성, 올바른 처리를 한 안정 메시징은 물론 내부

업무에 한 트랜잭션 처리, 내부자 보안 처리 내부 시스템 리 측면에서의

리가능성 등의 품질을 리하여야 한다. 두개의 비즈니스 트 기업 간의 일 일

통합의 경우는 기업 내 통합에 비하여 품질에 한 보장이 좀 더 요해 진다. 무

엇보다도 타 기업이 사용하는데 지불해야 하는 서비스 사용비용 압 , 그리고

서비스 인터페이스의 합성과 같은 비즈니스 가치 품질이 고려된다. 서비스 벨

측정 품질로는 성능뿐만 아니라 안정성도 요해 진다. 상호운 성과 올바른 처리

를 한 신뢰성 메시징은 올바른 처리를 한 필수요소이다. 트랜잭션 처리, 서비스

보안, 서비스 리가능성 품질들도 기업간의 계이므로 좀 더 잘 리되어야 한다.

<표 3-1>에서 요약된 1단계에서 고려하여야 할 품질속성들을 정리해 보면 다

음과 같다. 비즈니스 가치 품질은 비즈니스 측면에서 제일 먼 고려해야 하는 품

질은 비용/ 약 과 웹 서비스의 합성이다. 서비스 벨 측정 품질은 트랜잭션을

고려하지 않는 단순 웹 서비스 호출 시의 성능과 이용가능성 신뢰성이 고려 상

이다. 리가능성 품질은 웹 서비스 랫폼에 한 내부 찰 가능성과 통지 가

능성을 통한 자체 인 리가 필요하며 재 OASIS에서 표 화 작업을 진행 에

있는 WSDM 표 을 수하도록 권장한다. 상호운용성 품질에 해서는 하나 이상

의 웹 서비스들 간의 서로 작동 될 수 있는 웹 서비스 기본 표 인 SOAP, WSDL,

UDDI에 한 표 수는 물론 자 정부 기본 로 일(Basic Profile) 1.0을 수

하여 상호운용성도 지원해야 한다. 보안 품질은 보안 로 일0에 해서는 반드시

수하여야 하며 보안 로 일1은 옵션사항이다. 비즈니스 처리 품질에 해서는

비즈니스 처리의 기본 요구사항인 신뢰성 메시징과 단기 트랜잭션에 한 올바른

처리가 이루어 져야 한다.

6.2 제 2단계

품질 리 도입의 2단계는 웹 서비스를 기업 간의 정 인 비즈니스 로세스 통합

에 이용할 경우이다. 이 단계에서는 각 기업이 제공하는 서비스가 곧 기업의 생산

품이라는 인식이 확산되며 기업 간에 제공하는 서비스들을 결합하여 새로운 서비스

를 창출해 내려는 비즈니스 로세스 결합의 시도들이 많아진다. 따라서 각 기업의

서비스들은 BPEL과 같은 표 화된 비즈니스 로세트를 처리할 수 있어야하고 비

즈니스 로세스 상에서 일어나는 장기 트랜잭션도 지원 가능하여야 한다. 비즈니

스 트 가 아닌 기업 간에도 비즈니스 로세스 결합이 일어나므로 상호운용성과

보안이 더욱 요시 되는 단계이다. 한 같은 종류의 서비스가 경쟁하게 되므로

소비자에 한 평 도 고려하게 된다. 따라서 서비스 품질 리를 한 리가능성

품질도 더욱 요한 품질 속성이 된다. 서비스 품질 리 문 기 의 출 도 가능

한 단계이다.

2단계에서 고려하여야 할 품질속성들을 정리해 보면 다음과 같다. 비즈니스 가

- 54 -

치 품질은 비즈니스에 직업 인 향을 끼치는 비용 이외에 웹 서비스에 한 소비

자들의 평 에 한 고려가 이루어져야한다. 서비스 벨 측정 품질은 트랜잭션 서

비스에 한 성능 품질이 고려되어야 하고 다수의 사용자를 한 근성 세부 품질

도 다루어져야 한다. 리가능성 품질은 WSDM표 을 수하는지에 한 테스트와

웹 서비스 랫폼에 한 제어가능성과 내부 리자뿐만 아니라 외부에 존재한

리자를 통해서 리하기 한 리가능성도 지원되어야 한다. 상호운용성 품질은

자정부 보안 로 일(Security Profile) 1.0을 수하여야 한다. 보안 품질은 TTA

의 “웹 서비스 품질 모델“ 표 에서 제시하는 보안 로 일2은 지원하여야 하고보

안 로 일3에 해서는 옵션사항이다. 비즈니스 처리 품질에서는 BPEL을 지원하

여야 하고장기 비즈니스 트랜잭션 처리와 앙 집 인 비즈니스 처리 리도 지

원하여야 한다.

6.3 제 3단계

제 3단계는 기업 간의 비즈니스 로세스 통합이 좀 더 활성화되는 단계이다. 2단

계에서와 같은 정 인 비즈니스 로세스의 통합은 더욱 다양해지고 서비스 이용시

에 필요한 서비스를 찾아 연결시키는 동 인 비즈니스 로세스 통합도 등장하는

단계이다. 인터넷에 연결된 모든 웹 서비스들을 동 으로 찾아서 연결하여 새로

운 비즈니스가 창출될 수 있는 단계이기도 하다. 이 단계에서는 상시 제공할 수 있

는 좋은 서비스를 얼마나 많이 가지고 있느냐가 곧 기업의 경쟁력이 되는 시기이

다. 따라서 서비스 품질은 더욱 고 화 되어야 하고 서비스 이용에 한 미터링과

과 에 한 자동화도 요시 된다. 상호운용성, 보안, 비즈니스 로세스, 트랜잭션

품질에 한 강화는 물론이고 웹 서비스의 품질 리도 더욱 강화되는 단계이다. 따

라서 웹 서비스 품질 리에 모든 부분에서 표 화 작업이 완료되어야 하며 자동화

된 웹 서비스 품질 리를 한 품질 리 센터가 필요한 시기이다.

3단계에서 고려하여야 할 품질속성들을 정리해 보면 다음과 같다. 비즈니스 가

치 품질에는 추가 으로 사용자들이 얼마나 그 서비스를 사용하고 있는가에 한

정보 분석과 보다 자동화된 서비스 사용료 처리를 한 미터링/과 품질이 지원되

어야 한다. 서비스 벨 측정 품질에서는 다수의 웹 서비스 통합 과정 즉, 업

웹 서비스에 한 성능 품질이 추가로 고려되어야 한다. 리가능성 품질에 해서

는 통합 리 센터를 통한 웹 서비스 랫폼에 한 표 화된 통합 리 작업가

이루어져야 한다. 이러한 통합 리센터를 통해서 웹 서비스는 더 이상 리자의

개입 없이 품질을 유지하며 리 작업을 자동화 할 수 있다. 보안 품질은 보안

로 일4가 지원되어야 한다. 비즈니스 처리 품질에서는 사 인 웹 서비스 통합

단계에서 발생하는 보다 많은 비즈니스 로세스를 처리하기 해서 비즈니스 로

세스 분산 처리가 지원되어야 한다.

- 55 -

제 7 장 웹 서비스 테스트 가이드라인

본 장은 웹 서비스 제공자가 자신이 제공하려는 웹 서비스가의 품질을 자체 평가하

거나 웹 서비스 사용자나 리자가 제공되는 웹 서비스의 실제 품질이 계약서상의

품질 요구사항을 제 로 만족시키는지를 확인하려고 할 때 참고할 테스트 가이드라

인을 제시한다. 아직 국제 인 표 이 없는 상황에서 본 가이드라인은 실제 테스트

를 한 구체 인 기술보다는 웹 서비스 기 도입을 활성화시키기 한 목 으로

테스트에 한 개념과 기본 구조 방법을 제시를 한다. 한 6장에서 제시한 품

질모델의 품질속성 에서 7장의 제 1단계에 해당하는 품질 속성만을 다룬다.

7.1 서비스 벨 비즈니스 가치 품질 테스트

서비스 벨 비즈니스 가치 품질의 제공 여부 품질 수 의 테스트를 한 테스

트 로세스, 테스트 항목은 다음과 같다. 서비스 벨 비즈니스 가치 품질의 경우

본 가이드라인에서 제시하는 테스트 로세스 방법 이외에 다른 여러 가지 방법으

로 측정가능하다.

7.1.1 테스트 아키텍처

서비스 벨 비즈니스 가치 품질 테스트는 정량 으로 개량화 하기 쉽지 않고, 이

를 시스템 으로 테스트하기 한 아키텍처의 제공은 어려운 문제이다. 그러므로 비

즈니스 가치 품질을 측정하고 평가하기 해서는 다음의 2가지 방법으로 나 어 수

행할 수 있다. 첫 번째 테스트 방법은 사용 인 웹 서비스에 한 온라인 실시간

모니터링 후 기록된 로그 분석을 통해서 비즈니스 가치를 테스트 하는 방법과 웹

서비스 고객과 련된 정보를 바탕으로 오 라인 설문조사나 다른 매체를 통한 웹

서비스에 한 평 을 조사하는 방법을 사용해서 측정한다.

7.1.2 테스트 항목 테스트 방안

테스트 항목 테스트 방안은 테스트 아키텍처에서 제시하는 온라인 실시간 모니

터링 방법과 오 라인 설문 조사 방법으로 나 어서 고려한다.

7.1.2.1 온라인 실시간 모니터링 방법

온라인 실시간 모니터링 방법은 사용 인 웹 서비스에 한 온라인 실시간 모니터

링 후 기록된 로그의 웹 서비스별 분석 는 이용 고객별 분석을 통해 웹 서비스의

비즈니스 가치를 테스트 하는 방법이다. 로그분석을 통해 다음의 각 기 항목별

측정치를 서비스 벨 비즈니스 가치 품질에서의 BLA에 한 기 으로 활용 가능

하다.

- 56 -

서비스별 사용 빈도 (기간별 서비스 사용 빈도)

서비스별 사용 집 도 (시간 별, 일자별)

서비스별 이용 고객 수

서비스별 이용 고객 당 시스템 수

서비스별 이용 고객 당 시스템 사용 빈도

고객별 사용 서비스 수

고객별 서비스 사용 빈도

고객별 서비스 사용 집 도 (시간 별, 일자별)

고객 시스템별 사용 서비스 수 (서비스 연결 시스템의 수)

고객별 서비스 간 이용연 성

서비스 이용 가격

실제 서비스 사용량과 사용 요 간의 일치성

서비스 이용 가격 수 별 이용률 (High cost , Low cost) ( 치 변경)

고객 비즈니스 단 당 이용하는 연 서비스 종류( 쇼핑몰 결재 - 인증, 과

)

고객 비즈니스 단 당 연 서비스별 이용률

7.1.2.2 오 라인 설문 조사 방법

오 라인 설문 조사 방법은 웹 서비스에 한 평 을 조사하기 해서는 다음과 같

은 항목에 해서 설문조사를 각 항목별로 5단계로 실시하여 평 을 알아내는 방법

이다. 를 들어 평균이 기 값( 3.5) 이상이고, 최 항목이 최 기 값( 2) 이

상을 만족해야 비즈니스 가치를 가지는 웹 서비스로 단 한다.

서비스의 활용처 가치(필요성)

사용자들의 신뢰성

서비스 활용 용의 용이성(편리한 활용을 한 서비스 제공)

고객 만족도

컨텐츠의 충실도

실시간 상태 정보의 제공 여부

서비스 활동에 한 모니터링 지원

사용자 비즈니스 활동 기여도

사용자 비즈니스 활동 향도

서비스 용 사용자 비즈니스 요도(일반 정보 활용, 고객 서비스)

서비스 용 후 고객 비즈니스 가치 증가 여부

서비스 이용 가격 비 해당 고객 비즈니스 ROI (설문을 통한 고객 기 의

ROI)

- 57 -

7.2 서비스 벨 측정 품질 테스트

서비스 벨 측정 품질의 경우는 기존의 웹 성능 품질 테스트 방법과 비슷하다. 즉,

외부에서 실제 웹 서비스를 호출해 보고 모니터링의 결과를 바탕으로 품질을 테스

트한다. 원하는 수 의 서비스 벨 측정 품질이 제공되고 있는지 여부 품질 수

을 테스트하기 한 테스트 아키텍처, 테스트 항목, 테스트 시나리오, 테스트 방

안은 아래와 같다.


서비스 벨 측정 품질에 한 테스트 아키텍처는 <그림 7-1>과 같다.

<그림 7-1> 서비스 벨 측정 품질 테스트 아키텍처

서비스 벨 측정 품질은 실제 웹 서비스 호출시의 품질이다. 그러므로, 서비스

벨 측정 품질 테스트를 해서는 서비스를 직 호출하는 방법이 이용되는데, 이를

해 기존 웹 환경에서 사용하는 웹 스트 스 툴을 사용할 수 있다.

7.2.2 테스트 항목

아래는 서비스 벨 측정 품질의 각 속성에 한 테스트 항목이다.

응답시간: 호출 시간과 응답시간의 차이의 평균을 구한다.

임계성능: 단 시간동안 처리된 서비스 최 호출 수의 평균을 구한다.

이용가능성: 주기 으로 호출하거나 GetServiceStatus 등의 서비스를 직 호출

하여 재 웹 서비스를 사용할 수 있는지에 한 측정한다.

- 58 -

신뢰성: 웹 서비스 호출시 장된 로그에서 단 시간동안(년, 월, 일)의 서비스

호출 에러 결과를 구한다.

근성: 웹 스트 스 툴을 사용해서 몇 명까지의 서비스 호출을 처리할 수 있

는지를 측정한다.

7.2.3 테스트 시나리오

서비스 벨 측정 품질 테스트 과정은 실제 웹 서비스를 호출해 보는 방법을 사용

한다. 아래는 각 테스트 항목에 한 상세 테스트 시나리오이다.

응답시간

1) 테스트 드라이버(Test Driver)에 테스트 하려는 웹 서비스 제공자 련 정보와

테스트 기간, 테스트 오퍼 이션의 이름을 장한 테스트 시나리오를 입력한다.

2) 테스트 드라이버는 웹 서비스 호출 이 시각과 호출 이후 응답이 도착하는 시

각을 로그로 장한다.

3) 2)번 과정을 지정된 테스트 기간동안 반복한다.

4) 장된 로그 분석을 통해서 장된 두 시각 간의 차이의 평균을 구한다.

임계성능

1) 응답시간 테스트 시나리오를 통해서 얻어진 로그를 통해서 테스트 기간동안에

서버의 다운이나 기타 오류발생이 없이 정상 으로 서비스 되어진 기간동안의 최

서비스 처리량을 구한다.

2) 처리량에 한 일정기간 동안의 평균을 구한다.

이용가능성

1) 응답시간 테스트 과정에서 서비스 호출에 한 성공여부를 같이 로그에 장한

다.

2) 장된 로그 분석을 통해서 서비스 호출이 성공한 기간을 산출한다.

3) 체 테스트 기간과 서비스를 이용 가능한 기간동안의 비율을 통해서 이용가능

성을 구한다.

신뢰성

1) 응답시간 테스트 과정에서 서비스 호출에 한 호출 에러의 발생 시간과 발생

원인을 로그에 같이 장한다.

2) 일정기간 응답시간 테스트를 한 뒤 장된 로그에서 단 시간동안(년, 월, 일)

의 서비스 호출 에러 발생의 평균 시간을 구한다.

3) 체 테스트 기간과 서비스 호출 에러 발생 시간의 비율로 신뢰성을 구한다.

- 59 -

근성

1) 테스트 드라이버(Test Driver)에 테스트 하려는 웹 서비스 제공자 련 정보와

테스트 기간, 테스트 오퍼 이션의 이름, 동시에 처리 가능한 가상 사용자 수를

장한 테스트 시나리오를 입력한다.

2) 테스트 드라이버는 테스트 하려는 웹 서비스를 호출하면서 호출 쓰 드(Thread)

를 동시에 차 으로 늘려가면서 가상의 사용자 수를 늘려보면서 웹 서비스를 호

출한다.

3) 가상의 사용자의 입장에서 서비스 호출과 응답 유무를 로그에 장한다.

4) 3번 과정을 미리 입력된 테스트 기간과 가상 사용자의 수만큼 테스트 한다.

5) 로그에 장된 가상 사용자의 호출 메시지와 정상 인 응답 메지시의 수의 비

율을 통해서 근성 품질 수 을 구한다.

7.2.4 테스트 방안

본 가이드라인에서 제시하는 테스트 시나리오를 따르지 않더라도 기존의 웹 서

버의 성능 분석 도구나 상용 웹 스트 스 도구를 사용해서 응답시간, 임계성

능, 이용가능성 신뢰성, 근성을 테스트할 수 있다.

웹 서비스의 리가능성 인터페이스를 통해서도 응답시간, 임계성능 품질 수

을 측정할 수 있다.

근성 테스트의 경우 미리 정해진 동시 사용자의 수를 정하지 않은 경우는 서

버가 더 이상 웹 서비스 호출을 처리할 수 없기 직 까지를 테스트함으로써

근성 품질의 최 수 을 측정할 수 있다.

7.3 상호운용성 품질 테스트

웹 서비스 상호운용성 품질 테스트는 하나 이상의 웹 서비스들 간의 호환성 표 의

수 여부와 상호 운용 가능 여부를 테스트 해야 한다. 이러한 웹 서비스의 상호운

용성 품질 테스트에 해서는 이미 OASIS의 WS-I에서 상호운용성 련 테스트 가

이드라인을 제시하고 있다. WS-I에서는 웹 서비스의 상호운용성 품질(표 수성,

상호운용성) 수 을 평가하기 해 웹 서비스와 사용자 애 리 이션 사이에서 발

생하는 메시지정보와 웹 서비스의 WSDL, UDDI 정보를 분석하여 웹 서비스의 상

호운용성 품질 수 을 평가한다.


상호운용성 품질 테스트 툴은 크게 모니터와 분석기로 나뉘어 진다. 모니터는 웹

서비스가 운용되는 웹 서버에 설치되어 인터셉터로 하여 웹 서비스 클라이언트와

웹 서비스 간에 호출이 발생할 때, 송되는 SOAP 메시지를 가로채고 로그

(Logger)를 통해 분석기에서 요구하는 형태의 포맷으로 장한다. 장된 SOAP 메

- 60 -

시지는 WSDL, UDDI정보와 함께 분석기에 달되어 Test Assertion Document(상

호운용성 로 일의 XML정의 문서)에 정의된 각 항목들에 한 수 여부를 측정

하게 된다. 측정된 정보는 체 서비스의 상호운용성의 수 여부와 각 개개 항목

별 수여부를 보고서 형태로 생성하여 보여 다.(<그림 7-2> 참조).

<그림 7-2> 상호운용성 품질 테스트 아키텍처


상호운용성 테스트 시 측정 항목은 아래와 같다.

7.3.3.1 표 수성 테스트

SOAP

1) SOAP 메시지의 구조(Envelope, Header, Body)를 제 로 따르고 있는가?

2) SOAP 스키마에서 지원하지 않는 요소를 사용하고 있는가?

3) 표 SOAP 네임스페이스를 제 로 사용하고 있는가?

WSDL

1) WSDL 스키마에서 지원하지 않는 요소를 사용하고 있는가?

2) WSDL 스키마에서 정의하고 있는 문서의 구조를 제 로 따르고 있는가?

3) 표 WSDL 네임스페이스를 제 로 사용하고 있는가?

- 61 -

UDDI

1) UDDI에서 정의하고 있는 데이터 구조 스펙을 제 로 반용하고 있는가?

2) Business Entity 스키마를 제 로 따르고 있는가?

3) Business Service 스키마를 제 로 따르고 있는가?

4) Binding Template 스키마를 제 로 따르고 있는가?

5) tModel의 스키마를 따르고 있는가?

엔터 라이즈 환경에서 필요한 웹 서비스 표 의 수 여부

1) WS-Security 스키마를 제 로 따르고 있는가?

2) WS-Reliable Messaging 스키마를 제 로 따르고 있는가?

7.3.3.2 상호운용성 테스트

WS-I가 제공하는 SOAP, WSDL, UDDI 로 일 수 여부를 조사한다.

(1) SOAP

SOAP Envelope

1) 문서 엘리먼트가 Envelope을 제 로 사용하는가?

2) SOAP 스펙에서 정의한 네임 스페이스 이외의 네임 스페이스를 사용하 는

가?

3) Body 엘리먼트 이후에 추가 인 엘리먼트가 사용되었는가?

SOAP Processing Model

1) 사용되어서는 안 되는 encodingStyle 속성을 사용하 는가?

2) mustUnderstand 속성은 “true" 는 "false"만을 사용하 는가?

3) 처리할 수 없는 메시지를 수신 하 을 때 Fault를 발생하는가?

SOAP 폴트

1) 폴트를 구성하는 필수 엘리먼트인 Code와 Reason이 제 로 사용되었는가?

2) Reason 엘리먼트는 xml:lang 속성을 사용해 다국어 제 로 처리를 하 는가?

HTTP에서 SOAP의 사용

1) HTTP/1.1 는 HTTP/1.0 이외의 HTTP 로토콜 바인딩이 이루어 졌는가?

2) 사용할 수 없는 HTTP 확장 임 워크를 사용하 는가?

3) POST와 GET 메소드 이외의 메소드가 사용되었는가?

4) 당한 콘텐트-타입 헤더를 제 로 사용하 는가?

5) HTTP 상태코드를 정상 으로 사용하 는가?

- 62 -

(2) WSDL

WSDL 문서 구조

1) WSDL Schema를 제 로 따르고 있는가?

2) WSDL 문서 분리규칙을 제 로 따르고 있는가?

3) XML 1.0 버 을 제 로 용하고 있는가?

4) 확장 WSDL요소를 제 로 용하고 있는가?

WSDL 타입

1) 확장 자료형을 사용하고 있는가?

2) 자료형의 TargetNamespace를 제 로 명시하고 있는가?

3) soapenc:array 타입을 용하고 있는가?

WSDL 메시지

1) wsdl:part 요소들이 document-literal과 rpc-literal binding들을 제 로 용하고

있는가?

WSDL Port Types

1) part 요소들의 순서로 제 로 지켜지고 있는가?

2) Solicit-Response와 Notification 타입을 사용하고 있는가?

3) 다형성을 허용하고 있는가?

WSDL Binding

1) SOAP Binding을 제 로 사용하고 있는가?

2) 기본 송 로토콜을 HTTP로 제한하고 있는가?

(3) UDDI

wsdl:binding은 rpc-literal binding 는 document-literal binding을 제 로 사

용하고 있는가?

uddi:tModel에서 웹 서비스 정보를 표 하기 해 정의되는 구조는 UDDI

장소에서 WSDL을 사용하기 한 제를 제 로 따르고 있는가?


웹 서비스 상호운용성에 한 테스트 시나리오는 다음과 같이 수행한다.

SOAP, WSDL, XML, HTTP의 상호운용성 로 일 수 여부 측정

- 63 -

상호운용성 품질 수 을 테스트하고자 하는 웹 서비스를 선택한다.

모니터를 해당 웹 서버에 설치한다.

모니터의 interceptor를 통해 웹 서비스에서 발생되는 SOAP 메시지를 가로채어

기록한다.

분석기를 통해 기록된 SOAP 메시지와 WSDL문서를 Test Assertion Document와

비교한다. Test Assertion Document는 상호운용성 Profile를 참조한다.

분석된 결과를 토 로 상호운용성 품질 수 을 보고서 형태로 산출한다.

UDDI의 상호운용성 로 일 수 여부 측정

1. UDDI에 서비스 등록 시와 검색 시 사용된 XML메시지를 분석기를 통해 Test

Assertion Document와 비교 분석한다.

2. 분석된 결과를 통 로 UDDI에 한 상호운용성 품질 수 을 보고서 형태로

산출한다.


웹 서비스가 운용되는 서버에 모니터를 직 설치하지 않고 Agent만을 설치하

여 클라이언트로부터 요청되는 SOAP 메시지와 서버로부터 응답되는 SOAP 메

시지를 품질 테스트 서버로 송, 메시지에 정의된 SOAP, HTTP, XML의 상호

운용성 로 일 수 여부를 테스트 할 수 있다.

모든 상호운용성 로 일들에 한 Test Assertion Document를 상호운용성

품질 테스트 서버에서 리하게 하여, 테스트 툴로 하여 새로운 로 일들

에 한 수 여부를 테스트 할 수 있도록 한다.

UDDI 테스트는 UDDI에 등록여부에 따라 테스트 과정상에서 추가 는 배제

할 수 있도록 한다.

7.4 비즈니스 로세스 처리 품질 테스트

비즈니스 처리 품질이 제공되고 있는지 여부 품질 수 을 테스트하기 한 테스

트 아키텍처, 테스트 항목, 테스트 시나리오, 테스트 방안은 아래와 같다


비즈니스 처리 품질 테스트 아키텍처는 <그림 7-3>과 같다. 비즈니스 처리 품질을

테스트하기 해서는 비즈니스 로세스를 보내는 송신 측 BPH(Business Process

- 64 -

Handler)엔진과 수신 측 BPH 엔진 사이의 상호작동을 모니터링 해야 한다. BPH

엔진의 작동을 모니터링 하기 해서 BPH 엔진의 앞단에 로세스를 모니터링 할

수 있는 테스트 드라이버(Test Driver)를 설치해야 하며 각 송신, 수신 측 웹 서비스

랫폼에서는 테스트 드라이버를 통해서 로세스 처리에 련된 로그를 데이터베

이스에 장해야 한다. 비즈니스 로세스 품질 테스트를 해서는 로그 분석기를

통해서 비즈니스 처리 품질을 테스트 한다. 테스트 드라이버는 로그를 장하는 기

능 외에 일정한 시나리오로 처리되어야 하는 비즈니스 처리 품질에 해서

BP(Business Profile)을 외부로부터 입력 받아서 비즈니스 로 일에 나열된 차에

따른 품질 테스트를 수행하는 역할도 한다.

<그림 7-3> 비즈니스 로세스 처리 품질 테스트 아키텍처


비즈니스 처리 품질의 테스트 항목은 비즈니스 처리 품질의 세부 품질 요소인 신뢰

성 메시징, 트랜잭션 처리, 비즈니스 로세스 리 각각에 해서 명시한다. 아래

는 각 세부 품질 요소별 품질 테스트 항목과 각 항목에 한 상세 테스트 시나리오

이다.

7.4.2.1 신뢰성 메시징

- 65 -

신뢰성 메시징이란 메시지를 발송하고 수신하는 과정에서 어떠한 경우에라도 꼭 한

번, 복되지 않고, 송신 순서에 따라 수신할 수 있는 메시징 시스템의 능력을 말한

다. 이를 검증하기 해서는 기본 으로 다음과 같은 항목들을 검증해야 한다.

메시징 시스템 내부 으로 에러가 발생하지 않는지, 에러 메시지가 보내지지

않았는지 HTTP Failure 코드를 받지 않았는가?

요청 메시지의 메시지 ID 값과 Ack 메시지내의 요청 메시지 ID 값이 같은지

를 체크

요청 메시지에 한 Ack를 잘 받았는가?

요청 메시지에 한 응답 메시지를 잘 보내는가? 한 이에 한 Ack를 수신

하 는가?

간혹 네트웍에 한 이상이 생겨 송신자가 보낸 메시지를 수신자가 받지 못하는 경

우가 발생할 수 있다. 이러한 경우 송신자는 수신자가 받을 때까지 몇 차례 복

으로 같은 메시지를 송신할 수 있어야 한다. 이러한 능력을 테스트하기 해 다음

과 같은 항목을 검해 보아야 한다.

피평가 시스템이 요청 메시지를 보낸 후 Ack를 받지 못하는 경우 같은 메시

지를 일정 간격으로 재 송하는가?

Ack 메시지를 받은 후에는 더 이상의 메시지를 발송하지는 않는가?

정상 으로 메시지는 보냈지만 Ack를 받지 못하는 경우 송신자는 계속 메시지를

복 으로 보내게 된다. 이러한 경우 수신자 측에서는 같은 종류의 메시지가

복 으로 도착함을 악하고 하나의 메시지로 처리할 수 있는 능력이 있어야 한

다.

평가되는 시스템에 같은 ID의 메시지를 반복 송신해서 하나의 메시지로 인식

하는지를 체크메시지 ID와 메시지 페이로드내의 일련번호는 서로 다를 수 있다.

이러한 경우, 메시지 엔진은 메시지 ID와는 상 없이 페이로드의 일련번호 순에

따라 뒷단의 애 리 이션에게 데이터를 넘겨 수 있는 능력이 있어야 한다.

이를 해 다음의 항목을 검토한다.

메시지 처리 순서

요청 메시지가 피 평가자의 메시지시스템에 잘못된 순서로 도착했더라도 피 평가

자 측의 애 리 이션이 요청 메세지를 메시지 Sequence 번호순으로 받았는지 체

크한다.

- 66 -

7.4.2.2 트랜잭션 처리

웹 서비스 시스템은 기본 으로 분산 환경에서 가동이 되므로 트랜잭션 처리능력은

무엇보다 요하다 할 수 있다. 트랜잭션 처리능력을 가지고 있는지 악하기 해

2단계처리 능력(2PC: Two-Phase Commit)과 2PC를 처리하기 해 코디네이션 컨텍

스트를 생성할 수 있는 능력이 있는지를 테스트해 보는 것이 무엇보다 요하다.

2PC를 검하기 해 다음 항목을 테스트한다.

2PC 시스템 내부 으로 에러가 발생하지 않는지, 에러 메시지가 보내지지 않

았는지 HTTP Failure 코드를 받지 않았는지 조사

2PC를 해 요구되는 모든 메시지가 순서 으로 수신되었는지 검토

주어진 시간 내에 메시지를 수신했는지 여부 검토

코디네이션 컨텍스트 생성이 제 로 되는지 검하기 해 다음 항목을 테스트한

다.

활성화 서비스 기간 내에 에러가 발생하지 않았는지 검토.

등록 과정 에러가 발생하지 않았는지 검토

등록 서비스 간 상과정 에 문제가 발생하지 않았는지 체크.

코디네이션 컨텍스트를 구성하기 한 로토콜간의 메시지 교환에 문제가

발생하지 않았는가?


7.4.3.1 신뢰성 메시지

메시지 교환

비 단계에서 평가자 피평가자는 XML 문서를 비하고 피평가자는 메시지를

받을 테스트 드라이버를 비한다. 비가 완료되면 피평가자는 시작신호를 평가

자에게 보낸다. 이후 평가자는 문서를 페이로드 형태로 보내게 되며, 이 메시지는

Ack 요청 항목을 가지고 있어야 한다. 피평가자가 이 메시지를 받으면 Ack 메시

지를 평가자에게 비동기 방식으로 보낸다. 평가자가 Ack를 받으면 그는 받은

Ack 메시지에 한 수신을 피평가자에게 알린다. 양방향 메시지 교환 평가를 하

고 싶으면 피평가자가 메시지를 받고 이 메시지의 내용을 피평가자에게 다시 보

- 67 -

내는 과정을 진행한다. 이 경우에는 피평가자가 보내는 응답 메시지에 한 Ack

요청항목이 응답 메시지내에 있어야 한다. 테스트 완료 후 평가자와 피평가자는

검사항목에 따라 테스트 결과에 해 평가한다.

양방향 메시지 교환

1) 평가자는 XML 문서를 비하고 피평가자 역시 같은 문서를 비한다.

2) 피평가자는 메시지를 받을 테스트 드라이버를 비한다.

3) 피평가자는 시작신호를 평가자에게 보낸다.

4) 평가자는 1)과정에서의 문서를 페이로드 형태로 보낸다. 이 메시지는 Ack 요청

항목을 가지고 있어야 한다.

5) 피평가자가 이 메시지를 받으면 Ack 메시지 1을 평가자에게 비동기 방식으로

보낸다. 피평가자는 평가자로부터 받은 같은 페이로드를 응답 메시지에 실어

평가자에게 보낸다. 응답 메시지는 Ack 요청 항목을 가지고 있어야 한다.

6) 평가자가 Ack 메시지와 응답 메시지를 받으면 피평가자에게 Ack 메시지 2를

보낸다.

7) 피평가자가 Ack 메시지 2를 받으면 메시지의 수신을 평가자에게 알린다.

8) 평가자는 검사항목을 체크하고 테스트 결과에 해 정리한다.

요청 메시지의 실패 후 메시지 재 송

평가자는 페이로드를 해 XML 문서 비하고 피평가자는 테스트 드라이버를

비한다. 그러나 그 테스트 드라이버를 통해서 메시지 송신이 가능하지 않도록

비한다. ( : TCP monitor blocks HTTP) 이후 피평가자가 시작신호를 평가자에게

보내면 평가자는 페이로드를 가진 메시지를 보낸다. 이 메시지는 Ack 요청 항목을

가지고 있어야 한다. 피평가자의 테스트 드라이버는 메시지의 송을 막고 있기

때문에 메시지 송신이 실패할 것이다. 평가자는 메시지의 재송신을 한번 더 하고

난 후 피평가자에게 “블록 해제” 신호를 보낸다. 피평가자가 “블록 해제” 신호를

받으면 메시지 송을 막고 있던 블록을 해제한다.

피평가자가 블록 해제 후 요청메시지를 받으면 Ack 메시지를 평가자에게 보낸

다. 평가자가 Ack 메시지를 받으면 피평가자에게 수신을 알린다. 평가자와 피평가

자는 테스트 항목에 따라 결과를 검토한다. 평가자가 메시지를 보냈는데 피평가자

에게서 Ack 메시지를 받지 못하면 계속 메시지를 재 송하게 된다. 재 송되는 메

시지에 해서도 Ack를 지속 으로 보낼 수 있는지의 여부를 테스트하기 해서

는 평가자가 요청메시지는 보내되 Ack 메시지를 받을 수는 없는 환경을 만들어

놓고 테스트를 시행한다.

Ack 메시지 수신 실패이후 메시지 재 송

1) 평가자는 XML 문서를 만들고 그의 테스트 드라이버가 Ack 메시지를 찾을

수 없게 만든다.

- 68 -

2) 피평가자는 테스트 드라이버를 비한다.


4) 평가자는 Ack 요청 항목을 가진 메시지를 피평가자에게 보낸다.

5) 피평가자가 메시지를 받으면 Ack 메시지를 평가자에게 보낸다. 하지만 평가

자는 그 Ack 메시지를 받을 수 없다.

6) 평가자는 같은 메시지를 보낸다.

7) 피평가자는 평가자에게 Ack 메시지를 받을 수 있게 하라고 알린 후 다시

Ack 메시지를 보낸다.

8) 평가자는 피평가자에게 Notify를 듣고 난 후 Ack를 받을 수 있는 상태로 만

든다.

9) 평가자가 메시지를 다시 보내고 피평가자는 Ack를 다시 보낸다. 평가자가 그

Ack 메시지를 받고 피평가자에게 수신을 알린다.

10) 평가자와 피평가자는 테스트 항목에 따라 결과를 검토한다.

메시지 복 처리

평가자는 XML 문서를 만들고 그의 테스트 드라이버가 Ack 메시지를 찾을 수 없

게 만든다. 피평가자는 테스트 드라이버를 비하고 시작신호를 평가자에게 보낸

다. 평가자는 Ack 요청 항목을 가진 메시지를 2번 피평가자에게 보낸다. 피평가

자가 메시지를 받을 때마다 Ack 메시지를 보낸다. 피평가자가 3번째 메시지를 받

을 때 그는 평가자에게 3번의 메시지를 받았다고 알린다. 테스트 완료 후 평가자

와 피평가자는 테스트 항목에 따라 결과를 검토한다.

메시지 순서보장

평가자는 XML 문서를 만들고 그의 테스트 드라이버가 Ack 메시지를 찾을 수 없

게 만든다. 피평가자는 테스트 드라이버를 비하고 시작신호를 평가자에게 보낸

다. 평가자는 3개의 메시지를 보낸다. 이 3개의 메시지는 Ack 요청항목을 가져야

하고 메시지 페이로드 내 일련번호(0,1,2)를 가져야 하며 메시지는 임의의 순서로

보내져야 한다. 한 각 메시지는 서로 다른 메시지 ID를 가져야 한다. 피평가자

가 메시지를 받을 때마다 Ack를 보내야 한다. 피평가자가 모든 3개의 메시지를

다 받으면 3개의 메시지를 다 받았음을 알린다. 테스트 이후 평가자와 피평가자는

테스트 항목에 따라 결과를 검토한다. 한 같은 맥락의 메시지가 나 어져서 다

른 메시지들과 엇갈린 순서로 수신될 수 있다. 이것을 순서 로 다시 정렬하여 애

리 이션에게 달할 수 있는 능력을 검증하기 해 3개의 메시지 각각을 두

개로 나 고 이를 섞어서 송한 후 같은 종류의 메시지끼리 순서화가 가능한지

를 체크한다.

동시에 보내지는 메시지 순서 보장

- 69 -

1) 평가자는 XML 문서를 만들고 그의 테스트 드라이버가 Ack 메시지를 찾을

수 없게 만든다.

2) 피평가자는 테스트 드라이버를 비한다.


4) 평가자는 6개의 메시지를 보낸다. 각 메시지는 두 개의 컨버세이션 ID를 가진

다. 한 각 메시지는 Ack 요청항목을 가지고 페이로드로써 메시지 일련번호

를 가진다. 각 컨버세이션은 3개의 메시지를 가지며 각각의 메시지는 0,1,2의

일련번호를 가진다. 각 메시지는 서로 다른 Message ID를 가지며 각 컨버세이

션내의 메시지는 번갈아 가며 보내진다.

5) 피평가자는 메시지를 받을 때마다 Ack를 보낸다.

6) 피평가자는 6개의 메시지를 다 받고 나면 평가자에게 수신을 알린다.

7) 평가자와 피평가자는 테스트 항목에 따라 결과를 검토한다.

7.4.3.3 트랜잭션 처리

2PC를 이용한 트랜잭션 처리

평가자는 쓰기단계 0을 해 XML 문서를 비하고, 평가자의 코디네이터 1이 그

메시지를 피평가자의 코디네이터 2에게 보낸다. 코디네이터 2는 피평가자의 애

리 이션 2에게 메시지를 보내서 DB에 쓰게 한다. 이후 코디네이터 2는 Ack 메

시지를 평가자에게 보낸다. 코디네이터 1은 “ 비” 메시지를 피평가자 코디네이터

2에게 보낸다.

코디네이터 2는 이 메시지를 애 리 이션 2에게 보내고 애 리 이션 2는

2PC를 해 비가 되었는지 체크하고 비가 끝나면 “ 비완료” 메시지를 코디

네이터 2에게 보낸다. 코디네이터 2는 “ 비완료” 메시지를 코디네이터 1에게 보

낸다. “ 비완료” 메시지를 받으면, 코디네이터 1은 “Commit” 메시지를 보낸다.

코디네이터 2는 “Commit" 메시지를 받고 애 리 이션 2에게 송한다.

애 리 이션 2는 완료하고 “Committed” 메시지를 코디네이터 2에게 보낸다.

코디네이터 2는 “Committed” 메시지를 코디네이터 1에게 보낸다. 코디네이터 1

은 2PC 테스트 과정을 완료한다. 이후 평가자와 피평가자는 결과를 검토한다.

2PC 컨텍스트 생성

- 70 -

<그림 7-4> 2PC 컨텍스트 생성 과정

2PC 컨텍스트 생성을 테스트를 한 시나리오는 <그림 7-4>와 같다. 평가자 App1

은 테스트 코디네이터를 결정하고, 코디네이터가 2PC 테스트를 한 컨텍스트를 만

들도록 요청한다. 코디네이터 1는 테스트 컨텍스트 C1을 돌려 다. 평가자 App1 은

C1를 포함한 메시지를 비하고 피평가자 애 리 이션 2에게 보낸다. 피평가자

App2 는 코디네이터 2 에게 메시지를 보내 테스트를 한 2PC 컨텍스트를 만들도

록 한다. 코디네이터 2 는 코디네이션 컨텍스트 C2를 만들고 App 2에게 돌려 다.

애 리 이션 2는 2PC를 한 로토콜을 결정하고 엔드 포인트 퍼런스를 등록

한다. 코디네이터 2의 등록서비스는 App2의 2PC용 데이터 수신 엔드포인트

로토콜을 송신하여 코디네이터 1의 등록서비스에서 등록할 수 있도록 한다. 코디네

이터 1이 이 메시지를 받고 등록을 하면 자신의 엔드포인트와 로토콜을 코디네이

터 2에게 송신하여 등록할 수 있도록 한다. 평가자는 이러한 과정을 통해 피평가자

가의 코디네이터가 2PC를 한 컨택스트를 제 로 생성하는지 테스트 한다.


비즈니스 처리 품질 테스트 방안은 다음과 같다. 테스트 하려는 웹 서비스 랫폼

에 비즈니스 로세스를 처리할 수 있는 BPH 엔진을 설치하고 구동한다. 송신 측

BPH 엔진에 미리 정의된 비즈니스 로세스 테스트 로 일을 통해서 테스트 드

라이버가 테스트 시나리오 명령을 송신자 웹 서비스에 달한다. 송신 측과 수신

측의 BPH 엔진에서 비즈니스 로세스가 처리되는 과정을 모니터링해서 Test

Driver가 로그에 장한다. 로그분석을 통해서 웹 서비스의 비즈니스 로세스 처리

- 71 -

품질에 테스트 결과를 얻어낸다. 각각의 문서 송수신 테스트를 진행하기 해서는

테스트용 XML 문서를 비하여야 하며 테스트 드라이버를 통해 로딩할 수 있도록

비하여야 한다.

7.5 리가능성 품질 테스트

리가능성 품질은 비즈니스 처리 웹 서비스 이외에 리기능을 제공하는 웹 서비

스의 존재여부와 작동여부에 련되어 있다. 리가능성 품질이 제공되고 있는지

여부 품질 수 을 테스트하기 한 테스트 아키텍처, 테스트 항목, 테스트 시나

리오, 테스트 방안은 아래와 같다.


리가능성 품질을 테스트 하기 한 아키텍처는 <그림 7-5>과 같다.

<그림 7-5> 리가능성 품질 테스트 아키텍처

리가능성은 실제 웹 서비스로 제공되게 된다. 즉, 웹 서비스를 통한 리가 가능

해지는 구조(Management Using Web Service)를 가진다. 리가능성에 련된 표

화 작업인 WSDM에서도 웹 서비스를 통한 웹 서비스의 리 방법에 해서 표

화 작업을 진행 에 있다. 본 안에서도 웹 서비스를 통해서 웹 서비스의 리하

는 방법을 사용한다. <그림 7-5>의 아키텍처와 같이 리가능성을 테스트하려는 웹

서비스의 웹 서비스 리 인터페이스를 통해서 리가능성 제공 여부와 품질 수

- 72 -

을 테스트 하게 된다. 테스트 과정에서 테스트에 필요한 테스트 로 일을 품질

리자에게 달하며 품질 리자는 입력된 테스트 로 일에 맞게 리기능을 가

진 웹 서비스를 테스트 한다. 그리고 난 뒤 테스트 결과는 보고서 형태로 외부의

리자에게 제공되어진다.


리가능성 테스트 과정에서 체크해야 하는 테스트 항목은 각 세부 품질에 해서

다음과 같은 항목이 존재한다.

7.5.2.1 WSDM 표 수성

WSDM의 Management Using Web Service(MUWS)와 Management Of Web

Service(MOWS) 표 스펙을 수해서 웹 서비스 랫폼에 한 내부 찰

성과 통지가능성을 구 했는가?

7.5.2.2 웹 서비스 내부 찰 가능성

웹 서비스의 내부 상태를 볼 수 있는 인터페이스가 존재하는가?

- 수신/송신된 메시지 량

- 웹 서비스별 평균, 최 응답시간

- 웹 서비스별 시간당 평균, 최 처리량

- 웹 서비스 상태정보 ( 시작, 지 )

웹 서비스 사용자별 이용 상태 분석 정보를 얻을 수 있는가?

- 사용자별 웹 서비스 사용 횟수 사용 시간

- 사용자별 웹 서비스 사용 빈도

- 사용자별 웹 서비스 사용 패턴

- 사용자별 웹 서비스 사용 집 도

- 기간 별 웹 서비스 사용자 수 사용 시간

- 기간 별 웹 서비스 사용 빈도

- 기간 별 웹 서비스 사용 패턴

- 기간 별 웹 서비스 사용 집 도

7.5.2.3 웹 서비스 랫폼 내부 찰 가능성

웹 서비스 랫폼에 자원(Resource)에 한 상태 정보를 얻을 수 있는가?

- CPU 상태

- 메모리 사용량

- 하드 디스크 사용량

- 73 -

- 로세스 사용량

- 쓰 드 사용량

- 네트워크 사용량

- 웹 서비스 랫폼에 한 상세정보 ( 도우의 WMI 정보, 리 스의 proc 정보

...)

7.5.2.4 웹 서비스 통지가능성

웹 서비스 내부 상태 정보가 업데이트 되는 경우 변경 다는 이벤트가 통지가

능한가?

- 내부 상태 ID와 변경된 값이 이벤트 달

웹 서비스 생명주기(LifeCycle)에 한 정보가 통지가능한가?

- 웹 서비스 시작(Start), 지(Stop), 재시작(Restart)에 한 이벤트

7.5.2.5 웹 서비스 랫폼 통지가능성

특정 자원의 사용량이 한 임계 수치(Threshold) 이상일 경우 랫폼 이상을

이벤트로 통지가능한가?


리가능성 테스트 방법은 일반 웹 서비스 인터페이스와 같이 WSDL로 정의된 웹

서비스 리가능성 인터페이스를 호출해 보고 그 결과를 장하고 장된 결과를

바탕으로 리가능성 품질 수 을 측정한다. 아래는 각 세부 품질에 따른 품질 테

스트 시나리오다.

7.5.3.1 웹 서비스/ 랫폼 내부 찰 가능성

1. 미리 장된 리가능성 로 일(웹 서비스 리가능성 WSDL의 치정보 포

함)을 통해서 내부 찰 가능성 인터페이스를 얻어낸다.

2. 개의 경우 내부 찰 가능성 인터페이스는 GetXXX()처럼 Get으로 시작하는

이름을 갖는다.

3. 리가능성 인터페이스를 통해서 웹 서비스의 내부 상태 정보를 얻어낼 수 있

는가에 한 여부를 체크한다.

4. 웹 서비스의 내부 상태 정보를 더 많이 얻어낼 수 있는 웹 서비스가 더 높은

내부 찰 가능성 품질 수 을 제공하는 것이다.

- 74 -

5. 웹 서비스 랫폼에 한 내부 찰 가능성 인터페이스도 같은 방법으로 테스트

한다.

7.5.3.2 웹 서비스/ 랫폼 통지가능성

웹 서비스 랫폼의 통지가능성은 내부 상태가 변경되었을 경우나 제어가능성

품질을 제공하는 SetXXX 타입의 인터페이스를 호출해서 웹 서비스의 내부 상태가

변경되었을 경우 외부에 있는 품질 리자나 기타 모니터 시스템에 이벤트를 달

해야 한다. 웹 서비스 랫폼에 한 통지가능성은 아래의 방법으로 테스트 할

수 있다.

1. 내부 상태 변경을 외부로 알려 수 있는 인터페이스가 존재하는지 체크한다.

2. 이벤트 달의 한 이벤트 구독, 지, 달을 한 인터페이스가 존재하는지

체크한다.

3. 웹 서비스 랫폼의 내부 상태를 강제로 변경하거나 일정 기간동안 모니터

링 한다.

4. 실제 내부 상태가 변경되었을 경우 이벤트를 달하는지를 테스트한다.


웹 서비스 리가능성 품질은 웹 서비스 도입 단계인 1단계에서는 OASIS에서 정한

웹 서비스 품질 리 표 을 참조하여, 추가 구 되어야 한다.

7.6 보안 품질 테스트

보안 품질이 제공되고 있는지 여부 품질 수 을 테스트하기 한 테스트 아키텍

처, 테스트 로세스, 테스트 항목은 아래와 같다


BLA나 SLA상에 로 일 형태로 명시된 보안 품질 벨이 명시된 로 잘 동작하

는 여부를 알기 해서는 보안 테스트와 련된 테스트 아키텍처가 필요하다. 다음

<그림 7-6> 은 웹 서비스 보안 품질 테스트 아키텍처이다.

- 75 -

<그림 7-6> 보안 품질 테스트 아키텍처

상 웹 서비스가 명시한 보안 벨이 제공되고 있는지 여부에 해 테스트를 수행

하는 테스트 수행자는 상 웹 서비스에 제시된 보안 품질 벨을 보고 테스트와

련된 보안 룰(Security Rule)을 명시한다. 설정된 보안 룰 안에는 보안 벨에 따

라 명시된 보안 로 일에 따라 어떤 항목을 검증할 것인가에 한 내용이 들어간

다. 이러한 항목에 따라 보안 테스트 드라이버(Security Test Driver)안에서는 테스

트 항목을 처리한다. 보안 테스트 로 일에는 상 웹 서비스 보안 정책에 따라

서 어떤 보안 메커니즘이 사용되고 어떤 보안 토큰이나 보안 지원수 을 요구 하는

지에 따른 테스트 방법을 설명한다. 보안 테스트 드라이버는 두 가지 입력을 통해

테스트 시나리오 따라 보안 요청 이 라인 형태로 요구되는 테스트 이스를 만

들어서 상 웹 서비스에 테스트를 수행한다. 이 게 해서 나온 결과는 다시 보안

테스트 드라이버안의 보안 결과 이 라인 형태로 분석 되어서 분석기 (Analyzer)

로 넘어가고, 분석기는 받은 정보를 상 웹 서비스가 명시된 보안 벨을 제공하

는 여부를 단한다. 한, 웹 서비스 보안 벨에 한 테스트를 수행하기 해서

는 다음의 테스트 로세스가 필요하다.

1. 보안 테스트 모델을 설정

2. 테스트 시나리오를 작성

테스트 시나리오에는 테스트 하려는 웹 서비스가 보장하는 보안 품질 벨 정보

검증할 품질 항목과 실제 테스트를 수행하기 한 필요한 정보 등을 설정한다.

이러한 설정 정보에는 보안 벨 측정 방법과 테스트 데이터의 생성 방법 등을

- 76 -

포함하여야 한다.

3. 실제 테스트를 수행하기 해 필요한 경우 인증서를 비하거나 네트워크 연결

여부와 같은 테스트 환경 구축

4. 테스트를 한 비가 완료되면 실제 테스트를 수행

5. 테스트 결과를 분석하여 명시된 보안 벨 품질의 제공 여부를 단


웹 서비스 보안 품질 테스트에 공통 으로 요구되는 사항들은 다음과 같다.

표 과의 합성

각 보안 요소들에서 용되는 기술들에 국제 국내 표 이 있는 경우에 이 표

들과의 호환성 테스트가 필요하다. 특히, 인증에 사용되는 인증서의 경우에는 국내

에서 사용되는 국내 표 인증서를 지원할 수 있어야 한다.

비도

일반 으로 암호화 벨을 의미하며, 검증된 암호 알고리즘, 충분한 키 크기, 암

호화에 필요한 라미터들의 한 사용 등에 의해 강화될 수 있다. 비도를 높이

기 해서 암호화와 자 서명 등에 사용되는 알고리즘들의 경우에는 국제 국내

에 표 안 혹은 권고안이 있는 알고리즘들을 우선 으로 용하며, 각 알고리즘에

키 크기 (Key Length) 등의 라미터 등도 이에 따른다.

- 국내 알고리즘 : SEED, HAS160 KCDSA 지원

- 알고리즘 키 크기 : SEED-128bit 권장, RIJNDAEL-128bit, 256bit 권장, 192bit

선택, TripleDes-192bit 권장, RSA-1024bit 권장 등

본 테스트 가이드라인에서는 웹 서비스 보안 로 일 WS-SProfile 0과

WS-SProfile 1에 해서만 고려한다. WS-SProfile 0은 기존의 송 벨 보안 메커니

즘(SSL/TLS, 혹은 IPSec)을 사용해서 인증, 메시지 무결성, 메시지 기 성, 근제어

서비스를 제공하며 송 벨의 DOS 공격 등을 방지하여 근성을 보장하는 보안

로 일이다. WS-SProfile 1 은 WS-SProfile 0의 송 벨의 보안 요소들에 메시

지 벨의 보안 요소들(WS-Security를 통한 메시지 벨의 인증, 메시지 무결성, 부

인방지 기 성 서비스)이 추가 으로 들어가는 보안 로 일이다.

WS-SProfile 0 과 WS-SProfile 1에 한 웹 서비스 보안 품질 테스트 항목들은 다음

- 77 -

구별 보안 요소 테스트 항목

SSL/TLS

송 벨데이터

기 성

코드 로토콜(Record Protocol) 지원 기능

Block Cipher 알고리즘의 선택 지원 기능

송 벨데이터

무결성

공개키 기반 인증서 생성 처리 기능

해쉬 함수의 선택 지원 기능

송 벨사용자 인증

공개키 인증서 기반 인증 기능

핸드쉐이크(Handshake) 로토콜 지원 기능

인증 모드 지원 기능

Stream Cipher 알고리즘 선택 지원 기능

송 벨 근제어 키 교환 알고리즘 선택 지원 기능

IPSec

송 벨데이터

기 성

암호화 로토콜 (ESP) 지원 기능

모드 지원 기능

송 벨데이터

무결성인증 로토콜 (AH) 지원 기능

송 벨사용자 인증인증 로토콜 (AH) 지원 기능


송 벨 근제어 보안 연계 (SA) 기능

TLS/IPSEC

공통 항목

송 벨 근성 패킷 단 의 공격 방지

송 벨감사 추 패킷 단 의 감사 추

보안 요소 테스트 항목

송 벨 보안 품질 평가 WS-SProfile 0 의 테스트 항목 참조

과 같다. 표 안에 있는 SSL/TLS 표 테스트 항목, IPSEC 표 테스트

WS-Security 표 테스트 항목에 한 내용은 WS-SProfile 0과 WS-SProfile 1의 테

스트 항목 뒤에 있다.

WS-SProfile 0 테스트 항목

WS-SProfile 0은 송 벨에서의 기 성, 무결성, 인증, 근제어 감사 등의 보안

요구 사항들을 정의한 보안 로 일이다. 다음은 WS-SProfile 0에서 필요한 테스트

항목이다.

<표 7-1> WS-SProfile 0 테스트 항목

WS-SProfile 1 테스트 항목

WS-SProfile 1은 WS-SProfile 0의 송 벨의 보안 요소들에 메시지 벨의 보안

요소들이 추가 으로 들어가는 보안 로 일이다. 메시지 벨에서의 보안 요소들

은 WS-Security를 바탕으로 한다. 다음은 WS-SProfile 1에서 필요한 테스트 항목들

을 정리한 것이다.

<표 7-2> WS-SProfile 1 테스트 항목

- 78 -

메시지 벨 데이터 기 성

RPC 기반의 XML 암호 복호

Messaging 기반의 XML 암호 복호

국내 암호 알고리즘을 이용한 XML 암호 복호

기능

메시지 벨 데이터 무결성, 인

증, 부인 방지

Timestamp 기능

RPC 기반의 XML 자서명 생성 검증

Messaging 기반의 XML 자서명 생성 검증

인증서 보안토큰 처리 기능

국내 표 인증서 처리 기능

인증서 유효성 검사

메시지 벨 감사 추SOAP 메시지 단 의 감사

SOAP 메시지 단 의 추


WS-SProfile 0, 1 테스트를 한 테스트 시나리오는 해당 시스템의 성격과 보안 요

구사항에 따라 유동성이 있으나, 기본 으로 다음과 같이 수행한다.

1. 테스트 항목 설정 (WS-SProfile 0 제외)

해당 시스템의 보안요구사항에 따라 테스트 항목들을 선택한다. 송 벨 보안

품질 평가, 메시지 벨 데이터 기 성, 메시지 벨 데이터 무결성/인증/부인 방

지, 메시지 벨 감사 추 항목은 테스트하여야 하며, 자서명과 암복호 조합 메

시지 처리를 한 메시지 벨 데이터 기 성, 메시지 벨 데이터 무결성/인증/

부인 방지 항목도 업무성격에 따라 선택 으로 테스트 한다. 송 벨 보안 품질

평가 항목은 송 벨 메시지 교환이 있고, 보안이 요구되는 경우 수행하여야 한

다.

2. 테스트 수행 환경 설정 (WS-SProfile 0 제외)

해당 시스템의 보안요구사항에 따라 테스트 환경을 선택한다. 기본 으로 송신자

와 수신자 노드의 테스트 환경을 설정하고, 시스템 환경에 따라 테스트 환경을 설

정한다.

3. 서명/암호 알고리즘과 비도 설정

기본 알고리즘과 비도는 반드시 만족하여야 하며, 해당 시스템 보안 요구사항에

따라 알고리즘을 추가하거나 비도를 조정할 수 있다.

4. 테스트 로그램 작성

- 79 -

상기 항목, 환경, 알고리즘 선택에 따라 테스트 로그램을 작성하여, 항목별, 환경

별로 구성한다. 알고리즘과 비도는 항목별 구성에 포함한다.

5. 테스트 검증 데이터 설정

웹 서비스 보안 테스트의 검증은 신뢰할 수 있는 검증용 출력 메시지와 테스트 시

스템에 검증용 입력 메시지를 입력시켜 나온 출력메시지와의 비교를 통해 가능하

다. WS-SProfile 1의 경우 테스트 검증을 해 상기 1과 3의 테스트 항목 알고

리즘에 한 OASIS WS-Security Spec을 만족하는 검증용 입력 값과 출력 값을 각

항목과 알고리즘 별로 DB화 한다.

6. 테스트 검증

테스트 검증은 DB화된 검증용 데이터와 각 테스트 환경에 따라 수행된 테스트 수

행 결과 메시지와의 비교를 통해 성공, 실패를 정한다.


통상 으로 보안 테스트는 테스트 하고자하는 시스템에서 정의한 보안요구사항을

기본으로 다음과 같은 테스트 방안 지침에 따라 방안을 마련한다.

7.6.4.1 WS-SProfile 0 테스트 방안

테스트 항목 선택

해당 시스템의 보안 요구사항에 따라 <표 7-1> 테스트 항목에 한 테스트를

IPSec 는 SSL/TLS 항목 하나를 기본으로 선택하여야 한다.

암호 알고리즘 선택

부록에 있는 WS-SProfile 0의 상세 테스트 항목에 있는 암호 알고리즘과 RC4,

3DES, Foreteza 국내 알고리즘인 SEED을 기본으로 하고 ,해당 시스템의 보안

요구사항에 따라 가감할 수 있다. 비도는 블록 알고리즘의 경우는 128bit를 기본으

로 하고 보안요구사항에 따라 키 길이를 증가할 수 있다.

인증 키 교환 알고리즘 선택

부록에 있는 WS-SProfile 0의 상세 테스트 항목에 있는 알고리즘과 DH, RSA,

DSA, Foreteza, MD5, SHA 국내 알고리즘인 SHA-160을 기본으로 하고, 해당

시스템의 보안 요구사항에 따라 가감할 수 있다. 비도는 공개키의 경우는 1024bit

를 기본으로 하고 보안요구사항에 따라 키 길이를 증가할 수 있다.

7.6.4.2 WS-SProfile 1 테스트 방안:

- 80 -

테스트 항목 선택

<표 7-2> 테스트 항목의 메시지 벨 데이터 기 성, 메시지 벨 데이터 무결성/

인증/부인 방지, 메시지 벨 감사 추 항목 까지 테스트를 기본으로 선택하여야

하며, 송 벨 보안 품질 평가 항목은 선택항목으로 메시지 수 으로 보안기능

을 충족하는 경우 제외할 수 있다. 더해서, 해당 시스템의 테스트 기 에 따라, 각

항목들을 조합한 메시지 보안 테스트를 수행할 수 있다. (본 문서에서는, 추가로

사용자 인증과 데이터 기 성이 동시에 용된 메시지에 한 테스트를 해 메시

지 벨 데이터 기 성, 메시지 벨 데이터 무결성/인증/부인 방지 항목이 조합

한 보안 기능 테스트도 기본 테스트 항목으로 권장한다.)

테스트 환경 선택

테스트는 송신자와 수신자 노드를 가지는 수행 환경을 기본으로 한다. 더해서, 해

당 시스템의 테스트 기 에 따라 메시지 송신자와 수신자 사이에 간 노드들을

두어 서비스를 수행하는 다 노드 수행 환경을 선택할 수 있다. (본 문서는, 추가

로 송신자와 수신자 사이에 간 노드가 1개 있는 수행 환경도 기본 테스트 환경

으로 권장한다.)

XML 암호 알고리즘 선택

메시지 벨 데이터 기 성 테스트 시, *필수 암호 알고리즘인 TRIPLEDES(192),

AES-128, AES-256과 국내 표 암호 알고리즘인 SEED, *필수 Key Transport 알고

리즘인 RSA-v1.5, RSA-OAEP는 기본 으로 테스트 되어야 한다. 더해서, 해당 시

스템의 테스트 기 에 따라 추가의 암호 알고리즘을 지정할 수 있다. (*필수 알

고리즘은 W3C XML Encryption 규격에 명시된 것임)

XML 자서명 알고리즘 선택

메시지 벨 사용자 인증 테스트 시, *필수 다이제스트 알고리즘으로 SHA1, *필수

서명 알고리즘으로 DSA, RSA, *필수 Transform인 Canonical XML, Exclusive

Canonical XML, 그리고 국내 환경을 한 서명 알고리즘인 KCDSA(Optional)와

해쉬 알고리즘인 HAS-160은 테스트 되어야 한다. 더해서, 해당 시스템의 테스트

기 에 따라 추가의 암호 알고리즘을 지정할 수 있다. (*필수 알고리즘은 W3C

XML Signature와 OASIS WS-Security 규격에 명시된 것임)

- 81 -

제 8 장 결론

본 연구에서는 웹 서비스 품질 모델과 각 품질을 테스트하기 한 테스트 가이드라

인을 제시하 다. 웹 서비스 품질 모델에서는 웹 서비스를 사용함에 있어서의 품질

에 해서 크게 사용자 계층, 상호운용성 계층, 리 보안 계층

으로 나 며 각 계층에 속하는 세부 품질로는 서비스 벨 가치 품질, 서비스 벨

측정 품질, 상호운용성 품질, 비즈니스 처리 품질, 리가능성 품질, 보안 품질의 총

6개의 품질에 해서 설명하 다. 테스트 가이드라인에서는 앞서 설명한 품질 테스

트에 한 테스트 아키텍처, 테스트 항목, 테스트 차에 한 가이드라인을 다루고

있다 .

이들 각각은 웹 서비스 개발을 발주하는 정부의 입장에서 각 웹 서비스 개발업

체에 웹 서비스 개발을 의뢰할 때 웹 서비스의 품질 요구사항을 도출하거나 품질

달성을 한 가이드라인을 제시하는데 그 목표를 두고 있다고 볼 수 있다. 한 각

웹 서비스 개발업체에서도 본 보고서에서 제시하는 품질 모델을 기반으로 웹 서비

스 개발 과정에 품질 요구사항으로 사용할 수 있을 것이다.

본 보고서에서 제시하는 품질 테스트 가이드라인은 실제 테스트를 한 구체

인 기술보다는 웹 서비스 기 도입을 활성화시키기 한 목 으로 테스트에 한

개념과 기본 구조 방법만을 제시하 다. 따라서 테스트 가이드라인 계속 인 버

업 단계를 거쳐서 보다 상세하고 구체 인 테스트 방법을 제시할 수 있는 가이

드라인으로 발 해야 한다.

결론 으로 웹 서비스 개발을 발주하는 발주기 은 본 보고서에서 제시하는 웹

서비스 품질 모델을 기반으로 품질 세부속성에 한 객 인 품질 기 을 작성할

수 있으며 품질 테스트 가이드라인을 통해서는 개발된 웹 서비스에 한 품질을 테

스트하는 방법과 테스트 항목에 한 가이드라인을 작성할 수 있다. 한 웹 서비

스 제공자는 제공하려는 웹 서비스에 한 품질 수 과 품질 수 반 시 취해야

하는 보상 내용을 계약서로 작성하는 단계에서 본 보고서가 제시하는 품질 모델

품질 테스트 가이드라인을 통해서 보다 객 이고 상호 동의 가능한 기 을 제시

할 수 있다.

- 82 -

구별보안

요소테스트 항목 테스트 세부 항목

TLS

송 벨

데이터

기 성

코드 로토콜(Record

Protocol) 지원 기능

TCP 계층의 바로 에 치하여 호스트

사이의 통신 연결 시 보안을 제공하는

기능

Block Cipher 알고리즘

의 선택 지원 기능

IDEA_CBC, RC2_CBC_40, DES40_CBC,

DES_CBC, 3DES_EDE_CBC 지원

송 벨

데이터

무결성

공개키 기반 인증서 생

성 처리 기능

서버에서의 DH 인증서, RSA 서명 인증

서, DSA 서명 인증서, 그리고 RSA 암호

화 인증서 생성 처리 기능

클라이언트에서의 DH 인증서, RSA 는

DSA 서명 인증서 생성 처리 기능

해쉬 함수의 선택 지

원 기능

Hash Function 알고리즘 (MD5, SHA-1)

지원

송 벨

사용자

인증

공개키 인증서 기반 인

증 기능

인증서들을 이용한 자 서명(RSA

DSS 서명 방식) 생성 검증 기능

핸드쉐이크(Handshake)

로토콜 지원 기능

데이터를 송하기 에 서버와 클라이

언트가 서로 인증하는 기능

사용할 암호화 알고리즘과 암호키를

상할 수 있는 기능

인증 모드 지원 기능

익명모드(An, Anonymous authentication

mode) 지원 기능

서버 인증모드(SA, Server Authentication

mode) 지원 기능

클라이언트-서버 인증모드(MA, Mutual

Authentication Mode) 지원 기능

Stream Cipher 알고리즘

선택 지원 기능RC4_40, RC4_128 지원

송 벨

근제어

키 교환 알고리즘 선택

지원 기능

DHE_DSS, DHE_DSS_EXPROT,

DHE_RSA, DHE_RSA_EXPORT,

DH_anon, DH_anon_ EXPROT,

DH_DSS, DH_DSS_EXPROT, DH_RSA,

DH_RSA_EXPROT, RSA, RSA_EXPROT

지원

SSL송 벨

데이터

지원하는 암호화 알고리

즘 기능

지원되는 암호화 알고리즘이 무엇인지 고

객에게 문서로 제출

A. 별첨 - WS-SProfile별 테스트 세부 항목

<표 A-1> WS-SProfile 0 테스트 세부 항목

- 83 -

기 성

암호화 알고리즘 작동

기능

Key 교환과 Channel이 정상 으로 암호화

되는지 확인하는 테스트

Block Cipher 알고리즘

의 선택 지원 기능

CBC(Cyclic Block Chaining) 암호 모드를

지원과 Block 암호화 알고리즘의 선택 기능

송 벨

데이터

무결성

공개키 기반 인증서 생

성 처리 기능 해쉬알고리즘의 결과는 128bit 이상을 지원

하는지 확인 (인증서를 이용하여 확인)해쉬 함수의 선택 지

원 기능

송 벨

사용자

인증

공개키 인증서 기반 인

증 기능

인증서를 이용한 자 서명 검증 기능

(어 리 이션을 통하여 실제 사용자가 인

증이 되는지 web page를 통해 확인

SSL을 이용한 어 리 이

션간의 상호 호환성 확보

Cipher suite는 [해쉬알고리즘-암호알고리

즘-키교환방법]로 구성되는데 제안한 제품

이 얼마나 다양한 cipher suite를 지원하는

가

송 벨

근제어

새로운 알고리즘 추가의

용이성

정부 기 과 같은 기 에서 제공하는 암호

화 알고리즘을 쉽게 추가하여 용할 수 있

는가

IPSec

송 벨

데이터

기 성

암호화 로토콜 (ESP)

지원 기능

암호화 기법을 사용하여 데이터의 무결성, 리

이 방지, 기 성을 보장해 주는 로토콜

로 사용하는 암호 알고리즘의 형태와 모드에

따라 인증도 가능한 기능


터 모드 ESP 기능 - (터 모드 : 일반

으로 패킷의 궁극 인 목 지와 보안

터 의 종단이 다를 때 사용되는 기능_

트랜스포트 ESP 기능 - (트랜스포트 모드

: 단 단 보안이 요구될 경우 사용되는

기능)

송 벨

데이터

무결성

인증 로토콜 (AH) 지

원 기능

IP 데이터그램을 인증하기 해 필요한 정보

를 포함하는 방법으로 데이터의 무결성 제공

하는 기능

송 벨

사용자

인증

인증 로토콜 (AH) 지

원 기능

IP 데이터그램을 인증하기 해 필요한 정보

를 포함하는 방법으로 데이터의 인증과 리

이 방지를 보장해 주는 메커니즘

모드 지원 기능터 모드 AH 기능

트랜스포트 AH 기능

송 벨

근제어보안 연계 (SA) 기능

사용된 인증 알고리즘과 모드 키 정

보, 암호 알고리즘과 모드 키 정보

리 기능

- 84 -

공유되는 SA에 한 소스 어드 스,

보호되고 있는 데이터의 보안 등 등의

정보들을 리 기능

리 인 정보에 한 근 제어 기능

TLS/

SSL,

IPSE

C공통

항목

송 벨

근성패킷 단 의 공격 방지

패킷 단 의 침입 탐지 기능

패킷 단 의 침입 차단 기능

리소스에 한 근제어

송 벨

감사

추

패킷 단 의 감사 추

패킷 모니터링 기능

패킷 로그 정보 리 기능

보안 요소 테스트 항목 테스트 세부 항목

송 벨

보안 품질

평가(1-0)

WS-SProfile 0 의 테스트 항목 참조

메시지 벨

데이터

기 성(1-1)

RPC 기반의 XML

암호 복호

SOAP Body에 체에 한 XML 암호 복호

1. 미리 공유된 비 키를 이용해 암복호하는 방

법 (ReferenceList)

2. 세션 키를 생성해 상 방의 공개키로 암호화

하여 달하여 암복호하는 방법 (EncryptedKey)

SOAP 메시지에 일부에 한 XML 암호 복

호


법 (ReferenceList)



Messaging 기반의

XML 암호 복

호

SOAP Body에 체에 한 XML 암호 복호


법 (ReferenceList)



SOAP 메시지에 일부에 한 XML 암호 복

호


법 (ReferenceList)



국내 암호 알고리 SEED 알고리즘을 이용한 XML 암호 복호

<표 A-2> WS-SProfile 1 테스트 세부 항목

- 85 -

즘을 이용한 XML

암호 복호 기능기능 (RPC Messaging)

Timestamp 기능Timestamp 생성 추출 기능 (RPC)

Timestamp 생성 추출 기능 (Messaging)

메시지 벨

데이터 무결성,

인증, 부인

방지,

(1-2)

RPC 기반의

XML 자서명

생성 검증

SOAP Body에 체에 한 XML 자서명 생

성 검증

SOAP 메시지에 일부에 한 XML 자서명 생

성 검증

다수의 메시지 부분들에 한 자서명 생성

검증

Messaging 기반

의 XML 자서

명 생성 검증

SOAP Body에 체에 한 XML 자서명 생

성 검증

SOAP 메시지에 일부에 한 XML 자서명 생

성 검증

다수의 메시지 부분들에 한 자서명 생성

검증

인증서 보안토

큰 처리 기능

Username Token 생성 처리

X.509 Certificate Token 생성 처리

Token Reference를 이용한 Security Token 참조

기능

국내 표 인증서

처리 기능

국내에서 사용 인 국내 표 인증서의 지원

기능

인증서 유효성 검

사X.509 Certificate 유효성 검사 기능

메시지 벨

감사 추 (1-3)

SOAP 메시지 단

의 감사

SOAP 메시지 싱 기능

SOAP 메시지 장 재 기능

SOAP 메시지 로그 정보 리 기능

SOAP 메시지 단

의 추

SOAP 메시지의 발신지 주소, 발신자에 한 정

보 리 기능

- 86 -

B. 별첨 - 보안 용어 설명

암호, 서명 해쉬 알고리즘

￭ SEED - TTA 표 으로 128bit을 사용하는 비 키 암호 알고리즘

￭ HAS160 - TTA 표 으로 국내 서명 알고리즘 KCDSA를 하여 개발된 해쉬

함수로 MD5와 SHA1의 장 을 취하여 설계됨

￭ KCDSA - TTA 표 으로 서명 알고리즘

￭ AES - 미 상무성 주 의 차세 암호 시스템으로 암호 알고리즘인 RIJNDAEL

이 AES로 채택된 상태

￭ TripleDES - 64bit 암호알고리즘인 DES의 비도를 높이기 해 3개의 서로 다

른 DES 키로 DES 암호,복호 암호 순으로 암호화하는 방식의 비 키 알고

리즘

￭ DSA - 이산 수 문제의 어려움을 안정성의 바탕으로 삼는 미국 연방 표

서명 알고리즘

￭ RSA - 미국의 RSA 사에서 개발된 가장 많이 사용되고 있는 공개키 기반 알

고리즘으로 부분의 응용에서 1024 비트가 표 으로 사용됨. RSA-v1.5가 안정

성에 을 받고 있어, 새로운 응용 로그램에서는 RSA-OAEP의 사용을 권

장함

SSL/TLS

TLS는 IETF Transport Area 산하 TLS 작업반에서 1996년 5월부터 진행 인 표

으로 SSL3.0을 기반으로 하며 SSL은 TLS로 체될 것으로 상된다.

TLS는 두 개의 통신응용 로그램 사이에서 개인의 정보보호와 데이터의 무결성을

제공하기 해 만들어졌고, TLS 코드 로토콜(Record Protocol)과 TLS 핸드쉐이

크(Handshake) 로토콜로 구성되어 있다. TLS 코드 로토콜은 TCP 계층의 바

로 에 치하여 호스트 사이의 통신 연결 시 보안을 제공하며, 비 성과 계 서

비스를 제공한다. 이러한 로토콜 의 하나가 TLS 핸드쉐이크 로토콜이다.

핸드쉐이크 로토콜은 서버와 클라이언트가 데이터를 송하기 에 서로 인증

할 수 있도록 해주며, 사용할 암호화 알고리즘과 암호키를 상하도록 해 다. 이

로토콜은 통신 연결 시 보안을 제공하며, 다음 세 가지 특성을 가지고 있다.

￭ 상 방의 신분은 비 칭 암호화 기법을 사용하여 인증한다.

￭ 공유 비 정보의 상은 안 하다. 연결의 간에서 비 정보가 도청될 수

없다.

￭ 상 자체가 신뢰성이 있다. 공격자에 의해 상 통신 내용이 수정될 수 없

으며, 이에 한 시도를 감지할 수 있다.

다음 그림은 TLS에서의 핸드쉐이크 로토콜의 동작 모습을 보여 다.

- 87 -

<그림 B-1> TLS 핸드쉐이크 로토콜

IPSec

IPSec은 양 종단 간의 안 한 통신을 지원하기 해 IP 계층을 기반으로 하여 보

안 로토콜을 제공하는 개방 구조의 임워크로서 IP의 취약 을 보완하기 한

보안 기능을 제공한다.

다음은 IPSec의 주요 구성 요소이다.

￭ 로토콜

▪ 인증 로토콜 (AH)

▪ 암호화 로토콜 (ESP)

￭ 데이터베이스

▪ 보안 연계 데이터베이스 (SAD)

▪ 보안 정책 데이터베이스 (SPD)

￭ 키 리 메카니즘(IKE : Internet Key Exchange protocol)

다음은 IPSec에서의 AH와 ESP가 용된 IP 페이로드의 모습이다.

- 88 -

<그림 B-2> 인증 헤더로 보호된 IP 페이로드의 구조

<그림 B-3> ESP의 구조

WS-Security

WS-Security는 웹서비스의 메시지 교환 로토콜인 SOAP을 기반으로 하며 인증,

무결성, 부인 쇄, 기 성 등의 보안 기능을 확장하여 제공하는 웹서비스 보안의 핵

심이 되는 기술로 2004년 OASIS에서 표 으로 채택되었다.

W3C의 XML 자서명 XML 암호를 확장하여 용 공개키 등의 보안정보

를 교환하기 해 다양한 형태의 보안 토큰 (Security Token)을 지원하며 재 송 공

격(replay attack) 등을 방지하기 해 타임스탬 (Timestamp) 련 기능 멀티

홉(Multi-hop)을 거쳐 달되는 SOAP 메시지의 안 한 End-to-End 송 기능을 포

함한다.

한, X.509 Certificate Token Profile은 X.509 인증 임워크를 WS-Security에

- 89 -

용하기 한 구문과 처리 규칙을 규정하고, Username Token Profile은 웹 서비스

사용자가 사용자 ID (username)로 웹 서비스 제공자에게 인증 받기 한 처리 방법

을 규정하며, 이밖에 security token과 련된 다수의 profile들에 한 표 화가 진

행 으로 아직 draft 상태이다.

아래 그림은 WS-Security를 용하여 보안 처리된 SOAP 메시지의 구조를 개략

으로 보여 다. 보호하고자 하는 메시지에 한 자서명이 XML 자서명 기법을

이용해 생성되어 SOAP-Header 내부의 Security Header 엘리먼트에 포함되고, 기

성이 요구되는 메시지에 한 암호문이 XML 암호 기법을 이용해 XML 형태의 암

호문으로 생성되어 Security Header 엘리먼트 내부 혹은SOAP-Body 내부에 포함된

다.

한 자서명을 검증하기 한 공개키 정보가 Security Header 내부의 Security

Token 엘리먼트에 포함되어 상 방에 달된다. 이와 함께 생성된 SOAP 메시지에

한 Timestamp가 SOAP-Header 내부에 포함될 수 있어 어 리 이션에서 이를

이용하여 replay attack을 감지할 수 있다.

<그림 B-4> WS-Security가 용된

SOAP 메시지의 구조

SOAP-Envelope

SOAP-Header

SOAP-Body

Timestamp

Security Header

Security Token

Cipher Data

Signature

Cipher Data

SOAP-Envelope

SOAP-Header

SOAP-Body

Timestamp

Security Header

Security Token

Cipher Data

Signature

Cipher Data

다음은 WS-Security를 용하여 보안 처리된 SOAP 메시지의 이다.

<?xml version="1.0" encoding="utf-8"?><S:Envelope xmlns:S="http://www.w3.org/2001/12/soap-envelope" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/xx/secext" xmlns:wsu="http://schemas.xmlsoap.org/ws/2002/xx/utility" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> <S:Header> <wsu:Timestamp> <wsu:Created wsu:Id="T0">

- 90 -

2001-09-13T08:42:00Z </wsu:Created> </wsu:Timestamp> <wsse:Security> <wsse:BinarySecurityToken ValueType="wsse:X509v3" wsu:Id="X509Token" EncodingType="wsse:Base64Binary"> MIIEZzCCA9CgAwIBAgIQEmtJZc0rqrKh5i... </wsse:BinarySecurityToken> <xenc:EncryptedKey> <xenc:EncryptionMethod Algorithm=

"http://www.w3.org/2001/04/xmlenc#rsa-1_5"/> <wsse:KeyIdentifier EncodingType="wsse:Base64Binary"

ValueType="wsse:X509v3"> MIGfMa0GCSq... </wsse:KeyIdentifier> <xenc:CipherData> <xenc:CipherValue> d2FpbmdvbGRfE0lm4byV0... </xenc:CipherValue> </xenc:CipherData> <xenc:ReferenceList>

<xenc:DataReference URI="#enc1"/> </xenc:ReferenceList> </xenc:EncryptedKey> <ds:Signature> <ds:SignedInfo> <ds:CanonicalizationMethod

Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> <ds:SignatureMethod

Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI="#T0"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue> LyLsF094hPi4wPU... </ds:DigestValue> </ds:Reference> <ds:Reference URI="#body"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue> LyLsF094hPi4wPU... </ds:DigestValue> </ds:Reference> </ds:SignedInfo>

<ds:SignatureValue> Hp1ZkmFZ/2kQLXDJbchm5gK... </ds:SignatureValue> <ds:KeyInfo> <wsse:SecurityTokenReference> <wsse:Reference URI="#X509Token"/> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security> </S:Header>

<S:Body wsu:Id="body"> <xenc:EncryptedData Type="http://www.w3.org/2001/04/xmlenc#Element" wsu:Id="enc1"> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#3des-cbc"/> <xenc:CipherData> <xenc:CipherValue> d2FpbmdvbGRfE0lm4byV0... </xenc:CipherValue> </xenc:CipherData> </xenc:EncryptedData> </S:Body> </S:Envelope>

<그림 B-5> WS-Security가 용된 SOAP 메시지

- 91 -

C. 별첨 - 웹 서비스 리 표 화 기술

1. ISO-9126 소 트웨어 품질 표

ISO-9126은 국제 표 화 기구인 ISO에서 정의한 소 트웨어 품질 분류 표 이다.

웹 서비스도 하나의 로그래 언어로 작성된 소 트웨어이기 때문에 소 트웨어

품질 분류가 용되어 질 수 있다. ISO에서 정의한 품질은 소 트웨어를 하나의 제

품으로 보았을 때에 제품 자체에 한 표 과 제품을 사용 시 에 사용자가 느끼는

품질에 하여 정의하고 있다. 반면 웹 서비스 품질은 제품 자체의 품질보다는 원

격에 떨어진 사용자가 사용할 때의 사용상의 품질이 더 요하다. 즉 요도에 있

어서의 의 차이가 존재한다. 본 에서는 웹 서비스 품질을 논하기에 앞서서

기존에 존재하는 가장 유사한 국제 표 인 ISO에서 정의한 소 트웨어 품질 분류

표 을 소개한다.

ISO-9126 소 트웨어 품질은 소 트웨어 즉, 일반 인 공산품이 아닌 로그래

언어로 작성되고 컴퓨터 시스템에서 실행 가능한 소 트웨어 제품에 한 품질 분

류와 각 품질에 한 명세를 정의한다. 소 트웨어 품질을 크게 2가지로 분류하고

있다. 먼 개발과정을 거쳐서 생산된 하나의 소 트웨어 제품 그 자체를 기 으로

한 제품 품질과 소 트웨어를 사용하는 사용자 에서의 소 트웨어 시스템의 품

질인 사용상의 품질로 구성된다. 아래는 제품 품질과 사용상의 품질에 한 개요와

각 품질에 속한 속성에 한 정의다.

1.1 제품 품질(Product Quality)

ISO-9126에서 정의한 소 트웨어 제품 품질은 소 트웨어 개발 과정을 거쳐서 생산

된 하나의 제품으로써의 소 트웨어 품질을 의미한다. 이러한 제품 품질은 그 제품

이 가진 특성에 의해서 달라진다. 를 들어 같은 소 트웨어라 할지라도 사용자

명령에 한 응답이 빠른 소 트웨어가 더 성능(응답시간) 품질(속성)을 가지게 된

다. 제품 품질에는 기능성, 성능, 안정성 등을 포함해서 크게 6가지의 품질로 구성

되어 있다. 하나의 품질은 하나 이상의 속성을 가지게 된다. 제품 품질은 제품 자체

를 기 으로 한 품질이며 정확히 측정될 수 있으며 제품자체를 구성하고 있는 구성

요소의 품질에 의해서 결정된다. 제품 품질은 다음과 같이 구성된다.

<그림 C-1>은 ISO-9126에서 정의한 제품 품질 분류표이다. 다음은 각 품질에

한 세부 속성과 각 속성에 한 설명이다.

- 92 -

<그림 C-1> ISO-9126 제품 품질 분류

가. 기능성(Functionality)

기능성은 소 트웨어가 특정 조건에서 특정 요구를 충족시키는 기능을 제공할 수

있는 능력을 의미한다. 기능의 제공 여부와 그 정도를 기 으로 기능성 품질이 좋

은지 혹은 나쁜지를 단한다. 기능성에서의 정의하고 있는 기능 품질 속성에는

합성, 정 성, 상호운 성, 거성, 보안성이 있다. 각각의 속성의 정의는 아래와 같

다.

합성(Suitability): 특정 작업을 처리하는 기능의 합성과 존재에 향을 미치

는 속성

정 성(Accurateness): 합의한 결과나 효과 는 명문화한 권리 조항에 향을

미치는 속성

상호운 성(Interoperability): 정해진 소 트웨어와 상호 작용하는 능력에 향을

미치는 속성

거성(Compliance): 표 , 습, 법률, 규격, 정 같은 정해진 규칙을 수하는

속성

보안성(Security): 소 트웨어의 로그램이나 데이터에 고의 의도나 사고에 의

해서 법하지 않게 근하는 것을 막을 수 있는 능력에 향을 주는 속성

나. 신뢰성(Reliability)

신뢰성은 소 트웨어가 특정 상황에서 특정 기간동안 일정 수 이상으로 동작 할

- 93 -

수 있는 능력을 의미한다. 오류나 기타 측하지 못한 상황에 해서 일정 수 의

기능을 발휘할 수 있는지에 한 품질이다. 기능 제공 그 자체 보다는 제공되는 기

능의 수 이 정해진 수 이상으로 제공되는지에 한 품질이다. 따라서 신뢰성이

높은 제품은 정해진 기간동안 믿을 수 있는 기능 수 을 수할 수 있는 제품인 것

이다. 신뢰성 품질에는 성숙도, 오류 허용성, 회복성 속성이 있다. 각각은 아래와 같

다.

성숙도(Maturity): 해결하지 못하고 남아있는 장애 때문에 생기는 장애 빈도에

향을 주는 속성

오류 허용성(Fault Tolerance): 소 트웨어에 오류가 생기거나 정해진 상호작용

방식에 문제가 생겼을 때도 최소로 정해 놓은 수 으로 동작하는 능력에 향을

미치는 속성

회복성(Maturity): 장애로 직 향을 받는 데이터를 복구하고 일정 수 이상으

로 다시 동작하는 능력과 이때 필요한 시간과 노력에 향을 미치는 속성

다. 사용성(Usability)

사용성은 특정 조건에서 소 트웨어를 쓰고 배우고 이해하기 쉽게 만드는 능력을

의미한다. 소 트웨어 제품을 사용하는 사용자가 이해하기 쉽고 빨리 배울 수 있으

며 쉽게 사용할 수 있는지에 한 품질이다. 따라서 제품 사용자입장에서는 다른

품질보다 더 요하게 여기는 품질 요소이다. 사용성 품질에는 이해성, 습득성, 운

성이 있다.

이해성(Understandability): 소 트웨어의 개념과 활용 방법을 이해하는데 필요한

사용자의 노력에 향을 미치는 속성

습득성(Learnability): 소 트웨어의 활용 방법을 배우고 익히는 데 필요한 사용

자의 노력에 향을 미치는 속성

운 성(Operability): 소 트웨어를 운 하고 리하는 데 필요한 사용자 노력에

향을 미치는 속성

라. 효율성(Efficiency)

효율성은 특정 조건에서 한 자원을 소모하면서 한 성능을 제공 할 수 있는

능력이다. 효율성 얼마나 좋은 성능을 가지는지와 시스템에 가진 자원을 보다 잘

활용할 수 있는지 즉, 시간과 자원에 한 효과 인 사용이라는 측면의 품질이다.

효율성 품질에는 시간에 련된 실행 효율성과 자원사용에 련된 자원 효율성이

있다. 아래는 각각의 설명이다.

- 94 -

실행 효율성(Time Behavior): 소 트웨어가 기능을 수행할 때 한 응답 시간,

처리 효율, 처리 시간을 제공할 수 있는 능력에 향을 미치는 속성

자원 효율성(Resource Behavior): 소 트웨어가 기능을 수행할 때 한 의

자원을 소모하는 능력에 향을 미치는 속성

마. 유지보수성(Maintainability)

유지보수성은 이미 개발된 소 트웨어를 얼마나 쉽게 수정할 수 있는지 측정한 능

력을 의미한다. 유지보수성 품질에서의 수정에는 정정, 개선, 환경변화 수용, 요구사

항 변화 수용, 기능 추가 같은 것들이 포함된다. 유지보수성이 요한 이유는 재

많은 소 트웨어들의 경우 개발보다는 개발 이후에 소 트웨어의 기능이 제 로 제

공하기 해서 지원하는 유지보수 작업의 노력이 요 시 되기 때문이다. 유지보수

성 품질에는 분석성, 변경성, 안정성, 시험성이 있다. 아래는 유지보수성 각 속성에

한 정의이다.

분석성(Analyzability): 장애 원인과 결함을 분석하고 수정해야 할 부분을 찾아내

는 데 필요한 오력에 량을 미치는 속성

변경성(Changeability): 소 트웨어를 수정할 때, 장애를 제거할 때, 소 트웨어

동작 환경을 변경할 때 드는 노력에 향을 미치는 속성

안정성(Stability): 수정으로 상하지 못한 문제가 발생할 험에 향을 미치는

속성

시험성(Testability): 수정된 소 트웨어를 검증하는데 필요한 노력에 향을 미치

는 속성

바. 이식성(Portability)

이식성은 소 트웨어가 다른 환경으로 이식될 수 있는 능력을 의미한다. 여기서의

다른 환경은 소 트웨어가 실행하기 한 실행 환경을 가진 운 체제, 시스템을 포

함하는 런타임 환경을 의미한다. 이식성 품질이 요한 경우는 개발 완료된 소 트

웨어 제품을 실제 사용 고객의 시스템에 배포하거나 서비스 제공을 해서 설치할

경우에 요하게 작용된다. 이식성 품질에는 응성, 설치성, 일치성, 체성이 있

다.

응성(Adaptability): 원래 필요한 작업이나 방법만 써서 소 트웨어가 동작하는

환경을 바꿀 수 있는 가능성에 향을 미치는 속성

설치성(Installability): 특정 환경에 소 트에어를 설치할 때 필요한 노력에 향

을 미치는 속성성

일치성(Conformance): 소 트웨어가 이식성과 련된 표 이나 례를 잘 따르

- 95 -

는지를 나타내는 속성

체성(Replaceability): 상 소 트웨어를 특정한 다른 소 트웨어로 바꿔서 쓸

수 있는지를 나타내는 속성

1.2 사용상의 품질(Quality in Use)

사용상의 품질은 소 트웨어의 사용자 에서의 소 트웨어 시스템의 품질을 의

미한다. 따라서 소비자 개인의 욕구를 잘 충족시켜주는 제품과 서비스가 가장 좋은

제품 과 서비스가 사용상의 품질이 높다고 할 수 있다. 사용상의 품질은 제품 품질

과는 다르게 소 트웨어 자체의 특징으로 측정되기 보다는 소 트웨어를 사용함으

로써 나오는 결과를 바탕으로 품질을 측정한다. ISO-9126에서 정의한 사용상의 품

질은 크게 4가지로 구성되며 <그림 C-2>와 같다. 아래는 각 품질에 한 설명이다.

*출처: ISO-9126

<그림 C-2> ISO-9126 사용상의 품질 분류

가. 효율성(Effectiveness)

효율성은 소 트웨어가 사용하려는 특정한 용도에 정확하고 완벽하게 충족되는지에

한 능력에 한 품질이다.

나. 생산성(Productivity)

생산성은 시간, 노력, 물질과 경제 인 비용을 포함해서 시스템과 사용자에게 제공

되어 질 수 있는지에 한 능력에 한 품질이다.

다. 안정성(Safety)

안정성은 사용상의 불편 요소를 이거나 특정상황에 한 피해를 받아들일 수 있

는 정도로 일 수 있는 능력에 한 품질이다.

라. 만족성(Satisfaction)

만족성은 특정 소 트웨어를 사용하는 특정 사용자가 그 소 트웨어를 사용하고 나

- 96 -

서 얼마나 욕구가 만족했는지에 한 품질이다.

2. W3C 웹 서비스 리 모델

W3C의 리 모델은 웹 서비스 리의 아키텍처 측면의 리 메타 모델을 정의한

다. <그림 C-3>은 W3C 리 모델의 개념과 개념들이 계를 묘사한 그림이다. 아

래는 각 개념과 계들의 설명이다.

*출처: W3C Management Model

<그림 C-3> W3C 리 모델

W3C의 리 시스템은 모니터링을 한 이벤트 메시지를 받거나 리 조정을 한

이벤트 메시지를 시스템에 보낸다. 이러한 이벤트는 서비스 상태 변화나 리 요청

을 처리할 때 발생한다. 한 이벤트는 자원의 리 인터페이스를 통해서 리 정

보를 제공한다. 리 가능한 자원은 하나의 물리 인 자원이며 품질 련 Metric, 구

성상태, 생명주기, URI로 표 되는 고유 식별자를 가진다. 자원 리는 리 인터페

이스를 통해서 이루어지며 리 인터페이스는 URI로 표 되는 인터페이스와 자원

에 한 리 정보로 이루어져있다. W3C의 리 모델은 웹 서비스를 앞서 설명한

리 가능한 자원으로 표 한다.

3. HP WSMF 웹 서비스 리 임워크 표

- 97 -

HP는 웹 서비스 기반의 웹 서비스 리 임워크를 <그림 C-4>와 같이 정의한

다. 이 임워크는 기존의 웹 서비스를 바탕으로 웹 서비스를 사용한 웹 서비스

리에 을 둔다. WSMF(Web Service Management Framework)는 WS-Events,

WSMF-Foundation, WSMF-WSM 이 게 3부분으로 구성된다. 아래는 각각에 한

설명이다.

<그림 C-4> WSMF의 리 구조

WSMF Events

WSMF Events는 웹 서비스 리의 기본인 XML구조의 웹 서비스 이벤트를 정의한

다. 재 WS-Events는 2.0 버 까지 표 화 되었다. 웹 서비스 이벤트 고, 구독,

생성, 소비에 한 인터페이스 처리 룰로 구성되어 있다. 이러한 이벤트는 이벤

트 통지 서비스를 통해서 생산자에서 소비자에게 Push나 Pull의 방식으로 동기 혹

은 비동기 달 모델을 사용한다.

WSMF Foundation

WSMF Foundation에서는 리 가능한 자원을 정의하며 웹 서비스를 통한 리가

어떻게 표 되는지를 정의한다. 웹 서비스 통한 리 가능한 자원의 표 리인터

페이스를 정의하며 리 가능한 자원을 어떻게 찾는지, 리 가능성을 어떻게 기술

하는지, 다른 자원들을 어떻게 조합하는지를 기술한다. 그밖에 리 가능한 자원의

생명주기, 계, 에러 처리에 한 부분을 정의한다.

WSMF WSM

WSMF WSM은 WSMF Foundation을 웹 서비스에 용한 사례이다. 즉 WSMF를

사용하여 웹 서비스를 통한 웹 서비스 리에 한 리 인터페이스를 정의한다.

- 98 -

WSMF WSM은 웹 서비스 자체 한 Service, 웹 서비스 랫폼과 실행 환경에

한 WSExecutionEnvironment, 웹 서비스들로 교환되는 메시지의 컨텍스트 정보를

리하는 Conversation이 있다.

4. IBM WS-Manageability 웹 서비스 리 표

IBM의 WS-Manageability는 웹 서비스 리가능성에 한 메타 모델을 정의하며 이

러한 웹 서비스 리가능성을 지닌 웹 서비스를 리 가능한 웹 서비스로 정의하고

있다. 한 웹 서비스 리가능성을 통해서 리되는 웹 서비스 리 명세 스택을

정의하고 있다. <그림 C-5>는 IBM의 WS-Manageability에서 정의한 리 가능한 웹

서비스의 리 메타 모델이다. WS-Manageability의 리 메타 모델은 웹 서비스를

기반으로 웹 서비스 리 가능성을 5개의 Topic과 각 Topic에서 고려해야 하는 3가

지 측면으로 정의한다. Topic에는 Relationship, Identification, Sate, Configuration,

Metrics이 있으며 Aspect에는 Property, Operation, Event가 있다. 아래는 각 Topic

과 각 Topic에서 고려해야 할 측면에 한 설명이다.

*출처: WS-Manageability Management Meta Model

<그림 C-5> WS-Manageability 리 메타 모델

4.1 Topic

Topic에서는 리 객체가 가져야 하는 5가지의 특성 오퍼 이션에 해서 정의

한다. 리자는 이러한 특성, 오퍼 이션을 통해서 리 객체를 리한다. 각 Topic

은 아래와 같다.

Identification: 리되는 자원에 한 유일하게 구분 지을 수 있는 정보를 의미

한다. 이러한 정보에는 로퍼티, 기술 인 정보, 의미 인 정보를 포함한다.

- 99 -

State: 실제로 운 하는 생명주기에서 Up and down과 같은 자원 상태이다.

Configuration: 자원이나 리자에 의해 변화되는 로퍼티의 집합을 리하는

정보를 의미한다.

Metrics: 성능에 련된 정보( 를 들어 서비스 수행의 평균 응답 시간)에 한

리 정보를 정의한다. Metric의 기능에는 Metric 기화 오퍼 이션, Metric 수

집 오퍼 이션, 특정 시 에서의 Metric의 값을 얻어내는 오퍼 이션 등이 있다.

일반 으로 Metric의 값은 스트링이나 숫자로 표 된다. 한 Metric은 성능에

한 성능 계산 공식을 포함한다.

Relationships: 자원들 간의 계에 한 정보를 의미하며 자원과 다른 자원과의

계를 Query하는 오퍼 이션을 제공한다. 이러한 계 정보는 Problem

Isolation, 주요 원인 분석 등에 사용된다.

4.2 Aspect

Aspect는 리 객체가 에 5가지 리 Topic을 제공하는 방법이다. 따라서 리

객체는 각 Topic에 해서 다음의 3가지 측면의 방법으로 리자에게 리 가능성

을 제공해야 한다.

Properties: 로퍼티는 자원에 한 상태 정보를 고하거나 표면화하는 방법을

제공한다. 로퍼티의 타입은 단순 타입이거나 복합 타입일 수 있다. 로퍼티는

get/set operation과 같은 리 인터페이스로 정의 되는 오퍼 이션으로 근한

다.

Operations: 오퍼 이션은 자원을 조정하거나 상태정보를 근하는 방법을 제공

한다. 오퍼 이션을 통해서 웹 서비스의 행 가 변하게 된다.

Events: 이벤트는 자원 측면의 변화를 의미한다. 이벤트는 변화하는 정보의 집합

을 기술한다. 이벤트의 정보구조는 다양한 이벤트 정보를 표 하기 해서 복합

타입으로 정의한다. 이벤트는 공지 서비스를 통해서 리자에게 달된다.

앞서 설명한 웹 서비스 리가능성은 웹 서비스 리 명세 스택의 리 가능성 기

술 계층에 입된다. 즉 웹 서비스 리 구조에서 웹 서비스 리가능성을 정의하

는 구체 인 방법이 된다. <그림 C-6>은 IBM에서 제시하는 웹 서비스 리 명세

스택이다. 아래는 각 리 계층별 리 명세이다.

- 100 -

<그림 C-6> IBM의 리 명세 스택

Description 계층: 웹 서비스 리 표 기술에 한 일반 인 메커니즘을 제공

하는 계층이다. 이러한 웹 서비스 리 표 에는 WSDL에서 정의하는 서비스,

종단, 인터페이스, 주소, 속성, 속성에 정의되는 메타데이터, 웹 서비스 종단 시

스템과 다른 자원 사이의 계를 정의하는 릴 이션쉽, WS-Policy를 정의한

Policy, WS-Security를 정의한 Security, WSDM WS-Change Requirements에 의

해 정의된 Change가 있다.

Common Web Service Interface계층: 웹 서비스 리를 한 일반 인 유틸리티

를 정의한다. 일반 인 유틸리티에는 Notification, Address Resolver, 서비스의

컬 션을 찾을 수 있는 Collection, 릴 이션쉽 장소에 근하고 계를 정의

할 수 있는 Relationships, 이벤트를 장 할 수 있는 Logging, Policy 장소가

있다.

Manageability Description계층: 리 정보를 포함한 리 명세를 한 모델을

정의한다. <그림 3-5>의 웹 서비스 리가능성 모델을 명세 하는 계층이다. 리

명세에는 품질 련 측정값인 Metric, 구성과 구성 리의 집합의 표 인

Configuration, 자원의 상태와 변이 모델인 Resource State Model, XML 기반의

리 이벤트 형식이 있다.

Manageable Resource계층: 웹 서비스를 통해서 리 가능한 자원들의 리 메커

니즘, 기술 메커니즘을 어떻게 정의하는지 기술한다. 리 상에는 리 가능한

자원과 리 가능한 웹 서비스 자원이 포함된다.

Policies/Agreements 계층: 웹 서비스 제공자와 웹 서비스 클라이언트 사이의

리 상 자원과 계약을 정책들을 어떻게 정의 하는지 기술한다. 기술 상은

- 101 -

WS-Policy를 사용한 리 표 정책 템 릿, 보안 정책 명세, 서비스 품질 계약

을 기술이 있다.

Management Application계층: 리 정보, 리 서비스들을 사용하는 리 어

리 이션이 속한다. 이러한 리 어 리 이션은 리자 인터페이스(Manager

Interface)를 정의한다.

5. OASIS WSDM 웹 서비스 분산 리 표

OSAIS에서 기존의 WSMF와 WS-Managebility를 통합해서 WSDM이름의 웹 서비스

분산 리에 한 표 을 2004년 12월 재 1.0까지 완성했다. WSDM 표 은 원격

에서 웹 서비스를 이용해 리소스를 리하는 표 인 MUWS(Management Using

Web Service)와 웹 서비스를 통해 웹 서비스를 리하는 표 인 MOWS

(Management Of Web Services)를 정의하고 있다. MUWS가 웹 서비스를 이용해

다양한 리소스를 리하는 일반 인 표 이라면 MOWS는 MUWS를 기반으로

다른 웹 서비스를 리하기 한 웹 서비스 리를 한 표 이라 볼 수 있다.

5.1 MUWS (Management Using Web Services)

MUWS는 IT 리소스를 웹 서비스를 통해 원격으로 리할 수 있는 표 을 정의한

다. <그림 C-7>은 보면 MUWS가 IT 리소스를 리 하기 해 두 가지 방법을 쓰

는 것을 볼 수 있다. 웹 서비스를 이용하는 방법과 에이 트를 사용하는 방법이다.

아래는 각 리소스 리 방법에 한 설명이다.

*출처: OASIS WSDM

<그림 C-7> MUWS를 이용한 IT 리소스 리

- 102 -

첫째 방법은 IT 리소스를 웹 서비스를 통해 직 리하는 것이다. 웹 서비스는 리

소스를 리하기 해 리소스에서 제공하는 리 인터페이스를 이용한다. 를 들

어 Java에서 제시하는 리 표 인 JMX 인터페이스를 이용 하거나 C API 인터페

이스를 이용해 IT 리소스를 리할 수 있다.

둘째 방법은 IT 리소스를 에이 트를 통해 간 으로 리하는 것이다. 이 경우

에이 트가 리소스를 직 리 하거나 는 에이 트가 다른 에이 트를 통해

간 으로 리소스를 리할 수 있다.

이 게 두 가지 방법으로 MUWS는 웹 서비스를 통해서 IT 리소스를 리하는

방법을 정의하고 있다. 즉, 웹 서비스의 리 가능성이라는 품질 요소를 제공하는

것이다. 리가능성은 여러 기능으로 나 어져 있고 각 기능은 의미 으로 서로 구

별된다. <그림 C-8>은 리 가능한 IT 리소스에 웹 서비스 아키텍처를 어떻게 용

하고, 어떻게 리 기능을 제공 하는 가를 보여 다.

*출처: OASIS WSDM

<그림 C-8> MUWS의 개념

IT 리소스는 Java의 JMX나 C API 등과 같은 리 인터페이스를 통해 리 가능한

리소스가 된다. MUWS는 기존 웹 서비스 아키텍처에 리 가능한 인터페이스,

리가능한 서비스, 리 가능한 엔드포인트를 정의한다. <그림 3-8>에서 보는 것와

같이 하나의 리 가능한 엔드포인트는 리 가능한 서비스와 인터페이스를 갖는

다. 리 가능하다는 것은 서로 구별되는 리 기능을 제공하고 이 리 기능을 합

쳐 하나의 웹 서비스로 제공 한다는 것을 의미하는 것이다.

MUWS의 논리 개념

리자는 IT 리소스를 리하고자 하는 사용자이고, 리 기능 제공자는 MUWS에

- 103 -

서 정의하는 웹 서비스 형태로 IT 리소스에 한 리 기능을 제공하는 사용자이

다. 리자는 IT 리소스를 리하기 해 리 엔드 포인트에 근해 리 기능을

사용하게 된다. 리 엔트포인트는 직/간 으로 IT 리소스에 한 리 인터페

이스를 제공하고 리자는 IT 리소스를 리할 수 있게 된다. <그림 C-9>는 리

기능 제공자가 제공하는 MUWS 기반의 웹 서비스를 통해 어떻게 IT 리소스를

리 하는가 하는 지를 보여 다.

*출처: OASIS WSDM

<그림 C-9> MUWS의 논리 모델

MUWS 로세싱 모델

MUWS의 로세싱 모델은 웹 서비스의 기본 로세싱 모델의 개념을 벗어나지 않

는다. 웹 서비스의 기본 로세싱 모델에서 소비자는 UDDI와 같은 장소를 통해

WSDL 문서를 찾는다. 소비자는 WSDL 문서를 기반으로 서비스 제공자가 제공하는

웹 서비스에 근해 웹 서비스를 호출함으로서 웹 서비스를 사용하게 된다.

MUWS의 로세싱 모델도 웹 서비스 아키텍처의 기본 로세싱 모델을 크게 벗

어나지 않는다. 리 기능 제공자는 리 가능한 IT 리소스를 MUWS 기반의 리

웹 서비스를 제공한다. 리자는 리 WSDL 문서를 얻어 리 가능 웹 서비스와

통신하게 된다. 리자는 리 가능 엔드포인트를 통해 IT 리소스를 제어하기도 하

고 리소스에 한 정보를 얻기도 한다. <그림 C-10>은 MUWS 로세싱 모델을 보

여 다.

- 104 -

*출처: OASIS WSDM

<그림 C-10> MUWS의 로세싱 모델

리 가능한 인터페이스

MUWS에선 웹 서비스를 통해 리 기능을 제공하기 해 가장 기본 인 인터페이

스에 한 표 을 제안하고 그 인터페이스를 확장해 사용할 수 있도록 하고 있다.

<그림 3-11> 리 가능한 인터페이스(Manageability Description)는 기본 으로 리

소스에 한 ID, 리소스의 상태정보, 리소스 각 기능에 한 매트릭을 정의한다.

Manageability Ddescription은 WSDL 표 에 의해 Quality Description을 제외한

Functional Description과 같은 형태로 정의된다. 하지만 Manageability

Description은 WSDM 표 에 의해 미리 정의된 Manageability Interface를 갖는다.

WSDM에선 WS-Properties에서 제공하는 웹 서비스 로퍼티 기능을 사용하고 있

고, Manageability Interface는 WSDM에서 정의한 로퍼티 타입과 그에 한 기능

정의로 구성된다. Manageability Interface는 Identity Property 타입, Resource State

Property 타입, Metric Property 타입과 그에 련된 기능 정의로 나 어진다.

Identity Property 타입은 Manageability Endpoint가 리하고자 하는 리소스에

한 Id, 이름, 버 정보가 있고, Resource State Property 타입은 리소스의 여러

- 105 -

상태 정보를 나타내고 Manageability Endpoint가 리하는 리소스를 시작하고 단

하는 기능을 제공한다. Metric Property 타입은 리소스의 여러 Metric 정보를 나타

내 다. Metric은 크게 두 종류가 있는데, 기간으로 표 되는 Duration Metric과 단

순 수치로 표 되는 Integer Metric이 있다. <그림 C-11>은 앞서 설명한 리가능성

인터페이스를 클래스 다이어그램으로 보여 다.

<그림 C-11> 리 가능한 인터페이스

Manageability Interface

+Start()+Stop()

muws-xs:ResourceStatePropertiesType-ResourceId-Name-Version

muws-xs:IdentityPropertiesType

+ResetAll()

muws-xs:MetricsPropertiesType

1-Identity 1

1

-ResourceState 1

1

-Metrics 1

-State-TimeEntered

muws-xs:StateInformation

1

-ResourceState *

muws-xs:IntegerMetric

-ResetAt-LastUpdated-ChangeType-TimeScope

muws-xs:MetricAttributes

muws-xs:DurationMetric

1

*

1

*

Manageability Web Service

Manageability Description

1

*

1 *

*

-has*

Manageability Endpoint

1

*

Manageable Resource *

-provides access to

*

리소스 상태

Manageability Endpoint를 통해 리하는 웹 서비스 는 리소스는 여러 상태로

이될 수 있다. 리소스가 정상 으로 서비스 일 때는 Available 상태이고, 서비스

를 지 했을 땐 Unavailable 상태가 된다. 이 둘 사이엔 Start, Stop 메소드를 사용

- 106 -

해 Quality Manager가 이시킨다. 만약 리소스가 비정상 상태로 들어가 체 는

일부 서비스를 제공할 수 없는 상태가 될 때 Degraded 상태가 된다. Service

Creator는 이 세 가지 상태 외에 여러 다른 상태를 추가할 수 있다. <그림 C-12>은

Functional Endpoint의 기본 상태 이에 해 보여 다.

*출처: OASIS WSDM

<그림 C-12> 리소스 상태

5.2 MOWS (Management Of Web Services)

MUWS가 웹 서비스를 통해 IT 리소스를 리하는 표 이라면 MOWS는 MUWS를

기반으로 웹 서비스를 통해 다른 웹 서비스를 리하는 표 이다. MOWS는

MUWS를 기반으로 하고 있기 때문에 리 하는 리소스가 웹 서비스라는 것만을

제외하곤 MOWS와 동일하다. 다음 <그림 C-13> MOWS 아키텍처는 MOWS가

리하는 기능 웹 서비스와 MOWS가 제공하는 리 웹 서비스의 아키텍처를 보여

다.

리자가 웹 서비스 소바자에게 제공하는 웹 서비스를 기능 웹 서비스라고 하고

이 웹 서비스는 웹 서비스 스텍 표 을 따른다. 웹 서비스 제공자는 기능 웹 서비

스를 리하기 해 리 MUWS에서 정의하는 리 웹 서비스를 제공하고 리자

는 리 웹 서비스를 통해 기능 웹 서비스를 제어하고 기능 웹 서비스에 한 리

정보를 얻게 된다.

- 107 -

*출처: OASIS WSDM

<그림 C-13> MOWS 아키텍처

6. IBM WSLA 웹 서비스 품질 계약 표

웹 서비스 품질 계약에 한 표 화 동향에는 2001년 IBM에서 개발한 WSLA(Web

Service Language Agreement)가 있다. WSLA는 웹 서비스 사용에 있어서 웹 서비

스 제공자와 사용자들의 의무사항(Obligations)들을 정의한 합의(Agreement)문서이

다. WSLA에서 주로 명세화한 품질은 웹 서비스에 한 IT- 벨의 서비스 라미터

들( 를 들면 이용가능성, 응답시간, 처리량 등)과 서비스 라미터를 수하기 한

서비스 제공자의 의무사항(Obligations)을 명시하고 있다. WSLA는 <그림 C-14>와

같이 Parties, Service Description, 그리고 Obligations 부분으로 구성된다. 아래는

각 부분에 한 설명이다.

- 108 -

<그림 C-14> WSLA 구조

Parties

Parties는 비즈비스 계약에 련되는 모든 련된 기업체(Parties)들을 기술하는 부

분이다. Parties에는 Signatory Parties와 Supporting Parties가 포함된다. Signatory

Parties는 비즈니스 계약에 련 서비스 제공자와 서비스 사용자를 의미한다. 서비

스 제공자와 서비스 요청자의 회사 정보와 기술 인 특징, 를 들어 그들의 인터

페이스 정의나 주소들을 기술한다. Supporting Parties는 서비스 제공자와 요청자의

품질 리를 지원하는 제 3의 기 을 의미하며 Supporting Parties부분에는

Supporting Parties의 회사 정보 외에 어떤 서비스 제공자 혹은 서비스 사용자로부

터 임을 받아서 서비스 리를 하는지에 한 리정보가 기술된다.

Service Description

Parties부분 다음에는 계약의 주체가 서비스에 한 내용을 기술하는 부분인

Service Description이 있다. Service Description은 서비스 제공자가 구 하는 서비

스 오퍼 이션, SLAParameter, Metric에 한 내용을 명시한다. 서비스 오퍼 이션

에는 리의 상이 되는 서비스 오퍼 이션을 명시한다. SLAParameter는 품질의

항목을 명시한다. 를 들어 신뢰성과 같은 웹 서비스 품질의 항목을 명시한다.

SLAParameter로 명시된 웹 서비스 품질 항목은 Metric으로 표 된다. Metric은

SLAParameter로 명시된 품질 항목을 어떻게 계산해 내는지에 한 공식을 명세화

한다. 품질 리에 있어서 실제 Metric에서 정의하는 방법으로 품질 수 을 측정한

다. Metric은 Metric의 값을 구하는 방법에 따라서 MeasurementDirectives와

Function의 하 Metric으로 나 어진다. MeasurementDirectives는 Metric의 값을

얻을 수 있는 기 혹은 서비스 제공자로부터 라미터 값을 측정하는 방법에 해

- 109 -

서 정의하며 Function은 다른 Metric의 값의 연산으로부터 Metric의 값을 계산하는

방법을 정의한다. 즉, Function부분이 웹 서비스 품질에 한 공식으로 매핑된다.

Obligations

Obligations에는 서비스 제공자의 의무사항인 Service Level Objective를 보장하기

한 웹 서비스 품질 수 과 품질 리를 지원하는 기 (서비스 제공자 혹은 제3

기 )의 의무사항을 보장하기 한 Action Guarantee에 한 내용을 정의한다.

7. OASIS ebXML Test Framework 표

ebXML 테스트 임워크는 OASIS가 발표한 ebXML 표 합성 상호운용성

시험인증의 표 기술로 여러 시험인증 기 에서 활용되고 있다. 이것은 ebXML 표

명세서에 기반한 표 합성 상호운용성 테스트 방법을 정의하고 있고, 테스

트 임워크는 테스트 드라이버와 테스트 서비스로 구성된 컴포 트와 테스트

이스를 정의한 테스트 슈트문서( 로 일 문서, 요구문서, 테스트 이스 문서)로 구

성되어 있다.

테스트 차

○ 제 1단계 : 검사 계획 단계(권고사항)

○ 제 2단계 : 검사 요구사항 설계 단계(필수사항)

○ 제 3단계 : 테스트베드 구성 단계(필수사항)

○ 제 4단계 : 테스트슈트 설계 단계(필수사항)

○ 제 5단계 : 테스트슈트 검증 단계(권고사항)

○ 제 6단계 : 테스트수행 단계(필수사항)

테스트 임워크 컴포 트

○ 테스트 드라이버: 테스트 드라이버는 테스트 이스의 각 단계를 실행하는 컴포

트이다. 테스트베드에 따라 컴포 트 구성이 다르지만 다른 컴포 트와 상호작용

함으로써 테스트 이스를 구동한다.

○ 테스트 서비스: 테스트 서비스는 MSH(Messaging Service Handler)에 의해 수신

된 메시지를 받아서 메시지의 서비스와 액션에 한 정보를 추출하고, 추출된 정보

를 통해 특정 역할을 수행한다. 한, 미리 정의된 액션에 따라 MSH가 기능을 수

행하게 한다.

○ 테스트 슈트: 테스트슈트는 테스트 드라이버 설정 데이터, 사용되는 문서, 테스

트 이스들을 모아놓은 것으로, XML로 작성된 테스트 슈트의 구성은 로 일 문

서, 요구사항 문서, 테스트 이스 문서로 나 어진다.

- 110 -

ebXML기반 자상거래 시스템간의 호환성을 해 OASIS는 ebXML 테스트 임

워크를 발표하여 표 합성 상호운용성에 한 시험인증 기술과 방법을 제공하

고 있다. 이를 기반으로 미국, 아시아, 유럽 등에서 표 합성 상호운용성 시험

환경을 구축하여 왔으며 국제 컨소시엄을 구성하여 상호운용성 확보를 해 노력하

고 있다. ebXML 표 명세서 에서 CPPA, RS, RIM, BPSS의 표 합성 상호

운용성에 한 연구가 더욱 더 활발히 진행되어야 하며, 상호운용성 시험방식도 수

동 인 방식보다 자동화를 한 다양한 개선 방안이 필요하다.

- 111 -

연구 책임자 : 이 헌

(정보화기술기획 장, 02-2131-0446,[email protected])

웹서비스 품질 모델 테스트 가이드라인 연구

2004년 12월 인쇄

2004년 12월 발행

● 발행인 : 서 삼 영

● 발행처 : 한국전산원

경기도 용인시 수지읍 죽전리 168

전화 : 031-260-2114

● 인쇄처 : 한올

전화: 02-2279-8494 <비매품>

1. 본 연구보고서는 정보통신부의 출연 으로 수행한 정보통신

연구개발사업의 연구결과입니다.

2. 본 연구보고서의 내용을 발표할 때에는 반드시 정보통신부

정보통신연구개발사업의 연구결과임을 밝 야 합니다.

웹 서비스 품질 모델 및 테스트 가이드라인...

Documents