speclogo

IMS 웹서비스 - WSDL 바인딩 가이드
발행일 2009년 00월 00일
최신 버전 IMS 웹서비스 – WSDL 바인딩 가이드 버전 1.0
이전 버전
IPR 및 유포에 관한 공지사항 이 표준을 활용하는 이는 표준을 적용하면서 인지하게 된 관련 특허 또는 지적재산권의 침해 가능성 사실을 코멘트와 함께 문서의 형태로 제공해야 한다. IMS는 이 문서에 명시된 기술의 적용 또는 활용과 관련된 지적재산권 또는 기타 권리의 적용범위와 유효성에 대한 입장, 또는 그러한 권리와 관련하여 어느 정도까지 허용될 것인지에 대한 입장을 표명하지 않는다. 뿐만 아니라, 그러한 권리를 파악하는 노력을 기울였다는 사실 또한 명시하지 않는다. IMS 표준에 명시된 권리와 관련하여 IMS 절차에 관한 정보는 IMS 지적재산권 웹 페이지1)를 참조할 수 있다.

Copyright © IMS Global Learning Consortium 2007. All Rights Reserved.

이 표준을 배포하거나 제품 또는 서비스 제공을 위해서 활용하고자 한다면, IMS Korea 표준화 포럼 사무국(한국교육학술정보원)에 승인 요청을 하고 이메일을 통해 승인을 받아야 한다. IMS 정식회원 및 기부회원, 개발자 네트워크는 상기의 저작권 공지사항과 이 문장을 사본에 포함시키는 조건 하에 이 표준을 배포 및 활용할 수 있다. 그러나 저작권 공지사항 또는 IMS 명칭이 표기된 부분을 삭제하는 등, 이 표준을 훼손하는 행위는 금지된다. 단, IMS가 승인한 프로젝트그룹의 감독 하에 IMS 표준을 수정하는 경우는 예외적으로 허용된다. 상기 부여된 제한된 승인 내용은 영속적이며, IMS 또는 후임기관 그 누구라도 라이센스를 취소할 수 없다. 이 표준은 어떠한 보증도 하지 않으며, 특히 불침해에 대한 그 어떤 보증도 하지 않는다. 이 표준의 사용에 대한 책임은 온전히 사용자에 의하며, 그 어떤 컨소시엄이나 제공 주체도 이 표준을 사용함으로써 제3자가 직간접적으로 입을 수 있는 피해에 대해 책임지지 않는다.

Copyright © 2007 by IMS Global Learning Consortium, Inc. All Rights Reserved.

1)IMS 지적재산권 웹 페이지 : http://www.imsglobal.org/ipr/imsipr_policyFinal.pdf
원안작성 협력기관 : 한국교육학술정보원(IMS Korea 표준화 포럼)
성 명 근 무 처 직 위
(위 원 장) 황대준
성균관대학교
 교수
(실무위원) 김성윤
(주)포씨소프트
 이사
김 현
(주)씨티유니온
 차장
유욱종
(주)다울소프트
 부장
조성현
테크빌닷컴(주)
 부사장
조용상
한국교육학술정보원
 팀장
차남주
(주)디유넷
 부사장
최성기
SK C&C
 과장
(자문위원) 권희춘
수원여대
 교수
김종현
계원디자인예술대학
 교수
김현진
한국교원대학교
 교수
손진곤
한국방송통신대학교
 교수
정광식
한국방송통신대학교
 교수
한태인
(주)메디오피아
 부사장
(간 사) 신성욱
한국교육학술정보원
 연구원
목 차

머 리 말

이 표준은 한국의 이러닝 분야 디지털 콘텐츠의 공유 및 유통 체제 확립을 위해 IMS Global Learning Consortium(이하 GLC)의 General Web Service 표준을 기초로 작성한 IMS Korea 단체표준이다. 이 표준은 한국의 문화적, 교육적, 언어적 특수성 등을 감안하여 현지화 등 확장을 고려하여 작성되었다. 또한 이 표준을 실제 구현할 때 부분적으로 선택하여 적용할 수 있도록 필수와 선택 영역이 구분되어 있으므로 목적에 따라 선별적인 적용이 가능하다. 이 표준은 IMS GLC 표준 개발 과정에서 웹 서비스를 사용하려는 프로젝트 팀들에게 지침을 제시할 수 있는 프레임워크를 제공하기 위한 목적으로 개발되었다. 따라서 이 표준은 5가지 요건 즉, 상호운용성(Interoperability), 효율성(Efficiency), 일관성(Consistency), 유연성(Flexibility), 실용성(Practicality)을 충족하는 방법론과 어플리케이션 프로파일을 제공한다. 이 표준은 멀티파트로 구성되며, 다음과 같은 여섯 가지 표준 문서로 구성된다.
  • Part 1 : 어드레싱 프로파일 (Addressing Profile)
  • Part 2 : 베이스 프로파일 (Base Profilie)
  • Part 3 : 안내서 (Primer)
  • Part 4 : 보안 프로파일 (Security Profile)
  • Part 5 : 첨부 프로파일 (Attachments Profile)
  • Part 6 : WSDL 바인딩 가이드 (WSDL Binding Guidelines)
이 표준은 저작권법에서 보호 대상이 되는 저작물이다. 이 표준 문서의 표지에 있는 지적재산권 공지 사항을 숙지할 것을 다시한번 강조한다.

1 적용범위

IMS 웹서비스(General Web Services, 이하 GWS) 표준의 목적은 IMS GLC 표준 개발의 일환으로 웹서비스를 사용하려 하는 프로젝트 팀들에게 지침을 제시할 프레임워크를 제공하는 것이다. IMS 웹서비스 WSDL 바인딩 지침은 다음 기준을 충족하는 방법론을 제공한다.
  • 상호운용성(interoperability) – IMS 웹서비스 표준 활동에서 생산되는 산출물은 서로 다른 소프트웨어와 운영체제 플랫폼 환경에서 웹서비스 표준 구현물간의 상호운용성을 증진하는 매커니즘과 표준을 추구한다.
  • 효율성(efficiency) – IMS 웹서비스 표준 활동에서 생산되는 산출물은 IMS의 다른 표준활동에서 기능적 요구사항과 관련 있는 웹서비스 프로토콜을 효율적이고 효과적으로 검증하는 것을 도울 수 있도록 설계해야 한다.
  • 일관성(consistency) – IMS 웹서비스 표준 활동에서 생산되는 산출물은 일반 웹서비스 활동으로 생산된 인공물들은 각기 다른 IMS 표준제정 활동 및 제정하는 표준에서 웹서비스 프로토콜을 구현하고자 할 때 일관된 접근방법에 기반한 실행을 지원할 수 있도록 설계되어야 한다.
  • 유연성(flexibility) – IMS 웹서비스 표준 활동에서 생산되는 산출물은 ‘SOAP’처럼 진화하는 웹서비스 프로토콜에 적응할 수 있고, WSDL (Web Service Description Language)처럼 다양한 웹서비스 바인딩 방법들에도 적용할 수 있도록 유연해야 한다.
  • 실용성(practicality) – IMS 웹서비스 표준 활동에서 생산되는 산출물은 기업들이 IMS GLC 기반의 웹서비스 솔루션을 개발할 수 있는 역량을 지원할 수 있어야 하고, 플랫폼 및 웹서비스 프로토콜 벤더간에 상호운용성을 구현할 수 있도록 독려할 수 있어야 한다.
IMS 웹서비스 WSDL 바인딩 가이드는 IMS 웹서비스 베이스 프로파일, IMS 추상 프레임워크, 그리고 특정 표준의 정보 모델에 내재한 비즈니스 지식을 사용해 웹서비스 바인딩을 생성하는 과정을 보여준다. IMS 웹서비스 WSDL 바인딩 가이드는 정보수집, 정보가공, 그리고 웹서비스 프로토콜과 바인딩을 적절히 상세하게 설명하기 위해서 권장된 도구들을 이용하는 방법에 대한 지침을 프로젝트 그룹들에게 제시한다. 이 방법론은 웹서비스 방법론과 IMS GLC 표준간의 관계와 역할을 설명하기 위한 글과 그림을 포함하고 있다. WSDL 바인딩 파일 생성을 위해 표준을 설명하고 표현하는데 있어 UML을 이용한다. UML의 XMI (XML Metadata Interchange) 표현은 이후 자동생성을 위해 사용된다. 자동화된 변환작업은 그 XMI에 해당하는 일련의 WSDL과 XSD (Extensible Schema Definition) 파일을 생성하기 위해 특별히 개발된 하나 이상의 XSLT (Extensible Stylesheet Language Transformations)를 해당 XMI에 적용함으로써 이루어진다. 이 문서는 IMS 웹서비스 베이스 프로파일 문서와 확장 프로파일 집합 그리고 IMS 바인딩 자동생성 툴킷(I-BAT) 매뉴얼과 연계해서 이해해야 한다. 앞서 언급한 두 가지 문서들의 생성에 대한 참조용어는 프로젝트 헌장 원본에 정의되어 있다.

2 인용표준

다음은 이 표준의 인용 또는 참조표준으로 발행연도가 표기되지 않은 표준은 최신판을 적용한다.

2.1 참조표준

  • AbsASCs, 03 : IMS Abstract Framework: Applications, Services & Components v1.0, Ed. C.Smythe, IMS/GLC.
  • AbsGloss, 03 : IMS Abstract Framework: Glossary v1.0, Ed. C.Smythe, IMS/GLC.
  • AbsWhite, 03 : IMS Abstract Framework: White Paper v1.0, Ed. C.Smythe, IMS/GLC.
  • APG, 04a : IMS Application Profile Guidelines Whitepaper: Part 1 Management Overview, K.Riley and P.Hope, Version 1.0, IMS Publication.
  • APG, 04b : IMS Application Profile Guidelines Whitepaper: Part 2 Technical Manual, K.Riley and P.Hope, Version 1.0, IMS Publication.
  • Cockburn, 01 : Writing Effective Use-case, A.Cockburn, Addison-Wesley, 2001, ISBN 0-201-70225-8.
  • GWS, 03 : General Web Services Project Team Charter, C.Schroeder, R.Kleinman and S.Griffin, IMS/GLC.
  • GWS, 05a : IMS General Web Services UML to WSDL Binding Auto-generation Guidelines Public Draft, C.Schroeder, S.Raju and C.Smythe, V1.0 IMS/GLC.
  • GWS, 05b : IMS General Web Services Base Profile Final Release, C.Schroeder, J.Simon and C.Smythe, V1.0 IMS/GLC.
  • GWS, 05c : IMS General Web Services Addressing Profile Final Release, C.Schroeder, J.Simon and C.Smythe, V1.0 IMS/GLC.
  • GWS, 05d : IMS General Web Services Attachments Profile Final Release, C.Schroeder, J.Simon and C.Smythe, V1.0 IMS/GLC.
  • GWS, 05e : IMS General Web Services Security Profile Final Release, C.Schroeder, J.Simon and C.Smythe, V1.0 IMS/GLC.
  • GWS, 05f : IMS Binding Auto-generation Toolkit Manual, C.Smythe, V1.0 IMS/GLC.
  • SOAP, 01a : SOAP Messages with Attachments, W3C, W3C Note 11.
  • SOAP, 03a : SOAP Version 1.2 Part 1: Messaging Framework, W3C, W3C Final Specification.
  • SOAP, 03b : SOAP Version 1.2 Part 2: Adjuncts, W3C, W3C Final Specification.
  • SpecDev, 03 : IMS Specification Development Methods & Best Practices v1.0, C.Smythe, IMS/GLC.
  • UML, 04 : The Unified Modeling Language Reference Manual, J.Rumbaugh, I.Jacobson and G.Booch, 2nd Ed, Addison-Wesley, ISBN 0-321-24562-8.
  • WSDL, 01 : Web Services Description Language, http://www.w3.org/TR/2001/NOTE-wsdl-20010315, Version 1.1, W3C, W3C Note.
  • WSDL, 04 : Web Services Description Language, Version 2.0, W3C, W3C Working Draft 3.
  • WSI, 03 : Web Services Interoperability Basic Profile Version 1.0, Eds K.Ballinger, D.Ehnebuske, M.Gudgin, M.Nottingham and P.Yendluri Web Services-Interoperability Organization.
  • WSI, 04a : Web Services Interoperability Basic Profile Version 1.1, Eds K.Ballinger, D.Ehnebuske, C.Ferris, M.Gudgin, C.K.Liu, M.Nottingham and P.Yendluri, Web Services-Interoperability Organization.
  • WSI, 04b : WS-I Attachments Profile Version 1.0, Eds C.Ferris, A.Karmarkar and C.K.Liu, Web Services-Interoperability Organization.
  • WSI, 04c : WS-I Conformance Claim Attachment Mechanisms Version 1.0, Eds M.Nottingham and C. von Riegen, Web Services-Interoperability Organization.
  • WSI, 04d : WS-I Simple SOAP Binding Profile Version 1.1, Ed M.Nottingham, Web Services-Interoperability Organization.

3 용어정의

3.1 약자와 약어

  • a-API : 추상 어플리케이션 프로그래밍 인터페이스(Abstract Application Programming Interface)
  • API : 어플리케이션 프로그래밍 인터페이스((Application Programming Interface)
  • BPEL4WS : 웹서비스를 위한 비즈니스 프로세스 실행 언어(Business Process Execution Language for Web Services)
  • CORBA : 공통 객체 요구 연결 구조(Common Object Request Broker Architecture)
  • CRUD : 생성, 반입, 업데이트, 삭제(Create, Read, Update and Delete)
  • DCOM : 분산된 구성요소 객체 모델(Distributed Component Object Model)
  • ebXML : 전자 비즈니스 XML(Electronic Business XML)
  • FTP : 파일 전송 프로토콜(File Transfer Protocol)
  • GWSBP : 웹서비스 베이스 프로파일(General Web Services Base Profile)
  • HTTP : 하이퍼텍스트 전송 프로토콜(Hypertext Transport Protocol)
  • HTTPS : 보안 하이퍼텍스트 전송 프로토콜(Secure Hypertext Transport Protocol)
  • IAF : IMS 추상 프레임워크(IMS Abstract Framework)
  • IMS GLC : IMS 글로벌 러닝 컨소시엄(IMS Global Learning Consortium)
  • IPSec : IP 보안(IP Security)
  • LAN : 근거리 통신망(Local Area Network)
  • IIOP : 인터넷 ORB 간의 프로토콜(Internet Inter-ORB Protocol)
  • MIME : 다목적 인터넷 메일 확장(Multipurpose Internet Mail Extensions)
  • MOM : 미들웨어 지향 메세징(Middleware Oriented Messaging)
  • MTOM : 메시지 전송 최적화 매커니즘(Message Transmission Optimization Mechanism)
  • POS : 서비스 포인트(Point of Service)
  • REST : 실증적인 상태 전이(Representational State Transfer)
  • RPC : 원격 절차 호출(Remote Procedure Call)
  • SAML : 보안 단언 마크업 언어(Security Assertion Mark-up Language)
  • SAP : 서비스 접점(Service Access Point)
  • SLA : 서비스 수준 협약(Service Level Agreement)
  • SMTP : 단순 메일 전송 프로토콜(Simple Mail Transfer Protocol)
  • SOAP : 단순 객체 접근 프로토콜(Simple Object Access Protocol)
  • SOAPwA : 첨부 SOAP(SOAP with Attachment)
  • SSL : 보안 소켓 계층(Secure Socket Layer)
  • TCP/IP : 전송 제어 프로토콜/인터넷 프로토콜(Transmission Control Protocol/Internet Protocol)
  • TLS : 전송 레이어 보안(Transport Layer Security)
  • UML : 통합 모델링 언어(Unified Modelling Language)
  • URI : 범용 자원 식별자(Universal Resource Identifier)
  • URL : 범용 자원 로케이터(Universal Resource Locator)
  • VLE : 가상 학습 환경(Virtual Learning Environment)
  • VPN : 가상 사설망(Virtual Private Network)
  • W3C : www 컨소시엄(World Wide Web Consortium)
  • WAN : 광대역 통신망(Wide Area Network)
  • WSA : 웹 서비스 구조(Web Service Architecture)
  • WSDL : 웹 서비스 기술 언어(Web Services Description Language)
  • XMI : XML 메타데이터 인터페이스(XML Metadata Interface)
  • XML : 확장 마크업 언어(Extensible Mark-up Language)
  • XSD : XML 스키마 정의(XML Schema Definition)
  • XSLT : 확장 스타일시트 언어 변환(Extensible Stylesheet Language Transformations)

4 WSDL (Web Services Description Language) 파일

4.1 WSDL 문서구조

그림 4.1에서는 WSDL 1.1버전 문서의 구조를 제시하고 있다.
IMS KR 1005-6_4.1

그림 4.1 WSDL 문서구조

WSDL 문서에서는 서비스를 네트워크 종단, 또는 포트의 집합으로 정의한다. WSDL에서 종단과 메시지에 대한 추상적인 정의는 구체적인 네트워크 배치나 데이터 포맷 바인딩과는 분리된다. 이렇게 분리함으로써 메시지란 상호간에 교환되는 데이터에 대한 추상적인 설명이라는 개념적인 정의이며, 포트 유형이란 오퍼레이션의 추상적 집합이라는 개념적인 정의를 재사용할 수 있게 한다. 특정 포트 유형에 대한 구체적인 프로토콜과 데이터 포맷 표준은 재사용 가능한 바인딩을 구성한다. 포트는 재사용 가능한 바인딩과 네트워크 주소를 연계함으로써 정의되며 이러한 포트의 집합은 서비스를 정의한다. 그러므로, WSDL 문서는 네트워크 서비스를 정의하는 데 다음과 같은 요소를 사용한다.
  • 유형(Types) – (XSD 등과 같은) 어떤 유형 체계를 사용하는 데이터 유형 정의를 위한 컨테이너이다.
  • 메시지(Message) – 통신 대상이 되는 데이터의 추상적이며 유형화된 정의. 일반적으로 메시지 파트는 여러 개가 있다.
  • 오퍼레이션(Operation) – 서비스에 의해 제공되는 행위에 대한 추상적인 설명. 일반적으로 하나 또는 두 개의 메시지와 관련된 여러 오퍼레이션이 있다.
  • 포트유형(Port Type) – 하나 이상의 종단에 의해 지원되는 오퍼레이션의 추상적인 집합. 하나 이상의 정의된 포트유형이 있을 수 있으며 각 포트유형이 가질 수 있는 오퍼레이션의 수에는 제한이 없다.
  • 바인딩(Binding) – 특정 포트유형에 대한 구체적인 프로토콜과 데이터 포맷 표준. 가용한 모든 구체적 프로토콜에는 별도의 바인딩이 존재한다.
  • 포트(Port) – 바인딩과 네트워크 주소의 조합으로 정의되는 단일 종단. 각 서비스에 하나 이상의 포트가 정의될 수 있다.
  • 서비스(Service) – 관련 종단들의 집합. 하나 이상의 서비스가 WSDL 파일에 설명될 수 있다.
WSDL 1.1버전은 다음과 같은 단순 메시지 구성(choreographies)을 지원한다는 점에 유의하여야 한다.
  • 서버를 향한 단일 메시지 - WSDL에서 이는 '일방향(one-way)'으로 지칭된다.
  • 서버로부터의 단일 메시지 - WSDL에서 이는 '통지(notification)'로 지칭하며 WS-I 베이직 프로파일에서는 금지되어 있다.
  • 서버를 향한 단일 메시지 및 서버로부터의 단일 응답 - WSDL에서 이는 '요청-응답'으로 지칭된다.
  • 서버로부터의 단일 메시지 및 서버를 향한 단일 응답 - WSDL에서 이는 '청구-응답(solicit-response)'으로 지칭되며 WS-I 베이직 프로파일에서는 금지되어 있다.
더 복잡한 구성(choreography)은 표준의 구현 결과물에 의해 부여된 파일 집합들간의 구성을 포함하고 있는 다중 WSDL 파일 집합들을 이용하여 구성되어야 한다.

4.2 WSDL 스키마

4.2.1 최상위 구조 (<definition>)

그림 4.2에서는 WSDL 스키마를 위한 최상위 XSD를 제시하고 있다.
IMS KR 1005-6_4.2

그림 4.2 WSDL 스키마의 최상위 XSD

WSDL 디스크립션을 생성하는 데는 다음과 같은 네 가지 방식이 있다.
  1. 단일파일 - 모든 WSDL과 XSD 정의를 포함하는 단일 WSDL 파일을 생성하는 방식이다.
  2. 분할파일 - 단일 WSDL파일과 단일 XSD 파일을 생성. XSD는 WSDL 파일의 <wsdl:type> 요소의 <xsd:import> 구문을 사용함으로써 WSDL 파일에 링크된다.
  3. 서비스 분할파일 - 특정 서비스 WSDL 파일, 추상 정의 WSDL 파일과 단일 XSD 파일을 생성하는 방식. WSDL 파일들은 특정 서비스 WSDL 파일의 <wsdl:import> 구문을 이용해 링크된다. XSD 파일은 WSDL 파일의 추상 정의에 있는 <wsdl:type> 요소의 <xsd:import> 구문을 이용해 링크된다.
  4. 다중파일 - 특정 서비스 WSDL 파일, 추상 정의 WSDL 파일과 하나 이상의 XSD 파일을 생성하는 방식이다. WSDL 파일은 특정 서비스 WSDL 파일의 <wsdl:import> 구문을 사용해 링크된다. 루트 XSD 파일은 추상 정의 WSDL 파일의 <wsdl:type> 요소의 <xsd:import> 구문을 사용하여 링크된다.

4.2.2 <import> 요소 구조

그림 4.3는 <import> 스키마 구조를 제시하고 있다. <import>는 WSDL 디스크립션을 링크된 여러 물리적인 파일에서 정의될 수 있게 한다. IMS는 <import> 요소를 사용해 추상 정의 파일을 특정 서비스 파일에 링크할 것이다. 즉, 특정 서비스 파일은 추상 정의 파일을 임포트한다.
IMS KR 1005-6_4.3

그림 4.3 <import> 요소 구조

4.2.3 <types> 요소 구조

그림 4.4는 <types> 스키마 구조를 제시하고 있다. <types> 요소는 단일 WSDL이나 추상 정의 파일 내에서 사용되며 관련 XSD 파일들에 링크하기 위해 사용된다. XSD 파일들은 SOAP 구조에 대한 XML 정의를 포함할 것이다.
IMS KR 1005-6_4.4

그림 4.4 <types> 요소 구조

4.2.4 <message> 요소 구조

그림 4.5는 <message> 스키마 구조를 제시하고 있다. 이 요소는 특정 오퍼레이션을 위한 정보 교환에 사용되는 일련의 메시지들을 정의하기 위해 단일 WSDL이나 추상 정의 파일 내부에 사용된다. <part> 요소는 메시지 헤더와 바디 부분을 정의하기 위해 사용된다.
IMS KR 1005-6_4.5

그림 4.5 <message> 요소 구조

4.2.5 <portType> 요소 구조

그림 4.6은 <portType> 스키마 구조를 제시하고 있다. <portType> 요소는 오퍼레이션을 표현하는 메시지들을 식별하기 위해 추상 정의 파일 내에서 사용된다. 단일 추상 정의 구조에서 오퍼레이션은 최대 하나 이상의 (클라이언트에서 서버로 향하는) 입력 메시지와 하나의 (서버에서 클라이언트로 향하는) 출력 메시지를 가질 수 있다.
IMS KR 1005-6_4.6

그림 4.6 <portType> 요소 구조

4.2.6 <binding> 요소 구조

그림 4.7은 <binding> 스키마 구조를 제시하고 있다. <binding> 요소는 추상 메시지 정의를 특정 전송 매커니즘에 바인딩하기 위해서 단일 WSDL이나 특정 서비스 파일에서 사용된다. IMS 웹서비스의 경우 전송 시스템은 SOAP 1.1버전/HTTP 1.1버전이며, 다른 바인딩은 지원되지 않는다.
IMS KR 1005-6_4.7

그림 4.7 <binding> 요소 구조

4.2.7 <service> 요소 구조

<service> 요소는 포트 요소의 집합을 표현하기 위해 단일 WSDL이나 특정 서비스 파일 내에서 사용된다. 포트 요소에서 각 포트는 특정 종단에서 바인딩의 가용성을 나타낸다. 포트 요소의 '바인딩'속성은 포트 요소를 관련 바인딩 요소로 연결하는 역할을 한다(4.2.6 참조).
IMS KR 1005-6_4.8

그림 4.8 <service> 요소 구조

4.3 기본 WSDL 파일 내용

4.3.1 단일파일 표현

다음 예시는 WSDL과 XSD 정보를 단일 파일로 구성한 사례이다. 통합 WSDL 문서의 기본 구조는 다음과 같다. 
  0001
  0002
  0003
  0004
  0005
  0006
  0007
  0008
  0009
  0010
  0011
  0012
  0013
  0014
  0015
  0016
  0017
  0018
  0019
  0020
  0021
  0022
  0023
  0024
  0025
  0026
  0027
  0028
  0029
  0030
  0031
  0032
  0033
  0034
  0035
  0036
  0037
  0038
  0039
  0040
  0042
  0043
  0044
  0045
  0046
  0047
  0048
  0049
  0050
  0051
  0052
  0053
  0054
  0055
  0056
  0057
  0058
 
<?xml version = "1.0" encoding = "UTF-8"?>
  <wsdl:definitions name = "??" targetNamespace = "??">
     <wsdl:types>
        <xsd:schema>
           ...
        </xsd:schema>
     </wsdl:types>
     <wsdl:message name = "??">
        <wsdl:part name = "??" element = "??"/>
     </wsdl:message>
     ...
     <wsdl:message name = "??">
        <wsdl:part name = "??" element = "??"/>
     </wsdl:message>
     <wsdl:portType name = "??">
        <wsdl:operation name = "??">
           <wsdl:input message = "??"/>
           <wsdl:output message = "??"/>
           <wsdl:fault message = "??" name = "??"/>
        </wsdl:operation>
        ...
        <wsdl:operation name = "??">
           <wsdl:input message = "??"/>
           <wsdl:output message = "??"/>
           <wsdl:fault message = "??" name = "??"/>
        </wsdl:operation>
     </wsdl:portType>
     ...
     <wsdl:portType name = "??">
        ...
     </wsdl:portType>
     <wsdl:binding name = "??" type= "??">
        <wsdl:operation name = "??">
           <wsdl:input/>
           <wsdl:output/>
           <wsdl:fault name = "??"/>
        </wsdl:operation>
        <wsdl:operation name = "??">
           <wsdl:input/>
           <wsdl:output/>
           <wsdl:fault name = "??"/>
        </wsdl:operation>
     </wsdl:binding>
     ...
     <wsdl:binding name = "??" type= "??">
        ...
     </wsdl:binding>
     <wsdl:service name = "??">
        <wsdl:port name="??" binding= "??"/>
           ...
        <wsdl:port name="??" binding= "??"/>
     </wsdl:service>
     ...
     <wsdl:service name = "??">
        ...
     </wsdl:service>
  </wsdl:definitions>

4.3.2 분할파일 표현

다음 예시는 WSDL 과 XSD를 두 개의 별도의 파일로 분리하여 구성한 사례이다. WSDL 문서의 기본 구조는 다음과 같다. 
0001
0002
0003
0004
0005
0006
0007
0008
0009
0010
0011
0012
0013
0014
0015
0016
0017
0018
0019
0020
0021
0022
0023
0024
0025
0026
0027
0028
0029
0030
0031
0032
0033
0034
0035
0036
0037
0038
0039
0040
0042
0041
0043
0044
0045
0046
0047
0048
0049
0050
0051
0052
0053
0054
0055
0056
0057
0058
 
<?xml version = "1.0" encoding = "UTF-8"?>
 <wsdl:definitions name = "??" targetNamespace = "??">
       <wsdl:types>
      <xsd:schema>
         <xsd:import namespace = "??" schemaLocation = "??"/>
      </xsd:schema>
   </wsdl:types>
   <wsdl:message name = "??">
      <wsdl:part name = "??" element = "??"/>
   </wsdl:message>
   ...
   <wsdl:message name = "??">
      <wsdl:part name = "??" element = "??"/>
   </wsdl:message>
   <wsdl:portType name = "??">
      <wsdl:operation name = "??">
         <wsdl:input message = "??"/>
         <wsdl:output message = "??"/>
         <wsdl:fault message = "??" name = "??"/>
      </wsdl:operation>
      ...
      <wsdl:operation name = "??">
         <wsdl:input message = "??"/>
         <wsdl:output message = "??"/>
         <wsdl:fault message = "??" name = "??"/>
      </wsdl:operation>
   </wsdl:portType>
   ...
   <wsdl:portType name = "??">
      ...
   </wsdl:portType>
   <wsdl:binding name = "??" type= "??">
      <wsdl:operation name = "??">
         <wsdl:input/>
         <wsdl:output/>
         <wsdl:fault name = "??"/>
      </wsdl:operation>
      <wsdl:operation name = "??">
         <wsdl:input/>
         <wsdl:output/>
         <wsdl:fault name = "??"/>
      </wsdl:operation>
   </wsdl:binding>
   ...
   <wsdl:binding name = "??" type= "??">
      ...
   </wsdl:binding>
   <wsdl:service name = "??">
      <wsdl:port name="??" binding= "??"/>
         ...
      <wsdl:port name="??" binding= "??"/>
   </wsdl:service>
   ...
   <wsdl:service name = "??">
      ...
   </wsdl:service>
</wsdl:definitions>
WSDL 파일에서 <xsd:import> 구문(5번째 줄의 음영 부분)을 사용해 링크되는 관련 XSD 파일 구조는 다음과 같다. 
  0001
  0002
  0003
  0004
 
<?xml version = "1.0" encoding = "UTF-8"?>
  <xsd:schema>
     ...
    </xsd:schema>

4.3.3 서비스 분리 파일 표현

다음 예시는 WSDL을 두 개의 파일(추상 정의와 특정 서비스 파일)로 분리하고 XSD를 단일 파일로 구성한 사례이다. IMS 웹서비스는 추상 정의 파일에 대해 다음과 같은 구성을 권장한다. 
0001
0002
0003
0004
0005
0006
0007
0008
0009
0010
0011
0012
0013
0014
0015
0016
0017
0018
0019
0020
0021
0022
0023
0024
0025
0026
0027
0028
0029
0030
0031
0032

 		


<?xml version = "1.0" encoding = "UTF-8"?>
  <wsdl:definitions name = "??" targetNamespace = "??">
       <wsdl:types>


      <xsd:schema>


         <xsd:import namespace = "??" schemaLocation = "??"/>


      </xsd:schema>


   </wsdl:types>


   <wsdl:message name = "??">


      <wsdl:part name = "??" element = "??"/>


   </wsdl:message>


   ...


   <wsdl:message name = "??">


      <wsdl:part name = "??" element = "??"/>


   </wsdl:message>


   <wsdl:portType name = "??">


      <wsdl:operation name = "??">


         <wsdl:input message = "??"/>


         <wsdl:output message = "??"/>


         <wsdl:fault message = "??" name = "??"/>


      </wsdl:operation>


      ...


      <wsdl:operation name = "??">


         <wsdl:input message = "??"/>


         <wsdl:output message = "??"/>


         <wsdl:fault message = "??" name = "??"/>


      </wsdl:operation>


   </wsdl:portType>


   ...


   <wsdl:portType name = "??">


      ...


   </wsdl:portType>


</wsdl:definitions>



 		





IMS 웹서비스는 특정 서비스 파일에 대해 다음과 같은 구성을 권장한다(추상 정의 파일에 대한 링크는 3번째 줄의 <wsdl:import>문을 사용해 이루어진다. – 음영 부분 참조).







0001
0002
0003


0004


0005


0006


0007


0008


0009


0010


0011


0012


0013


0014


0015


0016


0017


0018


0019


0020


0021


0022


0023


0024


0025


0026


0027


0028


0029



 		


<?xml version = "1.0" encoding = "UTF-8"?>
  <wsdl:definitions name = "??" targetNamespace = "??">
       <wsdl:import namespace = "??" location = "??"/>


   <wsdl:binding name = "??" type= "??">


      <wsdl:operation name = "??">


         <wsdl:input/>


         <wsdl:output/>


         <wsdl:fault name = "??"/>


      </wsdl:operation>


      <wsdl:operation name = "??">


         <wsdl:input/>


         <wsdl:output/>


         <wsdl:fault name = "??"/>


      </wsdl:operation>


   </wsdl:binding>


   ...


   <wsdl:binding name = "??" type= "??">


      ...


   </wsdl:binding>


   <wsdl:service name = "??">


      <wsdl:port name="??" binding= "??"/>


         ...


      <wsdl:port name="??" binding= "??"/>


   </wsdl:service>


   ...


   <wsdl:service name = "??">


      ...


   </wsdl:service>


</wsdl:definitions>



 		





추상 데이터 정의 WSDL 파일에서 <xsd:import> 구문을 사용해 링크되는 각 관련 XSD 파일 구조들은 (5-7번째 줄의 음영 부분 참조) 다음과 같은 구조를 가진다.







  0001
  0002
  0003
  0004




<?xml version = "1.0" encoding = "UTF-8"?>
  <xsd:schema>
     ...
    </xsd:schema>












4.3.4 다중 파일 표현

다음 예시는 WSDL을 두 개의 파일(추상정의와 특정 서비스 파일)과 하나 이상의 XSD 파일로 분리한 것이다. IMS 웹서비스는 추상 정의 파일에 대해 다음과 같은 구성을 권장한다.







0001
0002
0003


0004


0005


0006


0007


0008


0009


0010


0011


0012


0013


0014


0015


0016


0017


0018


0019


0020


0021


0022


0023


0024


0025


0026


0027


0028


0029


0030


0031


0032


0033


0034



 		


<?xml version = "1.0" encoding = "UTF-8"?>
  <wsdl:definitions name = "??" targetNamespace = "??">
       <wsdl:types>


      <xsd:schema>


         <xsd:import namespace = "??" schemaLocation = "??"/>


         ...


         <xsd:import namespace = "??" schemaLocation = "??"/>


      </xsd:schema>


   </wsdl:types>


   <wsdl:message name = "??">


      <wsdl:part name = "??" element = "??"/>


   </wsdl:message>


   ...


   <wsdl:message name = "??">


      <wsdl:part name = "??" element = "??"/>


   </wsdl:message>


   <wsdl:portType name = "??">


      <wsdl:operation name = "??">


         <wsdl:input message = "??"/>


         <wsdl:output message = "??"/>


         <wsdl:fault message = "??" name = "??"/>


      </wsdl:operation>


      ...


      <wsdl:operation name = "??">


         <wsdl:input message = "??"/>


         <wsdl:output message = "??"/>


         <wsdl:fault message = "??" name = "??"/>


      </wsdl:operation>


   </wsdl:portType>


   ...


   <wsdl:portType name = "??">


      ...


   </wsdl:portType>


</wsdl:definitions>



 		





IMS 웹서비스는 특정 서비스 파일에 대해 다음과 같은 구성을 권장한다(추상 정의 파일에 대한 링크는 3번째 줄의 <wsdl:import> 구문을 사용해 이루어진다 – 음영 부분 참조).







0001
0002
0003


0004


0005


0006


0007


0008


0009


0010


0011


0012


0013


0014


0015


0016


0017


0018


0019


0020


0021


0022


0023


0024


0025


0026


0027


0028


0029



 		


<?xml version = "1.0" encoding = "UTF-8"?>
  <wsdl:definitions name = "??" targetNamespace = "??">
       <wsdl:import namespace = "??" location = "??"/>


   <wsdl:binding name = "??" type= "??">


      <wsdl:operation name = "??">


         <wsdl:input/>


         <wsdl:output/>


         <wsdl:fault name = "??"/>


      </wsdl:operation>


      <wsdl:operation name = "??">


         <wsdl:input/>


         <wsdl:output/>


         <wsdl:fault name = "??"/>


      </wsdl:operation>


   </wsdl:binding>


   ...


   <wsdl:binding name = "??" type= "??">


      ...


   </wsdl:binding>


   <wsdl:service name = "??">


      <wsdl:port name="??" binding= "??"/>


         ...


      <wsdl:port name="??" binding= "??"/>


   </wsdl:service>


   ...


   <wsdl:service name = "??">


      ...


   </wsdl:service>


</wsdl:definitions>



 		





추상 데이터 정의 WSDL 파일에서 <xsd:import> 구문을 사용해 링크되는 각 관련 XSD 파일 구조들은(5-7번째 줄의 음영 부분 참조) 다음과 같은 구조를 가지고 있다.







  0001
  0002
  0003
  0004




<?xml version = "1.0" encoding = "UTF-8"?>
  <xsd:schema>
     ...
    </xsd:schema>












4.3.5 구조간 관계와 명명규칙

WSDL 파일 집합내의 'types', 'message', 'operation', 'porttype', 'binding', 'port'와 'service' 요소들은 엄격한 관계를 가지고 있다. 이러한 관계를 만들기 위해 여기서는 명명규칙을 제안한다. 기본 목표 네임스페이스에는 'tns'의 접두어가 할당된다. 여기서 제시되는 명명규칙들은 5장에서 자세히 설명한다.



4.3.5.1 ’Service’ 정의

여러 서비스들이 정의될 수 있다. 각 서비스에는 고유한 이름이 주어지며 끝에 문자열 'Service'가 주어진다. WSDL 예시는 다음과 같다.







  0001
  0002
  0003
  0004
  0005
  0006




<wsdl:definitions>
     ...
     <wsdl:service name = "PackagingService">
        ...
     </wsdl:service>
  </wsdl:definitions>












4.3.5.2 ’Port’ 정의

각 서비스에는 여러 포트들이 정의될 수 있다. 포트는 바인딩을 네트워크 주소와 연계한다. 같은 포트유형에 바인딩된 포트는 대체 가능한 다른 포트로서 간주된다. 즉, 두 개의 각기 다른 포트는 같은 포트 유형을 위해 정의될 수 있지만, 하나의 포트는 SOAP 바인딩을, 다른 하나는 HTTP-Post 바인딩을 사용한다. 각 포트는 고유한 이름을 가지며 끝에 'Port' 문자열을 가진다. <wsdl:port> 선언으로 식별된 바인딩은 반드시 <wsdl:binding> 요소를 사용해 WSDL의 다른 곳에 정의되어야 한다. 이에 대한 WSDL 예시는 다음과 같다.







  0001
  0002
  0003
  0004
  0005
  0006
  0007
  0008
  0009
  0010
  0011
  0012
  0013
  0014




<wsdl:definitions>
     ...
     <wsdl:service name = "PackagingService">
        <wsdl:port name = "Packaging1SoapPort" binding = "tns:OpSet1SoapBinding">
           ...
        </wsdl:port>
        <wsdl:port name = "Packaging2SoapPort" binding = "tns:OpSet2SoapBinding">
           ...
        </wsdl:port>
        <wsdl:port name = "PackagingPostPort" binding = "tns:OpSet1PostBinding">
           ...
        </wsdl:port>
     </wsdl:service>
  </wsdl:definitions>












4.3.5.3 ’Binding’ 정의

각 ’Port Type’는 최소한 하나의 바인딩을 가져야 한다. 바인딩은 특정 포트 유형에 대해 구체적인 프로토콜과 데이터 포맷을 정의한다. 각 바인딩은 고유한 이름을 가져야 하며 끝에 문자열 ‘Binding’를 갖는다. <wsdl:binding> 요소를 통해 식별된 ’Port Type’는 <wsdl:portType> 요소를 사용해 WSDL의 다른 곳에서 정의되어야 한다. 이에 대한 WDSL 예시는 다음과 같다.







  0001
  0002
  0003
  0004
  0005
  0006
  0007
  0008
  0009
  0010
  0011
  0012
  0013




<wsdl:definitions>
     ...
     <wsdl:binding name = "OpSet1SoapBinding" type "tns:OpSet1PortType>
        ...
     </wsdl:binding>
     <wsdl:binding name = "OpSet2SoapBinding" type "tns:OpSet2PortType>
        ...
     </wsdl:binding>
     <wsdl:binding name = "OpSet1PostBinding" type "tns:OpSet1PortType>
        ...
     </wsdl:binding>
     ...
  </wsdl:definitions>







모든 바인딩 이름에는 관련한 포트 용도가 반드시 정의되어야 한다(‘포트 정의’와 ‘바인딩 정의’ 사례의 음영 부분 참조).






4.3.5.4 ’Port Type’ 정의

‘Port Type’는 하나 이상의 종단에 의해 지원되는 오퍼레이션의 추상적인 집합이다. 각 ‘Port Type’은 반드시 고유한 이름을 가져야 하며 끝에 ‘PortType’ 문자열이 주어진다. 이에 대한 WSDL 예시는 다음과 같다.







  0001
  0002
  0003
  0004
  0005
  0006
  0007
  0008
  0009
  0010




<wsdl:definitions>
     ...
     <wsdl:portType name = "OpSet1PortType">
        ...
     </wsdl: portType >
     <wsdl:portType name = "OpSet2PortType">
        ...
     </wsdl:portType>
     ...
  </wsdl:definitions>







모든 ‘Port Type’는 반드시 바인딩에서 사용되어야 함에 주의해야 한다. ‘포트유형 정의’와 ‘바인딩 정의’ 사이의 관계는 이 문서의 해당 정의내용 부분에서 제시된 관련 예시들에서 밑줄 표기된 부분들을 통해 확인할 수 있다.






4.3.5.5 ’Operation’ 정의

오퍼레이션은 서비스에 의해 지원되는 행동에 대한 추상적인 설명이다. 오퍼레이션은 ‘Port Type’과 관계된다. ‘Port Type’ 내의 각 오퍼레이션은 반드시 고유한 이름을 가져야 하며 이 이름은 오퍼레이션의 기능적 특징을 표현해야 한다. 이 대한 WSDL의 예시는 다음과 같다.







  0001
  0002
  0003
  0004
  0005
  0006
  0007
  0008
  0009
  0010
  0011
  0012
  0013
  0014
  0015
  0016
  0017
  0018
  0019
  0020
  0021
  0022




<wsdl:definitions>
     ...
     <wsdl:portType name = "OpSet1PortType">
        <wsdl:operation name = "createObject">
           ...
        </wsdl:operation>
        ...
        <wsdl:operation name = "deleteObject">
           ...
        </wsdl:operation>
     </wsdl: portType >
     <wsdl:portType name = "OpSet2PortType">
        <wsdl:operation name = "compressObjects">
           ...
        </wsdl:operation>
        ...
        <wsdl:operation name = "expandObjects">
           ...
        </wsdl:operation>
     </wsdl:portType>
     ...
  </wsdl:definitions>












4.3.5.6 ’Message’ 정의

메시지는 통신되는 정보의 추상적 구조이다. 메시지는 그에 상응하는 오퍼레이션의 활동을 통신하기 위해 사용된다. 오퍼레이션당 메시지의 수는 ‘일방향’, ‘요청-응답’, ‘청구-응답’ 또는 ‘통지’ 서비스의 구성(choreography)에 따라 결정된다. ‘요청-응답’ 구성에서 두 메시지를 위한 명명규칙은 오퍼레이션의 이름을 사용하며, 종단으로 향하는 메시지에는 ‘Request’ 문자열을 붙이고 종단으로부터 발송되는 메시지에는 ‘Response’ 문자열을 붙인다. 이에 대한 WSDL 예시는 다음과 같다.







  0001
  0002
  0003
  0004
  0005
  0006
  0007
  0008
  0009
  0010
  0011
  0012
  0013
  0014
  0015
  0016
  0017
  0018
  0019
  0020
  0021
  0022
  0023
  0024
  0025
  0026
  0027
  0028
  0029
  0030
  0031
  0032
  0033
  0034
  0035
  0036
  0037
  0038
  0039
  0040
  0041
  0042
  0043
  0044
  0045
  0046
  0047
  0048
  0049
  0050
  0051




<wsdl:definitions>
     ...
     <wsdl:message name = "createObjectRequest">
        ...
     </wsdl:message>
     <wsdl:message name = "createObjectResponse">
        ...
     </message>
     <wsdl:message name = "deleteObjectRequest">
        ...
     </wsdl:message>
     <wsdl:message name = "deleteObjectResponse">
        ...
     </wsdl:message>
     <wsdl:message name = "compressObjectRequest">
        ...
     </wsdl:message>
     <wsdl:message name = "compressObjectResponse">
        ...
     </wsdl:message>
     <wsdl:message name = "expandObjectRequest">
        ...
     </wsdl:message>
     <wsdl:message name = "expandObjectResponse">
        ...
     </wsdl:message>
     ...
     <wsdl:portType name = "OpSet1PortType">
        <wsdl:operation name = "createObject">
           <wsdl:input message = "tns:createObjectRequest">
           <wsdl:output message = "tns:createObjectResponse">
        </wsdl:operation>
        ...
        <wsdl:operation name = "deleteObject">
           <wsdl:input message = "tns:deleteObjectRequest">
           <wsdl:output message = "tns:deleteObjectResponse">
        </wsdl:operation>
     </wsdl: portType >
     <wsdl:portType name = "OpSet2PortType">
        <wsdl:operation name = "compressObjects">
           <wsdl:input message = "tns:compressObjectRequest">
           <wsdl:output message = "tns:compressObjectResponse">
        </wsdl:operation>
        ...
        <wsdl:operation name = "expandObjects">
           <wsdl:input message = "tns:expandObjectRequest">
           <wsdl:output message = "tns:expandObjectResponse">
        </operation>
     </wsdl:portType>
     ...
  </wsdl:definitions>







메시지 설명은 오퍼레이션 설명에 링크되어 있으며 모든 메시지는 반드시 하나 이상의 오퍼레이션을 가져야 한다. 위 WSDL 예시에서 명명규칙은 음영과 밑줄로 표시된 부분에 제시되어 있다.










4.4 WS-I 베이직 프로파일

WS-I 베이직 프로파일 1.1은 비독점 웹서비스 표준들과, 표준의 상호운용성을 촉진시키는 선언, 보완, 해석과 확장 사항들로 구성된다. 이 프로파일은 상호운용성을 촉진하는데 관련하는 원칙이자 프로파일의 기본 철학을 구성하는 다음과 같은 원칙들에 의거해 개발되었다.

    
	
  1. 상호운용성 비보장 - 특정 서비스의 상호운용성을 완전히 보장하는 것은 불가능하다. 하지만, 이 프로파일은 구현과정에서 가장 흔히 경험하는 문제들을 다룬다.
    2. 
	
  2. 어플리케이션 의미론(semantics) - 어플리케이션 의미론의 통신은 프로파일을 구성하는 기술들에 의해 더 용이하게 이루어질 수 있지만, 이러한 의미론의 공통적인 이해가 이를 통해 보장되는 것은 아니다.
    3. 
	
  3. 시험 용이성(Testibility) - 가능한 경우, 프로파일은 시험 가능한 명세를 제공한다. 하지만, 이러한 시험용이성이 필수적인 것은 아니다. 다만, 가능하다면 그 산출물을 유선(on the wire)으로 검사하는 등 비침해적인 방법(non-intrusive manner)으로 실시되는 것이 바람직하다.
    4. 
	
  4. 강제성 - 이 프로파일은 필요 시 '반드시 ~ 해야 한다', '절대로 ~해서는 안 된다' 등 강한 강제성을 부여한다. 이러한 강제성을 만족시키지 못할 정당한 이유가 있는 경우, '~ 해야 한다', '~해서는 안 된다' 등의 조건부 강제가 사용된다. 선택적이거나 조건부 강제는 구현물간에 모호함과 불일치를 가져온다.
    5. 
	
  5. 강화 대 완화 - 참조된 표준의 강제성을 확대할 경우, 예를 들어 '반드시 ~ 해야 한다'를 '~ 할 수 있다'로 바꾸는 것과 같이 프로파일은 강제성을 강화할 수 있지만, 완화할 수는 없다.
    6. 
	
  6. 다중 매커니즘 - 참조된 표준에 의해 다양한 유형의 매커니즘의 사용이 서로 교환가능 하게 허용된다면, 프로파일은 이러한 메커니즘들 중에 정확히 이해되고 광범위하게 구현되며 유용한 것을 선택할 수 있다. 관련이 없거나 충분히 상세하게 설명되지 않은 매커니즘을 사용하거나 확장을 적용하면, 복잡성이 가중되어 상호운용성이 저해된다.
    7. 
	
  7. 향후 호환성 - 가능한 경우 프로파일은 그것이 참조하는 표준에서 개정 진행중인 사항들에 대해 프로파일 자체의 요건을 맞춘다. 이는 (프로파일과 참조 표준간의) 매끄러운 전환을 가능하게 함으로써 표준을 구현하는 사람들에게 도움을 주며, WS-I가 이러한 노력들에 참여한다는 확신을 준다. 프로파일이 그것이 참조하는 표준내의 쟁점사항을 다루지 못하는 경우, 해당 정보는 추후적인 고려와 분석을 위해 적절한 기관 혹은 단체에 전달된다.
    8. 
	
  8. 전개된 서비스와의 호환성 - 전개된 웹서비스와의 하위호환성을 보장하는 것은 프로파일의 목표가 아니지만, 이에 대해 충분한 고려가 이루어지고 있다. 프로파일은 특정 상호운용성 관련 사항들에 대해 다루지 않는 한, 참조된 표준의 요건을 변경하지 않는다.
    9. 
	
  9. 상호운용성에 대한 집중 - 참조된 표준에는 모순점들과 설계상 오류들이 여럿 있지만, 프로파일은 상호운용성에 영향을 미치는 것들에 대하서만 다룬다.
    10. 
	
  10. 적합성 목표 - 가능한 경우, 프로파일은 소프트웨어의 행동이나 역할을 제공 또는 사용하기 보다는 WSDL 설명, SOAP 메시지 등과 같은 요건을 산출물에 부여한다. 산출물들은 구체적이어서 검증하기 쉬우며, 이에 따라 적합성에 대한 이해가 더 용이하며 오류에 대해 덜 취약하도록 한다.
    11. 
	
  11. 하위 계층 상호운용성 - 이 프로파일은 어플리케이션 계층에서의 상호운용성을 다룬다. 이 프로파일은 TCP/IP, 이더넷 등 하위 계층 프로토콜의 상호운용성이 적절하며 정확히 이해된다고 가정한다. 마찬가지로, 어플리케이션 계층 기반 프로토콜(SSL/TLS, HTTP등)에 대한 설명은 웹서비스에 영향을 주는 쟁점들이 있을 때에만 제공된다. WS-I는 전체적으로 이러한 프로토콜간의 상호운용성에 대해 확신하지 않는다. 다만, 웹서비스 표준에 대한 관심을 증대하고 WS-I의 전문성이 발휘될 수 있도록 하는데 초점을 두고 있다.
    12. 


IMS 웹서비스 베이스 프로파일은 WS-I 베이직 프로파일 1.1버전과 WS-I 심플 SOAP 바인딩 프로파일 1.0 버전을 기반으로 한다. IMS 웹서비스 베이스 프로파일은 WS-I와 다른 부분이 몇 가지 있으며, 그 차이점은 웹서비스 표준 WSDL 바인딩 자동 생성 가이드라인 공개초안 3장에 제시되어 있다.









5 통신 모델 집합을 위한 WSDL 파일

바인딩에 의해 지원되는 다음과 같은 통신 모델 세 가지에 대해 각각 하나씩의 변환 규칙이 필요하다.

    
	
  • 동기식(Synchronous) – 응답자가 응답하기 전까지 초기자는 차단된다.
    • 
	
  • 비동기식(Asynchronous) – 초기자는 차단되지 않으며, 처리되지 않은 요청이 하나 이상 있을 수 있다.
    • 
	
  • 폴링 방식(Polled) – 초기자가 요청을 일단 보내면 응답자는 초기자가 폴링하기 전까지 응답하지 않을 것이다.
    • 





5.1 동기식 통신 변환 알고리즘




5.1.1 단일파일 표현

그림 5.1은 단일파일 WSDL/XSD 표현을 생성하기 위한 변환 알고리즘을 제시하고 있다.

IMS KR 1005-6_5.1


그림 5.1 동기식 통신 단일파일 바인딩의 스키마

그림 5.1에서 설명하고 있는 바인딩 파일에는 다음 사항이 포함된다.

    
	
  • 'SyncSinglev1p0.wsdl' - 완전한 WSDL 및 관련 XSD 정의. 이 서비스는 SOAP/http를 사용할 것이다.
    • 
	
  • 음영으로 표시된 두 파일은 W3C WSDL 과 SOAP XSD이다.
    • 


표 5.1에서는 이 바인딩에 사용된 네임스페이스 접두어를 제시하고 있다.

표 5.1 동기식 통신 단일파일 바인딩에 사용된 네임스페이스 접두어







네임스페이스


용도






"tns:"
목표 네임스페이스 식별자




"xs:"
XML 스키마 정의 네임스페이스이며, 다음을 참조한다.http://www.w3.org/2001/XMLSchema




"soap11:"
WSDL 파일 내에 사용된 SOAP 참조이며, 이는 "wsisoapv1p1.xsd"를 참조한다.




"wsdl11:"
WSDL 1.1버전의 기본 WSDL 파일 네임스페이스이며, 이는 "wsiwsdlv1p1.xsd"를 참조한다.










5.1.2 분할파일 표현

그림 5.2에서는 단일 WSDL과 단일 XSD 파일표현을 생성하기 위해 사용된 변환 알고리즘을 제시하고 있다.

IMS KR 1005-6_5.2


그림 5.2 동기식 통신 분할파일

바인딩의 스키마그림 5.2에 설명하고 있는 바인딩 파일에는 다음 사항이 포함된다.

    
	
  • 'SyncWSDLv1p0.wsdl' – 서비스에 특정된 추상 정의 WSDL 바인딩 파일이다. 특정 서비스의 경우 SOAP/http를 기반으로 한다. 이 파일은 <xsd:import> 구조를 이용해 메시지와 데이터 XSD를 임포트한다.
    • 
	
  • 'SyncXSDv1p0.wsdl' - XSD 정의이다. 이는 동기식 메시지 바디와 헤더 정의, 그리고 데이터 스키마를 포함한다. 이 파일은 각각의 동기식 서비스 바인딩마다 생성되어야 한다.
    • 
	
  • 음영으로 표시된 두 가지 파일은 W3C WSDL과 SOAP XSD 이다.
    • 


표 5.2에서는 이 바인딩에 사용된 네임스페이스 접두어를 제시하고 있다.

표 5.2 동기식 통신 분할파일 바인딩에 사용된 네임스페이스 접두어









네임스페이스




용도






"tns:"
목표 네임스페이스 식별자




"data:"
WSDL 파일에 XSD를 임포팅하는데 사용되는 접두어




"xs:"
XML 스키마 정의 네임스페이스이며, "http://www.w3.org/2001/XMLSchema"를 참조한다.




"soap11:"
WSDL 파일 내에 사용되는 SOAP 참조이며, "wsisoapv1p1.xsd"를 참조한다.










5.1.3 서비스 분할파일 표현

이 변환 알고리즘은 그림 5.3에 제시된 특정 서비스 및 추상정의 WSDL 그리고 단일 XSD 파일을 생성하기 위해 사용된다.

IMS KR 1005-6_5.3


그림 5.3 동기식 통신 서비스 분할파일 바인딩의 스키마

그림 5.3에 설명된 바인딩 파일에는 다음 사항이 포함된다.

    
	
  • 'ServiceSyncv1p0.wsdl' - 서비스에 특정된 WSDL 바인딩 파일이다. 특정 서비스의 경우 이는 SOAP/http를 기반으로 한다. 이 파일은 <wsdl:import> 구조 사용해 추상정의를 임포트한다. 이 파일은 각각의 동기식 서비스 바인딩마다 생성되어야 한다.
    • 
	
  • 'AbstractSyncv1p0.wsdl' - 특정 서비스와 그 오퍼레이션의 행동을 표현하는 추상 메시지 정의. 이 파일은 <xsd:import> 구조를 사용해 메시지 XSD를 임포트한다. 이 파일은 각각의 동기식 서비스 바인딩마다 생성되어야 한다.
    • 
	
  • 'SyncXSDv1p0.wsdl' - XSD 정의이다. 이는 동기식 메시지 바디와 헤더 정의, 그리고 데이터 스키마를 포함한다. 이 파일은 각각의 동기식 서비스 바인딩마다 생성되어야 한다.
    • 
	
  • 음영표시된 두 파일은 W3C WSDL과 SOAP XSD이다.
    • 


표 5.3에서는 이 바인딩에 사용된 네임스페이스 접두어를 제시하고 있다.

표 5.3 동기식 통신 서비스 분할파일 바인딩에 사용된 네임스페이스 접두어







네임스페이스


용도






"tns:"
목표 네임스페이스 식별자




"data:"
XSD를 추상정의 WSDL 파일로 임포트 하기 위한 접두어




"xs:"
XML 스키마 정의 네임스페이스이며, "http://www.w3.org/2001/XMLSchema"을 참조한다.




"abs:"
추상정의 파일 참조이며, "AbstractSyncv1p0.wsdl"을 참조한다.




"soap11:"
WSDL 파일 내에 사용된 SOAP 참조이며, "wsisoapv1p1.xsd"을 참조한다.




"wsdl11:"
WSDL 1.1버전의 기본 WSDL 파일 네임스페이스이며, "wsiwsdlv1p1.xsd"을 참조한다.










5.1.4 다중파일 표현

이 변환 알고리즘은 그림 5.4에 제시된 다중 WSDL과 XSD 파일을 생성하기 위해 사용된다. 아래 그림 5.4에 제시된 바인딩 파일들에는 다음사항이 포함된다.

    
	
  • 'ServiceSyncv1p0.wsdl' - 서비스에 특정된 WSDL 바인딩 파일. 특정 서비스의 경우 이는 SOAP/http를 기반으로 한다. 이 파일은 <wsdl:import> 구조를 이용해 추상정의를 임포트한다. 또한, 이 파일은 각각의 동기식 서비스 바인딩마다 생성되어야 한다.
    • 
	
  • 'AbstractSyncv1p0.wsdl' - 특정 서비스와 그 오퍼레이션의 행동을 표현하는 추상 메시지 정의. 이 파일은 <xsd:import> 구조를 이용해 메시지 XSD를 임포트한다. 이 파일은 각각의 동기식 서비스 바인딩마다 생성되어야 한다.
    • 
	
  • 'MessSchemav1p0.xsd' - 동기식 메시지에 대한 XSD 정의. 이 파일은 <xsd:import> 구조를 이용해 적절한 데이터모델 XSD를 임포트한다. 이 파일은 각각의 동기식 서비스 바인딩 마다 생성되어야 한다.
    • 
	
  • 'DataSchemav1p0.xsd' - 특정 서비스 데이터 모델의 정의. 이 파일은 각각의 서비스 바인딩마다 생성되어야 한다. 같은 데이터모델이 동기식, 폴링, 비동기식 바인딩에 사용된다.
    • 
	
  • 'MessBindSchemav1p0.xsd' - 메시지 헤더 부분의 XSD 바인딩. 이는 동기식, 폴링 그리고 비동기식 메시지 모델에 대한 메시지 헤더를 포함한다. 이 파일은 지원되는 통신 모델의 유형과는 상관 없이 모든 바인딩 변환 규칙에 사용된다(이 파일의 구조와 콘텐츠는 첨부 A를 참조할 것).
    • 
	
  • 'CommonSchemav1p0.xsd' - IMS 공통 데이터 객체의 XSD 바인딩. 이 파일은 IMS 메시지 바인딩 XSD뿐만 아니라 서비스 데이터 모델 XSD도 사용 가능하다. 이 파일의 내용은 모든 서비스 정의에서 동일하다.
    • 
	
  • 'wsiwsdlv1p1.xsd' - WSDL 정의의 참조 XSD. 이 파일은 W3C의 원본 파일의 WS-I 개정 버전이다.
    • 
	
  • 'wsisoapv1p1.xsd' - WSDL에 대한 SOAP 확장의 참조 XSD. 이 파일은 WS-I에서 발행하였다.
    • 



IMS KR 1005-6_5.4


그림 5.4 동기식 통신 다중 파일 바인딩의 스키마

'Service Specific' 및'Abstract Definition' 파일들의 분리는 새로운 특정 서비스 바인딩이 추상 정의를 변경하지 않고서도 생성될 수 있음을 의미한다. 추상 정의는 UML 모델에서의 행위들을 설명하며, 서비스에 특정된 파일은 이 행위들을 필요한 전송 프로토콜(이 문서에서는 SOAP/http임)에 바인딩한다.

표 5.4에서는 이 바인딩에 사용된 네임스페이스 접두어를 제시하고 있다.

표 5.4 동기식 통신 다중파일 바인딩에 사용된 네임스페이스 접두어









네임스페이스




용도






"tns:"
목표 네임스페이스 식별자




'***:'
XSD 데이터 파일에 사용되어야 하는 접두어들




"xs:"
XML 스키마 정의 네임스페이스, "http://www.w3.org/2001/XMLSchema"를 참조한다.




"msg:"
서비스 오퍼레이션에 대한 메시지 구조 정의, "MessSchemav1p0.xsd"를 참조한다.




"iaf:"
IMS 공통 데이터 모델 정의 네임스페이스, "CommonSchemav1p0.xsd"를 정의한다.




"isb:"
IMS 메시지 헤더 바인딩 정의 네임스페이스, "MessBindSchemav1p0.xsd" 를 참조한다.




"abs:"
추상 정의 파일 참조, "AbstractSyncv1p0.wsdl"를 참조한다.




"soap11:"
WSDL 파일 내에 사용된 SOAP 참조, "wsisoapv1p1.xsd"를 참조한다.




"wsdl11:"
WSDL 1.1 버전의 디폴트 WSDL 파일 네임스페이스, "wsiwsdlv1p1.xsd"를 참조한다.












5.2 비동기식 통신 변환 알고리즘

현재 IMS는 비동기식 통신 변환 알고리즘 최종본의 발행을 승인하지 않은 상태이다. 이는 이 기법에 대한 검증된 구현물이 없기 때문이며, W3C는 이에 대한 IMS 접근법이 독점적이 될 수 있도록 작업을 진행 중이다. 이 작업은 공개초안으로 발행되었다.






5.3 폴링 통신 변환 알고리즘

현재 IMS는 폴링 통신 변환 알고리즘 최종본의 발행을 승인하지 않은 상태이다. 이는 이 기법에 대한 검증된 구현물이 없기 때문이며, W3C는 이에 대한 IMS 접근법이 독점적이 될 수 있도록 작업을 진행 중이다. 이 작업은 공개초안으로 발행되었다.









6 WSDL 바인딩 생성

IMS 웹서비스 베이스 프로파일에 기반해 WSDL 바인딩을 생성하는 과정은 다음과 같다.

    
	
  1. 정보 모델은 반드시 IMS 서비스 UML 프로파일을 사용해 정의되어야 한다. 이 프로파일은 UML이 IMS 자동생성 도구에 의해 사용될 수 있는 표준에 대한 디스크립션을 작성하는데 어떻게 사용되어야 하는지 설명한다. 이 표준은 바인딩에 의해 지원되어야 하는 통신 모델의 유형에 대한 명확한 식별 없이 생성되었다는 점, 다시말해 지원되는 통신 모델의 특성은 바인딩이 생성된 후 정의된다는 점에 유의하여야 한다.
    2. 
	
  2. UML을 이용한 디스크립션은 XMI 파일, 즉 XMI 표준에 적합한 XML 인스턴스로 이용 가능해야 한다. 현재 2.5버전 이상의 포세이돈 도구에 의해 생성된 XMI 파일들만 유효하다. 포세이돈 도구는 반드시 압축을 해제해야 하는 ‘.zuml’파일과 I-BAT에 입력되는 XMI 파일을 생성한다.
    3. 
	
  3. 이렇게 생성된 XMI 파일은 이제 I-BAT에서 입력용으로 사용된다. XSL 파일 'UMLtoWSDLTransform.xsl'은 WSDL 파일을 생성하기 위해 적절한 XSLT 도구(IMS는 Oxygen도구를 권장한다)를 사용해 XMI 파일에 적용된다. XSL 파일은 관련 디렉토리 구조에 대응되도록 미리 정의된 명명규칙, 서비스의 이름과 통신 모델을 사용해 일련의 완전한 WSDL 파일들을 자동으로 생성한다. 이러한 과정 중에 I-BAT이 바인딩 파일을 생성하는 동안 발견한 문제들을 확인할 수 있는 검증 보고 텍스트 파일이 생성된다.
    4. 


I-BAT 사용 시 유의할 점은 다음과 같다.

    
	
  • I-BAT은 검증 보고서에 기록된 문제와 관계없이 바인딩 파일을 생성하려고 시도한다.
    • 
	
  • I-BAT은 UML 디스크립션에서의 문제점들을 시정하기 위해 사용될 수 없다. 정보 모델 내의 문제들은 적절한 UML 저작 도구를 이용해 수정되어야 한다. 이후 바인딩 생성 과정은 반드시 새로운 XMI 파일을 이용해 재시도 되어야 한다.
    • 
	
  • 새로운 바인딩 파일이 생성되면 수동으로 편집된 WSDL/XSD 파일들은 삭제된다.
    • 








7 베이스 프로파일 WSDL 자동생성




7.1 동기식 통신을 위한 WSDL 자동생성




7.1.1 단일파일 표현

그림 7.1에서는 단일파일 WSDL/XSD 디스크립션을 생성하기 위해 사용된 자동생성 파일들을 제시하고 있다.

IMS KR 1005-6_7.1


그림 7.1 동기식 통신 단일파일 자동생성 스키마

이 변환 파일들의 용도는 다음과 같다.

    
	
  • 'UMLtoWSDLTransform.xsl' - 표준의 UML 디스크립션을 이용한 XMI 표현에서 완전한 단일 WSDL/XSD 파일을 생성하기 위함이다.
    • 
	
  • 'WSDLtoHTML.xsl' - 단일 WSDL 파일에 설명된 WSDL 서비스에 대한 설명을 포함하는 HTML 파일을 생성하기 위함이다.
    • 


이들 XSL 파일들의 상세정보는 I-BAT에 제시되어 있다.

이 변환 파일들은 표 7.1에서 설명한 바와 같이 UML 디스크립션에서 제공하는 정보를 사용한다. 표 7.1에 제시하고 있는 각 속성은 사례값을 가지고 있으며, 각 값에는 관련 WSDL 파일이 있다. 모든 속성값은 단일 WSDL/XSD 파일에서 사용된다.

표 7.1 동기식 단일파일 자동생성 속성의 용례









속성




원래값






서비스그룹모델(ServiceGroupModel) 속성




서비스 그룹 패키지 이름
사례 그룹




WSDLv1.1:NameSpaceRoot
http://www.example/services/




WSDLv1.1:TargetNameSpaceLeaf
wsdlfilev1p0




WSDLv1.1:TargetNameSpacePrefix
tns




WSDLv1.1:AbstractFileNameSpaceLeaf
미사용




WSDLv1.1:AbstractFileNameSpacePrefix
미사용




WSDLv1.1:XSDLinkNameSpaceLeaf
미사용




WSDLv1.1:XSDLinkNameSpacePrefix
미사용




WSDLv1.1:MessageHdrNameSpaceLeaf
미사용




WSDLv1.1:MessageHdrNameSpacePrefix
미사용




<wsdl11:definitions name = "ExampleGroupSyncServices"targetNamespace = "http://www.example/services/wsdl/sync/wsdlfilev1p0"

xmlns:tns = "http://ww.example/services/wsdl/sync/wsdlfilev1p0"

xmlns:soap11 ="http://schemas.xmlsoap.org/wsdl/soap/"

xmlns:wsdl11 ="http://schemas.xmlsoap.org/wsdl/"

xmlns:xs = "http://www.w3.org/2001/XMLSchema"

xmlns:xsi = "http://www.w3.org/2000/10/XMLSchema-instance">




서비스모델(ServiceModel) 속성 




서비스 패키지 이름
EgServiceName




SOAPv1.1:AddressLocationRoot
http://www.example.soap/serviceuri/




SOAPv1.1:OperationActionRoot
http://www.example/soap/service/




<wsdl11:service name = "EgServiceNameSyncService"><wsdl11:port name = "CoreOperationsNameSyncSoapPort" binding = "...">

<soap11:address

location="http://www.example.soap/serviceuri/EgServiceNameSyncServiceSoap/"/>

</wsdl11:port>

</wsdl11:service>




인터페이스(Interface) 속성




인터페이스 이름
CoreOperationsNamecreateObject

deleteObject

updateObject

readObject

replaceObject




<wsdl11:binding name="CoreOperationsNameSyncSoapBinding"type="tns: CoreOperationsNameSyncPortType">

<soap11:binding transport="http://schema.xmlsoap.org/soap/http" style="document"/>

<wsdl11:operation name="createObject">

<soap11:operation soapAction="http://www.example/soap/service/createObject"

style="document"/>

...

</wsdl11:operation>

<wsdl11:operation name="replaceObject">

<soap11:operation soapAction="http://www.example/soap/service/replaceObject"

style="document"/>

...

</wsdl11:operation>

</wsdl11:binding>

<wsdl11:service name = "EgServiceNameSyncService">

<wsdl11:port name = "CoreOperationsNameSyncSoapPort"

binding = "tns:CoreOperationsNameSyncSoapBinding">

<soap11:address

location="http://www.example.soap/serviceuri/EgServiceNameSyncServiceSoap/"/>

</wsdl11:port>

</wsdl11:service>




데이터모델(DataModel) 속성




NameSpaceRoot
미사용




NameSpaceLeaf
미사용




NameSpacePrefix
미사용




SchemaVersion
IMS 1.0




QualifiedElements
Yes




QualifiedAttributes
No




<wsdl11:types><xs:schema xmlns="http://www.w3.org/2001/XMLSchema"

targetNamespace="http://www.example/services/wsdl/sync/wsdlfilev1p0"

xmlns:xsd=http://www.w3.org/2001/XMLSchema

xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"

version="IMS 1.0"

elementFormDefault="qualified"

attributeFormDefault="unqualified">

</xs:schema>

</wsdl11:types>










7.1.2 분할파일 표현

그림 7.2에서는 분할파일 WSDL/XSD 표현을 생성하기 위해 사용된 자동생성 파일들을 제시하고 있다.

IMS KR 1005-6_7.2


그림 7.2 동기식 통신 분할파일 자동생성 스키마

이 변환 파일들의 용도는 다음과 같다.

    
	
  • 'UMLtoWSDLTransform.xsl' - 표준의 UML 디스크립션을 이용한 XMI 표현에서 완전한 단일 WSDL 및 XSD 파일을 생성하기 위함이다.
    • 
	
  • 'WSDLtoHTML.xsl' - 단일 WSDL 파일에 설명된 WSDL 서비스에 대한 설명을 포함하는 HTML 파일을 생성하기 위함이다.이들 XSL 파일들의 상세정보는 I-BAT에 제시되어 있다.
    • 


이 변환 파일들은 표 7.2와 7.3에 설명한 바와 같이 UML 디스크립션에서 제공하는 정보를 사용한다. 표 7.2와 7.3에서 제시하고 있는 각 속성은 사례값을 가지고 있으며, 각 값에는 관련 WSDL 파일이 있다. 모든 속성값은 분할된 WSDL과 XSD 파일에서 사용된다.

표 7.2 동기식 WSDL 분할파일 자동생성 속성의 용례









속성




원래값






서비스그룹모델(ServiceGroupModel) 속성




서비스 그룹 패키지 이름
사례 그룹




WSDLv1.1:NameSpaceRoot
http://www.example/services/




WSDLv1.1:TargetNameSpaceLeaf
wsdlfilev1p0




WSDLv1.1:TargetNameSpacePrefix
tns




WSDLv1.1:AbstractFileNameSpaceLeaf
미사용




WSDLv1.1:AbstractFileNameSpacePrefix
미사용




WSDLv1.1:XSDLinkNameSpaceLeaf
미사용




WSDLv1.1:XSDLinkNameSpacePrefix
미사용




WSDLv1.1:MessageHdrNameSpaceLeaf
미사용




WSDLv1.1:MessageHdrNameSpacePrefix
미사용




<wsdl:definitions name = "ExampleGroupSyncServices"targetNamespace = "http://www.example/services/wsdl/sync/wsdlfilev1p0"

xmlns:tns = "http://ww.example/services/wsdl/sync/wsdlfilev1p0"

xmlns:soap11="http://schemas.xmlsoap.org/wsdl/soap/"

xmlns:wsdl ="http://schemas.xmlsoap.org/wsdl/"

xmlns:xsd = "http://www.w3.org/2001/XMLSchema"

xmlns:xsi = "http://www.w3.org/2000/10/XMLSchema-instance">




서비스모델(ServiceModel) 속성




서비스 패키지 이름
EgServiceName




SOAPv1.1:AddressLocationRoot
http://www.example.soap/serviceuri/




SOAPv1.1:OperationActionRoot
http://www.example/soap/service/




<wsdl:service name = "EgServiceNameSyncService"><wsdl:port name = "CoreOperationsNameSyncSoapPort" binding = "...">

<soap11:address

location="http://www.example.soap/serviceuri/EgServiceNameSyncServiceSoap/"/>

</wsdl:port>

</wsdl:service>




인터페이스(Interface) 속성




인터페이스 이름
CoreOperationsNamecreateObject

deleteObject

updateObject

readObject

replaceObject




<wsdl:binding name="CoreOperationsNameSyncSoapBinding"type="tns: CoreOperationsNameSyncPortType">

<soap11:binding transport="http://schema.xmlsoap.org/soap/http" style="document"/>

<wsdl:operation name="createObject">

<soap11:operation soapAction="http://www.example/soap/service/createObject"

style="document"/>

...

</wsdl:operation>

<wsdl:operation name="replaceObject">

<soap11:operation soapAction="http://www.example/soap/service/replaceObject"

style="document"/>

...

</wsdl:operation>

</wsdl:binding>

<wsdl:service name = "EgServiceNameSyncService">

<wsdl:port name = "CoreOperationsNameSyncSoapPort"

binding = "tns:CoreOperationsNameSyncSoapBinding">

<soap11:address

location="http://www.example.soap/serviceuri/ EgServiceNameSyncServiceSoap/"/>

</wsdl:port>

</wsdl:service>




데이터모델(DataModel) 속성




NameSpaceRoot
http://www.imsglobal.org/xsd/




NameSpaceLeaf
exampleXSD




NameSpacePrefix
미사용




SchemaVersion
IMS 1.0




QualifiedElements
Yes




QualifiedAttributes
No




<wsdl11:types><xs:schema>

<xs:import namespace="http://www.imsglobal.org/xsd/exampleXSD"

schemaLocation="http://www.imsglobal.org/xsd/exampleXSD.xsd"/>

</xs:schema>

</wsdl11:types>






표 7.3 동기식 XSD 분할파일 자동생성 속성의 용례







속성


원래값






서비스그룹모델(ServiceGroupModel) 속성




서비스 그룹 패키지 이름
사례 그룹




WSDLv1.1:NameSpaceRoot
http://www.example/services/




WSDLv1.1:TargetNameSpaceLeaf
wsdlfilev1p0




WSDLv1.1:TargetNameSpacePrefix
tns




WSDLv1.1:AbstractFileNameSpaceLeaf
미사용




WSDLv1.1:AbstractFileNameSpacePrefix
미사용




WSDLv1.1:XSDLinkNameSpaceLeaf
미사용




WSDLv1.1:XSDLinkNameSpacePrefix
미사용




WSDLv1.1:MessageHdrNameSpaceLeaf
미사용




WSDLv1.1:MessageHdrNameSpacePrefix
미사용




서비스모델(ServiceModel) 속성




미사용





인터페이스(Interface) 속성




미사용





데이터모델 속성




NameSpaceRoot
http://www.imsglobal.org/xsd/




NameSpaceLeaf
exampleXSD




NameSpacePrefix
미사용




SchemaVersion
IMS 1.0




QualifiedElements
Yes




QualifiedAttributes





<?xml version = "1.0" encoding = "UTF-8"?><xs:schema xmlns="http://www.w3.org/2001/XMLSchema"

targetNamespace="http://www.imsglobal.org/xsd/exampleXSD"

xmlns:tns="http://www.telcert/services/xsd/crasv1p0"

xmlns:xsd=http://www.w3.org/2001/XMLSchema

xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"

version="IMS 1.0"

elementFormDefault="qualified"

attributeFormDefault="unqualified">

...

</xs>










7.1.3 서비스 분할파일 표현

그림 7.3 에서는 분할파일 WSDL/XSD 표현을 생성하기 위해 사용된 자동생성 파일들을 제시하고 있다.

IMS KR 1005-6_7.3


그림 7.3 동기식 통신 서비스 분할파일 자동생성 스키마

이 변환 파일들의 용도는 다음과 같다.

    
	
  • 'UMLtoWSDLTransform.xsl' - 표준의 UML 디스크립션을 이용한 XMI 표현으로부터 서비스에 특정된 추상 정의 WSDL과 XSD 파일들을 생성하기 위함이다.
    • 
	
  • 'WSDLtoHTML.xsl' - 단일 WSDL 파일에 설명된 WSDL 서비스에 대한 설명을 포함하는 HTML 파일을 생성하기 위함이다.
    • 


이들 XSL 파일들에 대한 상세정보는 I-BAT에 제시되어 있다. 현재 이 방식을 위해 생성된 파일들은 .NET과 J2EE 도구에서 충분히 테스트되지 않았으며, 이에 따라 이 파일들의 상세정보 또한 제시되어 있지 않다.






7.1.4 다중 파일 표현

그림 7.4에서는 다중파일 WSDL/XSD 표현을 생성하기 위한 자동생성 파일들을 제시하고 있다.

IMS KR 1005-6_7.4


그림 7.4 동기식 통신 다중 파일 자동생성 스키마

이 변환 파일들의 용도는 다음과 같다.

    
	
  • 'UMLtoWSDLTransform.xsl' - 표준의 UML 디스크립션을 이용한 XMI 표현에서 서비스에 특정된 추상정의 WSDL과 XSD 파일들을 생성하기 위함이다.
    • 
	
  • 'WSDLtoHTML.xsl' - 단일 WSDL 파일에 설명된 WSDL 서비스에 대한 설명을 포함하는 HTML 파일을 생성하기 위함이다.
    • 


이들 XSL 파일들에 대한 상세정보는 I-BAT에 제시되어 있다. 현재 이 방식을 위해 생성된 파일들은 .NET과 J2EE 도구에서 충분히 테스트되지 않았으며, 이에 따라 이 파일들의 상세정보 또한 제시되어 있지 않다.








7.2 비동기식 통신을 위한 WSDL 자동생성

현재 IMS는 비동기식 WSDL 자동생성의 최종본의 발행을 승인하지 않은 상태이다. 이는 이 기법에 대한 검증된 구현물이 없기 때문이며, W3C는 이 IMS 접근법이 독점적이 될 수 있도록 작업을 진행 중이다. 이 작업은 공개초안으로 발행되었다.






7.3 폴링 통신을 위한 WSDL 자동생성

현재 IMS는 폴링 통신 WSDL 자동생성의 최종본의 발행을 승인하지 않은 상태이다. 이는 이 기법에 대한 검증된 구현물이 없기 때문이며, W3C는 이 IMS 접근법이 독점적이 될 수 있도록 작업을 진행 중이다. 이 작업은 공개초안으로 발행되었다.









8 바인딩의 확장




8.1 바인딩의 변경

IMS 바인딩은 관리대상 문서이다. 변경사항이 있는 경우 IMS 응용 프로파일 지침의 권고안을 따를 것을 권장한다.

사전에 정의된 구조를 변경하기보다는 새로운 구조를 생성함으로써, 즉 오퍼레이션의 정의를 바꾸는 대신 새로운 오퍼레이션을 생성함으로써 새로운 기능을 추가해야 한다. 자동생성 파일들은 일단 새로운 UML 디스크립션에 재적용되면 새로운 특성들이 새 WSDL/XSD 파일에 삽입되도록 제작되었다. 모든 새로운 구조에는 원래의 정의에 대한 확장임을 보여주는 명확한 명명규칙을 둘 것을 권장한다.






8.2 신규 서비스 추가

이미 확립된 ‘Service Group’ 정의를 확장하기보다는 새로운 WSDL/XSD 파일들을 생성함으로써 새로운 서비스를 생산할 것을 강력히 권고한다.

새로운 ‘Service Group’를 생성하는 것이 바람직하지 않거나 부적합한 경우, 새로운 서비스는 원래 UML 정의에 새로운 ‘ServiceModel' 패키지를 추가함으로써 생성할 수 있다(이 과정이 어떻게 이루어지는지에 대해서는 IMS 자동생성 툴킷 매뉴얼을 참조할 것). 새로운 서비스가 정의되면 다음을 참고할 것을 권고한다.

    
	
  • 서비스에는 고유한 이름이 주어진다. 이 이름은 서비스가 원래 서비스 그룹 정의에 대한 확장임을 표시해야 한다.
    • 
	
  • 서비스의 ‘Legend'는 완전하게 정의되어 있어야 한다. 주석 필드는 이것이 표준에 대한 확장임을 표시해야 한다.
    • 
	
  • 서비스의 ‘Binding'는 완전하게 정의되어 있어야 한다. 바인딩이 포함되어 있지 않다면 SOAP 1.1버전이 기본으로 간주된다.
    • 
	
  • 새로운 ‘Interface' 정의와 'DataModel' 패키지가 생성되어야 한다(이 과정에 대해서는 IMS 자동생성 툴킷 매뉴얼을 참조).
    • 







8.3 새로운 행동의 추가

새로운 행동을 생성하기 위해 이미 정의된 오퍼레이션의 정의를 바꾸지 말 것을 강력히 권고한다. 대신, 새로운 오퍼레이션은 자신의 '인터페이스' 정의 내에서 생성되어야 한다. 즉, 새로운 오퍼레이션은 이미 설정된 '인터페이스'에 추가되어서는 안 된다. 새로운 행동이 정의되면 다음 사항을 참고할 것을 권고한다.

    
	
  • 새로운 '인터페이스' 클래스에는 고유한 이름이 주어진다(이는 서비스 그룹 내에 정의된 모든 서비스에 고유해야 한다). 이 이름은 클래스가 원래 서비스에 대한 확장임을 표시해야 한다.
    • 
	
  • 새로운 행동에는 고유한 오퍼레이션 이름이 주어진다(이는 서비스 그룹 내에 정의된 모든 서비스에 고유해야 한다). 이 이름은 행동이 원래 서비스에 대한 확장임을 표시해야 한다.
    • 
	
  • 각 행동은 반드시 반환 파라미터로 'StatusInfo' 또는 ' StatusInfoSet' 클래스를 사용해야 한다. 자동생성 파일은 'StatusInfo'가 반환 파라미터라는 것을 기본 행동으로 간주한다.
    • 
	
  • 새로운 행동이 새로운 데이터 모델 구조의 정의를 필요로 하면, 이 새로운 데이터 구조는 새로운 'DataModel' 패키지 내에서 정의되어야 한다(이 과정에 대해서는 IMS 자동생성 툴킷 매뉴얼을 참조할 것).
    • 
	
  • '인터페이스'에 대한 관련 주석은 완전하게 정의되어야 한다. 이 주석은 해당 인터페이스가 표준에 대한 확장임을 상세 기술해야 한다.
    • 







8.4 새로운 데이터 구조의 추가




8.4.1 새로운 ‘DataModel’ 패키지의 추가

데이터 구조 정의는 하나 이상의 새로운 ‘DataModel’ 패키지를 추가함으로써 확장될 수 있다. 새로운 ‘DataModel’ 패키지가 정의되면 다음을 참고할 것을 권고한다.

    
	
  • ‘DataModel’의 ‘Legend’는 완전하게 정의되어야 한다. 주석 필드는 이 범례가 표준에 대한 확장임을 명시해야 한다.
    • 
	
  • XSD 규칙의 표준 집합은 일관되게 채택되고 사용되어야 한다.
    • 


새로운 서비스나 행동을 추가하는 경우에서와 같이, ‘DataModel’ 패키지를 추가할 때도 클라이언트는 같은 WSDL/XSD 정의를 사용하는 시스템의 서버 파트여야 한다. 클라이언트가 새로운 서비스로부터 구성되도록 하고 서버는 원래 서비스 정의대로 그대로 두는 것은 불가능하다. 이렇게 하면 서비스 거부가 일어나며 관련 SOAP 실패 코드가 생성되어 반환될 것이다.






8.4.2 DataModel 확장 클래스의 사용

시스템의 양 종단을 변경하지 않고 서비스 정의를 확장하는 유일한 방법은 데이터 모델 확장 클래스를 사용하는 것이다. 이 클래스는 XSD자체의 변경 없이 XSD가 확장될 수 있도록 한다. 하지만 이러한 방식을 이용할 경우 XML 파서가 수정된 데이터 정의 모델을 검증할 수 없다.








8.5 SOAP 헤더 확장

자동생성 파일을 이용해 SOAP 헤더 정의를 확장하는 것이 가능하다. SOAP 헤더 확장은 서비스 WSDL 파일 내의 ’Statusinfo’ 클래스를 위한 ‘DataModel’ 패키지 디스크립션에 삽입되어야 한다. 이 확장에는 원래의 정의와 구별하기 위해 새로운 네임스페이스가 부여되어야 한다.









9 표준에 대한 적합성 자격(Claim)




9.1 WS-I 적합성 자격 첨부

IMS 서비스 지향 표준에서 적합성 표준은 바인딩이 아닌 정보 모델과 관련해 정의되어 있다. 바인딩은 반드시 관련 정보 모델 적합성 명세를 유지해야 한다. 바인딩에 대한 적합성은 그에 상응하는 일련의 어플리케이션 프로파일들의 일부로 표현된다. 어플리케이션 프로파일은 그에 관련하는 사용자 커뮤니티에 의해 정의된다. 그러므로, 서비스 바인딩에 대해 적합성 표준을 정의하는 것은 IMS의 의무가 아니지만, IMS는 바인딩에 대한 적합성 표준을 생성할 수 있는 매커니즘을 반드시 제공해야 한다. 이 접근법은 WS-I가 사용하는 접근법에 기반한다.

WS-I는 적합성 자격 첨부 매커니즘 문서를 작성하였다. 이 문서는 WS-I 프로파일 적합성 자격이 WSDL 디스크립션, UDDI 등록 정보(registries) 등과 같은 웹서비스 산출물에 첨부할 때 사용할 수 있는 매커니즘들을 분류하여 목록화한다.

프로파일 적합성을 알리기 위해 내용물에 적합성 자격에 대한 주석을 달 수 있다. 이 주석은 내용물이나 웹서비스의 당사자 등, 특정 적합성 자격 대상이, 지시된 프로파일에 있는 적절한 요건을 충족함을 보여주기 위해 URI를 사용한다. 특정 적합성 자격에 해당되는 요구는 그에 연관된 프로파일에 따라 자격 첨부 메커니즘과 연결된 적합성 대상에게 요구되는 것들이다. 그러므로, 모든 프로파일은 자신만의 적합성 자격 URI를 상세하게 설명한다. 또한, 모든 프로파일은 어떤 적합성 대상이 다음에서 설명할 각 적합성 첨부 매커니즘에 해당되는지 상세 기술한다. WS-I에서의 적절한 자격 첨부 매커니즘은 다음과 같다.

    
	
  1. 웹서비스 인스턴스에 대한 WSDL 1.1 자격 첨부 매커니즘 -적합성 자격은 적합성 자격 스키마를 사용해 WSDL 1.1버전 디스크립션의 <wsdl:port> 요소에 있는 <wsdl:documentation> 하위 요소로서 첨부될 수 있다. 이러한 적합성 자격은 관련 웹서비스 인스턴스가 그것이 참조하는 프로파일에 의해 해당 첨부 매커니즘과 연계된 요건에 따라 정의된 행동에 적합함을 나타낸다. <wsdl:port> 요소에 첨부된 적합성 자격 또한 그 자체가 적합한 XML 구조임을 나타낸다. 그리고, ‘디스크립션 구조(Description Construct)를 위한 WSDL 1.1 자격 첨부 매커니즘’에 설명된 이행성 규칙에 기반하여 동일 자격은 모든 요소들이 재귀반복적으로 해당 자격에 의해 참조되어지도록 한다.
    2. 
	
  2. 디스크립션 구조(Description Construct)에 대한 WSDL 1.1 자격 첨부 매커니즘 –적합성 자격은 적합성 자격 스키마를 사용해 WSDL 1.1 버전 디스크립션의 <wsdl:binding>, <wsdl:portType>, <wsdl:operation> (<wsdl:portType>의 하위 요소이지만, <wsdl:binding>의 자식 요소는 아님) 그리고 <wsdl:message> 요소에 첨부될 수 있다. 이들 요소들에 첨부된 적합성 자격은 그것이 참조하는 프로파일에 의해 해당 첨부 매커니즘과 연계된 요건들에 따라 정의된 바와 같이 해당 요소가 적합한 XML 구조체임을 나타낸다. 또한, 재귀적으로 적용되는 다음 이행성 규칙에 따라, 참조하는 모든 요소에 동일 자격이 제시된다.

      
	
    • <wsdl:port> 요소에 대한 자격은 참조되는 <wsdl:binding> 요소에 의해 상속된다.
      • 
	
    • <wsdl:binding> 요소에 대한 자격은 참조되는 <wsdl:portType> 요소에 의해 상속된다.
      • 
	
    • <wsdl:portType> 요소에 대한 자격은 참조되는 <wsdl:operation> 요소에 의해 상속된다.
      • 
	
    • <wsdl:operation> 요소에 대한 자격은 자식노드인 <wsdl:output> 그리고/아니면 <wsdl:input> 요소의 참조된 <wsdl:message> 요소에 의해 상속된다.
      • 

    

    3. 
	
  3. 적합성 자격 XML 스키마 - 가능한 경우, 즉 자격이 확장 가능한 XML 문서에 첨부된 경우, 적합성 자격은 요소 정보항목에 제시되어야 한다. <Claim> 요소는 'conformsTo'라는 필수 속성을 가지며, 그 값은 실제 적합성 자격 URI를 갖는다. 적합성 자격 스키마는 확장성 요소와 속성을 명확히 허용한다.
    4. 







9.2 IMS 프로파일에 대한 적합성 자격(Claim) 생성

WS-I 적합성 자격 매커니즘과는 별도로, W3C는 WS-정책의 용례에 대해 조사하고 있다. 즉, WS-I 접근법의 사용에 대해서 어떠한 결정적 권고사항도 제시되지 않았다. 하지만, 적합성 명세가 어떠한 형태로든 필요한 경우 WS-I 접근법을 사용할 순 있지만 이 기법을 IMS 웹서비스 표준의 추후 버전에서 지원한다는 보장은 없다.









10 권장 도구




10.1 UML 및 바인딩의 자동생성

자동생성 파일의 개발을 지원하기 위해 사용되는 도구들은 다음과 같다.

    
	
  • UML 개발 – UML 기반 디스크립션의 생성을 위해서 UML 표준 에디션 3.0 (MacOS X 버전용) 포세이돈이 이용되었다. 포세이돈은 XMI 표현을 이용해 데이터 파일을 저장하는 방식에 기반해서 XSL 파일들을 생성한다는 점에 유의한다. 그러나 이러한 방식은 도구마다 다르다(어떤 경우, 같은 도구이더라도 버전마다 그 방식이 다르다).
    • 
	
  • XSL 생성 - XSL 파일의 생성에는 SyncRO Soft 사의 Oxygen Editor 6.2(MacOS X 버전용)가 사용되었다. XSL 파일은 Xalan 프로세서에 특화된 지침을 포함한다. XSLT 테스트 또한 이 도구를 이용해 이루어졌다(다른 XSLT 프로세서가 사용되는 경우, Xalan 확장을 반드시 지원해야 한다). XSL 파일은 XMI 파일들이 UML 표준 에디션 3.0을 위한 포세이돈을 이용해 생성되었다고 가정한다(위 내용 참조). 다른 UML 도구로 제작된 XMI 파일을 이용한 결과에 대한 내용들은 정의되지 않았다.
    • 







10.2 Java를 이용한 코드스텁 생성

오픈 소스 아파치 액시스(open source Apache Axis) 웹서비스 엔진은 WSDL로부터 시작해 Java에서 웹서비스를 구현하는 방법을 설명하기 위해 사용된다. 액시스(Axis)는 WSDL에서 클라이언트측과 서버측 코드를 생성하기 위해 유틸리티 클래스인 org.apache.axis.wsdl.WSDL2Java를 제공한다. 클라이언트측 서비스 콜을 하기 위해 스텁(stub)을 생성하려면, WSDL에 대해 WSDL2Java를 실행한다. 기본적으로 WSDL2Java는 클라이언트측 코드를 생성하며, 이는 WSDL의 유형 섹션에 포함된 스키마에서 상세 기술하는 각 유형을 위한 클래스, 콜을 표현하는 스텁, 서비스 로케이터(service locator) 구현물, 그리고 관련 인터페이스를 포함한다.

서버측 클래스를 생성하기 위해서는 ‘server-side –skeletonDeploy true’라는 인자를 가진 WSDL에 WSDL2Java를 실행한다. 생성된 스켈레톤(skeleton), 즉 서버측 클라이언트 스텁은, 서비스 구현물과 액시스 웹서비스 엔진 사이에 위치하며, WSDL에 사용된 네임스페이스를 생성된 Java 클래스에 매핑하는 등의 정보를 처리한다. WSDL2Java는 또한 아파치 톰캣 등의 J2EE servlet container에서 작동하는 액시스 웹서비스 인스턴스에 서비스를 배치하는데 사용되는 전개 설명자(deployment descriptor)를 생성한다. 클라이언트에서 클래스들은 스키마 유형을 위해 생성된다. WSDL2Java는 원격 URL에서 WSDL을 추출하고, 그 클라이언트의 영역 내에서 인식 가능한 패키지 이름에 네임스페이스를 매핑하고, Junit 테스트 사례 생성을 가능하게 하는 많은 인자를 가진다. 액시스는 또한 Ant 빌드 내에서 자동화된 코드 생성과 서비스 배치를 가능하게 하는 Ant 메소드를 제공한다. 결국 Java 개발자에게는 친숙한 외형을 가진 클래스의 집합이 제공된다.

액시스는 아파치 사이트 http://xml.apache.org/axis/ 에서 받을 수 있다.






10.3 Microsoft.NET 프레임워크를 사용한 코드스텁 생성

WSDL.EXE 도구는 Microsoft.NET와 함께 제공되며, 웹서비스 및 WSDL 약정 파일을 사용하는 웹서비스 클라이언트, XSD 스키마 파일, 그리고 ‘discomap’ 디스커버리 문서에 대해 코드를 생성한다. 이 문서는 WSDL을 사용한 코드생성에 초점을 맞춘다. 예제 및 WSDL.EXE 도구를 이용한 기타 코드생성 옵션에 대해서는 'MSDN Table2' (WSDL.EXE 도구에 대한 옵션 설명)를 참조한다.



10.3.1 WSDL.EXE를 이용한 코드 생성

WSDL.EXE 도구는 Visual Studio 또는 .NET 프레임워크 1.1이 설치되면 자동적으로 설치된다. Visual Studio 2003에서 WSDL.EXE 도구는 C:\Program Files\Microsoft Visual Studio.NET 2003\SDK\v1.1\Bin folder에 위치한다. 개발자가 시스템 경로에 포함된 모든 .NET 도구들을 가질 수 있도록 배치 파일이 포함된다.

프록시 클래스를 생성하기 위해 WSDL.EXE를 사용하는 경우, 단일 소스 파일이 사용하는 프로그래밍 언어 내에 생성된다(아래 표의 언어 옵션 참고할 것). WSDL.EXE 도구는 서비스 설명 내에 상세설명되는 객체들이 사용할 수 있는 최선의 유형을 결정한다. 그 결과, 프록시 클래스에서 생성된 유형은 개발자가 원하거나 예상하지 않은 것일 수 있다. 정확한 객체 유형 캐스트를 위해서는, 생성된 프록시 클래스를 포함하는 파일을 열고 원하는 객체 유형과 비교하여 부정확한 객체 유형을 변경한다. WSDL. EXE 도구는 모든 WSDL 파일이 명령라인에서 상세기술 되는 것을 권장한다. WSDL 파일이 하나 이상의 <wsdl:import> 요소를 통해 추가적인 스키마를 임포트하면, 코드 생성 오류가 일어날 수 있다. 이 문제를 피하기 위해서는 WSDL 파일을 따르는 명령라인에 있는 모든 스키마를 상세 기술한다. 예를 들어, ‘foo.wsdl’ 이 ‘bar.xsd’를 임포트하고 ‘bar.xsd’는 ‘example.xsd’를 임포트 한다면, WSDL.EXE의 명령라인은 다음과 같아야 한다.

wsdl foo.wsdl bar.xsd example.xsd

‘location’ 속성(<wsdl:import>에 포함)과 ‘schemaLocation’ 속성(<xsd:import>에 포함)은 스키마의 위치를 파악하기 위한 대체 가능한 방법을 제공하는 ‘힌트’들이며 프로세서에 의해 무시될 수 있다 (이는 W3C의 WSDL과 XSD 권고안을 따른 것이다).

WSDL.EXE 도구의 용도는 아래 표에 다음과 같이 제시된다.

용도:

wsdl [options] {URL | path}







인자(Argument)




설명






URL
WSDL 파일에 대한 URL (.wsdl).




경로
로컬 WSDL 약정 파일(.wsdl), XSD 스키마 파일(.xsd), 또는 디스커버리(discovery) 문서(.disco 또는 .discomap)에 대한 경로




옵션


내용






/appsettingurlkey:key또는

/urlkey:key
코드 생성시 URL 속성에 대한 기본값을 읽어 들이기 위해 설정 키를 지정한다.




/appsettingbaseurl:baseurl또는

/baseurl:baseurl
URL의 일부를 연산할 때 사용되는 베이스 URL을 상세 기술한다. 이 도구는 baseurl 인자에서 상대 URL을 WSDL문서의 URL로 변환함으로써 URL fragment를 계산한다. 이 옵션과 함께 /appsettingurlkey 옵션을 반드시 지정해야 한다.




/d[omain]:domain
검증을 필요로 하는 서버에 연결할 때 필요한 도메인 이름을 지정한다.




/l[anguage]:language
생성된 프록시 클래스에 사용할 언어를 지정 할 수 있다. 언어인자로 CS(C#; 디폴트), VB (비주얼 베이직), JS (Jscript), 또는 VJS (Visual J#)을 지정할 수 있다.또한 System.CodeDom.Compiler.CodeDomProvider 클래스를 실행하는 클래스의 적격한 이름을 지정할 수 있다.

http://msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemCodeDomCompilerCodeDomProviderClassTopic.asp




/n[amespace]:namespace
생성된 프록시나 템플릿의 네임스페이스를 지정한다. 기본 네임스페이스는 전역 네임스페이스이다.




/nologo
Microsoft 시작 배너 표시를 제거한다.




/o[ut]:filename
생성된 프록시 코드를 저장할 파일을 지정한다. 이 도구는 XML 웹서비스 이름으로부터 기본 파일 이름을 가져온다. 또한 여러 파일에 생성된 데이터집합을 저장한다.




/parsableerrors
언어 컴파일러에 의해 사용되는 오류 보고 포맷과 유사한 포맷의 오류를 표시한다.




/p[assword]:password
검증이 필요한 서버에 연결할 때 사용하는 패스워드를 지정한다.




/protocol:protocol
구현할 프로토콜을 지정한다. SOAP (기본), HttpGet, HttpPost, 또는 설정 파일에 지정된 커스텀(custom) 프로토콜을 지정할 수 있다.




/proxy:URL
HTTP 요청에 사용할 프록시 서버의 URL을 지정한다. 이 디폴트는 시스템 프록시 설정을 위해 사용된다.




/proxydomain:domain또는

/pd:domain
검증이 필요한 프록시 서버에 연결할 때 사용할 도메인을 상술한다.




/proxypassword:password또는

/pp:password
검증이 필요한 프록시 서버에 연결할 때 사용할 패스워드를 지정한다.




/proxyusername:username또는

/pu:username
검증이 필요한 프록시 서버에 연결할 때 사용할 유저 이름을 지정한다.




/server
약정에 기반해 XML 웹서비스에 추상 클래스를 생성한다. 디폴트는 클라이언트 프록시 클래스를 생성하기 위함이다.




/u[sername]:username
검증이 필요한 서버에 연결할 때 사용할 유저 이름을 지정한다.




/?
도구의 명령 구문과 옵션을 보여준다.





자원

    
	
  1. WSDL.EXE 도구 사용법에 대해서는 다음 주소를 참조한다.http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconcreatingwebserviceproxy.asp
    2. 



    
	
  1. WSDL.EXE 도구 옵션을 보기 위해서는 다음 주소를 참조한다.
    2. 
	
  2. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cptools/html/cpgrfWebServicesDescriptionLanguageToolWsdlexe.asp
    3. 







10.3.2 NET 도구

NET 도구는 다음 사항을 포함한다.



10.3.2.1 설정과 배치 도구


    
	
  • ASP.NET IIS 등록 도구(Aspnet_regiis.exe) - 관리자나 설치 프로그램이 ASP.NET 애플리케이션의 스크립트맵을 업데이트해 도구와 관련된 ASP.NET ISAPI 버전을 지시하도록 한다. 다른 ASP.NET 설정작업을 위해 도구를 사용해도 좋다.
    • 
	
  • 어셈블리 캐시 뷰어(Shfusion.dll) – 윈도우 익스플로러를 사용해 전역 어셈블리 캐시의 콘텐츠를 읽고 변경할 수 있도록 한다.
    • 
	
  • 어셈블리 링커(Al.exe) – 하나 이상의 자원파일 또는 마이크로소프트 중계 언어 (Microsoft intermediate language, MSIL) 파일로부터 어셈블리 매니페스트를 이용해 파일을 생성할 수 있도록 한다.
    • 
	
  • 어셈블리 등록 도구(Regasm.exe) – 어셈블리 내의 메타데이터를 읽고 레지스트리에 필요한 엔트리를 추가하도록 한다. 이는 COM 클라이언트가 .NET 프레임워크 클래스를 투명하게 생성할 수 있도록 한다.
    • 
	
  • 어셈블리 바인딩 로그 뷰어(Fuslogvw.exe) – 실패한 어셈블리 바인딩에 대한 구체적인 정보를 보여준다. 이 정보는 .NET 프레임워크가 실행 시 어셈블리의 위치를 왜 파악할 수 없는지 진단하는 데 도움을 준다.
    • 
	
  • 전역 어셈블리 캐시 도구(Gacutil.exe) – 전역 어셈블리 캐시와 다운로드 캐시의 콘텐츠를 읽고 변경할 수 있도록 한다. Shfusion.dll은 유사한 기능을 제공하지만, 빌드 스크립트(build scripts), makefile files, 그리고 배치 파일(batch files)로부터 Gacutil.exe를 사용할 수 있다.
    • 
	
  • 설치자 도구(Installutil.exe) – 특정 어셈블리의 설치자 구성요소를 실행함으로써 서버자원을 설치하고 제거할 수 있도록 한다.
    • 
	
  • 격리 저장 도구(Storeadm.exe) – 현재 로그인한 사용자들을 위해 모든 기존 저장소들을 목록화 하거나 제거한다.
    • 
	
  • 원시(Native) 이미지 생성 도구(Ngen.exe) – 관리된 어셈블리로부터 원시 이미지를 생성하고 로컬 컴퓨터의 원시 이미지 캐시에 설치한다.
    • 
	
  • .NET 프레임워크 설정 도구 (Mscorcfg.msc) – 원격 서비스를 사용하는 .NET 프레임워크 보안 정책과 애플리케이션을 관리하기 위한 그래픽 인터페이스를 제공한다. 이 도구를 이용해 전역 어셈블리 캐시에서 어셈블리를 관리하고 설정할 수 있다.
    • 
	
  • .NET 서비스 설치 도구 (Regsvcs.exe) – 어셈블리 로딩 및 등록, 그리고 유형 라이브러리를 기존 COM+1.0 애플리케이션에 생성하고 등록하고 설치함으로써 관리된 클래스를 윈도우 2000 구성요소 서비스에 추가한다.
    • 
	
  • Soapsuds 도구 (Soapsuds.exe) – 리모팅(remoting)이라는 기법을 이용해 XML 웹서비스와 통신하는 클라이언트 애플리케이션을 컴파일 할 수 있도록 한다.
    • 
	
  • 유형 라이브러리 출력자 (Tlbexp.exe) – 공통 언어 수행 어셈블리로부터 유형 라이브러리를 생성한다.
    • 
	
  • 유형 라이브러리 입력자 (Tlbimp.exe) – COM 유형 라이브러리에서 확인된 유형 정의를 관리되는 메타데이터 포맷의 정의에 따라 변환한다.
    • 
	
  • 웹서비스 디스커버리(Discovery)도구 (Disco.exe) –웹서버에 위치한 XML 웹서비스의 URL을 탐색(discover)하며, 각 XML 웹서비스에 관련된 문서들을 로컬 디스크에 저장한다.
    • 
	
  • WSDL 코드 생성 도구 (Wsdl.exe) – WSDL 약정(contract) 파일, XSD 스키마 파일, 그리고 ‘discomap’ 디스커버리(Discovery) 문서를 이용해 웹서비스와 웹서비스 클라이언트에 대해 코드를 생성한다
    • 
	
  • XML 스키마 정의 도구 (Xsd.exe) – W3C에 의해 제안된 XML 스키마 정의 (XSD) 언어를 따르는 XML 스키마를 생성한다. 이 도구는 공통 언어 실행 클래스와 ‘DataSet’ 클래스를 XSD 스키마 파일로부터 생성한다.
    • 







10.3.2.2 오류 수정 도구


    
	
  • 마이크로소프트 CLR 오류 수정 도구(DbgCLR.exe) – 애플리케이션 개발자들이 실행을 목표로 하는 프로그램에서 오류를 발견하고 고칠 수 있도록 그래픽 인터페이스를 가진 오류 수정 서비스를 제공한다.
    • 
	
  • 실행 오류 수정 도구 (Cordbg.exe) – 공통 언어 실행 오류 수정 API를 사용해 명령라인(command-line) 방식의 오류 수정 서비스를 제공한다. 이 도구를 실행을 목표로 하는 프로그램에서 오류를 발견하고 수정하는데 사용하기 바란다.
    • 







10.3.2.3 보안 도구


    
	
  • 인증서 생성 도구(Makecert.exe) – 시험용으로만 X.509 인증서를 생성한다.
    • 
	
  • 인증서 관리 도구(Certmgr.exe) – 인증서, 인증서 신뢰 목록 (certificate trust list, CTL), 그리고 인증서 폐기 목록(certificate revocation list, CRL)을 관리한다.
    • 
	
  • 인증서 검증 도구(Chktrust.exe) – X.509 인증서로 서명된 파일의 유효성을 검증한다.
    • 
	
  • 코드 접근 보안 정책 도구(Caspol.exe) – 장비, 사용자 및 전사적 수준(enterprise-level)의 코드 접근 보안 정책을 검사하고 변경한다.
    • 
	
  • 파일 서명 도구(Signcode.exe) – 휴대 가능한 실행 (portable executable, PE) 파일에 검증코드 (Authenticode) 전자서명을 한다.
    • 
	
  • 허가사항 보기 도구(Permview.exe) – 어셈블리에 의해 요청된 최소의, 선택적이며 거부된 허가요청 사항들을 보여준다. 이 도구를 사용해 어셈블리에 의해 사용되는 모든 선언적 보안사항(declarative security)을 볼 수 있다.
    • 
	
  • PE검증 도구(PEverify.exe) – MSIL 유형의 안전성 검증을 확인하고, 특정 어셈블리에서 메타데이터 검증 확인을 한다.
    • 
	
  • Secutil 도구(Secutil.exe) – 어셈블리에서 강력한 이름 공개 키(public key)정보나 검증코드 발행자 인증서를 코드로 병합할 수 있는 포맷으로 압축 해제한다.
    • 
	
  • 레지스트리 설정 도구(Setreg.exe) – 소프트웨어 발행상태 키의 레지스트리 설정을 변경하도록 하여, 인증서 검증 절차의 행동을 조절할 수 있도록 한다.
    • 
	
  • 소프트웨어 발행 인증서 시험 도구(Cert2spc.exe) – 시험용도로만 소프트웨어 발행자의 인증서(SPC)를 하나 이상의 X.509 인증서로부터 생성한다.
    • 
	
  • 강력한 이름 도구(Sn.exe) – 강력한 이름(strong name)을 가진 어셈블리를 생성하는 데 도움을 준다. Sn.exe는 키 관리, 서명 생성, 그리고 서명 검증에 대한 옵션을 제공한다.
    • 







10.3.2.4 일반 도구


    
	
  • 공통 언어 실행 미니덤프(minidump) 도구(Mscordmp.exe) – 실행시의 시스템 문제들을 분석하는 데 유용한 정보를 포함하는 파일을 생성한다. 마이크로소프트 Dr.Watson (Drwatson.exe)은 이 프로그램을 자동적으로 호출한다.
    • 
	
  • 라이센스 수집(Lc.exe) – 라이센싱 정보를 포함하는 텍스트 파일을 읽고 공통언어 실행에 임베딩될 수 있는 라이선스 파일을 만든다.
    • 
	
  • 강력한 관리유형 클래스 생성자(Mgmtclassgen.exe) – C#, 비주얼베이직, 또는 윈도우 관리 도구(WMI) 클래스의 JScript에서 조기 바인딩된 클래스를 생성할 수 있도록 한다.
    • 
	
  • MSIL 어셈블러(Ilasm.exe) – 마이크로소프트 중계 언어(MSIL)로부터 PE파일을 생성한다. 이 과정에서 생겨나는 실행파일을 실행시킬 수 있다. 이 실행파일은 MSIL 코드가 예상대로 실행되는지 확인하기 위해 MSIL 코드와 필요한 메타데이터를 포함한다.
    • 
	
  • MSIL 분해기(Ildasm.exe) – MSIL 코드를 포함하는 PE파일을 가지고 MSIL 어셈블러 (Ilasm.exe)에 입력에 적합한 텍스트 파일을 생성한다.
    • 
	
  • 자원 파일 생성자 도구(Resgen.exe) – 텍스트 파일과 .resx (XML 기반 자원 포맷) 파일을 런타임 바이너리 실행파일에 임베딩될 수 있거나 위성 어셈블리내에 컴파일 될 수 있는 .NET 공통언어 실행 바이너리.자원 파일로 변환한다.
    • 
	
  • Visual J# 바이너리 변환 도구(Jblmp.exe) – 특정 자바언어 바이트코드(.class) 파일을 MSIL로 변환한다. 이 도구는 개발자들이 대부분의 JDK 1.1.4급 라이브러리와 바이트코드 파일로만 가용한 응용프로그램을 MSIL 어셈블리로 변환할 수 있도록 하며 이를 비주얼 J# 재배포가능 패키지를 통해 .NET 프레임워크에서 실행시킨다. 응용프로그램이나 라이브러리의 자바 언어 소스가 가용하지 않은 경우에만 이 도구를 사용한다. 자바 언어 소스가 사용 가능한 경우, 대신 비주얼 J# 컴파일러(vjc.exe)를 사용한다(이 도구를 사용하기 위해서는 비주얼 J# 재배포가능 패키지 1.1 버전이 반드시 설치되어야 한다).
    • 
	
  • 윈도우 폼 ActiveX 컨트롤러 입력자(Aximp.exe) – COM 유형 라이브러리에서의 유형 정의를 윈도우 폼 콘트롤로 변환환다.
    • 
	
  • 윈도우 폼 클래스 뷰어(Wincv.exe) – 특정 검색 패턴에 맞는 관리대상 클래스를 발견하고 리플렉션(reflection) API를 사용하는 클래스에 대한 정보를 보여준다.
    • 
	
  • 윈도우 폼 자원 에디터(Winres.exe) – ‘WindowsForms’ 양식을 더 쉽고 빠르게 로컬화할 수 있도록 한다.
    • 














11 추가작업

자동생성 파일의 개발을 위해 추가적으로 이루어져야 할 작업은 다음과 같다.

    
	
  1. 새로운 SOAP 기능을 위한 지원에는 다음 사항이 포함된다.

      
	
    • 신뢰가능한 메시징 – 응용프로그램간 통신의 신뢰성을 보장하기 위해서 SOAP 메시징 프로토콜이 사용되어야 한다. TCP는 SOAP 메시지를 다루기 위해서 필요한 통신 스택(communication stack)에 적절한 수준으로 작동하지 않는다.
      • 

    

    2. 
	
  2. SOAP 1.2의 채택 – 기존 프로파일은 SOAP 1.1을 기반으로 하지만 SOAP 1.2가 현재 사용가능하게 되었다. 하지만 SOAP 1.2의 사용을 지원할 신뢰가능한 도구들이 개발되기 전에는 IMS 웹서비스 베이스 프로파일의 변경을 고려하지 않을 것이다
    3. 
	
  3. WSDL 2.0의 채택 – W3C는 WSDL 2.0을 개발 중이다(초기에는 1.2버전으로 참조되었다). 중계자 표현(intermediate representation)을 변경한다고 해서 생성될 실제 SOAP 메시지들이 변하지는 않지만, 보다 향상된 표현들은 WSDL 파일에 보다 복잡한 바인딩이 기술될 수 있도록 할 것이다. WSDL 2.0의 지원을 가능하게 할 신뢰가능한 도구들이 개발되기 전까지는 IMS 웹서비스 베이스 프로파일의 변경을 고려하지 않을 것이다
    4. 
	
  4. 적합성 요청 삽입에 대한 지원 – 이는 WS-I 적합성 요청 매커니즘 또는 WS-정책의 사용을 기반으로 한다.
    5. 
	
  5. 적합성 정보의 자동생성 – 원칙적으로는 UML 기술에서 직접 적합성 테스트 집합을 자동 생성하는 것이 가능하다. 또한, 적합성 명세의 구성요소를 식별하기 위해 스테레오타입 (stereotype)을 사용해 표준에 지시자(indicator)를 표시할 수 있다.
    6. 
	
  6. 관련 공개 서비스 인터페이스 정의 (OSID)의 자동생성 – UML 기술의 적절한 정보를 캡슐화함으로써 새로운 OSID를 생성할 수 있다. XSL의 사용은 OSID의 자동생성을 가능하게 할 수 있다. 이는 공통 UML 기술을 통해 웹서비스/OSID 조합을 생성할 수 있다. 
    7. 








부속서 A(참고)


바인딩 지원 XSD 파일

다음 데이터 구조들은 WSDL 파일들 내에서 정의되거나 외부 XSD 파일: ‘imsMessBindSchemav1p0.xsd’에서 제공된다.



A.1 상태정보




A.1.1 상태 클래스 데이터 모델

디스크립션(Description)

그림 A1.1에는 ‘StatusInfo’ 클래스 다이어그램을 제시하고 있다. 이 클래스는 관련 요청의 결과를 보고하는 상태정보를 반환 하기 위해 사용된다.

IMS KR 1005-6_A1.1


그림 A1.1 상태정보 클래스 다이어그램

속성(attributes)

표 A1.1에서는‘StatusInfo’ 클래스의 속성들을 요약하여 제시하고 있다.

표 A1.1 ‘StatusInfo’ 클래스의 속성 요약









속성명




유형




다중성




내용






codeMajor
CodeMajor
1
상태블록에 지정된 주요 코드. 이는 고정된 열거목록이며, ‘severity’와 연계해 사용된다.




severity
Severity
1
상태보고서의 중요도. 이는 고정된 열거목록이며, ‘codeMajor’와 연계해 사용된다.




codeMinor
CodeMinor
0..1
실패의 특정 원인을 식별하는 데 사용되는 상세한 보고 코드.




messageRefIdentifier
String
1
응답을 호출하는 요청 메시지의 메시지 식별자




operationRefIdentifier
String
0..*
이 상태블록에서 상태가 보고되는 특정 오퍼레이션(들)의 식별자




description
String
0..1
사람이 읽을 수 있는 메시지나 보고서





OCL 정의

이 클래스의 관련 객체 제한 언어 설명은 다음과 같다.

콘텍스트 상태정보(Context StatusInfo)

inv: Set{success, processing, failure, unsupported}.includes(codeMajor)

inv: Set{status, warning, error}.includes(severity)

inv: codeMinorName.size <= 32

inv: codeMinorValue.size <= 32

inv: messageRefIdentifier.size <= 32

inv: operationRefIdentifier.size <= 32

’CodeMajor/Severity’ 매트릭스 해석

표 A1.2에서는 ‘CodeMajor/Severity’ 매트릭스의 해석을 제시하고 있다.

표 A1.2 ' CodeMajor/Severity' 매트릭스의 해석









중요도 




주요코드 








성공 




처리 




실패 




지원되지 않음 








상태 


요청이 성공적으로 이루어짐.
요청이 대상에 의해 처리되고 있음. 즉, 요청이 수신되어 통신 대상 처리자가 인지함.
요청이 실패함. 관련 하위코드 정보는 요청 실패에 대한 보다 상세한 원인내역을 담고 있음.
대상은 요청된 오퍼레이션을 지원하지 않음. 이 요청은 원래 서비스 표준의 일부임.






경고 


요청의 일부분이 성공적으로 이루어짐. 즉, 저장된 자료 구조의 일부가 부분적으로 보내짐.
요청이 처리중임(이는 통신 대상 처리자가 수신을 했음을 의미하지는 않는다). 하지만 그 통신 대상이 수신한 것으로 확인되지는 않음.
허용되지 않음.
허용되지 않음.






오류 


허용되지 않음.
직접 전송 통신 처리자에서 오류가 감지됨. 즉, 메시지는 종단 시스템에서 전송되지 않음.
요청이 실패했지만 통신 처리자로부터 보내짐. 보다 상세한 오류 보고서가 포함될 수 있음. SOAP 오류 코드는 이 CodeMajor/Severity (하위코드 객체에서 제공됨)를 이용해 보고됨.
알려지지 않은 서비스 요청임. 즉, 원래 서비스 표준의 일부가 아님.





’CodeMinor’의 값

표 A1.3에서는 사전정의된 ‘CodeMinor’의 집합을 제시하고 있다(이는 공통 코드의 초기 집합이다. 각 표준은 자체적으로 코드를 정의해아 한다).

표A1.3 사전정의된 ‘CodeMinor’’ 코드









논리적이름(Logical Name)




생성에대한설명






성공적 서비스 완성 코드




' fullsuccess'
요청은 요청을 받는 목표 시스템에 의해 성공적으로 그리고 완전하게 구현됨.




' statealreadysuccess'
목표 객체가 이미 요청상태에 있기 때문에 요청은 성공적으로 구현됨




' unsupported'
요청 서비스는 요청을 받는 목표 시스템에 의해 지원되지 않음.




...





트랜잭션 서비스 소스 실패 상태 코드




' incompletesourcedata'
기록이 존재하지 않기 때문에 소스는 메시지를 최소한의 데이터 집합으로 전송할 수 없다.




'invalidsourcedata'
데이터가 유효하지 않으므로, 즉 잘못된 유형이므로 소스는 메시지를 보낼 수 없다.




...





트랜잭션 서비스 타겟 실패 상태 코드




' overflowfail'
타겟 배치 메모리 부족으로 인해 타겟은 객체 기록을 생성할 수 없다.




'idallocfail'
가용한 식별자가 더 이상 없기 때문에 타겟은 고유한 ‘식별자’를 객체에 할당할 수 없다.




'incompletetargetdatafail'
타겟은 레코드를 위해 수신된 최소한의 데이터가 존재하지 않음을 감지하였다.




'invalidtargetdatafail'
타겟은 수신된 데이터 일부가 유효하지 않음, 즉 잘못된 유형임을 감지하였다..




'duplicateidallocfail'
타겟은 현재 제공된 ‘식별자’가 이미 객체에 할당되었기 때문에 이를 다시 할당할 수 없다.




'unknownidfail'
타겟은 제공된 ‘식별자’를 가진 객체를 발견할 수 없다.




'invalididfail'
제공된 ‘식별자’를 사용해 식별된 레코드는 올바른 객체 유형이 아니다.




'corruptionfail'
타겟이 오류가 있는 저장된 레코드를 발견하여 이를 반환할수 없다.




'partialdatastorage'
타겟이 수신된 데이터 구조의 하위집합만을 저장하였다. 즉, 필수 요소들만 저장되었다.




...





공통 서비스 소스 실패 상태 코드




GWS 2.0버전에서 앞으로 정의될 예정





공통서비스타겟실패상태코드




GWS 2.0버전에서 앞으로 정의될 예정





인프라 소스 실패 상태 코드




'targetcommsfail'
타겟 시스템은 요청에 응답하지 않음. 통신 연결 실패가 일어남.




'sourcecommsfail'
소스 시스템은 요청을 보낼 수 없음. 통신 연결 오류가 있음.




...





인프라 타겟 실패 상태 코드




GWS 2.0버전에서 앞으로 정의될 예정






XSD 바인딩

그림 A1.2에서는 식별자 클래스의 XML 바인딩을 제시하고 있다. 이 바인딩은 복합유형(complex-type) StatusInfo 유형의 생성에 기반한다.

IMS KR 1005-6_A1.2


그림 A1.2 상태정보 클래스 XSD 바인딩







A.1.2 ‘StatusInfoSet’ 클래스 데이터 모델

디스크립션(Description)

그림 A1.3에서는 StatusInfoSet 클래스 다이어그램은 제시하고 있다. 이는 StatusInfo 클래스의 집합이며 그 순서는 개별 오퍼레이션이 요청된 순서를 반영한다.

IMS KR 1005-6_A1.3


그림 A1.3 상태정보집합 클래스 다이어그램

속성(Attributes)

없음.

연관성(Associations)

표A1.4에서는 StatusInfoSet 클래스에 대한 연관성을 요약 제시하고 있다.

표 A1.4 StatusInfoSet 클래스의 연관성 요약









연관클래스이름




다중성




설명






StatusInfo
1..*
모든 오퍼레이션에 각각 반환되는 상태정보 클래스. 각 상태정보 인스턴스는 각 오퍼레이션의 상태를 참조한다.





OCL정의

없음.

XSD 바인딩

그림 A1.4에서는 식별자 클래스의 XML 바인딩을 제시하고 있다. 이 바인딩은 복합유형 ‘StatusInfoSet.Type’의 생성에 기반한다.

IMS KR 1005-6_A1.4


그림 A1.4 상태정보집합 클래스 XSD 바인딩









A.2 동기식 모델의 메시지 헤더 구조

다음 구조들은 동기식, 비동기식, 그리고 폴링 메시지 구성에 사용되어 행동을 구현하는 메시지 헤더들이다.

A2.1 - 동기식 요청 메시지 헤더

그림 A2.1에서는 동기식 요청 메시지 헤더 구조를 제시하고 있다. 이 헤더는 클라이언트 시스템에 의해 발행되는 요청 메시지에 첨부된다. ‘wildCard’ 확장 요소는 어떠한 네임스페이스를 가진 요소라도 사용될 수 있도록 허용한다.

IMS KR 1005-6_A2.1


그림 A2.1 동기식요청헤더정보 메시지 헤더 XSD 바인딩

<version> 요소

채택된 웹서비스 표준 인프라 버전의 컨테이너며, 열거된 필드이다. 이것은 선택사항 필드이며 사용되지 않는 경우 기본 값은 ‘1.0’으로 간주된다.

<messageIdentifier>요소

고유 메시지 식별자의 컨테이너다. 메시지 헤더를 구성하는 시스템에 의해 지정되어야 한다. 메시지 식별자의 고유성을 보장하는 것은 전송 시스템의 책임이다.



A.2.1 동기식 응답 메시지 헤더

그림 A2.2에서는 동기식 응답 메시지 헤더 구조를 제시하고 있다. 이 헤더는 서버 시스템에서 발행된 응답 메시지에 첨부된다. ‘wildCard’ 확장 요소는 어떠한 새로운 네임스페이스를 가진 요소라도 사용될 수 있도록 허용한다.

IMS KR 1005-6_A2.2


그림 A2.2 동기식요청헤더정보 메시지 헤더의 XSD 바인딩

<version> 요소

이는 채택된 IMS 웹서비스 인프라의 버전에 대한 컨테이너며, 열거된 필드이다. 이는 선택사항 필드이며, 사용되지 않는 경우 기본값은 1.0으로 간주된다.

<messageIdentifier> 요소

고유한 메시지 식별자의 컨테이너다. 이는 메시지 헤더를 구성하는 시스템에 의해 지정된다. 메시지 식별자가 고유함을 보장하는 것은 전송 시스템의 책임이다.

<statusInfo> 요소

A1.1.단일 전송 요청에 대한 상태정보이다. A1.1를 참조한다.

<statusInfoSet> 요소

다중 전송 요청에 대한 응답으로 반횐된 상태정보이다. A1.2를 참조한다.








A.3 비동기식 모델에 대한 메시지 헤더 구조

현재 IMS는 비동기식 WSDL 메시징의 최종본 발행을 승인하지 않은 상태이다. 이는 이 기법에 대한 검증된 구현물이 없기 때문이며, W3C는 이 IMS 접근법이 독점적이 될 수 있도록 작업을 진행 중이다. 이 작업은 공개초안으로 발행되었다.






A.4 폴링 모델에 대한 메시지 헤더 구조

현재 IMS는 폴링 WSDL 메시징의 최종본 발행을 승인하지 않은 상태이다. 이는 이 기법에 대한 검증된 구현물이 없기 때문이며, W3C는 이 IMS 접근법이 독점적이 될 수 있도록 작업을 진행 중이다. 이 작업은 공개초안으로 발행되었다.









해설

이 해설은 본체 및 부속서에 규정ㆍ기재한 사항 및 이것에 관련된 사항을 설명하는 것으로 표준의 일부는 아니다.

1. 제정의 취지 

이러닝 서비스 다양화 및 고도화에 따라 이러닝 표준에 대한 필요성과 수요가 나날이 급증하고 있으며, 나아가 표준화를 지향하고 있는 국내외적 요구와 환경에 대응하기 위한 기반 마련이 시급하다.

또한, 국제 이러닝 표준화 분야에서 선진국간의 치열한 경쟁이 심화되고 있는 시점에서 국내 산업 및 국가 지식경쟁력 강화를 위한 실천적 차원의 표준화 추진 사례가 부족한 실정이다.

따라서 이러닝 표준화 요소 중 글로벌 경쟁력을 갖춘 웹서비스 표준을 우선 단체표준으로 제안함으로써 산업 경쟁력 및 교육경쟁력 강화를 도모하고자 한다. 효율적인 단체표준 개발을 위해 IMS 웹서비스 표준을 인용하였다.

2. 제정의 경위

    
	
  • 제1차 개발위원회(2009.1.): 단체표준 개발을 위한 참여 전문가를 위촉하고 규격 제정 취지와 규격의 제정 방향을 설정하였고, 초안 작성 기준을 토의하였다.
    • 
	
  • 제2차 개발위원회(2009.3.): IMS GLC의 이러닝 표준을 기초로 작성한 초안을 통하여 부합화에 적합한 표준 용어를 정의하였다.
    • 
	
  • 제3차 개발위원회(2009.5.): 기초(안)을 작성하여 적용범위, 인용표준, 용어정의 등의 내용을 검토하고, 참여진의 표준의 이해도를 높이기 위해 규격에 대한 검수 작업을 실시 하였다.
    • 
	
  • 제4차 개발위원회(2009.6.): 표준 수정(안)을 토대로 IMS Korea 표준화 포럼의 표준 심사위원회를 통하여 표준을 검토하고 의견을 수렴하였다.
    • 


a) 규격서의 서식은 KS A 0001 : 2008의 규격서를 기준으로 하여 작성하였다.

b) 양식은 기존의 유사 KS규격을 인용하였으며, IMS와 부합화된 최신규격을 적용하였다

3. 심의 중 주요 논의 및 수정사항 

    
	
  1. 인용 표준의 형식은 KS A 0001의 구성에 맞게 조정하며, 연도는 삭제한다. (2009년 6월)
    2. 
	
  2. 표준 규격서의 목차는 적용 범위 인용표준, 용어 정의 순으로 목차를 정렬 하며, 단, 원문에 서론이 있는 경우 서론은 유지한다. (2009년 6월)
    3. 
	
  3. NETg, Boein Coporation와 같은 고유한 회사명은 A, B 형태의 가칭으로 대체 표기한다. (2009년 6월)
    4. 
	
  4. 그림, 표, 본문 등에 포함된 영어를 최대한 번역하여 국문으로 표기한다. (2009년 10월)
    5. 
	
  5. MS GLC의 표준 인용 정책에 의하여 페이지의 'IPR 공지’ 및 'IMS 로고’ 적용은 현행을 유지하며, 규격의 매 페이지마다 포함된 copyright 표기 문구는 삭제한다. (2009년 10월)
    6. 
	
  6. 규격에 해설서(제정의 취지 등) 내용을 추가 작성한다. (2009년 10월)
    7. 


4. 적용 범위 

IMS 웹서비스(General Web Services, 이하 GWS) 표준의 목적은 IMS GLC 표준 개발의 일환으로 웹서비스를 사용하려 하는 프로젝트 팀들에게 지침을 제시할 프레임워크를 제공하는 것이다. IMS 웹서비스 WSDL 바인딩 지침은 다음 기준을 충족하는 방법론을 제공한다.

    
	
  • 상호운용성(interoperability) – IMS 웹서비스 표준 활동에서 생산되는 산출물은 서로 다른 소프트웨어와 운영체제 플랫폼 환경에서 웹서비스 표준 구현물간의 상호운용성을 증진하는 매커니즘과 표준을 추구한다.
    • 
	
  • 효율성(efficiency) – IMS 웹서비스 표준 활동에서 생산되는 산출물은 IMS의 다른 표준활동에서 기능적 요구사항과 관련 있는 웹서비스 프로토콜을 효율적이고 효과적으로 검증하는 것을 도울 수 있도록 설계해야 한다.
    • 
	
  • 일관성(consistency) – IMS 웹서비스 표준 활동에서 생산되는 산출물은 일반 웹서비스 활동으로 생산된 인공물들은 각기 다른 IMS 표준제정 활동 및 제정하는 표준에서 웹서비스 프로토콜을 구현하고자 할 때 일관된 접근방법에 기반한 실행을 지원할 수 있도록 설계되어야 한다.
    • 
	
  • 유연성(flexibility) – IMS 웹서비스 표준 활동에서 생산되는 산출물은 ‘SOAP’처럼 진화하는 웹서비스 프로토콜에 적응할 수 있고, WSDL (Web Service Description Language)처럼 다양한 웹서비스 바인딩 방법들에도 적용할 수 있도록 유연해야 한다.
    • 
	
  • 실용성(practicality) – IMS 웹서비스 표준 활동에서 생산되는 산출물은 기업들이 IMS GLC 기반의 웹서비스 솔루션을 개발할 수 있는 역량을 지원할 수 있어야 하고, 플랫폼 및 웹서비스 프로토콜 벤더간에 상호운용성을 구현할 수 있도록 독려할 수 있어야 한다.
    • 


IMS 웹서비스 WSDL 바인딩 가이드는 IMS 웹서비스 베이스 프로파일, IMS 추상 프레임워크, 그리고 특정 표준의 정보 모델에 내재한 비즈니스 지식을 사용해 웹서비스 바인딩을 생성하는 과정을 보여준다. IMS 웹서비스 WSDL 바인딩 가이드는 정보수집, 정보가공, 그리고 웹서비스 프로토콜과 바인딩을 적절히 상세하게 설명하기 위해서 권장된 도구들을 이용하는 방법에 대한 지침을 프로젝트 그룹들에게 제시한다. 이 방법론은 웹서비스 방법론과 IMS GLC 표준간의 관계와 역할을 설명하기 위한 글과 그림을 포함하고 있다. WSDL 바인딩 파일 생성을 위해 표준을 설명하고 표현하는데 있어 UML을 이용한다. UML의 XMI (XML Metadata Interchange) 표현은 이후 자동생성을 위해 사용된다. 자동화된 변환작업은 그 XMI에 해당하는 일련의 WSDL과 XSD (Extensible Schema Definition) 파일을 생성하기 위해 특별히 개발된 하나 이상의 XSLT (Extensible Stylesheet Language Transformations)를 해당 XMI에 적용함으로써 이루어진다.

5. 표준개발 참여자 

이 규격의 초안은 IMS Korea 표준화 포럼 활동으로 작성되었으며, 규격 개발에 참여한 전문가는 다음과 같다.

표준개발 참여자(경칭생략, 무순)









성 명




근 무 처




직 위








조용상


한국교육학술정보원


팀장








김종현


계원디자인예술대학


교수








김현진


한국교원대학교


교수








정광식


한국방송통신대학교


교수








황대준


성균관대학교


교수








고영승


(주)디유넷


대리








이정우


(주)포씨소프트


차장








장근원


(주)크레듀


과장








정호원


(주)씨티유니온


차장








지승환


테크빌닷컴(주)


차장








최성기


SK C&C


과장








권영진


한국교육학술정보원


연구원








최미애


한국교육학술정보원


연구원