speclogo

IMS 웹서비스 - 베이스 프로파일
발행일 2009년 00월 00일
최신 버전 IMS 웹서비스 – 베이스 프로파일 버전 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 웹서비스 서비스 바인딩은 다음 기준을 충족하는 방법론과 어플리케이션 프로파일을 제공한다.
  • 상호운용성(interoperability) – IMS 웹서비스 표준 활동에서 생산되는 산출물은 서로 다른 소프트웨어와 운영체제 플랫폼 환경에서 웹서비스 표준 구현물간의 상호운용성을 증진하는 매커니즘과 표준을 추구한다.
  • 효율성(efficiency) – IMS 웹서비스 표준 활동에서 생산되는 산출물은 IMS의 다른 표준활동에서 기능적 요구사항과 관련있는 웹서비스 프로토콜을 효율적이고 효과적으로 검증하는 것을 도울 수 있도록 설계해야 한다.
  • 일관성(consistency) – IMS 웹서비스 표준 활동에서 생산되는 산출물은 일반 웹서비스 활동으로 생산된 인공물들은 각기 다른 IMS 표준제정 활동 및 제정하는 표준에서 웹서비스 프로토콜을 구현하고자 할 때 일관된 접근방법에 기반한 실행을 지원할 수 있도록 설계되어야 한다.
  • 유연성(flexibility) – IMS 웹서비스 표준 활동에서 생산되는 산출물은 ‘SOAP’처럼 진화하는 웹서비스 프로토콜에 적응할 수 있고, WSDL (Web Service Description Language)처럼 다양한 웹서비스 바인딩 방법들에도 적용할 수 있도록 유연해야 한다.
  • 실용성(practicality) – IMS 웹서비스 표준 활동에서 생산되는 산출물은 기업들이 IMS/GLC 기반의 웹서비스 솔루션을 개발할 수 있는 역량을 지원할 수 있어야 하고, 플랫폼 및 웹서비스 프로토콜 벤더간에 상호운용성을 구현할 수 있도록 독려할 수 있어야 한다.
IMS 웹서비스 베이스 프로파일은 웹서비스를 정의하기 위한 기본 구조를 제공한다. 베이스 프로파일(Base Profile)은 상호운용성을 증진하는 명시 및 보완사항들과 함께 비독점 웹서비스 표준들로 구성되어 있다. IMS 웹서비스 베이스 프로파일은 웹서비스 표준을 구현하는 과정에서 흔히 경험하는 문제들을 다룬다. IMS 웹서비스 베이스 프로파일은 널리 알려지고, 폭넓게 구현되거나 유용한 참조 표준들 내에 존재하는 매커니즘들의 선택방법을 정의한다. IMS 웹서비스 베이스 프로파일들은 IMS 표준 개발 방법론과 추상 프레임워크와 일치하는 문법규약들을 포함한다. IMS 웹서비스 베이스 프로파일은 각각 다른 소프트웨어와 벤더들의 플랫폼 상에서 웹서비스 기반 표준 구현에서의 상호운용성을 증진한다. 베이스 프로파일은 핵심 웹서비스 표준 집합과 알려진 웹서비스 표준들의 구현에서 흔히 경험하는 문제들에 초점을 맞춘다. IMS 웹서비스 베이스 프로파일은 웹서비스를 지원하는 플러그 앤 플레이 아키텍처를 만들거나 완전한 상호운용성을 보장하는 것을 목표로 하지는 않는다. IMS 웹서비스 베이스 프로파일은 어플리케이션 계층에서의 상호운용성, 특히 웹서비스를 통해 노출되는 동작들에 대한 설명을 다룬다. IMS 웹서비스 베이스 프로파일은 낮은 계층 프로토콜의 상호운용성은 충분하다고 가정한다. 이 문서는 IMS 웹서비스 베이스 프로파일에 대한 확장 방법을 포함한 권고사항들과 활용사례들을 포함하고 있다. 이러한 확장은 오류 처리, 보안, 매니페스트, 콘텍스트와 라우팅 등 추상 프레임워크의 일반 서비스 계층에 대한 웹서비스 바인딩 생성의 가이드를 제시한다. IMS GLC는 W3C에서 개발한 웹서비스 표준과 규격을 더 구체화하기 위해 베이스 프로파일을 기반으로 하여 보완적인 프로파일들을 정의한다. 그러므로, 이 문서는 IMS 웹서비스 확장 프로파일들과 IMS 웹서비스 WSDL 바인딩 가이드라인과 함께 읽어야 한다. 앞서 언급한 두 가지 문서들을 작성할 때 참조한 용어는 프로젝트 헌장 원본에 정의되어 있다.

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, 05a : IMS Application Profile Guidelines Whitepaper: Part 1 Management Overview, S.Wilson and K.Riley, Version 1.0, IMS GLC.
  • APG, 05b : IMS Application Profile Guidelines Whitepaper: Part 2 Technical Manual, S.Wilson and K.Riley, Version 1.0, IMS GLC.
  • BPEL, 03 : Business Process Execution Language for Web Services, T.Andrews, F.Curbera, H.Dholakia, Y.Goland, J.Klein, F.Leymann.K.Liu, D.Roller, D.Smith, S.Thatte, I.Trickovic
  • and S. Weerawarana, V1.1, BEA Systems, IBM, Microsoft, SAP and Siebel Systems.
  • Cockburn, 01 : Writing Effective Use-case, A.Cockburn, Addison-Wesley, 2001, ISBN 0-201-70225-8.
  • ebXML, 01 : Message Service Specification ebXML Transport, Routing & Packaging, ebXML, Version 1.0.
  • GWS, 03a : General Web Services Project Team Charter, C.Schroeder, R.Kleinman and S.Griffin, IMS GLC.
  • GWS, 05a : IMS General Web Services Addressing Profile Final Release, C.Schroeder, J.Simon and C.Smythe, V1.0 IMS GLC.
  • GWS, 05b : IMS General Web Services Attachments Profile Final Release, C.Schroeder, J.Simon and C.Smythe, V1.0 IMS GLC.
  • GWS, 05c : IMS General Web Services Security Profile Final Release, C.Schroeder, J.Simon and C.Smythe, V1.0 IMS GLC.
  • GWS, 05d : IMS General Web Services WSDL Binding Guidelines Final Release, C.Schroeder, J.Simon and C.Smythe, V1.0 IMS GLC.
  • GWS, 05e : IMS Binding Auto-generation Toolkit Manual, C.Smythe, V1.0 IMS GLC.
  • GWS, 05f : IMS General Web Services UML to WSDL Binding Auto-generation Guidelines Public Draft, C.Schroeder, S.Raju and C.Smythe, V1.0 IMS GLC.
  • MTOM, 05 : SOAP Message Transmission Optimization Mechanism,
  • http://www.w3.org/TR/2004/CR-soap12-mtom-20040826/.
  • 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 Draft v5.0, C.Smythe, IMS GLC.
  • WSA, 03 : Web Services Architecture, D.Booth, H.Haas, F.McCabe, E.Newcomer, M.Champion, C.Ferris and D.Orchard, http://www.w3.org/TR/ws-arch/ W3C, W3C Working Draft.
  • WSAddress, 04 : W3C WS-Addressing Submission, http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810, W3C.
  • 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.0a, 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.0, Ed M.Nottingham, Web Services-Interoperability Organization.
  • WSR, 03 : Web Services Reliability (WS-Reliability), Version 1, OASIS Specification, OASIS.
  • XML, 04 : Extensible Markup Language (XML) 1.0 (Third Edition), T.Bray, J.Paoli, C.M.Sperberg-McQueen, E.Maler and F.Yergeau, W3C, W3C Recommendation.
  • XSD, 01 : XML Schema Part 0: Primer, Ed. D.C.Fallside, W3C, W3C Recommendation.

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 : 월드와이드웹 컨소시엄(World Wide Web Consortium)
  • WAN : 광대역 통신망(Wide Area Network)
  • WSA : 웹 서비스 구조(Web Service Architecture)
  • WSDL : 웹 서비스 기술 언어(Web Services Description Language)
  • WS-I : 웹서비스 상호운용성 (Web Services Interoperability Organization)
  • XMI : XML 메타데이터 인터페이스(XML Metadata Interface)
  • XML : 확장 마크업 언어(Extensible Mark-up Language)
  • XSD : XML 스키마 정의(XML Schema Definition)
  • XSLT : 확장 스타일시트 언어 변환(Extensible Stylesheet Language Transformations)

4 IMS 웹서비스 프로파일의 내용

<h3>4.1 문법 규약</h3>

4.1.1 IMS 추상 프레임워크의 권고사항

모든 IMS 서비스 지향 표준은 IMS 추상 프레임워크의 내용 안에서 정의될 것이다. 웹서비스는 IMS 서비스 지향 표준 바인딩의 한 가지 사례이다. 이 문서의 6장은 정보 모델에 기반해서 정의되는 여러 IMS 표준이 어떻게 적절한 ‘인프라 바인딩’을 통해 웹서비스들과 관련되는지를 정의한다.

4.1.2 국제 적합성 프로그램의 권고사항

IMS 국제 적합성 프로그램(IMS International Conformance Program)은 특정 정보모델과 바인딩이 어플리케이션 프로파일 가이드라인의 형태를 지닌 특정 도메인을 지원하기 위한 목적으로 어떻게 제한되는지를 정의한다. 적합성 검사에 대한 지원은 적절한 시점, 예를 들어 WS-I가 WSDL 파일에 적합성 명세를 포함할 때에 추가될 것이다.

4.1.3 IMS 바인딩 자동생성 툴킷의 권고사항

IMS 바인딩 자동생성 툴킷 문서는 UML을 이용하여 IMS 정보 모델을 문서화하는 방법을 설명한다. UML 설명은 관련 바인딩을 더 용이하게 할 수 있도록 설계되었다. 즉, UML 설명은 API 를 구현하는 관점에서 설계된 것은 아니다. 또 UML 설명은 XMI 파일로 변환하는 것이 가능하다. 이는 툴을 사용하여 UML 설명을 탑재하고 해당하는 코드 조각들(code stubs)을 생성할 수 있게 한다. IMS는 UML을 WSDL 등으로 자동 변환할 수 있는 XSLT 파일들을 개발하였다. 이러한 XSLT들과 관련 툴의 사용법은 IMS 바인딩 자동생성 툴킷 매뉴얼에 설명되어 있다.

4.1.4 W3C 웹서비스 아키텍처의 권고사항

WSA는 웹서비스를 이해하기 위한 배경과 모델을 제공하고, 웹서비스 표준과 기술이 WSA 외의 다른 기술들과 함께 더 큰 웹서비스 프레임워크 내에 위치할 수 있도록 하는 표준문서이다. WSA의 목표는 웹서비스의 공통 정의와 그 핵심 개념 및 관계를 통해 상호운용성을 증진하는 것이다. 웹서비스를 구현하는 방법을 자세히 설명하거나 웹서비스들의 조합이나 조율에 대한 제약조건을 부과하는 것은 WSA의 목적이 아니다. WSA는 다양한 관점에서 WSA의 핵심 개념과 관계를 논의한다. 적절하다고 판단된 경우, IMS는 WSA를 IAF에서 사용할 것이다. 웹서비스 아키텍처에 대한 더 자세한 정보를 얻으려면 W3C 웹서비스 아키텍처(http://www.w3.org/TR/ws-arch/)를 참조한다.

4.1.5 웹서비스 상호운용성 베이직 프로파일의 권고사항

IMS 웹서비스 베이스 프로파일은 WS-I 베이직 프로파일 1.1버전과 WS-I 심플 SOAP 바인딩 프로파일 1.0버전을 기반으로 한다. WS-I 베이직 프로파일은 표 4.1에 제시되어 있다. 표 4.1 WS-I 베이직 프로파일 1.1버전

핵심표준

기술
XML 스키마 1.0버전 모든 데이터 모델은 XML 스키마 관점에서 정의되며 관련 관리문서(XSD)의 정의가 필요하다.
HTTP 1.1버전 (RFC2616) HTTP는 SOAP 메시지에서 필수적인 프로토콜 바인딩이다.
SOAP 1.1버전 SOAP는 필수적인 메시징 프로토콜이다.
WSDL 1.1버전 서비스의 인스턴스는 WSDL 1.1버전을 사용해 정의한다. WSDL은 서비스를 메시지에 작동하는 종단의 집합으로 설명하기 위해 사용된다.
UDDI 2.0버전 서비스의 인스턴스는 UDDI 2.0버전 바인딩을 사용해 정의될 수 있다.
SOAP 1.2버전과 WSDL 2.0버전은 각각 SOAP 와 WSDL 표준의 차후 버전이 될 것으로 예상된다. SOAP 1.2버전과 WSDL 2.0버전은 향후 추가로 개정될 것이다. 채택된 표준들의 관점에서 보면 WS-I 베이직 프로파일 1.1버전과 심플 SOAP 바인딩 프로파일 1.0버전의 조합은 WS-I 베이직 프로파일 1.0a 버전과 동일하다는 점에 주의해야 한다.

4.2 핵심기술

4.2.1 XML

XML 1.0(3판)은 IMS 표준의 바인딩을 위해 채택한 핵심 데이터 표현 기술이다. IMS 데이터모델 지향 정보 모델은 계층 구조로 정의될 수 있다. 계층적 모델은 많은 요소와 하위 요소들로 구성된 데이터를 표현하는 데 편리하다. XML은 계층적 모델을 표현하는 데 매우 적합하다.

4.2.2 XML 스키마

XSD는 IMS의 가장 중요한 XML 바인딩 관리문서 포맷이다(현재 이들 바인딩은 XML 스키마의 2001년 5월 버전으로 적용되고 있다). XSD는 요소와 그 콘텐츠 모델 및 속성을 정의한다. 또한 표준 IMS 어휘(vocabularies)도 정의한다. XSD는 요소 유형과 속성 그룹을 요소와 분리하여 정의한다. 베이스 프로파일과 관련한 XML 스키마에 대한 핵심 권고사항은 다음과 같다.
  1. SOAP 메시지의 맥락에서 사용할 때 모든 데이터 구성은 요소로 정의되어야 하며 속성을 사용해서는 안 된다. 이는 WS-I의 권고사항을 따른다.
  2. 모든 데이터 속성은 ‘전역적’으로 정의되어야 한다. ‘지역적’ 데이터 유형의 사용은 ‘Axis’ 등 일부 WSDL 탑재 툴에서 문제가 발생한다.
  3. 모든 데이터 유형은 이름 끝에 문자열 ‘Type’을 지정해야 한다. 이는 인스턴스와 그 유형 이름의 중복을 피하기 위함이다.

4.2.3 SOAP

SOAP는 XML 문서를 위한 메시징 프로토콜로 분산 환경에서 동기계층 간에 구조화되고 유형화된 정보를 교환하는 데 사용한다. SOAP는 상태정보를 지니지 않은 단방향 메시지 교환 매커니즘이지만, 어플리케이션은 이러한 일방향적인 교환을 기본 전송 프로토콜 그리고/또는 어플리케이션의 특정적인 정보에 의해 제공되는 특징들과 조합함으로써 더 복잡한 상호작용 패턴(요청/응답, 요청/다중응답 등)을 생성할 수 있다. SOAP는 특정한 어플리케이션 정보를 확장 가능한 방법으로 전달할 수 있는 프레임워크를 제공한다. 또한 SOAP는 SOAP 메시지를 수신하면 SOAP 프로세서가 취할 것으로 예상되는 동작들에 대한 완전한 설명을 제공한다. SOAP 메시지는 전체 엔벨로프(envelope)에서 ‘헤더(header)’와 ‘바디(body)’의 두 가지 특정한 SOAP 하위 요소를 포함한다. 비록 ‘바디’는 이러한 요소들이 어떻게 다루어져야 하는지를 논하고 있지만, 이들 요소의 내용은 어플리케이션에서 정의되며 SOAP 표준의 일부는 아니다. ‘헤더’는 선택요소이다. 헤더는 SOAP의 다양한 활용을 위해 설계되었으며, SOAP의 여러 활용방법을 보면 송신자에서 최종 수신자에 이르는 메시지 경로에서 다른 SOAP 처리 노드들이 개입하여 SOAP 프로세서들이 정보 교환을 통해서 부가가치적인 서비스를 제공할 수 있도록 한다. 이는 SOAP 메시지들이 특정한 어플리케이션에 맞는 방법으로 확장되는 매커니즘을 형성한다. ‘바디’는 엔벨로프내에서 필수 요소이며 전달해야 하는 SOAP 메시지에서 주요 정보가 포함되는 곳이다. ‘헤더’의 직계 하위 요소를 헤더 블록이라고 부르며, 송신자로부터 수신자에게 이르는 메시지 경로에서 마주칠 수 있는 SOAP 노드들에 대해 목표대상을 지정할 수 있도록 논리적인 데이터의 분류를 표현한다. SOAP 엔벨로프는 시스템간에서 메시지 교환을 가능하게 하는 컨테이너(container)이다. 이들 메시지는 적절한 전송 매커니즘을 이용해 통신 시스템간에 물리적으로 전송될 필요가 있다. 많은 경우 HTTP가 이러한 전송 매커니즘으로 사용된다. 베이스 프로파일과 관련된 XML 스키마의 핵심 권고사항은 다음과 같다.
  1. SOAP 1.1버전/HTTP 1.1버전에 기반한 바인딩만이 지원된다.
  2. SOAP 메시지 바디는 관련 연산에서 정의된 모든 파라미터를 포함한다.
  3. 상태정보는 SOAP 메시지 헤더에 위치해야 한다.

4.2.4 WS-어드레싱

WS-어드레싱은 전송 프로토콜과 메시징 시스템에 의해 일반적으로 제공되는 정보 전달 방법을 위한 두 가지 상호운용적인 구조체를 정의한다. 이들 구조체는 이러한 기본정보를 전송하거나 또는 어플리케이션과는 독립적으로 처리될 수 있는 공통 포맷으로 표준화된다. 이 두 가지 구조체는 ‘종단 참조’와 ‘메시지 정보’ 헤더이다. 두 구조체는 다른 표준들이 종단 참조와 메시지 정보 헤더를 구축하고 강화할 수 있도록 확장과 재사용이 가능하도록 설계되었다. 웹서비스 종단은 웹서비스 메시지를 전달하고자 하는 위치의(참조 가능한) 개체(entity), 프로세서를 말한다. 종단 참조는 웹서비스 종단을 식별/참조하는데 필요한 정보를 전달하며, 여러가지 다른 방법으로도 사용될 수 있다. 예를 들어 종단 참조는 웹서비스 종단 접근(access)을 위한 필요 정보를 전달하는데 적합할 뿐만 아니라, 웹서비스로 메시지를 보내거나 웹서비스로부터 메시지를 받을 때에 개별 메시지에 주소를 부여하는 데에도 사용된다. 이 용도를 위해서 이 표준은 기본 전송과는 독립적으로 메시지의 표준화된 어드레싱을 허용하는 메시지 정보 헤더군을 정의한다. 이러한 메시지 정보 헤더들은 웹서비스 제공자와 목적지 종단, 그리고 메시지 식별자에 대한 어드레싱을 포함하는 종단간 메시지 특징들을 전달한다.

4.2.5 SOAP 메시지에 대한 첨부

SOAP 메시지에 대한 첨부는 여러 다양한 형태가 가능하다.
  1. 첨부가 있는 SOAP (SOAPwA: SOAP with Attachements) – 첨부가 있는 SOAPwA는 다중 메시지 페이로드(payload)를 지원하기 위해 MIME 바인딩을 제공함으로써 SOAP 1.1버전을 확장하지만, 반면에 RPC 인자(arguments)가 XML에서 마샬링되거나(marshalled) 언마샬링되는(unmarshalled) 규칙은 무시한다. SOAPwA는 특히 통신이 이루어지는 두 개체가 같은 조직 내에 위치하지 않을 때 적합하며, 교환 패러다임은 한 기업(또는 대학) 내에서의 동기식 RPC보다는 인터넷에서의 비동기식 문서 교환이 더 맞다.
  2. WS-첨부(WS-Attachments) – 이 표준은 SOAP 첨부에 대한 추상모델을 정의하며, 이 모델에 기반해 SOAP 메시지와 DIME 메시지 내에서 0 또는 하나 이상의 첨부를 캡슐화하는 매커니즘을 정의한다. SOAP 첨부는 SOAP 메시지와 첨부인 0 또는 하나 이상의 관련 문서들로 구성된 복합문서 구조의 개념을 사용하여 설명된다.
  3. MTOM (Message Transmission Optimization Mechanism) – MTOM은 SOAP 메시지들이 비XML 객체를 포함할 수 있도록 한 W3C 메시지 첨부 접근법 중 하나이다. MTOM은 SOAPwA가 발전한 것으로 SOAPwA 표준에 대한 대체방법으로써 제안되었다.
IMS 웹서비스에 대한 대체 첨부에 대한 권고사항은 IMS 웹서비스 첨부 프로파일 문서에 정의되어 있다.

4.2.6 WSDL

WSDL 문서는 서비스를 네트워크 종단, 또는 포트의 집합으로 정의한다. WSDL에서 종단과 메시지에 대한 추상적인 정의는 구체적인 네트워크 배치나 데이터 포맷 바인딩과는 분리한다. 이는 교환되는 데이터에 대한 개념적인 설명인 메시지와 연산에 대한 추상적 집합인 포트 유형이라는 추상적 정의를 재사용할 수 있게 한다. 특정 포트 유형에 대한 구체적인 프로토콜과 데이터 포맷 표준은 재사용 가능한 바인딩을 구성한다. 포트는 재사용 가능한 바인딩과 네트워크 주소의 조합으로 정의되며 포트의 집합은 서비스로 정의된다. 앞으로 WSDL 문서에서 네트워크 서비스를 정의하는데 다음과 같은 요소를 사용한다.
  • 유형(Type) – 일종의 유형 시스템(XSD 등)을 사용하는 데이터 유형 정의에 대한 컨테이너
  • 메시지(Message) – 통신되는 데이터에 대한 추상적이며 유형적인 정의
  • 연산(Operation) – 서비스에 의해 지원되는 행동(action)에 대한 추상적인 설명
  • 포트유형(Port Type) – 하나 이상의 종단에 의해 지원되는 연산의 추상적인 집합
  • 바인딩(Binding) – 특정 포트유형에 대한 구체적인 프로토콜과 데이터 포맷 표준
  • 포트(Port) – 바인딩과 네트워크 주소의 조합으로 정의되는 단일 종단
  • 서비스(Service) – 관련 종단들의 집합
베이스 프로파일과 관련하여 WSDL에 대한 핵심 권고사항은 다음과 같다.
  1. 바인딩을 통해 지원되는 통신 모드의 각 유형에는 별도의 WSDL 파일 집합이 정의되며, 하나의 물리적 파일 내에는 하나의 WSDL 바인딩 형태가 포함된다.
  2. 이에 대한 대안으로 XSD 정보가 나머지 WSDL 정의를 포함하는 별도의 파일에 정의된 분할파일 바인딩이 있다. WSDL 파일은 <xsd:import> 구조체를 이용해 XSD 정의를 임포트한다.
  3. 두 번째 대안은 WSDL 정의를 특정 서비스 파일과 추상파일, 그리고 XSD로 분할해 세 가지 별도의, 그러나 링크된 파일을 생성하는 것이다. 특정 서비스 파일은 <wsdl:import> 구성소를 이용해서 추상정의를 임포트하며, 추상정의 파일은 <xsd:import> 구조체를 이용해 XSD 정의를 임포트한다.
  4. 마지막 대안은 두 개의 WSDL 파일과 여러 개의 XSD 파일을 가지는 것이다. 데이터 스키마와 메시지 구조 스키마는 별도의 파일에서 정의될 것이다. 메시지 구조 XSD는 지원될 각기 다른 통신 모드들에서 필요한 모든 메시지들을 포함한다.

4.2.7 WS-보안(WS-Security)

WS-보안은 기밀성(confidentiality), 무결성(integrity), 부인봉쇄(non-repudiation), 인증(authentication), 권한 부여(authorization) 등에 대한 기존의 보안 표준들을 이용해 보안정보를 SOAP 메시지로 편입시키기 위한 표준적인 방법을 정의한다. WS-보안은 SOAP 메시지 내에서 보안정보를 표현하는 방법을 제공한다. WS-보안은 단순 사용자명, SAML, X.509 인증서와 Kerberos ticket, SOAP 메시지 전체 또는 일부를 디지털 서명으로 변환하기 위해 XML 서명(XML Signature)을 활용하는 매커니즘, SOAP 메시지의 일부를 암호화하기 위해 XML 암호화(XML Encryption)를 사용하는 매커니즘, 그리고 서명과 암호 헤더를 SOAP 메시지에 첨부하는 방법 등 보안 토큰(token)을 전달하는 방법을 정의한다. IMS 웹서비스에서 보안 프로파일은 IMS 웹서비스 보안 프로파일에서 정의한다.

4.2.8 구성(Choreography)

IMS는 IMS만의 메시지와 서비스 구성 표준을 만들기보다는 기존의 표준들을 채택할 계획이다. IMS 웹서비스 바인딩에서 기본 메시지 구성은 5장에 상세하게 설명되어 있다. 신뢰할 수 있는 메시징은 기본 통신 인프라의 기능, 즉 TCP로써만 지원된다. 안정성이 증명되는 경우 다음 표준들이 채택될 것이다.
  1. WSR (WS-Reliability, Web Services Reliable Messaging Framework) – WS-신뢰성(WS-Reliability)의 목적은 신뢰 가능한 메시징 요건을 다루는 것으로, 이는 B2B 어플리케이션에서 웹서비스를 사용할 경우 중요하게 다루어진다. SOAP/HTTP는 어플리케이션 수준의 메세징 프로토콜이 신뢰성과 보안성도 다루어야 하는 경우 충분하지 않다. 웹서비스 표준 개발에서 보안은 진척을 보이고 있지만 신뢰성은 그렇지 않다. 이 표준은 현재의 웹서비스 표준의 맥락에서 신뢰성을 정의하기 위한 초기 단계의 제안이다. 이 표준은 SOAP, ebXML 메시지 서비스(ebXML Message Service) 등의 전송 프로토콜에서 이뤄진 메시징에 대한 이전 연구들을 차용하고 있다. 이 연구들을 웹서비스에 적용하기 위한 적절한 수정방법을 제시한다.
  2. WS-CDL (Web Services Choreography Description Language) 1.0버전(W3C 2004년 4월 27일자 초안) – WS-CDL은 전역적인 관점에서 웹서비스 참여자들의 공통적이고 보완적이고 관찰가능한 행동을 XML 기반 언어로 정의함으로써 웹서비스 참여자들간의 공동작업을 설명한다. 또 순차적인 메시지 교환은 공통의 비즈니스 목표를 달성한다. 웹서비스 표준은 어플리케이션을 개발하고 호스팅하는 데 사용되는 이종의 전산환경들간의 통신 중개를 제공한다. 웹서비스 구성 표준은 호스팅 환경의 구현에서 사용된 지원플랫폼이나 프로그래밍 모델과는 상관없이 모든 종류의 웹서비스 참여자들 사이에서 상호운용이 가능한 공통작업을 구성하는 것을 목표로 한다.
  3. BPEL4WS (약어로 BPEL)는 비즈니스 프로세스를 구현하기 위해 조합될 수 있는 웹서비스를 정의하는 XML 기반 표준이다. BPEL은 WSDL과 XSD를 생성한다. BPEL은 웹서비스에 기반한 비즈니스 프로세스 행동을 설명하는 XML 표기법과 의미론을 제공한다. BPEL4WS 프로세스는 파트너들과의 상호작용으로 정의된다. 파트너는 프로세스에 서비스를 제공하고, 프로세스로부터 서비스를 요청하며, 프로세스에서 양방향적 상호작용에 참여한다. 즉 BPEL은 서비스의 집합을 호출하는 의미있는 순서를 설명하고 파트너들에게 각 서비스에 대한 의무사항을 명시함으로써 웹서비스를 통합한다. BPEL은 파트너에 대한 공용 인터페이스와 실행가능한 프로세스의 기술을 설명하는 데 사용될 수 있다.

5 베이스 프로파일 규칙

5.1 IMS 베이스 프로파일

IMS 웹서비스 베이스 프로파일의 정의는 표 5.1에 제시되어 있다. 이 프로파일과 WS-I 베이직 프로파일/심플 SOAP 바인딩 프로파일과의 유일한 차이는 이 프로파일에는 UDDI 표준이 포함되어 있지 않다는 점이다.
표 5.1 IMS 웹서비스 베이스 프로파일

핵심표준

내용
XML 스키마 1.0버전 IMS 표준의 모든 데이터 모델은 XML 스키마로 정의되며, 관련 관리문서(XSD)의 정의를 필요로 한다.
HTTP 1.1버전 HTTP는 SOAP 메시지에서 필수적인 프로토콜 바인딩이다.
SOAP 1.1버전 SOAP는 필수적인 메시징 프로토콜이다.
WSDL 1.1버전 WSDL 1.1버전을 이용해 서비스의 인스턴스를 정의한다..

5.2 WS-I 베이직 프로파일에서 도출한 베이스 프로파일 규칙

표 5.2는 WS-I 베이직 프로파일 1.1버전에서 사용되는 규칙들을 요약하고 있으며, IMS 웹서비스 베이스 프로파일에서의 채택여부를 보여준다. 표 5.2에서는 다음 규칙들이 사용된다.
  • 이 문서에 등장하는 ‘반드시~해야 한다’, ‘절대로 ~해서는 안 된다’, ‘ 필수 사항’, ‘~한다’, ‘~하지 않는다’, ‘ ~해야 한다’, ‘ ~해서는 안 된다’, ‘ ~을 권고한다’, ‘ ~할 수 있다’, ‘ 선택사항’ 등의 키워드는 RFC2119의 설명과 해석을 따른다.
  • 적합성에 영향을 끼치고‚ 프로파일 적합성의 윤곽을 형성하는 프로파일의 표준 명세는 다음과 같이 표시한다. ’RnnnnStatement’ 텍스트에서, ‘nnnn’는 명세번호로 대체된다. 각 명세는 ‘반드시 ~를 해야 한다’와 같은 정확히 하나의 필수 키워드와, ‘메시지’ 등 하나의 적합성 타겟 키워드를 포함한다.
표 5.2 WS-I 베이직 프로파일 규칙 요약

규칙

내용

IMS 웹서비스와의관련성
프로파일 적합성(Profile Conformance)
R0002 디스크립션(description)은 적합성 자격 스키마에 설명된 대로 인스턴스와 관련된 적합성 준수사항들을 포함할 수 있다. 적합성 준수에 대한 매커니즘은 IMS 웹서비스 2.0버전에서 다뤄질 것이다.
R0003 디스크립션의 적합성 준수는 반드시 <wsdl:port>, <wsdl:binding, wsdl:portType>, <wsdl:operation> (<wsdl:binding>이 아닌 <wsdl:portType>의 하위 요소), <wsdl:message> 요소들 각각의 <wsdl:documentation> 요소의 자식이어야 한다. 적합성 준수에 대한 매커니즘은 IMS 웹서비스 2.0버전에서 다뤄질 것이다..
메시징 (Messaging)
R9980 엔벨로프(envelope)는 반드시 SOAP 1.1버전 4장 ‘SOAP Envelope’ (프로파일에 의해 개정 가능함)에서 설명된 구조에 적합해야 한다. 채택
R1015 수신자는 문서 요소가 엔벨로프의 로컬 이름을 갖고 있고, <soap:Envelope>가 아닌 네임스페이스 이름을 가진 메시지의 경우 반드시 결함(fault)을 생성해야 한다. 채택
R1014 메시지에서 <soap:Body> 의 하위요소는 반드시 네임스페이스에 적합해야 한다. 채택
R1008 메시지는 절대로 DTD (Document Type Declaration)를 포함해서는 안 된다. 채택
R1009 메시지는 절대로 프로세싱 지침(Instructions)을 포함해서는 안된다. 채택
R1033 엔벨로프는 네임스페이스 선언 xmlns:xml=”http://www.w3.org/XML/1998/namespace”를 포함해서는 안 된다. 채택
R1034 디스크립션은 네임스페이스 선언 xmlns:xml=”http://www.w3.org/XML/1998/namespace”를 포함해서는 안 된다. 채택
R1011 메시지는 절대로 <soap:Body> 요소 뒤에 오는 <soap:Envelope>의 하위 요소를 가져서는 안 된다. 채택
R1005 메시지는 절대로 “http://schemas.xmlsoap.org/soap/envelope/”를 네임스페이스 이름으로 하는 요소에 <soap:encodingStyle> 속성을 포함해서는 안 된다. 채택
R1006 메시지는 절대로 <soap:Body>의 하위 요소에 <soap:encodingStyle> 속성을 포함해서는 안 된다. 채택
R1007 ‘rpc-literal’ 바인딩에 설명된 메시지는 절대로 <soap:Body>의 손자 노드인 요소에 <soap:encodingStyle> 속성을 포함해서는 안 된다. 채택되지 않음. ‘rpc – literal’ 바인딩은 지원되지 않는다.
R1013 <soap:mustUnderstand> 속성은 반드시 ‘0’과 ‘1’의 어휘만을 사용해야 한다. 채택
R1017 수신자는 파생된 유형을 지칭하기 위해(XML 스키마 1부: 2.6.1 구조 참조) 필요한 경우를 제외하고는 메시지에서 ‘xsi:type’ 속성의 사용을 절대로 강제할 수 없다. 채택
R1032 엔벨로프에서 ‘soap:Envelope’, ‘soap:Header’, 그리고 ‘soap:Body’ 요소는 절대로 네임스페이스 ”http://schemas.xmlsoap.org/soap/envelope/”에서 속성을 가져서는 안 된다. 채택
R1025 수신자는 반드시 실제 프로세싱 전에 필수 헤더 블록이 모두 검사를 명백히 거칠 수 있도록 메시지를 처리해야 한다. 채택
R1027 (<soap:actor>를 통해) 수신자 대상을 지정하는 필수 헤더 블록(예를 들어 ‘1’ 값을 갖는 <soap:mustUnderstand> 속성이 있는 헤더 블록) 중 수신자가 이해할 수 없는 헤더 블록을 포함한 메시지의 경우 수신자는 반드시 ‘soap:MustUnderstand’ 결함을 생성해야 한다. 채택
R1028 수신자에 의해 ‘Fault’가 생성되었을 때, ‘Fault’가 생성되기 전 메시지의 처리 결과에 대한 롤백(rollback)이나 보정이 필요한 경우가 아니면 SOAP 메시지에 대한 추가적인 처리를 진행해서는 안 된다. 채택
R1029 일반적으로 SOAP 메시지 처리결과로 인해 SOAP 응답의 전송이 일어나지만, ‘SOAP Fault’가 생성되는 경우 수신자는 반드시 응답 대신 ‘SOAP Fault’ 메시지를 전송해야 한다. 채택
R1030 결함을 생성하는 수신자는 필요하다고 생각될 때, 실행 도중에 사용자에게 결함이 생성되었음을 통지해야 한다. 채택
R1107 수신자는 반드시 <soap:Fault> 요소만을 포함하는 SOAP 메시지에 대해서만 ‘Fault’로 해석해야 한다. 채택
R1000 메시지가 <soap:Fault> 요소를 포함하는 경우, 해당 요소는 절대로 'faultcode', 'faultstring', 'faultactor' 그리고 'detail'을 제외한 다른 하위 요소를 가져서는 안 된다. 채택
R1001 메시지가 <soap:Fault> 요소를 포함하는 경우 하위 요소는 반드시 속성이 비한정적(unqualified)이어야 한다. 채택
R1002 수신자는 반드시 <detail> 의 하위 요소로 나타나는 0을 포함하여 하나 이상의 요소를 가진 결함 메시지를 수용해야 한다. 이러한 하위 요소는 속성이 한정적(qualified) 혹은 비한정적 일 수 있다. 채택
R1003 수신자는 반드시 ‘detail’ 요소에 나타나는 0을 포함하여 하나 이상의 한정적 또는 비한정적 속성을 가진 결함 메시지를 수용해야 한다. 한정적 속성의 네임스페이스는 “http://schemas.xmlsoap.org/soap/envelope/” 외에는 어떤 것이든 가능하다. 채택
R1016 수신자는 반드시 <faultstring> 요소의 ‘xml:lang’ 속성을 가지는 결함 메시지를 수용해야 한다. 채택
R1004 메시지가 <faultcode> 요소를 포함할 경우, 요소의 콘텐츠는 SOAP 1.1이나 네임스페이스 한정 결함 코드(qualified fault code)에서 정의된 결함코드여야 한다. 채택
R1031 메시지가 <faultcode> 요소를 가지는 경우 요소의 콘텐츠에서 ‘Fault’의 의미를 개선하기 위해 SOAP 1.1 ‘점(dot)’ 표기법을 사용해서는 안 된다. 채택
R1140 메시지는 HTTP/1.1을 이용해 전송되어야 한다. 채택
R1141 메시지는 반드시 HTTP/1.1이나 HTTP/1.0 중 하나를 사용해 전송되어야 한다. 채택됨. HTTP/1.1 지원을 통해 HTTP/1.0 지원을 내포한다
R1132 HTTP 요청 메시지는 반드시 HTTP POST 방법을 사용해야 한다. 채택
R1108 메시지는 절대로 HTTP 확장 프레임워크를 사용해서는 안 된다. 채택
R1109 HTTP 요청 메시지에서 ‘SOAPAction’ HTTP 헤더 필드의 값은 반드시 따옴 문자열(quoted string)이어야 한다. 채택
R1119 ‘SOAPAction’ HTTP 헤더 필드의 값이 따옴 문자열이 아닌 경우 수신자는 ‘Fault’로 응답할 수 있다. 채택
R1127 수신자는 메시지를 정확히 처리하기 위해서는 절대로 ‘SOAPAction HTTP’ 헤더의 값에 의존해서는 안 된다. 채택
R1124 요청의 결과가 성공적임을 나타내는 응답에서 인스턴스는 반드시 ‘2xxHTTP’ 상태 코드를 사용해야 한다. 채택
R1111 인스턴스는 SOAP 결함이 아닌 SOAP 메시지를 포함하는 응답에 대해 ‘200 OK’ HTTP 상태 코드를 사용해야 한다. 채택
R1112 SOAP 메시지를 포함하지는 않지만 요청에 대한 HTTP 결과가 성공적임을 나타내는 응답에 대해서 인스턴스는 ‘200 OK’ 또는 ‘202 Accepted’ R1130 HTTP 상태 코드를 사용해야 한다. 채택
R1130 요청을 다른 종단에 보낼 때 인스턴스는 반드시 HTTP 상태코드 ‘307 Temporary Redirect’를 사용해야 한다. 채택
R1131 소비자(consumer)는 응답에서 ‘307 Temporary Redirect’ HTTP 상태코드를 보면 요청을 자동적으로 다른 곳으로 전달할 수 있다. 채택
R1125 요청의 포맷에 문제가 있음을 나타내는 응답에 대해서 인스턴스는 반드시 ‘4xxHTTP’ 상태 코드를 사용해야 한다. 채택
R1113 요청 메시지가 잘못 생성된 HTTP 요청이거나, 적합하지 않은(not well-formed) XML인 경우에 인스턴스는 ‘400 Bad Request’ HTTP 상태코드를 사용해야 한다. 채택
R1114 요청 방법이 ‘POST’가 아닌 경우에 인스턴스는 ‘405 Method not Allowed’ HTTP 상태 코드를 사용해야 한다. 채택
R1115 콘텐츠 유형 HTTP 요청 헤더가 입력 메시지의 바인딩에 지정된 값과 일치하는 값을 가지지 않는 경우에 인스턴스는 ‘415 Unsupported Media Type’ HTTP 상태코드를 사용해야 한다. 채택
R1126 응답 메시지가 ‘SOAP Fault’인 경우에 인스턴스는 반드시 ‘500 Internal Server Error’ HTTP 상태코드를 사용해야 한다. 채택
R1120 인스턴스는 HTTP 상태 매커니즘(‘쿠키’)를 사용할 수 있다. 채택되지 않음. ‘쿠키’는 사용하지 않는다
R1122 쿠키를 사용하는 인스턴스는 RFC2965에 적합해야 한다. 채택되지 않음. ‘쿠키’는 사용하지 않는다
R1121 인스턴스는 올바르게 기능하기 위해서 쿠키에 대한 소비자 지원을 요청해서는 안 된다. 채택되지 않음. ‘쿠키’는 사용하지 않는다
R1123 쿠키의 값은 반드시 소비자가 알기 힘든(opaque)것이어야 한다 채택되지 않음. ‘쿠키’는 사용하지 않는다
서비스 디스크립션(Service Description)
R0001 인스턴스는 반드시 WSDL 1.1 서비스 디스크립션, UDDI 바인딩 템플릿, 또는 이 두 가지 모두에 의해 설명되어야 한다. 인스턴스는 WSDL 1.1 서비스 디스크립션에 의해 설명되어야 한다.
R2028 WSDL 네임스페이스를 사용하는 디스크립션은 “http://schemas.xmlsoap.org/wsdl/2003-02-11.xsd”에서 발견되는 XML 스키마에 의해 반드시 유효해야 한다. 채택됨. WS-I 프로파일에 사용된 접두어는 변경 가능하다.
R2029 WSDL SOAP 바인딩 네임스페이스를 사용하는 디스크립션은 ”http://schemas.xmlsoap.org/wsdl/soap/2003-02-11.xsd”에서 발견되는 XML 스키마에 의해 반드시 유효해야 한다. 채택됨. WS-I 프로파일에 사용된 접두어는 변경 가능하다.
R2001 디스크립션은 다른 WSDL 디스크립션을 임포트하기 위해서 반드시 WSDL ‘import’ 명령문만을 사용해야 한다. 채택됨. 본 방법은 추상 정의 파일을 특정 서비스 파일에 임포트하기 위해 사용된다.
R2803 디스크립션에서 ‘wsdl:import’의 네임스페이스 속성은 절대로 상대 URI여서는 안 된다. 채택
R2002 XML 스키마 정의를 임포트하기 위해서, 디스크립션은 반드시 XML 스키마 ‘import’ 명령문을 사용해야 한다. 채택됨. 이 방법은 XSD 디스크립션을 임포트하기 위해 사용된다.
R2003 디스크립션은 반드시 유형 섹션에서 <xs:schema> 요소 내에서만 XML 스키마 ‘import’ 명령문을 사용해야 한다. 채택
R2004 디스크립션은 “http://www.w3.org/2001/XMLSchema” 네임스페이스에서 최상위 요소가 ‘스키마’가 아닌 문서에서 스키마를 임포트하기 위해서 XML 스키마 ‘import’ 명령문을 절대로 사용해서는 안 된다. 채택
R2009 디스크립션에 의해 직접, 또는 간접적으로 입력된 XML 스키마는 유니코드의 BOM (Byte Order Mark)을 포함할 수 있다. 채택
R2010 디스크립션에 의해 직접 또는 간접적으로 입력된 XML 스키마는 반드시 UTF-8 또는 UTF-16 인코딩을 사용해야 한다. 채택
R2011 디스크립션에 의해 직접 또는 간접적으로 입력된 XML 스키마는 반드시 XML W3C 권고안의 1.0버전을 사용해야 한다. 채택
R2007 디스크립션은 반드시 <wsdl:import> 요소의 ‘non-empty location’ 속성을 상술해야 한다. 채택됨. ‘location’은 http://www.imsglobal.org/services/의 URL 루트에 기반한다
R2008 디스크립션에서 <wsdl: import> 요소의 ‘location’ 속성 값은 힌트로 다루어야 한다. 채택
R2022 <wsdl:import> 요소가 디스크립션에서 나타나는 경우, <wsdl:documentation>을 제외한 WSDL 네임스페이스의 다른 모든 요소들보다 상위에 있어야 한다. 채택
R2023 <wsdl:types> 요소가 디스크립션에서 나타나는 경우, <wsdl:documentation>과 <wsdl:import>를 제외한 다른 모든 요소보다 상위에 있어야 한다. 채택
R4004 디스크립션은 XML W3C 권고안의 1.0버전을 반드시 사용해야 한다. 채택
R4005 디스크립션은 네임스페이스 선언 “xmlns:xml=http://www.w3.org/XML/1998/namespace”를 포함해서는 안 된다. 채택
R4002 디스크립션은 유니코드의 BOM (Byte Order Mark)을 포함할 수 있다. 채택
R4003 디스크립션은 반드시 UTF-8이나 UTF-16 인코딩을 사용해야 한다. 채택
R2005 임포트되는 디스크립션의 <wsdl:definitions> 요소의 ‘targetNamespace’ 속성은 반드시 탑재하는 디스크립션의 <wsdl:import> 요소의 네임스페이스 속성과 같은 값을 가져야 한다. 채택
R2030 디스크립션에서 <wsdl:documentation> 요소는 WSDL 1.1 표준에서 지칭된 요소 외에도 <wsdl:import>, <wsdl:part>, <wsdl:definitions>의 첫 번째 자식 요소로 존재해야 한다. 채택
R2025 WSDL 확장을 포함하는 디스크립션은 WSDL 확장을 프로파일의 다른 요건들을 부인하기 위해 절대로 사용해서는 안 된다. 채택
R2026 디스크립션은 프로파일에 대한 적합성을 주장하는 어떤 WSDL 구조체(<wsdl:binding>, <wsdl:portType>, <wsdl:message>, <wsdl:types> 또는 <wsdl:import>)에서든 ‘참(true)’의 ‘wsdl:required’ 속성 값을 가지는 확장 요소를 포함해서는 안 된다. 채택
R2027 디스크립션의 WSDL 네임스페이스에서 요소를 처리하는 동안 소비자가 WSDL 확장 요소를 자식 요소 중에서 발견하였는데 해당 요소가 ‘참’의 Boolean 값을 가진 <wsdl: required> 속성을 갖고 소비자가 이해하거나 처리할 수 없는 경우, 소비자는 반드시 WSDL 네임스페이스에서 해당 요소의 처리에 실패해야 한다. 채택
R2101 디스크립션은 참조하는 WSDL 문서에서 임포트되거나 정의되지 않은 네임스페이스의 요소에 대한 ‘QName’ 참조를 절대로 사용해서는 안 된다. 채택
R2102 디스크립션에서 스키마 구성요소에 대한 ‘QName’ 참조는 반드시 <xs:schema> 요소의 ‘targetNamespace’ 속성에서 정의된 네임스페이스, 또는 <xs:schema> 요소 내의 <xs:import> 요소의 네임스페이스 속성에 정의된 네임스페이스를 사용해야 한다. 채택
R2105 디스크립션의 <wsdl:types> 요소에 포함된 모든 <xs:schema> 요소는 <xs:schema> 요소가 <xs:import> 그리고/또는 <xs:annotation>만을 유일한 자식요소로 가지고 있는 경우를 제외하고는 반드시 유효하며 널이 아닌(non-null) 값을 가진 ‘targetNamespace’ 속성을 가져야 한다. 채택
R2110 디스크립션에서 배열 선언은 절대로 ‘soapenc:Array’ 유형을 확장하거나 제한해서는 안 된다. 채택
R2111 디스크립션에서 배열 선언은 절대로 유형선언의 ‘wsdl:arrayType’ 속성을 사용해서는 안 된다. 채택
R2112 디스크립션에서 배열선언 래퍼(wrapper) 요소는 ‘ArrayOfXXX’ 규칙을 사용해서 이름지어서는 안 된다. 채택
R2113 직렬화된 배열을 포함하는 메시지는 ‘soapenc:arrayType’ 속성을 절대로 포함해서는 안 된다. 채택
R2114 디스크립션에서 WSDL 정의의 목표 네임스페이스와 스키마 정의의 목표 네임스페이스는 동일할 수 있다. 채택
R2201 디스크립션에서 ‘document-literal’ 바인딩은 파트 속성이 설명된 경우 각 <soapbind:body> 요소에서 반드시 파트속성에 대해 최대 하나의 파트가 게재되어야 한다. 채택
R2209 디스크립션에서 <wsdl:binding>는 <wsdl:portType>에서 <wsdl:message>의 <wsdl:part>를 <soapbind:body>, <soapbind:header>, <soapbind:fault> 또는 <soapbind:headerfault> 중 참조 대상에 바인딩해야 한다. 채택
R2210 디스크립션의 ‘document-literal’ 바인딩이 <soapbind:body> 요소에서 파트속성을 설명하지 않는 경우, 해당 추상 <wsdl:message>는 반드시 0 또는 하나 이상의 <wsdl:parts>를 정의해야 한다. 채택됨. 모든 메시지는 SOAP 메시지 바디에 대해 하나의 <wsdl:part>를 가져야 한다.
R2202 디스크립션의 <wsdl:binding>는 0개의 파트가 <soap:Body>를 구성함을 명시하는 <soapbind:body> 요소를 포함할 수 있다. 모든 메시지는 <soap:Body>에 대해 하나의 파트를 가진다.
R2203 디스크립션에서 ‘rpc-literal’ 바인딩은 반드시 <soapbind:body> 요소에서 유형속성을 이용해 정의된 <wsdl:part> 요소만을 참조해야 한다. 채택되지 않음. ‘'rpc-literal' 바인딩은 지원되지 않는다.
R2211 ‘rpc-literal’ 바인딩으로 디스크립션된 메시지는 값이 ‘1’ 또는 ‘참’인 ‘xsi:nil’ 속성을 파트 접근자(part accessors)에서는 절대로 가질 수 없다. 채택되지 않음. ‘'rpc-literal' 바인딩은 지원되지 않는다.
R2207 디스크립션에서 <wsdl:message>는 요소 속성을 사용하는 <wsdl:parts>이 ‘rpc-literal’ 바인딩의 <soapbind:body>에 의해 참조되지 않는다는 조건 하에 <wsdl:parts>을 포함할 수 있다. 채택되지 않음. ‘'rpc-literal' 바인딩은 지원되지 않는다.
R2204 디스크립션에서 ‘document-literal’ 바인딩은 각 <soapbind:body> 요소에서 반드시 요소 속성을 이용해 정의된 <wsdl:part> 요소만을 참조해야 한다. 채택
R2208 디스크립션의 바인딩은 <soapbind:body> 요소에 의해 참조되는 같은 <wsdl:message>의 <wsdl:parts>를 참조하는 <soapbind:header> 요소를 포함할 수 있다. 채택
R2212 엔벨로프는 반드시 자신의 해당 <soapbind:body> 요소에 바인딩된 각 <wsdl:parts> 요소에 대해 정확히 하나의 파트 접근자를 반드시 포함해야 한다. 채택
R2213 ‘Doc-literal’ 디스크립션에서 ‘soapbind:body’의 파트속성의 값이 빈 문자열인 경우 해당 엔벨로프는 <soap:Body> 요소에서 절대로 요소 콘텐츠를 가지고 있어서는 안 된다. 'soapbind:body'의 파트속성의 값은 빈 문자열이어서는 안 된다.
R2214 ‘rpc-literal’ 디스크립션에서 ‘soapbind:body’의 파트속성 값이 빈 문자열인 경우, 해당 엔벨로프는 파트 접근자 요소를 절대로 가지고 있어서는 안 된다. 채택되지 않음. ‘'rpc-literal' 바인딩은 지원되지 않는다.
R2205 디스크립션에서 <wsdl:binding>는 자신의 <soapbind:header>, <soapbind:headerfault> 그리고 <soapbind:fault> 요소에서 요소 속성을 이용해 정의된 <wsdl:part> 요소만 반드시 참조해야 한다. 채택
R2206 디스크립션에서 요소 속성을 사용하는 <wsdl:part>를 포함하는 <wsdl:message>는 해당 속성에서 반드시 전역적 요소 선언을 참조해야 한다. 채택
R2301 메시지의 <soap:body> 요소의 순서는 이를 설명하는 <wsdl:message> 내에서의 <wsdl:parts> 요소 순서와 반드시 같아야 한다. 채택
R2302 디스크립션은 반환값과 메소드 서명(signature)을 코드 생성자에게 힌트로 제공하기 위해 <wsdl:operation> 요소의 ‘parameterOrder’ 속성을 사용할 수 있다. 채택
R2303 디스크립션은 <wsdl:portType> 정의에서 청구-응답(Solicit-Response)과 통지(Notification) 형식 연산을 절대로 사용해서는 안 된다. 채택
R2304 디스크립션의 <wsdl:portType>은 이름 속성에 대해 고유의 값을 가지는 연산을 반드시 가져야 한다. 채택
R2305 디스크립션의 <wsdl:portType>는 ‘parameterOrder’ 속성이 존재한다면, 출력 메시지에서 최대 하나의 <wsdl:part>를 생략하도록 구성되어야 한다. 채택
R2306 디스크립션의 <wsdl:message>는 동일한 <wsdl:part>에서 절대로 유형과 요소 속성을 둘 다 상술해서는 안 된다. 채택
R2401 디스크립션의 <wsdl:binding> 요소는 반드시 WSDL 1.1의 3장에 정의된 WSDL SOAP 바인딩을 사용해야 한다. 채택
R2701 디스크립션에서 <wsdl:binding> 요소는 반드시 <soapbind:binding> 자식 요소가 전송 속성을 설명하도록 구성되어야 한다. 채택
R2702 디스크립션의 <wsdl:binding> 요소는 반드시 SOAP바인딩을 가진 HTTP 전송 프로토콜을 명시해야 한다. 즉 <wsdl:binding> 요소의 <soapbind:binding> 자식은 반드시 ”http://schemas.xmlsoap.org/soap/http”의 값을 가져야 한다. 채택
R2705 디스크립션의 <wsdl:binding>는 반드시 ‘rpc-literal’ 바인딩이나 ‘document-literal’ 바인딩을 가져야 한다. 채택됨. 바인딩은 언제나 'document-literal'을 기반으로 한다.
R2706 디스크립션의 <wsdl:binding>은 <soapbind:body>, <soapbind:fault>, <soapbind:header> 그리고 <soapbind:headerfault> 요소에서의 사용속성에서 ‘literal’의 값을 반드시 사용해야 한다. 채택
R2709 디스크립션에서 <wsdl:portType>는 같은 WSDL 문서나 다른 WSDL 문서에서 자신을 참조하는 0 또는 하나 이상의 <wsdl:binding>를 가질 수 있다. <wsdl:portType> 정의의 결과는 항상 <wsdl:binding>정의가 된다.
R2710 디스크립션에서 <wsdl:binding>의 연산은 반드시 각기 다른 ‘wire signature’를 만들어 내야 한다. 채택
R2711 디스크립션은 <soapbind:address> 요소의 위치속성에 대해서 같은 값을 갖는 하나 이상의 <wsdl:port>를 가져서는 안 된다. 채택
R2712 ‘document-literal’ 바인딩은 반드시 자식 요소가 관련 <wsdl:message> 파트에 의해 참조되는 전역적 요소 선언의 인스턴스인 <soap:Body>를 가진 메시지로 와이어에 표현되어야 한다. 채택
R2714 일방향 연산에서 인스턴스는 절대로 SOAP 엔벨로프를 포함하는 HTTP 응답에 회신해서는 안 된다. 특히 HTTP 응답 엔터티-바디(entity-body)는 비어 있어야 한다. 채택됨. 현재 모든 서비스는 요청/응답을 사용한다.
R2750 소비자는 일방향 연산으로부터의 응답에 포함된 SOAP 응답을 반드시 무시해야 한다. 채택됨. 현재 모든 서비스는 요청/응답을 사용한다.
R2727 일방향 연산의 경우, 소비자는 성공적인 HTTP 응답 상태코드(2xx 등)를 메시지가 유효하거나 수신자가 이를 처리한다는 의미로 절대로 해석해서는 안 된다. 채택됨. 현재 모든 서비스는 요청/응답을 사용한다.
R2716 디스크립션의 ‘document-literal’ 바인딩은 <soapbind:body>, <soapbind:header>, <soapbind:headerfault> 그리고 <soapbind:fault> 요소에 명시된 네임스페이스 속성을 절대로 가져서는 안 된다. 채택
R2717 디스크립션의 ‘rpc-literal’ 바인딩은 <soapbind:body> 요소에 절대 URI의 값을 가지는 네임스페이스 속성을 반드시 명시해야 한다. 채택되지 않음 ‘rpc – literal’ 바인딩은 지원되지 않는다.
R2726 디스크립션의 ‘rpc-literal’ 바인딩은 <soapbind:header>, <soapbind:headerfault> 그리고 <soapbind:fault> 요소에 명시된 네임스페이스 속성을 절대로 가져서는 안 된다. 채택되지 않음 ‘rpc – literal’ 바인딩은 지원되지 않는다.
R2718 디스크립션의 <wsdl:binding>은 자신이 참조하는 <wsdl:portType>과 같은 <wsdl:operations>를 반드시 가져야 한다. 채택
R2719 디스크립션의 <wsdl:binding>는 알려진 헤더 결함이 없다면 <soapbind:headerfault> 요소를 하나도 가지지 않아도 된다. 채택됨. 현재 IMS는 헤더 결함을 정의하지 않는다.
R2740 디스크립션의 <wsdl:binding>는 알려진 각 결함을 설명하는 <soapbind:fault>를 포함해야 한다. 알려진 비즈니스 거래 결함은 SOAP 헤더에 포함된 IMS 상태정보 객체에 보고된다.
R2741 디스크립션의 <wsdl:binding>는 알려진 각 헤더결함을 설명하는 ‘soapbind:headerfault’를 포함해야 한다. 채택됨. 현재 IMS는 헤더 결함을 정의하지 않는다.
R2742 메시지는 관련 WSDL 디스크립션의 <wsdl:fault> 요소에 설명되지 않은 SOAP 결함 내의 결함 상세 입력을 포함해야 한다. 알려진 비즈니스 거래 결함은 SOAP 헤더에 포함된 IMS 상태정보 객체에 보고된다.
R2743 메시지는 관련 WSDL 디스크립션의 <wsdl:headerfault> 요소에 의해서 설명되지 않은 SOAP 헤더 블록의 헤더 처리와 관련한 결함의 세부사항을 포함할 수 있다. 채택됨. 현재 IMS는 헤더 결함을 정의하지 않는다.
R2720 디스크립션의 <wsdl:binding>는 포함된 모든 <soapbind:header>과 <wsdl:headerfault> 요소에 반드시 ‘NMTOKEN’의 스키마 유형을 가진 속성 이름의 파트를 사용해야 한다. 채택
R2749 디스크립션의 <wsdl:binding>는 <soapbind:header>과 <soapbind:headerfault> 요소에 속성 이름의 파트를 절대로 사용해서는 안 된다. 채택
R2721 디스크립션의 <wsdl:binding>는 모든 <soapbind:fault> 요소에 이름 속성을 반드시 명시해야 한다. 알려진 비즈니스 거래 결함은 SOAP 헤더에 포함된 IMS 상태정보 객체에 보고된다.
R2754 디스크립션에서 <soapbind:fault> 요소의 이름속성 값은 반드시 부모 <wsdl:fault> 요소의 이름 속성의 값과 일치해야 한다. 알려진 비즈니스 거래 결함은 SOAP 헤더에 포함된 IMS 상태정보 객체에 보고된다.
R2722 디스크립션의 <wsdl:binding>는 포함된 <soapbind:fault>의 사용 속성을 명시한다. 알려진 비즈니스 거래 결함은 SOAP 헤더에 포함된 IMS 상태정보 객체에 보고된다.
R2723 디스크립션의 <wsdl:binding>에 포함된 <soapbind:fault> 요소의 사용 속성이 존재한다면, 그 값은 반드시 ‘literal’이어야 한다. 알려진 비즈니스 거래 결함은 SOAP 헤더에 포함된 IMS 상태정보 객체에 보고된다.
R2707 <soapbind:body>, <soapbind:fault>, <soapbind:header> 또는 <soapbind:headerfault> 요소 중에서 사용 속성을 명시하지 않은 요소를 하나 이상 포함하는 디스크립션의 <wsdl:binding>은 반드시 ‘literal’값이 명시된 것으로 해석해야 한다. 채택
R2724 인스턴스가 WSDL 디스크립션과 일치하지 않는 메시지를 수신하면, ‘MustUnderstand’나 ‘VersionMismatch’ 결함이 생성되지 않는 이상 ‘Client’의 결함코드를 가진 <soap:Fault>를 생성해야 한다. 채택
R2725 인스턴스가 WSDL 디스크립션과 일치하지 않는 메시지를 수신하는 경우, 반드시 ‘VersionMismatch’, ‘MustUnderstand’ 그리고 ‘Client’ 결함 조건을 순서대로 확인해야 한다. 채택
R2729 ‘rpc-literal’ 바인딩으로 설명된 메시지 중 응답 메시지인 경우 반드시 문자열 ‘응답’ 접미어를 가진 <wsdl:operation>의 이름과 같은 래퍼 요소를 반드시 가져야 한다. 채택되지 않음 ‘rpc – literal’ 바인딩은 지원되지 않는다.
R2735 ‘rpc-literal’ 바인딩으로 설명된 메시지는 파라미터와 반환값에 대한 파트접근자를 반드시 ‘no namespace’에 위치하도록 해야 한다. 채택되지 않음 ‘rpc – literal’ 바인딩은 지원되지 않는다.
R2755 ‘rpc-literal’ 바인딩으로 설명된 메시지의 파트접근자는 반드시 관련된 ‘wsdl:part’ 요소의 이름속성과 같은 값의 로컬이름을 가져야 한다. 채택되지 않음 ‘rpc – literal’ 바인딩은 지원되지 않는다.
R2737 ‘rpc-literal’ 바인딩으로 설명된 메시지는 파라미터에 대한 파트 접근자의 자식과, 유형이 정의된 'targetNamespace'를 가진 반환값에 대하여 네임스페이스를 한정해야 한다. 채택되지 않음 ‘rpc – literal’ 바인딩은 지원되지 않는다.
R2738 메시지는 <wsdl:input>에 명시된 모든 <soapbind:headers> 또는 이를 설명하는 <wsdl:binding>의<wsdl:operation>의 <wsdl:output>를 반드시 포함해아 한다. 채택
R2739 메시지는 SOAP 헤더 블록을 설명하는 <wsdl:binding>에 기술되지 않은 SOAP 헤더 블록을 포함하는 메시지를 포함할 수 있다. 채택
R2753 적절한 <wsdl:binding>에 설명되지 않은 SOAP 헤더 블록을 포함하는 메시지는 ‘1’에 세팅되어 있는 SOAP 헤더 블록에 ‘mustUnderstand’ 속성을 가질 수 있다. 채택
R2751 디스크립션의 <soapbind:binding> 섹션의 <soapbind:header>요소의 순서는 메시지 내의 SOAP 헤더 블록의 순서에 독립적이라고 간주해야 한다. 채택
R2752 메시지는 관련 디스크립션의 <soapbind:binding>의 적절한 자식의 각 <soapbind:header> 요소에 대한 각 SOAP 헤더 블록의 하나 이상의 인스턴스를 포함할 수 있다. 채택
R2744 HTTP 요청 메시지는 해당 WSDL 디스크립션에 존재하는 <soapbind:operation>의 'soapAction' 속성의 값과 동등한 인용값을 가진 'SOAPAction' HTTP 헤더 필드를 반드시 포함해야 한다. 채택
R2745 HTTP 요청 메시지는 관련 WSDL 디스크립션에서 <soapbind:operation>의 'soapAction'이 존재하거나, 빈 문자열을 그 값으로 하면서 존재할 경우에 인용된 빈 문자열 값을 가진 'SOAPAction' HTTP 헤더 필드를 반드시 포함해야 한다. 채택
R2747 소비자는 확장 요소에 <wsdl:required> 속성의 존재 또는 부재 여부와 관계 없이, 그리고 <wsdl:required> 속성의 값과 관계 없이 모든 WSDL 1.1 SOAP 바인딩 확장 요소를 이해하고 처리해야 한다. 채택
R2748 소비자는 ‘거짓(false)’의 값을 가진 'soapbind' 확장 요소에서 'wsdl:required' 속성이 존재하면, 확장 요소가 WSDL 디스크립션에서 생성된 메시지에서 선택사항이라고 절대로 해석해서는 안 된다. 채택
R2800 디스크립션은 XML 스키마 1.0의 어떠한 구조체라도 사용할 수 있다. 채택됨. 추상 유형에 대한 요소 양식이 반드시 사용되어야 한다. 요소에 대한 전역적 정의가 반드시 사용되어야 한다.
R2801 디스크립션은 반드시 사용자 정의 데이터 유형과 구조에 대한 기준으로 XML 스키마 1.0 권고안을 반드시 사용해야 한다. 채택
서비스 발행 및 발견(Service Publication & Discovery)
R3100 적합한 인스턴스를 표현하는 ‘uddi:bindingTemplate’유형의 ‘REGDATA’는 반드시 <uddi:accessPoint> 요소를 포함해야 한다. UDDI는 IMS 웹서비스 베이스 프로파일의 일부가 아니다.
R3002 적합한 웹서비스 유형을 표현하는 ‘uddi:tModel’ 유형의 ‘REGDATA’는 반드시 WSDL를 디스크립션 언어로 사용해야 한다. UDDI는 IMS 웹서비스 베이스 프로파일의 일부가 아니다.
R3003 적합한 웹서비스 유형을 표현하는 ‘uddi:tModel’ 유형의 ‘REGDATA’는 반드시 ‘uddi:types’ 분류체계와 ‘wsdlSpec’ 분류체계를 이용하여 분류되어야 한다. UDDI는 IMS 웹서비스 베이스 프로파일의 일부가 아니다.
R3010 적합한 웹서비스 유형을 표현하는 ‘uddi:tModel’ 유형의 ‘REGDATA’는 반드시 UDDI 저장소에서 WSDL 사용에 대한 UDDI 활용사례의 1.08버전을 충족해야 한다. UDDI는 IMS 웹서비스 베이스 프로파일의 일부가 아니다.
R3011 ‘uddi:tModel’ 유형의 ‘REGDATA’에 의해 참조되는 ‘wsdl:binding’은 반드시 프로파일에 적합해야 한다. UDDI는 IMS 웹서비스 베이스 프로파일의 일부가 아니다.
보안(Security. IMS 웹서비스 보안 프로파일은 베이스 프로파일의 보안 부문에서 더 완전한 명세를 위해 사용되어야 한다)
R5000 인스턴스는 HTTPS의 사용을 필요로 할 수 있다. 베이스 프로파일의 보안 형식을 위해 채택 되었다.
R5001 인스턴스가 HTTPS의 사용을 필요로 한다면, <wsdl:port> 설명 내의 <soapbind:address> 요소에 대한 ’location’ 속성은 반드시 스키마가 ‘https’인 URI이어야 한다. 그렇지 않은 경우 스키마가 ‘http’인 URI이어야 한다. 베이스 프로파일의 보안 형식을 위해 채택 되었다.
R5001 인스턴스는 상호인증된 HTTPS의 사용을 필요로 할 수 있다. 베이스 프로파일의 보안 형식을 위해 채택 되었다.
표 5.3은 WS-I 베이직 프로파일 1.1버전에서 IMS 웹서비스에 포함된 확장점들을 요약하여 보여준다. 기본 표준들의 확장점들은 다음과 같이 표현된다.
  • Ennnn 확장점 이름(EnnnnExtensibility Point Name) - 설명의 하나로, ‘nnnn’은 프로파일 내의 확장점 중에서 고유한 번호로 대체된다. 요건 명세와 같이, 확장 명세는 네임스페이스에 적격한 것으로 간주한다.

5.3 WS-I 심플 SOAP 바인딩 프로파일에서 도출한 베이스 프로파일 규칙

표 5.4는 WS-I 심플 SOAP 프로파일 1.0버전에서 사용한 규칙들과 IMS 웹서비스 베이스 프로파일에서의 채택여부를 요약하여 보여준다. 표 5.4에서는 다음과 같은 규칙들이 사용된다. 이 문서에 등장하는 ‘반드시~해야 한다’, ‘절대로 ~해서는 안 된다’, ‘ 필수 사항’, ‘~한다’, ‘~하지 않는다’, ‘ ~해야 한다’, ‘ ~해서는 안 된다’, ‘ ~을 권고한다’, ‘ ~할 수 있다’, ‘ 선택사항’ 등의 키워드는 RFC2119의 설명대로 해석된다. 이 프로파일의 표준 명세는 다음과 같이 표시된다. RADPnnnnStatment 텍스트에서, ‘nnnn’는 명세번호로 대체된다. 각 명세는 ‘반드시 ~를 해야 한다’를 비롯해 정확히 하나의 필수 키워드와 ‘메시지’ 등 하나의 적합성 타겟 키워드를 포함한다. 표 5.4 WS-I 심플 SOAP 프로파일 규칙 요약

규칙

내용

IMS 웹서비스와의연관성
메시지 직렬화(Message Serialization)
R9700 메시지는 반드시 엔벨로프를 HTTP 개체-바디의 단독 페이로드로 직렬화해야 한다. 채택
R9701 메시지는 반드시 엔벨로프를 XML 1.0으로 직렬화해야 한다. 채택
R9702 메시지는 반드시 ‘Content-Type’ HTTP 헤더 필드를 가져야 한다. 채택
R9703 메시지의 ‘Content-Type’ HTTP헤더 필드는 반드시 미디어 유형이 ‘text/xml’인 필드값을 가져야 한다. 채택
R9704 엔벨로프는 네임스페이스 선언 xmlns:xml=”http://www.w3.org/XML/1998/namespace” 를 포함해서는 안 된다. 채택
R4001 수신자는 반드시 유니코드의 BOM (Byte Order Mark)을 포함하는 엔벨로프를 받아들여야 한다. 채택
R1010 수신자는 ‘XML Declaration’을 포함하는 엔벨로프들을 가진 메시지를 반드시 받아들여야 한다. 채택
R1012 메시지는 반드시 UTF-8이나 UTF-16 문자 인코딩을 이용해 엔벨로프를 직렬화해야 한다. 채택
R1018 메시지의 ‘Content-Type’ HTTP 헤더 필드 값은 반드시 ‘charset’ 파라미터를 이용해 정확한 문자 인코딩을 나타내야 한다. 채택
R1019 수신자는 메시지에서 엔벨로프의 XML 선언의 인코딩 의사 속성(pseudo-attribute)을 반드시 무시해야 한다. 채택
바인딩
R9802 디스크립션의 <wsdl:binding> 요소는 반드시 WSDL 1.1.버전 3장에 정의된 WSDL SOAP Binding 만을 사용해야 한다. 채택
R9800 디스크립션에서 와이어의 메시지들이 프로파일에 부적합하도록 하는 WSDL 바인딩 확장 요소와 속성들은 절대로 사용해서는 안 된다. 채택
R9801 디스크립션에서 WSDL MIME과 HTTP GET/POST 및 DIME 바인딩 확장은 SOAP 바인딩에서 절대로 나타나서는 안 된다. 채택
R2209 디스크립션의 <wsdl:binding>는 참조하는 <wsdl:portType>에서 <wsdl:message>의 모든 <wsdl:part>를 <soapbind:body>, <soapbind:header>, <soapbind:fault> 또는 <soapbind:headerfault> 중 하나에 바인딩해야 한다. 채택

5.4 IMS와 WS-I 프로파일의 차이 요약

IMS 베이스 프로파일의 핵심 요점은 다음과 같다.
  1. SOAP 결함 메시지는 WSDL바인딩에서 정의되지 않는다. 모든 상태 정보는 ‘StatusInfo/StatusInfoSet’ 객체에 포함된다. SOAP 결함 코드가 수신되면 반드시 IMS에서 정의한 대로 ‘StatusInfo/StatusInfoSet’ 객체에 매핑되어야 한다.
  2. WS-I 적합성 자격의 사용은 필수사항이 아니다. WS-I 적합성 자격이 사용된 경우에는 특정한 구현과 관련을 갖는다.
  3. UDDI는 프로파일의 일부가 아니다.
  4. ‘Document-literal’ 인코딩을 사용한다. 즉, ‘rpc-literal’ 인코딩은 사용하지 않는다.

6 추상 프레임워크와의 관계

6.1 IAF 개요

IMS GLC 추상 프레임워크는 그림 6.1에서 보여주듯 다음 네 가지 계층으로 구성된 모델로 표현될 수 있다.
    • 어플리케이션 계층(Application layer) – 사용자에게 적절한 어플리케이션 서비스를 제시하는 툴, 시스템, 에이전트 등이다. 즉 어플리케이션은 사용자 인터페이스를 관리한다. 어플리케이션은 하나 이상의 어플리케이션 서비스를 사용할 수 있지만 가능하다면 시스템 구성은 사용자에게 보여주지 않는다.
    • 어플리케이션 서비스 계층(Application Services layer) – 필요한 이러닝 기능을 어플리케이션에게 제공하는 서비스의 집합이다. 어플리케이션 서비스는 하나 이상의 공통 서비스를 활용할 수 있다. 분산된 어플리케이션 서비스는 인프라 계층을 통해 통신한다.
    • 공통 서비스 계층(Common Services layer) – 어플리케이션 서비스가 활용하는 서비스의 집합이다. 공통 서비스는 다른 공통 서비스를 사용할 수 있다. 그러므로 다른 서비스도 공통 서비스를 사용할 수 있다.
    • 인프라 계층(Infrastructure layer) – 종단간 트랜잭션과 통신 서비스를 어플리케이션과 공통 서비스에 제공한다.
IMS KR 1005-2_6.1

그림 6.1 추상 프레임워크 계층 모델

  • 서비스에 대한 접근은 적절한 서비스 접점(Service Access Point)을 통해 이루어진다. 각 서비스는 단일한 SAP를 가진다. 하나의 구성요소는 하나 또는 그 이상의 SAP를 지원할 수 있다(객체지향 표현에서 SAP는 클래스 자체가 서비스에 대한 정의인 하나 또는 그 이상의 연산자에 의해 지원될 수 있다).
웹서비스 환경에서 일반적으로 볼 수 있는 계층 프레임워크를 분산환경에서 구현할 때 서비스간의 상호작용은 그림 6.2와 같이 나타난다. 이 상호작용 프레임워크에서 인프라 계층이 지원해야 하는 인터페이스는 다음과 같이 세 가지로 분류된다.
  • 어플리케이션 서비스 인터페이스(A1) – 이 인터페이스는 기업간 시스템 등 공통 어플리케이션 서비스간의 상호운용성을 제공하기 위해 사용된다. 이러한 인터페이스의 한 가지 형태는 XML 메시징에 기반한다.
  • 공통 서비스 인터페이스(A2) – 이 인터페이스는 특정 어플리케이션 서비스, 즉 기업 시스템의 인증 및 권한 부여(authorization) 등 사용 가능한 공통 서비스의 집합에게 상호운용성을 제공하기 위하여 사용된다.
  • 런타임 인터페이스(B) – 이 인터페이스는 클라이언트의 런타임 어플리케이션을 원격 서비스 제공자와 상호연결하기 위해 사용된다.
IMS KR 1005-2_6.2

그림 6.2 계층을 통한 추상 프레임워크 서비스 상호작용

그림 6.2는 상호운용성을 보장하기 위해 명시되어야 하는 다음의 두 가지 상호작용 행동이 있음을 보여준다.
  • 메시지 전달(Message passing) – 특정한 형태의 메시지 교환을 사용하는 시스템간의 정보 교환. 메시지의 콘텐츠와 시퀀스는 예상되는 행동을 정의한다. 통신이 이루어지는 시스템은 알려지고 협의된 이벤트들에 대한 응답으로써 메시지를 처리하고 생성한다. 시스템은 알려지지 않은 오류 조건을 처리할 수 있어야 한다.
  • 런타임(Run-time) – 엔드 시스템(end system)이 사전 정의된 알고리즘을 사용해 정보에 대해 신뢰성 있게 작동하는 것. 데이터는 알고리즘의 결과를 결정하지만 동작은 모든 가능한 결과에 대해 정의된다.
IMS GLC 표준은 데이터 교환 상호운용성에 초점을 맞춘다. 이를 목적으로 IMS GLC 표준은 교환대상 정보의 데이터 모델과 데이터 모델을 캡슐화하고 데이터가 조작되는 방법을 제한하는 행동모델을 정의한다. IMS GLC 정보모델은 이 행동과 데이터 설명이 실체화한 것이며 정보모델은 하나 또는 그 이상의 IMS GLC 구성요소로 구성된다(이는 어플리케이션 서비스를 모두 또는 부분적으로 실체화한다). 이들 구성요소는 다양한 방법으로 실체화가 가능하다. 정의된 IMS GLC 방법은 XML 기반 바인딩이다. 즉 이 바인딩은 데이터가 어떻게 XML 메시지/문서로 교환되는지를 설명한다. 하지만 이러한 구조들을 실질적으로 전달하기 위해서는 최소한 적절한 통신 시스템이 필요하다. 추상 프레임워크 내의 XML 구성요소들 사이의 데이터 교환은 인프라 계층을 통해 정의된다. 이 인프라 설명에 대한 시스템 구성요소의 스키마 표현은 그림 6.3에 제시되어 있다. 이 표현은 시스템이 웹서비스 등에 대해서 느슨하게 결합되어 있다고 가정한다.
IMS KR 1005-2_6.3

그림 6.3 추상 프레임워크의 인프라 계층

그림 6.3에서 인프라의 핵심 부분은 다음과 같다.
  • IMS GLC XML 구성요소(components) – 필요한 이러닝 시스템을 만들기 위해 조합되는 어플리케이션과 공통 서비스 구성요소. 이들 구성요소들은 XML 문서의 형태로 정보를 교환한다고 가정한다.
  • XML 기반 콘텍스트(context) – XML 문서는 XML 메시지로 변환되며 이는 신뢰 가능한 데이터 전송, 데이터그램, 게시와 구독(publish and subscribe) 등 필요한 종단간 서비스를 지원하기 위해 설계된 공통 XML 메시징 인프라로 매핑된다. 선호되는 콘텍스트 매핑 언어는 WSDL이다.
  • XML 기반 엔벨로프 – 공통 XML 메시징 시스템은 SOAP/SOAP 메시지 첨부(이미지 등의 파일 첨부를 지원하기 위해 사용된다), eb-XML 등 여러 종류의 XML 엔벨로프 캡슐화를 사용해서 지원될 수 있다. WSDL은 SOAP, ‘HTTP-Get’ 그리고 ‘HTTP-Post’ 전송 매커니즘을 지원한다.
  • 일반 전송 – 엔벨로프는 SMTP, FTP, HTTP 등 적절한 종단간 전송 프로토콜을 이용해서 네트워크에서 전송된다.
  • 통신 네트워크 – 데이터를 하나의 시스템에서 다른 시스템으로 물리적으로 전송하기 위해 사용되는 실제 데이터 네트워크이다. 이는 거의 모든 경우에 유선 및 무선 네트워크 사이의 끊김없는 연결을 가능하게 하는 유비쿼터스 TCP/IP 통신을 기반으로 한다.

6.2 어플리케이션 서비스 계층

6.2.1 종단 정의의 규칙

통신 서비스의 종단들은 ‘초기자’와 ‘응답자’로 정의된다. ‘초기자’는 상호작용을 시작하고 메시지를 전송하는 시스템이며, ‘응답자’는 메시지를 처리한 후 정보를 회신할 수도, 하지 않을 수도 있는 즉, 초기 상호작용에 응답하는 시스템이다. 어플리케이션 서비스는 서비스 접점(SAP), 즉 추상 API로 표현된다. 성공적인 통신을 위해서 ‘응답자’는 무엇이 요청되는지 식별할 수 있어야 하며 지시의 시퀀스, 즉 비동기식 상호작용의 스트림을 장기간 수집해야 한다. 그러므로 바인딩은 다음과 같은 종단 식별 정보를 반드시 지원해야 한다.
  • 시스템 식별(system identification) – 고유한 시스템 식별자. 이 식별자는 물리적 어드레싱 시스템의 여러 부분 중 하나에 사용될 수 있다.
  • 서비스 식별(service identification) – ‘직원 관리 서비스(Person Management Service)’ 등 비즈니스 프로세스를 지원하는 서비스 객체.
  • 트랜잭션 식별(transaction identification) – 비즈니스 프로세스를 지원하기 위해 필요한 서비스 트랜잭션이며, ‘그룹’ 객체를 생성하기 위한 ‘그룹생성(createGroup)’ 등을 예로 들 수 있다.
  • 연산 식별(operation identification) – 트랜잭션 메시지 교환을 일으키기 위해 사용되는 추상 API 호출(call)의 작동이며, ‘개인(Person)’ 객체를 생성하기 위한 ‘개인생성(createPerson)’을 예로 들 수 있다.
  • 객체 식별(object identification) – 연산에 의해 조정되는 객체 식별자이며, ‘Person’에 대한 고유 식별자를 예로 들 수 있다.

6.2.2 행동 정의의 규칙

어플리케이션 서비스의 추상 API는 행동을 UML 클래스 다이어그램에서는 연산으로 정의한다. UML 상호작용 다이어그램은 연산을 표현하는 메시지가 어떻게 다른 행동들로부터의 메시지와 상호작용하는지를 보여준다. 이 행동들은 다음을 포함한다.
  • 제공된 파라미터(supplied parameters) – 연산을 위해 제공된 값/객체(values/objects)이며 UML에서 이들은 내부표식 파라미터(denoted 'in' parameters)이다.
  • 반환된 파라미터(returned parameters) – 연산 후 반환한 값/객체들이며 UML에서 이들은 외부표식 파라미터(denoted 'out' parameters)이다.
이러한 값/객체는 XML로 표현되며 적합성 관리 원천의 역할을 하기 위해 관련된 XSD를 반드시 가져야 한다. 모든 연산은 각각 반환해야 하는 ‘Status’ 객체를 가진다. ‘Status’ 객체는 수신한 메시지를 처리하기 시작하면 ‘응답자’의 종료 상태를 설명하는 상태정보를 포함하게 된다. 처리의 결과로 ‘응답자’의 오류상태/조건이 발생하면 이 상태는 오류정보를 포함할 수도 있다. 오류의 원인은 다음과 같다.
  • 비즈니스 규칙 위반(business rule violations) – 이는 데이터에 대한 의미상의 정확도와 관련이 있다. 오류에는 유효하지 않은 객체 식별자, 제한정보에 대한 접근 시도 등이 포함된다.
  • 유효하지 않은 데이터 콘텐츠(invalid data content) – 제공된 데이터가 구문적 오류를 가지고 있을 경우, 즉 XML이 유효하지 않을 수도 있을 경우. 너무 많은 정보가 제공된 경우, 즉 선택사항인 데이터 요소들이 필수 필드만을 저장할 수 있는 서비스에 제공되는 경우도 있다.
  • 가용불가 자원(unavailable resources) – 엔드시스템이 요청을 지원할 자원을 가지고 있지 않을 경우 발생한다. 이는 불충분한 데이터 저장, 바쁜(busy) 메시지 버퍼등의 조건 등이 원인일 수 있다.
  • 관련 공통 서비스 실패(related common service failures) – 오류는 정확한 종단간 연산을 제공하기 위한 상호작용을 위해 하나 이상의 서비스가 필요할 때 발생한다. 일반적인 예로는 인증, 권한 부여 등 SOAP 헤더에 포함된 제공된 정보가 필요한 상호작용에 대해 유효하지 않은 경우를 포함한다.
  • 인프라 서비스 실패(infrastructure service failures) – 기본 통신 인프라의 실패. 에러의 결과로 ’SOAP Fault’의 수신이 일어난다. 즉 SOAP 메시지에 다른 형태의 오류 정보가 있지 않을 수도 있다.
그러므로 바인딩 SOAP 메시지는 반드시 다음 행동정보를 지원해야 한다.
  • 서비스 식별(service identification) – SOAP 메시지에 의해 지원되는 서비스
  • 연산 식별(operation identification) – 요청되는 연산. 연산은 하나 이상의 비즈니스 트랜잭션으로 구성될 수 있다.
  • 객체식별(object identification) – 객체에 대한 고유한 식별자. 식별자는 반드시 ‘제공된 파라미터(Supplied Parameter)’의 하나로 전달되어야 한다.
  • 제공 파라미터 XML (supplied parameter XML) – ‘초기자’에서 ‘응답자’에게 보내는 정보. 관련 SOAP 메시지의 바디에 포함되어 있다.
  • 반환 파라미터 XML (returned parameter XML) – ‘응답자’에서 ‘초기자’에게 보내는 정보. 관련 SOAP 메시지의 바디에 포함되어 있다. 이는 상태객체 정보를 제외한다.
  • 상태객체 XML (status object XML) – 객체는 응답-유형 메시지에 포함된 모든 상태정보를 포함한다. 상태객체는 오류 보고 정보를 포함하기 위해 사용되며, 관련 SOAP 메시지의 헤더에 포함되어 있다.
  • 메시지 구성(message choreography) – 각 메시지는 종단간 구성의 각기 다른 부분들이 일치할 수 있도록 반드시 고유한 식별자를 포함해야 한다. 모든 응답-유형 메시지는 반드시 관련 요청-유형 메시지를 식별해야 한다. 구성은 메시징 모델의 유형에 의해 결정된다.

6.3 공통 서비스 계층

현재로써는 어플리케이션과 공통서비스 사이의 상호작용이 어떻게 구성되어야 하는지에 대한 IMS 권고사항은 존재하지 않는다. 일단 WS-CDL과 BPEL4WS 등 적절한 표준이 완성되면, 관련 권고사항들이 만들어 질 것이다.

6.3.1 오류 및 예외 처리

IMS GLC에 의해 바인딩의 일부로 정의된 SOAP 헤더 상태 정보 객체를 사용하는 어플리케이션 서비스 교환 상태 정보. 이 상태객체는 오류상태 정보를 포함하기 위해 사용된다. SOAP 통신에서의 추가적인 오류 정보는 SOAP 결함 메시지의 형태로 제공된다. 결함 정보는 SOAP 헤더에도 제공된다. IMS 웹서비스 베이스 프로파일은 상태정보가 어떻게 처리되어야 하는지, 그리고 어떠한 대응법을 적용해야 하는지에 대해 설명하지 않는다. 오류상태 정보의 경우, 이는 엔드시스템에서 예외를 처리하는 방법이 정의되지 않음을 의미한다. 일부 구현에서 예외 처리를 지원하기 위해 외부 공통 서비스가 호출될 수도 있다.

6.3.2 보안

시스템 보안은 전반적인 시스템 아키텍처의 설계에서 그 중요성이 갈수록 증가하고 있다. IMS 웹서비스 베이스 프로파일의 관점에서는 시스템 아키텍처의 많은 부분이 적용범위 밖에 있다. 이 기능은 적절한 공통 서비스를 이용해 지원될 수 있다. IMS 웹서비스 보안 프로파일은 보안 아키텍처가 어떻게 SOAP 메시징 매커니즘에 의해 지원되는지를 정의한다. 보안의 관점에서 공통 서비스 요건의 의미는 다음과 같다.
  • 세션(session) – 세션 관리는 공통 서비스를 이용해 제공될 수 있으며, 보안/사적 어플리케이션 멀티캐스팅(secure/private application multicasting), 복제 저장소 관리(replicated repository management) 등의 기능을 가능하게 한다.
  • 인증 및 권한 부여(authentication and authorization) – 엔드 시스템이 기업 내, 또는 기업들 사이에서 필요로 하는 사용자 상호작용을 최소화하기 위해서는 다중 어플리케이션을 SSO 인증(single sign-on authentication) 및 권한 부여 서비스(authorization service)를 이용하는 것이 바람직하다.
  • 암호화 및 전자서명(encryption and digital signing) – 데이터 암호화와 전자서명을 지원하기 위해 ’X.509’ 등 키 관리 공통 서비스가 사용되어야 한다.

6.3.3 라우팅

SOAP는 종단간(point-to-point) 프로토콜이다. 메시지 브로커(message broker), 저장전달방식(store-and-forward) 등 다른 통신 아키텍처에서 SOAP를 구현하는 것이 가능하다. 이를 위해 SOAP 메시지 라우팅/스위칭이 필요할 수 있으며 종단간 연결성의 스푸핑(spoofing)이 필요할 수 있다. 이들 서비스가 기본이 되는 IMS 웹서비스 베이스 프로파일 메시징 모델(동기식, 비동기식 등)과 상호작용하는 방법은 아직 정의되지 않았지만, 중개 시스템(intermediate system)의 구현에서는 엔드시스템의 행동이 관련 정보모델과 바인딩 표준과 일치해야 한다.

6.4 인프라 계층

그림 6.3에서 인프라 계층은 XMl 기반 엔벨로프 하위 계층으로부터 시작한다. WSDL의 경우 SOAP, HTTP-POST 또는 HTTP-Get의 형태를 취한다. 일반 전송 하위 계층은 TCP/IP 외에 HTTP 또는 HTTPS인 것으로 가정된다.

6.4.1 서비스 품질

가능한 서비스의 품질은 TCP에 의해 유지되는 서비스와 같다.
6.4.1.1 최선의 노력(Best Effort)
대부분의 TCP 유형은 ‘최선의 노력’ 서비스를 제공한다. 즉, 종단간 최대 지연시간이나 데이터 최소 전송속도를 보장하지는 않는다. 그러므로, 엔드시스템에서 인지하는 서비스의 품질은 네트워크 인프라의 다른 로드(load, 이는 시간에 따라 결정된다), 네트워크 링크의 대역, 네트워크 링크의 오류, 스위치와 라우터의 숫자와 기능, 그리고 이보다는 영향이 작지만 종단 사이의 물리적 전달 거리에 의해서 결정된다.
6.4.1.2 세션 지원
TCP 내에는 세션 지원이 이루어지지 않는다.
6.4.1.3 중복 제거
TCP의 바이트 스트리밍 연산(byte streaming operation)은 데이터 복제가 링크된 TCP 종단 사이의 물리적 네트워크 인프라에서 일어나지 않도록 한다. 하지만 상위 프로토콜이 정보를 복제한다면 TCP는 이를 감지하지 못한다. 현재 IMS 웹서비스 베이스 프로파일은 신뢰성 있는 SOAP 메시징을 제공하지 않지만 구현 시에 고유 메시지 번호부여 능력(unique message numbering) 등을 생성할 수 있는 매커니즘은 제공한다(6장 참조).
6.4.1.4 전달 보장
일단 TCP 프로세스가 데이터 전송 요청을 수신하면 데이터 전송을 보장하거나 데이터 전송 실패 상태를 통지한다. 스트리밍 프로토콜이 훼손된 데이터를 재전송하기 때문에 데이터 오류가 발생하지는 않는다. 하지만 유효하지 않거나 훼손된 데이터가 TCP 프로세스에 제출된다고 하더라도 해당 정보는 목적지에 제대로 전달된다.

6.4.2 메시지 패키징

6.4.2.1 단일 XML 페이로드
XML 페이로드(payload)는 SOAP 바디에 포함된다. 이 페이로드의 유효성은 관련 XSD에 의해 결정된다.
6.4.2.2 다중 페이로드
IMS 웹서비스 베이스 프로파일은 단일 XML 페이로드만이 SOAP 바디에서 지원하도록 제한한다. 그러므로 다중 XML 페이로드는 XML 컨테이너 XSD의 사용을 필요로 한다. 이 컨테이너는 하나 또는 하나 이상의 핵심 데이터 XML 구조를 지원하도록 정의된다.

6.4.3 일반 전송 계층

SOAP 메시징 매커니즘은 여러 전송 프로토콜을 지원한다. 인터넷 프로토콜 스위트(Internet Protocol Suite)와 관련해 이들 전송 프로토콜들은 공식적으로 어플리케이션 프로토콜로 지칭된다. 모든 프로토콜은 TCP/IP를 이용해 작동한다.
6.4.3.1 HTTP/HTTPS 규칙
SOAP 메시지의 교환을 위해 IMS 웹서비스 베이스 프로파일에서 권고하는 프로토콜이다.
6.4.3.2 SMTP 규칙
이 프로토콜은 IMS 웹서비스 베이스 프로파일에서 지원되지 않는다.
6.4.3.3 FTP 규칙
이 프로토콜은 IMS 웹서비스 베이스 프로파일에서 지원되지 않는다.

7 구현 프로파일

7.1 메시징 모델

7.1.1 동기식 요청/응답 메시징 구성

동기식 메시지 바인딩의 메시지 구성은 그림 7.1에 제시되어 있다. 이 다이어그램은 ‘서비스 요청자(Service Requester)’와 ‘서비스 제공자(Service Provider)’가 어떻게 관련 통신 처리자인 ‘Service Request Comms Hndlr' 및 'Service Provider Comms Hndlr'과 각각 정보를 교환하는지를 보여준다.
IMS KR 1005-2_7.1

그림 7.1 동기식 요청/응답 메시지 구성

오류 없는 연산을 위한 메시지 구성은 다음과 같다.
  1. ‘서비스 요청자’는 요청을 촉발한다. 이는 동기식 요청이며 ‘서비스 요청자’는 ‘서비스 제공자’가 요청에 응답할 때까지 통신이 차단된다.
  2. ‘Service Requester Comms Hndlr'은 요청 메시지를 구성하고 전송한다(베이스 프로파일의 경우 이는 SOAP 메시지의 형태를 띈다). 'Service Requester Comms Hndlr'은 응답 메시지를 수신할 때까지 기다린다(우수한 시스템 설계에서는 시스템이 교착상태에 놓이는 것을 막기 위해 적절한 결함 회복 매커니즘의 실행을 갖출 것을 요구한다. 이는 베이스 프로파일의 적용범위가 아니다).
  3. 'Service Provider Comms Hndlr'은 요청 회신 후 처리되며 캡슐화된 요청은 ‘서비스 제공자’에게 전달된다.
  4. ‘서비스 제공자’는 요청을 처리하여 적절한 응답을 구성한다. 일단 이 응답이 'Service Provider Comms Hndlr'에 의해 수신되면 ‘서비스 제공자’는 다른 처리 작업을 시작해도 된다.
  5. ‘Service Provider Comms Hndlr'은 적절한 응답 메시지를 구성하고 전송한다(베이스 프로파일에서 이는 SOAP 메시지의 형태를 띤다).
  6. 'Service Requester Comms Hndlr'은 응답 메시지를 수신한다. 이에 따라 관련 응답정보는 ‘서비스 요청자’에게 전달된다. 이는 ‘서비스 요청자’에 대한 통신차단을 해지하며, 이에 따라 ‘서비스 요청자’는 다른 요청들을 보낼 수 있다.
오류 회복(error recovery)은 베이스 프로파일 정의 범위에 해당되지 않는다. 구성의 구현은 정확한 정보의 동기식 교환을 보장해야 한다. 실제 WSDL/SOAP 바인딩 실현은 오류회복을 위해 사용될 수 있는 여러 기능들을 제시한다.

7.1.2 비동기식 메시징 구성

현재 IMS는 비동기식 통신 메시징 구성(Asynchronous Communications messaging choreography)의 최종판 발행을 승인하지 않았다. 이는 이 기법에 대한 적합한 구현 예가 없기 때문이며, W3C는 IMS 접근법이 독점적이 될 수 있도록 작업을 진행 중이다. 이 작업은 여전히 공개초안(Public Draft) 자료 이다.

7.1.3 폴링 메시징 구성

현재 IMS는 폴링 통신 메시징 구성의 최종판 발행을 승인하지 않았다. 이는 이 기법에 대한 적합한 구현 예가 없기 때문이며, W3C는 IMS 접근법이 독점적이 될 수 있도록 작업을 진행 중이다. 이 작업은 여전히 공개초안 자료이다.

7.1.4 게시 및 구독(Publish and Subscribe)

이 문서의 다음 버전에서 다루어질 것이다.

7.2 조직 프로파일(Organizational Profiles)

요청자와 공급자가 조직 경계(bounds) 또는 신뢰 경계(trust bounds) 중 어떤 것을 지나는지에 따라 웹서비스가 사용되고 호출되는 방법에서 고려해야 할 사항이 여러가지 있다. 조직 내, 그리고 조직간 통신에서의 고려사항들은 서로 관련이 있으므로 독자들은 조직 내, 그리고 조직간 통신에서의 고려사항들을 모두 검토해야 한다.

7.2.1 조직내 통신

고려사항들은 다음과 같다.
  • 학습자에게 ‘SSO’ 경험이 필요한가?
  • 모든 시스템들이 조직 내에서 서로를 ‘신뢰’ 한다고 가정할 수 있는가? 즉, 조직은 진정으로 단일 ‘신뢰 단위(Unit of Trust)’로 모델링 될 수 있는가?
  • ‘연합 계정(Federated Identity)’의 구심점 역할을 하며 통합 할 수 있는 중앙 시스템이나 ‘서비스’가 존재하는가?
    • 사용자 식별관리 및 인증(user identity management and authentication)
    • 사용자 속성(user attributes)
    • 사용자 등록(권한 부여, authorization)

7.2.2 조직간 통신

조직간 통신에서의 고려사항들은 다음과 같다.
  • 모든 서비스 제공자들이 사전에 확정되는가, 아니면 검색이나 레지스트리를 통해 동적으로 설정되는가?
    • 2단계 커미트(two-phase commit)의 일환으로 시스템 그리고/또는 조직간에 필요한 모든 트랜잭션에 대해 고려할 사항들이 존재하는가?
    • 서비스 제공자와 요청자의 계정을 검증하기 위해 서드파티 ‘인증서’가 필요한가?
  • 하나의 조직은 계정관리를 위한 ‘기록 시스템(system of record)’이 되는가? 그렇다면, 다음 작업도 담당하는가?
    • 인증을 관리하고 사용자 인증의 현 상태를 통신하는가?
    • ‘로그아웃’을 관리하고 다른 조직과 관련 행동을 통신하는가?
    • 사용자에 대한 모든 필요한 자격 정보를 가지는가?
    • 필요한 모든 사용자 속성과 자격정보를 가지는가?
    • 어떤 속성들을 공유할 수 있는가?
  • SLA (Service Level Agreement)에 어떤 파라미터가 적용되는가?
    • 가용성(availability)?
    • 접근성(accessibility)?
    • 성능(performance)?
    • 신뢰성(reliability)?
    • 보안(security)?
    • 서비스를 호출할 수 있는 합의된 역할/요청자는 어떤 자격을 가져야 하는가?
  • ‘신뢰 범위(Circle of Trust)’, 즉 ‘신뢰 사슬(Trust Chain)’에 포함된 조직들 사이의 모든 통신에 대해서 다음 사항을 고려한다.
    • 요청되어 실행된 서비스에 대해서 ‘부인봉쇄’의 필요가 있는가?
    • XML 패키지의 일부 데이터는 요청을 받기 전에 ‘블랙 아웃(blacked out)’ 또는 암호화되어야 하는가(데이터는 민감하며 서비스의 일부일 필요는 없다)?
    • 요청/응답은 기밀성을 유지하기 위해 암호화(SSL, TLS)되어야 하는가?
  • SLA와 암호화 요건은 어떤 메시징 모델이 사용되어야 하는지에 영향을 주는가?

8 활용사례

8.1 지원상태/오류코드 및 예외 처리

SOAP 메시지에 매핑되어야 하는 행동 기반 IMS 정보 모델이 개발되면 각 연산은 상태정보를 회신해야 한다. 이 상태정보는 연산의 성공 등 상태에 대한 주변정보를 제공한다. 엔드시스템이 사용할 수 있는 상태 정보에는 다음과 같은 두 가지가 있다.
  • 비즈니스 트랜잭션(business transaction) – 엔드시스템에 의해서 교환되는 트랜잭션의 비즈니스 논리를 반영하는 상태 보고서. 이 상태정보는 특수하게 정의된 데이터 구조하에서 메시지 헤더 내에 포함된다. 포함된 상태정보는 오류코드를 포함하기 위해 사용된다. 즉, 오류보고는 상태정보 보고의 하위집합으로 처리된다.
  • SOAP 결함(SOAP fault) – SOAP 메시징 인프라에 의해 보고되는 SOAP 결함코드로, SOAP 메시지 헤더에 포함된다. 2계층(two-tier) 결함 메시지 코드가 사용 가능하며, 2계층 중 상위 계층은 확장 불가능한 리스트이다.
비즈니스 트랜잭션을 위한 상태정보는 다음 하위구조를 포함하는 단일 상태정보 객체에 포함되어 있다.
  • CodeMajor – 상태 블록에 지정된 주요 코드이다. 고정된 열거 목록이며, ‘severity’와 연계되어 사용된다. 코드의 목록은 ‘ Success, Processing, Failure, Unsupported’이다.
  • Severity – 상태보고의 중요도이며, 고정된 열거목록이다. ’CodeMajor’과 연계되어 사용되며, 코드 목록은 ‘Status, Warning, Error’이다.
  • CodeMinor – 실패의 구체적인 원인을 식별하기 위해 사용되는 자세한 보고 코드 구조. 각 트랜잭션에 대한 코드의 집합이 정의될 수 있으며, 이는 관련 정보모델의 일부로 정의된다.
‘CodeMajor/Severity’ 매트릭스의 해석방법은 표 8.1에 제시되어 있다. IMS 표준은 상태정보가 엔드시스템 내에서 어떻게 처리되는지 설명하지 않는다. 즉, 이는 구현 시에 추상 API가 어떻게 물리적으로 실현되는지에 따라 좌우된다. 하지만, 구현물은 다음을 수행할 수 있어야 한다.
  • 트랜잭션 상태정보와 SOAP 오류코드를 단일 통합 상태보고 매커니즘(single integrated status reporting mechanism)으로 통합한다. 구현물에 의해 사용가능한 다른 시스템의 실패 정보 또한 같은 매커니즘을 사용해야 한다.
  • 연산의 적절한 단계가 완료된 이후, 특히 연산이 완료된 이후에 보고된 상태정보를 검토한다. 이는 명확한 상태정보 호출을 필요로 할 수 있으며 API 호출의 일부로 보고될 수 있다.
  • 연산 내의 각 트랜잭션에 대한 상태정보 보고를 구분한다. 일부 표준은 하나 이상의 트랜잭션 요청을 포함하는 연산을 제공하며 이러한 트랜잭션에 각기 다른 상태정보가 주어질 수 있다.
예외 처리는 알려진 또는 알려지지 않은 오류조건에 대한 시스템의 대응이다. 예외 처리는 IMS 웹서비스 베이스 프로파일 표준의 범위에 포함되어 있지 않다. 하지만 오류조건이 엔드시스템을 제어되지 않은 상태에 놓이게 해서는 안 된다. 모든 연산이 상태정보를 회신하는 것은 구현물이 제어가능한 방법으로 종료되도록 하기 위해서이다. 표 8.1 ‘CodeMajor/Severity’ 매트릭스의 해석

중요도

CodeMajor

Success

Processing

Failure

Unsupported
Status 요청이 성공적으로 이루어짐. 타겟(target)에 의해 요청이 처리되고 있음. 즉, 요청이 타겟 통신 처리기에 의해 수신되어 확인됨. 요청이 실패함. 관련 ‘CodeMinor’ 정보는 요청 실패에 대한 더 자세한 원인을 포함함. 관련된 비즈니스 표준은 반드시 이 코드의 집합을 정의해야 함. 타겟은 요청된 연산을 지원하지 않음.
Warning 일부 요청이 성공적으로 완성됨. 즉, 부분적으로 저장된 데이터 구조가 송신됨. 요청이 처리되고 있음(이는 타겟 통신 처리기에 의한 수신을 의미하지는 않음). 하지만 타겟에 의해 수신된 것으로 확인되지는 않음. 허용되지 않음. 허용되지 않음.
Error 허용되지 않음. 직접 전송 통신 처리기에서 오류가 감지됨. 즉, 메시지는 엔드시스템을 떠나지 않음. 요청이 실패했지만 로컬 통신 처리기에 의해서 보내짐. 자세한 실패 보고서가 포함될 수 있음. SOAP 결함 코드는 이 ‘CodeMajor/Severity’ 값을 이용해 보고됨(‘CodeMinor’ 객체에서 제공됨). 타겟은 요청된 연산을 확인하지 않음. 즉, 알려지지 않은 서비스 확장임.

8.2 여러가지 통신 메시징 모델의 지원

다양한 통신 모드의 지원을 위한 IMS의 접근법은 이를 바인딩 내에 숨기는 것이다. 즉, 정보모델은 바인딩에서 사용되는 통신 모델들의 형식을 제한하지 않는다. 그러므로 바인딩은 다음 특징들을 갖도록 설계되었다.
  • 각 메시지는 고유한 식별자를 가진다. 메시지 식별자들은 시퀀스로 지정되지 않아도 된다. 즉, 식별자는 메시지 시퀀스 번호가 아니다.
  • 모든 응답과 확인 메시지는 초기 메시지 식별자를 제공할 것이다. 이는 구현물이 원인과 결과(cause and effect) 메시지를 연결할 수 있도록 한다.
  • 메시지 식별자 정보는 적절한 메시지 구조체의 헤더에 실린다. 즉, 이 경우에는 SOAP 메시지이다.
다음 기능들은 바인딩에서 지원되지 않으며, 구현물은 이들에 대해서 요청을 받는 즉시 제공해야 한다(이들 기능 중 일부는 적절한 웹서비스 표준에서 개발되고 승인되면 바로 제공될 수 있다).
  • 오류 인식 및 수정(error detection and correction) – 모든 메시지는 정확하다고 가정한다. 즉, 비트 오류(bit error)는 존재하지 않는다.
  • 메시지 손실과 복제 예방(message loss and duplication avoidance) – 메시지는 통신 인프라에 의해 손실되거나 복제되지 않은 것으로 가정한다.
SOAP는 단일, 또는 두 개의 메시지(two-message) 통신 매커니즘이다. 즉, SOAP는 두 개 이상의 메시지에 대해서 복잡한 구성을 하지 않는다. 그러므로 비동기식과 폴드 통신 메시지 모델들은 WSDL과 그 SOAP 메시징 정의를 정교하게 사용해야 한다. 이를 위해서는 구현물이 완전한 메시지 구성을 생성하기 위해서 결합해야 하는 여러 WSDL 파일에 대한 정의 집합을 필요로 한다. 이 접근법은 IMS 웹서비스 WSDL 바인딩 가이드라인에 충분히 설명되어 있다.

8.2.1 동기식 메시징 상태 코드

단일 상태코드는 각 트랜잭션에 대한 응답 메시지에서 보내진다.

8.2.2 비동기식 메시징 상태코드

현재 IMS는 비동기식 통신 메시징 구성의 최종본 발행을 승인하지 않은 상태이다. 이는 이 기법에 대한 검증된 구현 예가 없기 때문이며, W3C는 IMS 접근법이 독점적이 될 수 있도록 작업을 진행 중이다. 이 작업은 여전히 공개초안자료이다.

8.2.3 폴링 메시징 상태코드

현재 IMS는 폴링 커뮤니케이션 메시징 구성의 최종본 발행을 승인하지 않은 상태이다. 이는 이 기법에 대한 검증된 구현 예가 없기 때문이며 W3C는 IMS 접근법이 독점적이 될 수 있도록 작업을 진행 중이다. 이 작업은 여전히 공개초안자료이다.

8.3 버전 관리

버전 관리에 대한 다음 사항들은 W3C의 버전 관리 XML 언어를 기반으로 하며 ‘http://www.w3.org/2001/tag/doc/versioning-20031003’에서 참조 가능하다. 넓은 관점에서 보면, 버전 관리에 대한 접근법은 다음과 같다.
  • 없음(none) – 언어의 버전간에 차이를 두지 않는다. 어플리케이션은 버전관리에 관여하지 않거나, 어떤 버전을 마주치더라도 이를 처리할 수 있다.호환성(compatible) – 개발자들은 하위 버전과의 호환성(backwards compatibility), 상위 버전과의 호환성(forwards compatibility), 또는 두 가지 모두로 변경을 제한할 수 있다.
    • 하위 버전과의 호환성: 어플리케이션이 언어의 ‘구형’ 버전의 인스턴스 문서를 수신하면 제대로 동작할 것으로 기대된다. 하위 호환 가능한 변경(backwards compatible changes)은 어플리케이션이 언어의 ‘구형’ 버전을 수신하면 제대로 동작하도록 한다.
    • 상위 버전과의 호환성: 어플리케이션이 언어의 ‘신규’ 버전의 인스턴스 문서를 수신하면 제대로 동작할 것으로 기대된다. 상위 호환 가능한 변경(forwards compatible changes)은 기존의 어플리케이션이 언어의 ‘신규’ 버전을 수신하면 제대로 동작하도록 한다.
  • 변종(Flavor) – 어플리케이션이 문서유형의 변종집합의 한 가지를 수신하면 제대로 동작할 것으로 기대된다.빅뱅(big bang) – 어플리케이션이 예상하지 못한 버전을 보면 처리를 중단할 것으로 예상된다.
항상 정확한 접근법이란 존재하지 않는다. 어플리케이션 도메인은 각기 다른 접근법을 선택할 것이다. 접근법에 여러 가지가 있듯이, 접근법을 구현하는 데에도 여러 가지 접근법이 있다. 인터넷을 포함하는 MIME, 마크업 언어, 그리고 XML 언어는 단일한 전략, 또는 XML 네임스페이스나 스키마 등 여러 전략을 통합해 사용해왔다. 어떤 접근법에서는 일부 전략이 다른 전략보다 더 적절할 수 있다. 다음과 같은 전략들이 있다.
  • 반드시 이해(Must Understand) – 수신자들은 수신된 모든 요소들과 속성들을 반드시 이해해야 하며 이해하지 못할 시에는 처리를 중단해야 한다. SOAP 프로세서는 필수인 것으로 명확하게 식별된 헤더들을 반드시 이해해야 한다.
  • 반드시 무시(Must Ignore) – 수신자는 이해하지 못하는 요소나 속성을 반드시 무시해야 한다. 어떤 경우 ‘반드시 이해’와 ‘반드시 무시’ 접근법은 더 선별된 용도를 위해 결합되어 사용될 수 있다. 헤더가 자신을 반드시 이해 되어야 하는 것으로 명확히 밝히지 않는 이상 SOAP 프로세서는 반드시 헤더를 무시해야 한다. ‘반드시 무시’ 전략에는 두 가지 파생된 형태가 있다.
    • 반드시 모두 무시(Must Ignore All): ‘반드시 무시’에서 파생된 형태로 수신자는 이해하지 못하는 요소나 속성, 그리고 요소의 경우 모든 하위 요소들을 무시해야 한다. SOAP 헤더블록이나 WSDL 확장을 사용하는 웹서비스 등 대부분의 데이터 어플리케이션은 예상치 못한 마크업에 대처하기 위해 이 접근법을 사용한다.
    • 반드시 무시 컨테이너 (Must Ignore Container): ‘반드시 무시’에서 파생된 형태로 수신자는 이해하지 못하는 요소나 속성을 무시해야 한다. 하지만 요소의 경우에는 해당 하위 요소를 처리하도록 한다. ‘반드시 무시 컨테이너’의 사례는 HTML 2.0에 설명되어 있다.
  • 명확한 대안(Explicit Fallback) – 확장이 지원되지 않은 경우, 언어는 분명한 대안을 위한 매커니즘을 제공할 수 있다. MIME은 ’multipart/alternative’를 제공하며, 콘텐츠 표현을 대체한다. HTML 4.0은 ’NOFRAMES’ 요소에서 이 접근법을 사용한다. XML에서 XML 포함 표준(XML Inclusions specification)인 Xinclude는 포함된 것으로 추정되는 곳에서 자원을 검색할 수 없는 경우를 처리하기 위한 대안 요소를 제공한다.
  • 명확한 테스트(Explicit Testing) – 언어는 명확한 테스트를 위한 매커니즘을 제공할 수 있다. XSLT 표준은 조건부 논리 요소와 확장 기능의 존재를 테스트할 수 있는 기능을 제공한다. 이는 스타일 시트 설계자들이 다른 수신자 기능들을 명확하게 처리할 수 있도록 해준다.
언어는 다양한 접근법들을 여러 개 사용할 수 있다. 예를 들어, XSLT는 일부 조건에는 명확한 대안 매커니즘을 그리고 다른 조건들에는 명확한 시험을 제공한다. 또 다른 사례인 SOAP 표준은 ‘반드시 무시’를 결함 전략으로 설명하며 구성요소들을 동적으로 마크할 수 있는 능력을 ‘반드시 이해’ 전략에 포함된 것으로 설명한다.

8.3.1 IMS 버전 관리 해결책

IMS의 해결책은 SOAP 헤더에 포함된 별도의 버전구조를 추가하는 것이다. 이 구조는 선택사항이며, 부재 시 결함버전은 IMS 웹서비스 베이스 프로파일 1.0버전이다.

8.4 메시징 설문지 템플릿의 사용

첨부 B에 실린 메시징 설문지는 다음 세 가지 메시징 매커니즘을 살펴본다.
  • 요청 데이터 업데이트(request data update)
  • 요청/응답 읽기(read request/response)
  • 데이터 모니터링(data monitoring)
다음 절들은 위에 나열된 각 메시징 매커니즘들에 대한 질문들을 확인한다. ‘[]’안의 숫자들은 메시징 설문지의 질문 번호를 표시한다. 질문들은 관련 메시징 매커니즘을 사용해 통신하는 시스템인 ‘X’(소스)와 ‘Y’(타켓)을 식별한다.

8.4.1 유스케이스 #1: 요청 데이터 업데이트/ACK (또는 NAK)

다음을 기반으로 하는 시스템에 대한 핵심 질문들이다.
  • ‘X’는 생성/업데이트/삭제(Create / Update / Delete)를 ‘Y’에 보낸다.‘Y’는 응답을 ‘X’로 회신한다.
1) [3] 허용만 가능 또는 거절 가능? ‘Y’ 시스템은 ‘X’의 변경을 거절할 수 있는가? 버전번호가 잘못되거나 이보다 심한 경우 요청 메시지가 ‘well formed’ 또는 ‘valid’ 조사를 통과하지 못한다면 무엇인가? 변경이 위반인 경우, 예를 들어 객체가 존재하지 않는다면 무엇인가? 모든 오류(시스템 수준, XML 수준, 비즈니스 수준 등)는 동일한 방법으로 보고되어야 하는가? 2) [4] 동기식 또는 비동기식 응답 ‘Y’의 응답은 즉시 나올 것으로 예상되는가? 그렇지 않다면, 응답은 어떻게 요청과 연관되는가? 응답은 ‘Y’의 데이터베이스 업데이트가 실제로 이루어졌음을 의미하는가? 그렇다면 ‘X’는 업데이트가 이루어지기 전까지 항상 요청 처리를 보류하는가(‘Y’가 다른 조직에 있더라도 그러한가)? ‘Y’의 데이터베이스 업데이트가 실제로 이루어진 이후라면, 또는 요청 메시지를 처리하는 동안 오류가 발생하는 경우 변경요청은 즉시 인지하고 실제 응답은 나중에 비동기식으로 보내질 수 있는가? 특정 ‘X’ 시스템이 응답을 기다리는 시간에 제한이 있는지, 그리고 ‘Y’ 시스템이 이 시간제한을 알아야 하는가? 만약 그렇고, 단순히 프리와이어(pre-wired)된 것이 아니라면, 인프라는 ‘세션상태’를 지원해야 할 수도 있다. ‘X’ 시스템은 실행 전 요청을 취소해야 할 필요가 있는가? 3) [5,6] 어떠한 서비스품질 수준(QoS)이 필요한가? 응답 메시지가 분실되면, 그리고 일정 시간이 지나 ‘X’가 재송신을 한다면, ‘Y’는 중복 메시지의 전달을 인식할 필요가 있는가? 즉, 업데이트 메시지를 두 번 보내는 것은 오류인가? 인프라는 중복 메시지 전달을 방지해야 하는가? 요청이 성공적으로 이루어지기 위해 수신자(또는 네트워크)는 활성화되어야 하는가? 인프라는 보장된 메시지 전달을 지원해야 하는가(그렇게 함으로써 요청을 보내는 ‘X’의 작업을 더 용이하게 하는가)?’ 4) [9,10,11] 파트너 위치는 어떻게 결정되는가? ‘Y’의 위치는 ‘X’에 프리와이어되는가? 하나 이상의 ‘Y’가 ‘X’에 연결된다면 ‘X’는 변경사항을 어떤 ‘Y’에게 통지해야 할지를 어떻게 알 수 있는가? ‘전역적으로 고유한’ 기록ID가 있는가? 만약 그렇다면, ‘Y’ (그리고 ‘Y’와 연결된 모든 ‘X’ 파트너)에 대해서 전역적인가? 또는 적합할 수 있는 모든 ‘Y’에 대해서 전역적인가? 전자의 경우라면, 하나의 ‘X’는 여러 개의 ‘Y’에 연결될 수 없다. 5) [12, 13] 데이터 모니터링 능력은 필수인가? ‘X’는 ‘Y’에 담긴 데이터와 일치해야 하는가? 다시 말해, ‘X’에게 통지해야 할 변경사항 중 ‘X’가 야기하지 않은 ‘Y’의 데이터 변경사항이 있는가? 만약 있다면, ‘X’는 그 자체가 웹서비스이며 ‘Y’가 ‘X’를 알고 있어야 하며, ‘Y’는 ‘X’의 API를 이용해 이러한 변경사항을 게시할 것이다. 이에 따라, ‘X’는 ‘Y’로부터 통보 받은 변경사항들을 반드시 ‘구독’해야 한다. 서드파티(‘이벤트 로거’ 등)가 모든 변경사항들을(‘X’ 또는 ‘Y’의 변경) 추적하도록 허용할 필요가 있는가? 만약 그렇다면, 게시/구독 모델의 변형을 지원하는 인프라는 매우 유용하다. 6)[14,15,16,17] 어느 정도의 보안 등급이 필요한가? ‘X’와 ‘Y’ 사이의 통신에 대한 보안 요건이 있는가? 있다면 어떤 방향이며 어떤 유형인가? A. 데이터의 암호화? B. ‘X’를 ‘Y’에 대한 변경 요청의 소스로 인증? C. 이 데이터에 대한 변경 요청을 보내기 위한 ‘X’의 인증? 인프라에 의해서 이러한 보안 요건은 어느 정도까지 제공되어야 하나? 7) [18, 19, 20] ‘One-shot’ 통신 교환으로 충분한가, 아니면 세션 지원이 필요한가? ‘X’와 ‘Y’는 더 오래 지속되는 통신을 하는가? 상태가 지속되는 세션이 ‘X’와 ’Y’ 사이에 만들어지는가? 만약 그렇다면, 그러한 세션에서의 상태변수에는 어떤 것들이 있는가? A. 보안 ’쿠키’? B. 각 참여자의 버전번호? C. 지원되는/지원되지 않는 선택적 서비스 위 정보 중 ‘X’와 ‘Y’가 합의해야 하는 정보 중 동적으로 발견되어야 할 정보는 어느 정도 되는가? 이 정보 중 시스템관리자에 의해 사전에 설정되어야 하는 정보는 어느 정도 되는가? 8) [21, 22] 선택 요소들은 어떻게 해석되는가? 스키마에서 이러한 교환을 정의하는 선택적 요소들이 있는가? 만약 그렇다면, 한 쪽이 그러한 선택적 요소를 지원하지는 않지만 다른 한 쪽은 이에 의존하는 사례가 없다고 양측은 어떻게 확신할 수 있는가? 9) [23] 다른 전송들이 사용될 수 있는가? ‘X’와 ‘Y’간 통신이 논리적으로 일어날 것이라고 예상되는 여러 다른 전송들의 범위는? A. HTTP B. HTTPS C. IIOP (Corba) 또는 DCOM D. MOM (MQ/Series, MSMQ, JMQ 등) E. SMTP (다중 이진 페이로드 지원하는 것에 주의) F. 기타(FTP 등) 10) [28, 29] 배치 업데이트에 대한 지원이 필요한가? X’는 하나 이상의 객체에 참조 데이터를 업데이트할 수 있는가? 만약 그렇다면, 업데이트 메시지 스키마는 통합을 지원할 수 있는가? 11) [30, 31, 32] 이 데이터베이스 업데이트에서 트랜잭션과 관련한 고려사항이 있는가? ‘X’의 변경 요청은 더 큰 규모의 트랜잭션(여러 당사자가 참여하는 트랜잭션도 가능)의 일부로 여겨질 수 있는가? 예를 들어, ‘X’의 변경요청을 ‘Z’ 시스템에 전달할 수 있는가? 만약 그렇다면, ‘Z’ 시스템은 ‘Y’ 시스템이 수신 응답을 보내기 전에 데이터 업데이트를 완성해야 할 수도 있다. 만약 그렇다면, 문서에서 식별된 트랜잭션의 경계는? 트랜잭션 식별자들이 와이어에 나타나야 할 필요가 있는가? 12) [33] 버전 번호는 무엇을 의미하는가? 교환에 개입하는 메시지들의 버전번호는 다음 중 무엇을 지칭하는가? A. 양측에 의해 지원되는 특정 배포 버전? B. 업데이트가 이루어지는 데이터 객체의 버전? C. 응답 메시지 또는 변경 요청을 위한 스키마의 버전? 13) [34, 35] 메시지 패키징 요건은 무엇인가? 요청 또는 응답은 다중 독립 페이로드들로 구성될 수 있는가? 이러한 페이로드들은 XML 외의 다른 포맷을 가질 수 있는가? 14) [36, 37] 적법성(Legality) 업데이트 요청 또는 요청에 대한 응답의 부인봉쇄에 관한 요건이 있는가? 메시지 데이터의 변경불가 보장에 대한 요건이 있는가? 15) [38, 39, 40, 41, 42] 연산 상세사항 데이터 기록에 대한 부분적 수정이 가능한가? 만약 그렇다면, 변경되는 요소들의 원래 값들도 변경 요청에 포함되어야 하는가? 그렇지 않다면, 전체 객체 스키마 내의 이들 요소들의 ‘위치’는 어떻게 제시되는가? ‘X’로부터의 변경요청이 ‘생성’을 지시하면, 메시지 내에는 해당 객체에 대한 GUID가 포함되는가? ‘Y’가 객체에 대해서 GUID 생성을 소유하는 경우 이는 문제가 될 수 있음에 유의할 것. GUID가 포함되지 않은 경우, ‘Y’가 지정하는 GUID의 값은 ‘X’로 보내지는 응답 메시지를 통해 송신되는가?

8.4.2 유스케이스 #2: 읽기 요청/응답

다음을 기반으로 하는 시스템에 대한 핵심 질문들이다.
  • ‘X’는 ‘Y’에 ‘읽기요청’을 보낸다.
  • ‘Y’는 ‘X’에 응답을 보낸다.
1) [4] 동기식 응답인가 비동기식 응답인가? ‘Y’ 응답은 즉시 보내질 것으로 예상되는가? 그렇지 않다면 응답은 어떻게 요청과 연관되는가? ‘X’ 시스템이 응답을 기다리는 시간에 제한이 주어지는가? 그리고 ‘Y’ 시스템은 이 제한시간을 알 필요가 있는가? 만약 그렇고, 그리고 단순히 프리와이어된 것이 아니라면, 인프라는 ‘세션상태’를 지원해야 할 수도 있다. 2) [5, 6] 요구되는 서비스품질(QoS)의 수준은? 요청이 성공적으로 이루어지기 위해 수신자(또는 네트워크)는 활성화되어야 하는가? 인프라는 메시지 전달 보장을 지원해야 하는가(그럼으로써 요청하는 ‘X’의 작업을 더 용이하게 하는가)? 3) [9, 10, 11] 파트너에 대해 알려진 정보는? ‘Y’의 위치는 ‘X’에 프리와이어되는가? ‘전역적으로 고유한’ 기록 ID가 있는가? 만약 그렇다면, 단일 ‘Y’에게만 전역적인가 아니면 적합 가능성이 있는 모든 ‘Y’에게 전역적인가? 전자의 경우, 하나의 ‘X’는 다중 ‘Y’에 연결될 수 없다. 요청자가 장치라면(예를 들어, 가격검색의 경우 클라이언트는 내부 서버, POS 또는 스캐너일 수 있다) 응답은 다를 수 있다(단일 라인 디스플레이에 대한 완전한 정보). 응답이 요청자의 유형에 좌우된다면, 응답자는 어떻게 관련 정보를 얻는가? 4) [12, 13] 데이터 모니터링 능력은 꼭 필요한가? X는 Y에 포함된 데이터와 일치해야 하는가? 즉, ‘Y’ 데이터에 대한 변경사항 중 ‘X’에게 통보되어야 하는 것이 있는가? 만약 그렇다면, ‘X’는 그 자체가 웹서비스이거나, ‘Y’가 알고 있어야 하며, ‘Y’는 ‘X’의 API를 이용해서 그러한 변경사항들을 게시할 것이다. 이에 따라, ‘X’는 반드시 ‘Y’로부터 통보된 변경사항들을 ‘구독’해야 한다. 서드파티(‘이벤트 로거’ 등)가 ‘Y’의 모든 변화를 추적하도록 허락해야 하는가? 만약 그렇다면 게시/구독 모델의 변형된 형태를 지원하는 인프라는 매우 유용하다. 5) [14, 15, 16, 17] 어느 정도의 보안 등급이 필요한가? ‘X’와 ‘Y’사이의 통신에 대한 보안 요건이 있는가? 있다면 어떤 방향이며, 어떤 유형인가? A. 데이터의 암호화? B. ‘Y’에 대한 변경요청의 소스로써 ‘X’의 인증? C. 데이터의 변경요청을 발행하기 위한 ‘X’의 인증? 인프라는 어느 정도의 보안요건을 제공해야 하는가? 6) [18, 19, 20] ‘One-shot’ 통신 교환으로 충분한가 아니면 세션 지원이 필요한가? ‘X’와 ‘Y’ 시스템은 상대적으로 통신을 길게 하는가? ‘X’와 ‘Y’ 시스템 사이에서 상태가 유지되는 세션이 확립되어 있는가? 이러한 세션에 대한 상태변수는 무엇인가? A. 보안 ’쿠키’? B. 각 참여자의 버전번호? C. 지원되는/지원되지 않는 선택사양 서비스 위 정보 중 ‘X’와 ‘Y’가 합의해야 하는 정보 중에서 동적으로 발견되는 정보는 얼마나 있는가? 이 정보 중 시스템관리자에 의해 사전 설정되는 정보는 얼마나 되는가? 7) [21, 22] 선택사양 요소들은 어떻게 해석되는가? XML 스키마에서 이러한 교환을 정의하는 선택사양 요소가 있는가? 만약 그렇다면, 한 쪽이 그러한 선택적 요소를 지원하지는 않지만 다른 한 쪽은 이에 의존하는 사례가 없다고 양측은 어떻게 확신할 수 있는가? 8) [23] 다양한 전송이 사용될 수 있는가? ‘X’에서 ‘Y’로의 통신이 논리적으로 일어날 수 있는 전송의 범위는? A. HTTP B. HTTPS C. IIOP (CORBA) 또는 DCOM D. MOM (MQ/Series, MSMQ, JMQ 등) E. SMTP (다중 이진 페리로드 지원에 주의) F. 기타(FTP 등) 9) [24, 25] 다중객체 검색에 대한 지원이 필요한가? ‘X’ 요청은 하나 이상의 객체에 대해 정보를 요청할 수 있는가? 쿼리는 얼마나 융통성이 있는가(즉, 객체 수집에서부터 완전한 SQL 능력에 이르기까지 구체적인 기록 ID의 목록)? 다중객체가 생기는 경우, 응답 메시지 스키마는 통합을 지원하는가? 10) [33] 버전번호는 무엇을 의미하는가? 교환작업에 관여된 메시지들의 버전번호는 무엇을 지칭하는가? A. 양 당사자에 의해 지원되는 특정한 배포 버전? B. 요청되는 데이터 객체의 버전? C. 요청 또는 응답 메시지의 스키마 버전? 11) [34, 35] 메시지 패키징 요건은? 요청 또는 응답은 다중 독립 페이로드로 구성되는가? 이들 페이로드들의 포맷은 XML 외의 다른 것일 수 있는가? 12) [36, 37] 적법성 요청 또는 요청에 대한 응답의 부인봉쇄에 관한 요건이 있는가? 메시지 데이터의 변경불가 보장에 대한 요건이 있는가? 13) [30, 31, 32] 이 데이터베이스 요청에서 트랜잭션과 관련된 고려사항이 있는가? ‘X’의 읽기 요청은 더 큰 규모의 트랜잭션(여러 당사자가 참여하는 트랜잭션도 가능)의 일부로 여겨질 수 있는가? 예를 들어, ‘X’의 읽기요청을 ‘Z’ 시스템에 전달할 수 있는가? 만약 그렇다면, ‘Z’ 시스템은 ‘Y’ 시스템이 수신 응답을 보내기 전에 데이터를 일부 제공해야 할 수도 있다. 만약 그렇다면 문서에서 식별된 트랜잭션의 경계는? 트랜잭션 식별자들이 와이어에 나타나야 할 필요가 있는가?

8.4.3 유스케이스 #3: 데이터 모니터링(Data Monitoring)

다음에 기반한 시스템에 대한 핵심 질문들이다.
  • ‘X’는 이벤트를 게시한다(주로 객체에 대한 업데이트를 지칭한다).
  • ‘Y’와 ‘Z’는 서드파티 메시지 브로커(MOM)를 통해 이벤트를 수신한다.
1) [1, 2] ‘X’로부터 이벤트 메시지를 수신하기 위해 ‘Y’와 ‘Z’는 어떻게 선택되었는가? ‘Y’와 ‘Z’는 ‘X’의 이벤트를 수신하기 위해 동적으로 사전구독을 하는가, 아니면 ‘X’가 ‘소유’한다고 식별된 특정 ‘토픽(일반적으로 특정 유형의 객체에 대한 변경)’에 대한 메시지를 수신하기 위해 사전구독을 하는가? 후자의 경우라면, ‘X’는 토픽에 대한 이벤트를 게시하기 위해 사전등록을 해야 하는가? 2) [6, 7, 8] 어떠한 서비스품질(QoS) 수준이 필요한가? 각 수신자(그리고 네트워크)는 이벤트가 성공적으로 생성되기 위해 반드시 활성화되어야 하는가? 인프라는 메시지 전달 보장을 지원해야 하는가(이는 새로 재활성화된 어플리케이션은 이전에 대기하던 모든 이벤트들을 수신해야 함을 의미한다)? 이벤트는 반드시 게시된 순서대로 전달되어야 하는가? 모든 이벤트들이 성공적으로 전달되면 수신자는 항상 통지를 받아야 하는가? 3) [43, 44, 45, 46, 47] 어떠한 보안수준이 요구되는가? 메시지 브로커와 ‘X’, ‘Y’ 그리고 ‘Z’ 시스템 사이의 통신에 대한 보안 요건이 있는가? 메시지 브로커는 다음 중 무엇을 실시해야 하는가? A. 데이터의 암호화? B. ‘X’를 ‘Y’에 대한 변경요청의 소스로 인증? C. ‘X’를 데이터에 대한 변경요청을 발행하기 위한 목적으로 인증? 이벤트 전달을 위한 보안 수준은 어플리케이션 ‘X’를 게시함으로써 설정될 수 있는가, 아니면 모든 보안 수준은 메시지 브로커의 관리자에 의해 사전 설정되어야 하는가? 4) [21, 22] 선택사양 요소들은 어떻게 해석되는가? XML 스키마 내에는 이벤트를 정의하는 선택사양 요소들이 있는가? 만약 그렇다면, 한 쪽이 그러한 선택적 요소를 지원하지는 않지만 다른 한 쪽은 이에 의존하는 사례가 없다고 양측은 어떻게 확신할 수 있는가? 5) [26, 27] 다중 객체 검색에 대한 지원이 필요한가? ‘X’의 이벤트는 하나 이상의 객체 인스턴스의 변경에 대해 보고할 수 있는가? 만약 그렇다면, 이벤트 메시지 스키마는 통합을 지원하는가? 6) [33] 버전번호는 무엇을 의미하는가? 교환작업에 참여하는 이벤트의 버전번호는 무엇을 지칭하는가? A. 양 당사자에 의해 지원되는 배포본의 특정 버전? B. 보고되는 데이터 객체의 버전? C. 이벤트 메시지 스키마의 버전? 7) [34, 35] 메시지 패키징 요건은? 이벤트 메시지는 다중 독립 페이로드들로 구성될 수 있는가? 이 페이로드들의 포맷은 XML 외의 포맷일 수 있는가? 8) [36, 37] 적법성(Legality) 이벤트의 부인봉쇄를 위한 요건이 있는가? 메시지 데이터의 수정불가 보장을 위한 요건이 있는가? 9) [38, 39, 40] 연산 상세사항 업데이트 이벤트에 언급된 객체에 대한 부분적인 수정은 가능한가? 만약 그렇다면, 변경되는 요소들의 원래 값 또한 업데이트 이벤트에 포함될 필요가 있는가? 그렇지 않다면, 전체 객체 스키마 내의 이들 요소들의 ‘위치’는 어떻게 제시되는가? 10) [30, 31] 이 데이터베이스 업데이트 통지에서 트랜잭션과 관련된 고려사항은? 이벤트는 더 큰 규모의 (당사자가 여럿일 수도 있다) 트랜잭션의 일부로 여겨질 수 있는가? 예를 들어, 원본에 ‘결합(tied)’되어야 하는 다른 이벤트들을 생성할 수 있는가? 만약 그렇다면, 트랜잭션의 경계는 문서에서 어떻게 식별되는가? 트랜잭션 식별자들 중 와이어에 전달되어야 하는 것들이 있는가?

9 베이스 프로파일 확장

9.1 전용 확장(Proprietary Extensions)

베이스 프로파일의 기능 확장 방법에는 세 가지가 있다.
  1. 새로운 SOAP 메시지의 추가 – 새로운 비즈니스 트랜잭션과 새로운 메시징 모델의 사용을 위해서는 새로운 SOAP 메시지의 생성이 필요하다. 새로운 비즈니스 트랜잭션의 추가로 표준 자체가 변화된다. 그러므로 전송 규칙의 적용으로 인해서 새로운 SOAP 메시지가 자동 생성된다. 새로운 메시징 모델에 대한 지원은 새로운 변환 규칙들의 생성과 적용을 필요로 한다.
  2. SOAP 헤더 확장 – 기존 IMS 웹서비스 베이스 프로파일은 어플리케이션간 전송 상태정보를 포함하기 위해 SOAP 헤더를 활용한다. WS-보안 등 다른 표준들 또한 적절한 정보를 담기 위해 SOAP 헤더를 사용한다. SOAP 헤더에 대한 전용 확장은 기존의 활용 패턴을 유지할 것을 권고한다.
  3. SOAP 바디 내에 포함된 데이터의 확장 – SOAP 바디는 표준의 트랜잭션 연산에 정의된 파라미터를 표현하기 위해서 사용되는 XML 인스턴스를 포함한다. 새로운 파라미터를 추가하거나 기존 파라미터의 XML 구조를 확장할 필요가 생길 수도 있다. XML 데이터 구조의 확장을 위해서는 IMS 확장 매커니즘을 사용해야 한다. 그렇지 않을 경우, SOAP 메시지 수신 프로세서는 메시지를 마샬링할 수 없다. 즉, 수신자는 수신된 메시지의 구조를 반드시 미리 알아야 한다. 새로운 파라미터는 새로운 XSD를 필요로 할 수 있으며, 최소한 메시지 구조 XSD에 대한 변경을 필요로 할 것이다.

9.2 2.0 버전의 추가작업

IMS 웹서비스 베이스 프로파일의 발전을 위한 추가 작업 분야는 다음과 같다.
  1. 적합성 명세의 포함 – WS-I는 적합성 명세가 어떻게 WSDL 디스크립션에 임베드될 수 있는지 설명한다. 이 명세들은 SOAP 메시지들이 프로파일에 적합한지 결정하기 위해 사용될 수 있다. WS- 정책은 W3C에 의해 현재 개발 중인 대체 매커니즘이다.
  2. SOAP 1.2의 채택 – 기존 프로파일은 SOAP 1.1을 기반으로 하지만 SOAP 1.2가 현재 사용 가능하게 되었다. 하지만 SOAP 1.2의 사용을 지원할 수 있는 신뢰할만한 툴들이 개발되기 전에는 IMS 웹서비스 베이스 프로파일의 변경을 고려하지 않을 것이다.
  3. WSDL 2.0의 채택 – W3C는 WSDL 2.0을 개발 중이다(초기에는 1.2버전으로 지칭되었다). 중개자 표현을 변경한다고 해서 생성될 실제 SOAP 메시지들이 변하지는 않지만, 더 향상된 표현들은 WSDL 파일에서 더 복잡한 바인딩이 설명될 수 있도록 할 것이다. WSDL 2.0의 지원할 수 있는 신뢰할만한 툴들이 개발되기 전까지는 IMS 웹서비스 베이스 프로파일의 변경을 고려하지 않을 것이다.
  4. UDDI 2.0의 채택 – UDDI 2.0은 현재 광범위하게 채택되고 있지 않다. UDDI 사용에 대한 충분한 사례들이 생기기 전까지는 IMS 웹서비스 베이스 프로파일에 UDDI의 사용을 추가하는 것을 고려하지 않을 것이다.
  5. 신뢰가능한 메시징 – 신뢰 가능한 어플리케이션간 통신을 위해서는 신뢰 가능한 관련 SOAP 메시징 프로토콜의 사용이 필요하다. TCP는 SOAP 메시지를 다루기 위해서 필요한 통신 스택에 맞는 레벨로 작동하지 않는다.
  6. 메시지 구성 – 더 복잡한 메시징 모델, 즉 ‘동기식’, ‘폴링 방식’ 그리고 ‘게시 및 구독’ 모델들은 지원되어야 한다(동기식 및 폴링 모델들에 대한 IMS 전용 구현은 이 문서의 공개초안 버전에서 활용가능하다). WSDL 2.0의 사용으로 이 문제가 해결될 수 있다.
  7. 서비스 구성 – 적절한 서비스 구성을 이용해서 어플리케이션과 공통서비스간의 상호작용이 설명될 필요가 있다. 이를 통해 서비스들이 어떻게 상호작용을 하는지에 대해서 구체화할 수 있다. 이 구성을 위해 BPEL4WS의 사용에 대해 자세히 살펴볼 것이다.

10 베이스 프로파일에 대한 적합성

10.1 국제 적합성 프로그램(International Conformance Programme)

IMS 국제 적합성 프로그램은 어플리케이션 프로파일 가이드라인을 개발하였다. 이 가이드라인들은 적절한 어플리케이션 프로파일을 이용해 어떻게 특정 표준을 특정 사용 도메인에 맞출 수 있는지를 설명한다. 관련 도메인 프로파일을 생성하기 위해 어플리케이션 프로파일들의 집합이 생산된다(많은 경우 사용 도메인은 여러 관련 어플리케이션 프로파일들의 생산을 필요로 한다).

10.2 베이스 프로파일 적합성

적합성 표준과 관련해, 테스트 표준은 두 가지 관점에서 생산되어야 한다.
  • ‘서비스 요청자’ – 서비스의 드라이버(driver)와 소비자
  • ‘서비스 공급자’ – 서비스의 공급자

10.2.1 서비스 요청자의 관점

표준의 UML 인터페이스 다이어그램에서 정의된 행동에 관해서는, 관련 SOAP/HTTP 메시지를 생성하기 위해 다음 테스트들이 정의되어야 한다.
  1. 지원되지 않은 서비스 보고 – 서비스 요청은 서비스 제공자에 의해 지원되지 않기 때문에 거부된다(이는 서비스 확장을 필요로 하는 요청들에 대해서도 해당된다).
  2. 필수 요소만을 가진 성공적인 서비스 공급 – 서비스는 제공된 데이터가 필수 데이터 요소만을 포함할 경우에 정확히 지원된다.
  3. 필수 및 선택사항 요소들을 갖춘 서비스의 성공적 제공 – 제공된 데이터가 필수 데이터(선택사항 데이터, 단일한 선택사항 데이터, 그리고 여러 개의 선택사항 데이터의 결합을 모두 포함한다) 모두와 선택사항 데이터의 결합을 포함하는 경우 정확하게 지원된다.
  4. 필수 및 선택사항 요소들을 갖춘 서비스의 성공적 제공 – 제공된 데이터가 필수 데이터(선택사항 데이터, 단일한 선택사항 데이터, 그리고 여러 개의 선택사항 데이터의 결합을 모두 포함한다) 모두와 선택사항 데이터의 결합을 포함하는 경우 정확하게 지원된다.
  5. 오류 상태 코드의 정확한 생성 – 유효하지 않은 데이터가 공급되거나, 시스템이 요청과 일치하지 않는 상태에 있거나, 시스템(서비스 내에서 완전한 데이터베이스 구성 등) 내에서 일부 구성요소가 실패한 경우 요청자는 반드시 적절한 오류코드를 처리해야 한다.
  6. 데이터 과부하 처리 – 요청자가 지원할 수 있는 것보다 더 많은 데이터를 받은 경우, 예를 들어 요청자는 필수 요소만 지원하지만 선택사양 요소들 또한 받은 경우에 이를 어떻게 처리하는지에 대한 관찰이다.
  7. 확장 지원 – 요청자가 다른 상태코드들에 대해서 정확하게 대응하는 것을 보장하기 위한 목적이며, 이 코드들은 확장의 목적에 따라 회신된다.

10.2.2 서비스 제공자의 관점

표준의 UML 인터페이스 다이어그램에서 정의된 행동에 대해, 관련 SOAP/HTTP 메시지를 생성하기 위해 다음 테스트들이 정의되어야 한다.
  1. 지원되지 않은 서비스 보고 – 서비스 요청은 서비스 제공자에 의해 지원되지 않기 때문에 거부된다(이는 서비스 확장을 필요로 하는 요청들에 대해서도 해당된다).
  2. 필수 요소만을 가진 성공적인 서비스 공급 – 서비스는 제공된 데이터가 필수 데이터 요소만을 포함할 경우에 정확히 지원된다.
  3. 필수 및 선택사항 요소를 갖춘 서비스의 성공적 제공 – 공급된 데이터가 선택사항 데이터와 모든 필수 데이터(이는 모든 선택사항 데이터, 단일한 선택사항 데이터, 그리고 다중 선택사항 데이터의 조합을 포함한다)의 조합을 포함하는 경우 서비스는 정확하게 지원된다.
  4. 성공적 시퀀스 서비스 공급 – 서비스는 같은 행동이 여러 번 호출되는 경우 정확히 지원된다. 이는 동일한 다중 행동들이 적절한 증분 기록(incremental record)의 변경을 하도록 하기 위함이다.
  5. 오류상태 코드의 정확한 생성 – 유효하지 않은 데이터가 공급된 경우, 시스템이 요청과 일치하지 않는 상태에 있는 경우, 그리고 서비스 내 완전한 데이터베이스 등 시스템의 특정 구성요소에 장애가 있는 경우 서비스는 적절한 오류 코드를 정확히 보고해야 한다.
  6. 확장에 대한 지원.
  7. 서비스 공급자가 알려지지 않은 서비스 확장들을 정확하게 거부한다는 확인.
  8. 데이터 확장이 지원되지 않지만 서비스 연산은 완성됨을 서비스가 보고할 수 있다는 확인.
  9. 완전한 확장 시설(장비) 지원에 대한 확인.

10.3 베이스 프로파일의 확장 프로파일에 대한 적합성

베이스 프로파일을 확장한 프로파일에 대한 적합성은 관련 프로파일 설명 문서에 정의되어 있다.

부속서 A (참고)

용어집

일반 웹서비스 문서에서는 다양한 용어, 개념과 설명을 소개하고 있다. 이들 용어, 개념 그리고 설명들은 다음과 같이 정의되지만, 경우에 따라서는 IAF 용어집의 표준 정의를 참조한다.
추상프레임워크 추상프레임워크용어참조
어플리케이션서비스 추상프레임워크용어참조
비동기식통신메시징모델 각 단계가 개별적으로 확인되는 요청/응답 메시지 교환. 서비스 요청자는 요청 메시지를 게시하고 서비스 공급자의 승인을 기다린다. 서비스 요청자는 승인을 받는 즉시 통신 차단이 해제된다. 이후 서비스 공급자는 응답 메시지를 게시한다. 응답 메시지가 서비스 요청자에 의해 수신되면, 서비스 공급자에게 확인 승인이 보내진다.
인증 추상프레임워크용어참조
권한부여 추상프레임워크용어참조
웹서비스를위한비즈니스프로세스실행언어 BPEL4WS BPEL4WS - BPEL4WS(약어로 BPEL)는 웹서비스에 기반해 비즈니스 프로세스 행동을 상술하기 위한 표기법을 정의한다. 이 표기법은 웹서비스에 대한 비즈니스 프로세스 실행 언어라고 지칭된다. BPEL4WS는 웹서비스 인터페이스를 독점적으로 사용함으로써 기능들을 입력하고 출력한다. 비즈니스 프로세스는 두 가지 방법으로 설명될 수 있다. 실행가능한 비즈니스 프로세스 모델은 비즈니스 거래에서의 참여자의 실제 행동이다. 이에 반해 비즈니스 프로토콜은 프로토콜에 연관된 각 당사자들의 내부 행동을 공개하지 않으면서, 이들의 상호 가시적인 메시지 교환 행동을 설명하는 프로세스 설명을 사용한다. 비즈니스 프로토콜에 대한 이러한 프로세스 설명은 추상 프로세스로 지칭된다. BPEL4WS는 실행가능한 프로세스와 추상 프로세스 양쪽 모두의 행동에 대한 모델을 구성하도록 의도되었다. BPEL4WS는 비즈니스 프로세스와 비즈니스 트랜잭션 프로토콜의 정식 표준에 대해 언어를 제공한다. 이를 통해 BPEL4WS는 웹서비스 트랜잭션 모델을 확장하며 비즈니스 트랜잭션을 지원할 수 있도록 한다. BPEL4WS는 기업내, 그리고 기업간 자동화된 프로세스 통합의 확장을 더 용이하게 하는 상호운용가능한 통합 모델을 정의한다.
공통서비스 추상프레임워크용어참조
IMS 바인딩자동생성툴킷 (I-BAT) I-BAT는 UML (WSDSL과 XSD 바인딩 모두 지원됨)을 사용해 개발된 표준들에 대한 바인딩의 생성을 지원하기 위해서 사용되는 툴들의 집합이다. I-BAT는 IMS UML 프로파일의 사용을 지원하며, XSL을 사용해 UML 설명의 XMI를 관련 WSDL/XSD 바인딩으로 변환한다.
IMS 웹서비스베이스프로파일 IMS 웹서비스 베이스 프로파일은 웹서비스를 정의하기 위한 기본 구조를 제공한다. 일반 웹서비스 베이스 프로파일은 비독점 웹서비스 표준들과, 상호운용성을 증진하는 명시사항 및 보완사항으로 구성되었다. IMS 웹서비스 베이스 프로파일은 웹서비스 표준을 구현할 때 가장 흔히 경험하는 문제들을 다룬다. IMS 웹서비스 베이스 프로파일은 정확하게 이해되고, 광범위하게 구현되며 유용한 참조 표준들 내의 매커니즘들을 정의한다. IMS 웹서비스 베이스 프로파일은 다양한 소프트웨어와 협력업체 플랫폼에서 구현되는 웹 표준들에서 상호호환성을 증진한다. IMS 웹서비스 베이스 프로파일은 핵심 웹서비스 표준의 집합과 인지된 웹서비스 표준을 구현하는 데에서 흔히 경험하는 문제들에 초점을 맞춘다. IMS 웹서비스 베이스 프로파일은 WS-I 베이직 프로파일 1.1버전과 WS-I 심플 SOAP 바인딩 프로파일 1.0버전을 기반으로 한다.
IMS 웹서비스어드레싱프로파일 IMS 웹서비스 베이스 프로파일에 대한 확장 프로파일로써, 서비스가 어떻게 전송 매커니즘과는 독립적인 어드레싱 시스템으로 정의될 수 있는지를 정의한다. 이 프로파일은 W3C의 WS-어드레싱 작업을 기반으로 한다.
IMS 웹서비스첨부프로파일 IMS 웹서비스 베이스 프로파일에 대한 확장 프로파일로, 비XML 기반 데이터가 어떻게 비디오 파일, 이미지 파일 등 SOAP 메시지로 전달될 수 있는지를 정의한다. 이 프로파일은 W3C의 MTOM 작업을 기반으로 한다.
IMS 웹서비스보안프로파일 IMS 웹서비스 베이스 프로파일에 대한 확장 프로파일이며, 보안 정보가 SOAP 메시지 내에서 어떻게 전달되어야 하는지를 정의한다. 보안 아키텍처를 정의하지는 않으며, 대신 SOAP 메시지 내의 정보가 구현물에 의해 사용되는 보안 아키텍처를 지원하기 위해 어떻게 확장되는지를 정의한다. 그러므로 보안 프로파일은 여러가지 보안 아키텍처를 지원할 수 있다. 이 프로파일은 W3C의 WS-보안 작업을 기반으로 한다.
메시지전송최적화매커니즘 MTOM은 SOAP 메시지가 비XML 객체를 포함할 수 있도록 하는 W3C 메시지 첨부 접근법 중 하나이다. MTOM은 첨부를 가진 SOAP를 발전시킨 것이며 이 프로파일에서는 MTOM을 원래 SOAPwA 표준을 대체하기 위한 것으로 제시된다.
폴드통신메시징모델(Polled Communications Messaging Model) 요청/응답 메시지 교환으로, 응답 메시지는 서비스 요청자가 폴드 메시지를 보내는 경우에만 돌려보내진다. 서비스 요청자는 요청 메시지를 보내고 나서 서비스 공급자로부터의 확인을 기다린다. 서비스 요청자는 서비스 공급자의 확인을 받은 후에야 차단이 해제된다. 이후 서비스 요청자는 폴드 메시지를 발행한다. 서비스 공급자는 응답 메시지에 응답할 수도, 하지 않을 수도 있다. 서비스 요청자는 무제한으로 폴드 메시지를 보낼 수 있다.
실증적상태전이 차세대 웹서비스는 현재 웹의 기본 아키텍처 모델인 REST (Representational State Transfer)로 지칭되는 아키텍처 스타일을 준수할 것으로 예상된다. REST는 우수하게 설계된 웹 어플리케이션이 어떻게 행동하는지에 대한 다음과 같은 이미지를 호출하는 것을 목적으로 한다. 사용자가 링크를 선택함으로써 어플리케이션에서 진행을 하는 웹페이지의 네트워크(실질적 상태기계)에서는 다음 페이지(어플리케이션의 다음 상태 표현)가 사용자에게로 전송되고 활용을 위해 변환된다.
SOAP SOAP는 XML 문서를 위한 메시징 프로토콜로, 분산 환경에서 동기간 구조화되고 유형화된 정보를 교환하는 데 사용될 수 있다. SOAP는 상태정보를 지니지 않은 일방적 메시지 교환 매커니즘이지만, 플리케이션은 이러한 일방향적인 교환을 기본 전송 프로토콜 그리고/또는 특정 어플리케이션 정보에 의해 제공되는 기능들과 조합함으로써 더 복잡한 거래 패턴(요청/응답, 요청/ 다중응답 등)을 생성할 수 있다.
첨부를가진 SOAP 첨부를 가진 SOAP(SWA)는 여러 메시지 페이로드(payloads)를 지원하기 위해 MIME바인딩을 제공하는 동시에 RPC가 XML에서 마샬링되고 언마샬링되는 규칙은 무시하면서 SOAP 1.1버전을 확장한다. SOAPwA는 단일 비즈니스(또는 대학) 내의 동기식 RPC인 경우보다, 두 통신 당사자가 같은 조직 내에 위치하지 않으며, 교환 패러다임이 인터넷에서 하나 이상의 비동기식 문서교환인 경우에 적합하다.
동기식통신메시징모델 서비스 요청자와 서비스 제공자 사이의 단순 요청/응답 메시지 교환이다. 서비스 요청자는 요청 메시지를 게시하고 서비스 제공자로부터 응답 메시지를 기다린다. 서비스 요청자는 응답 메시지를 수신하기 전까지 차단된다.
웹서비스아키텍처 웹서비스 아키텍처(WSA)는 웹서비스를 이해하기 위한 의미와 모델을 제공하고, 더 큰 웹서비스 프레임워크 내에서, 그리고 WSA 외의 다른 기술들에 포함될 수 있도록 하는 것을 목적으로 하는 표준문서이다. WSA의 목적은 웹서비스와 그 핵심 개념 그리고 관계의 정의를 통해 상호운용성을 증진하는 것을 목적으로 한다. WSA의 목적은 웹서비스가 어떻게 구현되는지를 설명하거나 웹서비스의 조합이나 구성에 제한을 두는 것이 아니다. WSA는 WSA의 핵심 개념과 관계를 다양한 관점에서 논의한다.
WS-CDL (Web Services Choreography Description Language) WS-CDL은 전역적인 관점에서 웹서비스 참여자들의 공통적이고 보완적인 관찰가능한 행동을 정의함으로써 웹서비스 참여자들간의 공통작업을 기술하는 XML 기반 언어이며, 순차적 메시지 교환은 공통의 비즈니스 목표를 달성하게 된다. 웹서비스 표준은 어플리케이션을 개발하고 호스팅하기 위한 이종의 컴퓨테이션 환경간의 통신을 가능하게 한다. e비즈니스 어플리케이션의 미래는 앞으로 조직의 신뢰 도메인 내, 또는 신뢰 도메인들간에 참여하는 서비스들의 장기간의 공통작업을 수행할 수 있는 능력을 필요로 하게 될 것이다. 웹서비스 구성 표준을 사용하는 목적은 호스팅 환경의 구현에 의해 사용되는 지원 플랫폼이나 프로그램 모델과 관계없이, 모든 웹서비스 참여자들의 유형 사이의 상호운용 가능한 동기간(peer-to-peer) 협력을 구성하는데 있다.
웹서비스기술언어 WSDL 문서는 서비스를 네트워크 종단, 또는 포트의 집합으로 정의한다. WSDL에서 종단과 메시지의 추상적인 정의는 구체적인 네트워크 구축 또는 데이터 포맷 바인딩에서 분리된다. 이는 추상 정의, 즉 교환되는 데이터의 추상적인 설명인 메시지와 연산의 추상적인 집합인 포트 유형의 재사용을 가능하게 한다. 특정 포트 유형에 대한 구체적 프로토콜과 데이터 포맷 표준은 재사용가능한 바인딩을 구성한다. 포트는 네트워크 주소를 재사용가능한 바인딩과 연계함으로써 정의되며 포트의 집합은 서비스를 정의한다.
WS-어드레싱 WS-어드레싱은 웹서비스와 메시지를 다루기 위한 전송중립적인 매커니즘을 제공한다. 특히, 이 표준은 웹서비스 종단을 식별하고 종단간 종단 식별 메시지를 확보하기 위해 XML 요소를 정의한다. 이 표준은 메시징 시스템이 종단 관리자, 방화벽, 그리고 게이트웨이 등의 처리 노드를 포함하는 네트워크를 통해 메시지 전송을 전송중립적인 방법으로 지원할 수 있도록 한다.
WS-첨부 WS-첨부는 SOAP 첨부의 추상적 모델을 정의하며, 이 모델을 기반으로 SOAP 메시지와 0 또는 하나 이상의 첨부를 캡슐화하는 매커니즘을 정의한다. SOAP 첨부들은 1차 SOAP 메시지와 첨부로 알려진 0 또는 하나 이상의 관련 모델들로 구성된 복합 문서구조의 개념을 이용해 설명된다.
WS-I 베이직프로파일 웹서비스 상호운용성 조직에서 생성된 WS-I 베이스 프로파일은 비독점 웹서비스 표준들과, 이 표준들에 대한 상호운용성을 증진하는 명시사항과 보완사항들로 이루어진다. 이 프로파일은 XML 스키마 1.0버전, HTTP 1.1버전, WSDL 1.1버전, 그리고 UDDI 2.0버전의 사용을 권고한다.
WS-정책 웹서비스 정책 프레임워크(WS-정책)는 웹서비스의 능력, 요건, 그리고 일반적인 특징들을 표현하는 데 사용되는 특정 웹서비스 메타데이터(정책이라고 불림)의 설명을 허용한다. WS-정책 표준은 언어를 나타내고 일반 메시지 사전조건을 설명하는 등 단순한 일반적 목적들에 대한 정책들을 정의한다. 또한 WS-정책을 보완하는 WS-보안 정책 표준은 보안요건에 대한 정책을 정의한다.
WS-신뢰성 WS-신뢰성의 목적은 비즈니스간 어플리케이션에서 웹서비스를 사용할 때 중요하게 다뤄지는 신뢰가능한 메시징 요건을 다루기 위함이다. SOAP/HTTP는 어플리케이션 수준에서 메시징 프로토콜의 신뢰성과 보안을 다루어야 할 경우 충분하지 않다. 보안은 웹서비스 표준의 개발에서 진척을 보이고 있지만, 신뢰성은 그렇지 않다. 이 표준은 현재의 웹서비스 표준에서 신뢰성을 정의하기 위한 제안을 한다. 이 표준은 SOAP, 그리고 ebXML 메시지 서비스 등의 전송 프로토콜과 메시징에서의 이전 작업들을 차용한다. 또한 이 표준은 이 작업들을 웹서비스에 제공하기 위한 적절한 보완사항들을 제안한다.
WS-보안 WS-보안은 신뢰성, 무결성, 부인봉쇄, 인증 및 권한 부여(authorization)에 대한 기존 보안기준을 사용해 보안정보를 SOAP 메시지로 통합하기 위한 표준방법을 정의한다. WS-보안은 SOAP 메시지의 보안정보를 표현하는 방법을 제공한다. WS-보안은 단순 사용자명, SAML, X.509 인증서와 Kerberos ticket 등의 보안토큰을 전달하는 방법, XML 서명을 이용해 SOAP 메시지를 전부 또는 일부 전자적으로 서명하는 매커니즘, XML 암호화를 이용해 SOAP 메시지를 부분적으로 암호화하는 매커니즘, 그리고 서명과 암호 헤더를 SOAP 메시지에 첨부하는 방법을 정의한다.
WS-보안미니멀리스트프로파일 WS-보안 미니멀리스트 프로파일은 웹서비스 보안의 하위집합을 설명한다. 자원 제한 플랫폼에 의해 수신된 메시지들이 효과적으로 처리될 수 있도록 핵심 표준에 제약을 가하는 SOAP 메시지 보안(WS-보안) 표준이다. WS-보안 표준은 SOAP 메시지를 확보하고, 메시지 통합성과 기밀성을 제공하고, SOAP 메시지를 통해 보안정보를 교환하는 융통성 있는 방법을 설명한다. WS-보안은 다양한 보안모델을 지원하기 위해 사용될 수 있다. WS-보안은 여러 보안토큰 포맷, 다중 신뢰 도메인, 다중 서명 포맷, 다중 암호화 기술과 종단간 메시지 콘텐츠 보안을 지원한다. WS-보안과 WS-보안 미니멀리스트 프로파일은 어플리케이션이 안전한 방법으로 SOAP 메시지를 교환하기 위한 프레임워크와 구문법을 제공한다. WS-보안 또는 WS-보안 미니멀리스트 프로파일을 사용하는 것은 구성된 시스템이 공격에 대비할 필요가 있음을 보여준다. IMS는 WS-보안 미니멀리스트 프로파일 권고사항들을 IMS 웹서비스 베이스 프로파일의 더 안전한 버전에서 사용할 것이다.
WS-I 심플 SOAP 바인딩프로파일 1.0버전 WS-I는 WS-I 베이직 프로파일 문서에서 메시징 특정 기술정보를 분리했다. WS-I 베이직 SOAP 바인딩 프로파일은 베이직 프로파일을 통해 SOAP 메시징의 사용을 설명한다.
XML 스키마 XML 스키마 정의(XSD)는 IMS의 초기 XML 바인딩 제어 문서 포맷이다(현재 이들 바인딩은 XML 스키마의 2001년 5월 버전을 작업하고 있다). XSD는 요소, 콘텐츠 모델 그리고 속성들을 정의한다. 또한 표준 IMS어휘를 정의한다. XSD는 요소 유형과 속성그룹을 요소와는 별도로 정의한다.

부속서 B (참고)

메시징 설문지 양식

메시징 설문지는 표 B1에 제시되어 있다. 이 설문지는 가능한한 각 사례별로 작성되어야 한다. 설문에 대한 응답들은 필요한 기능들을 지원하기 위해서 가용한 바인딩의 집합을 결정하기 위해 분석된다.

표 B1 메시징 설문지 양식
인프라 설문 - 모든 트랜잭션에 적용
설정된 트랜잭션의 유형(한 줄만 체크할 것; A | B중 하나만 선택할 것; A | B, C | D의 경우 하나씩 선택할 것)
No. 데이터 업데이트 요청/ ACK (또는 NAK) 요청 읽기/ 응답 데이터 모니터링
1 이벤트 수신자들의 사전구독 대상 해당없음 해당없음 소스의 이벤트| 소스의 토픽/객체
2 토픽/객체의 경우, 소스는 이벤트를 토픽에 미리 등록해야 하는가? 해당없음 해당없음 예 | 아니오
3 타겟 시스템은 요청을 거부할 수 있는가? 예 | 아니오 해당없음 해당없음
4 동기식 또는 비동기식 동기식 | 비동기식 동기식 | 비동기식 해당없음
5 QOS - 복제 타겟은 인지함 | 인프라는 방지함 타겟은 인지함 | 인프라는 방지함 해당없음
6 QOS – 연결 타겟은 반드시 실행중이어야 함 | 인프라 보장 타겟은 반드시 실행중이어야 함 | 인프라 보장 수신자는 반드시 실행중이어야 함 | 인프라 보장
7 QOS - 메시지 전달 순서는 메시지 게시 순서와 같아야 하는가? 해당없음 해당없음 예 | 아니오
8 QOS - 모든 메시지가 전달될 때 수신자에게 통지해야 하는가? 해당없음 해당없음 예 | 아니오
9 타겟 식별 ‘프리와이어’됨 | 발견됨 ‘프리와이어’됨 | 발견됨 해당없음
10 타겟이 여러 개일 경우, 어떻게 선택되는가? ? ? 해당없음
11 기록 ID의 범위 타겟과 파트너| 인터넷 타겟과 파트너| 인터넷 해당없음
12 소스는 타겟과 일치해야 하는가? 예 | 아니오 예 | 아니오 해당없음
13 서드파티 이벤트 로거 예 | 아니오 예 | 아니오 해당없음
14 암호화 필요 예 | 아니오, 방향 X>Y | X<Y | X<>Y, 유형 예 | 아니오, 방향 X>Y | X<Y | X<>Y, 유형 해당없음
15 Y에 자원 인증됨 예 | 아니오 예 | 아니오 해당없음
16 Y에 자원 허가됨 예 | 아니오 예 | 아니오 해당없음
17 인프라에 의해 보안 제공 없음 | 암호화, 인증, 권한 부여 없음 | 암호화, 인증, 권한 부여 해당없음
18 상태유지 세션 예 | 아니오 예 | 아니오 해당없음
19 상태유지가 된다면, 어떤 것을 기반으로 하는가? 쿠키 | 기타?? 쿠키 | 기타?? 해당없음
20 상태유지인 경우, 상태id의 기반은? 동적으로 발견됨| 설정됨 동적으로 발견됨| 설정됨 해당없음
21 스키마의 선택가능한 요소 예 | 아니오 예 | 아니오 예 | 아니오
22 선택 가능한 요소 해석 전략 ? ? ?
23 전송요건 HTTP, HTTPS, IIOP (Corba), IIOP DCOM, MOM - MQ/Series, MOM-MSMQ, MOM-JMQ, SMTP, 기타? HTTP, HTTPS, IIOP (Corba), IIOP DCOM, MOM - MQ/Series, MOM-MSMQ, MOM-JMQ, SMTP, 기타? 해당없음
24 다중 객체 회수 가능 해당없음 예 | 아니오 해당없음
25 쿼리는 얼마나 유연한가? 해당없음 List | Full SQL 해당없음
26 소스는 여러 객체를 보고할 수 있는가? 해당없음 해당없음 예 | 아니오
27 만약 그렇다면, 메시지 스키마는 집합들을 지원하는가? 해당없음 해당없음 엔터프라이즈 스키마는 지원함
28 소스는 배치를 타겟에 보낼 수 있는가 예 | 아니오 해당없음 해당없음
29 만약 그렇다면, 스키마는 통합을 지원하는가? 엔터프라이즈 규격은 지원함 해당없음 해당없음
30 트랜잭션/이벤트가 더 큰 트랜잭션의 일부일 수 있는가? 예 | 아니오 예 | 아니오 예 | 아니오
31 만약 그렇다면, 트랜잭션의 경계는 어떻게 식별되는가? ? ? ?
32 더 큰 규모의 트랜잭션의 일부인 경우, 서드시스템 또는 그 이상이 개입하는가? 예 | 아니오 예 | 아니오 해당없음
33 버전번호 콘텍스트 어플리케이션 | 객체 | 스키마 어플리케이션 | 객체 | 스키마 어플리케이션 | 객체 | 스키마
34 다중 페이로드 예 | 아니오 예 | 아니오 예 | 아니오

해 설

이 해설은 본체 및 부속서에 규정ㆍ기재한 사항 및 이것에 관련된 사항을 설명하는 것으로 표준의 일부는 아니다. 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. 표준 규격서의 목차는 적용 범위 인용표준, 용어 정의 순으로 목차를 정렬 하며, 단, 원문에 서론이 있는 경우 서론은 유지한다. (2009년 6월)
  3. NETg, Boein Coporation와 같은 고유한 회사명은 A, B 형태의 가칭으로 대체 표기한다. (2009년 6월)
  4. 그림, 표, 본문 등에 포함된 영어를 최대한 번역하여 국문으로 표기한다. (2009년 10월)
  5. MS GLC의 표준 인용 정책에 의하여 페이지의 'IPR 공지’ 및 'IMS 로고’ 적용은 현행을 유지하며, 규격의 매 페이지마다 포함된 copyright 표기 문구는 삭제한다. (2009년 10월)
  6. 규격에 해설서(제정의 취지 등) 내용을 추가 작성한다. (2009년 10월)
4. 적용 범위 IMS 웹서비스 베이스 프로파일은 웹서비스를 정의하기 위한 기본 구조를 제공한다. 베이스 프로파일(Base Profile)은 상호운용성을 증진하는 명시 및 보완사항들과 함께 비독점 웹서비스 표준들로 구성되어 있다. IMS 웹서비스 베이스 프로파일은 웹서비스 표준을 구현하는 과정에서 흔히 경험하는 문제들을 다룬다. IMS 웹서비스 베이스 프로파일은 널리 알려지고, 폭넓게 구현되거나 유용한 참조 표준들 내에 존재하는 매커니즘들의 선택방법을 정의한다. IMS 웹서비스 베이스 프로파일들은 IMS 표준 개발 방법론과 추상 프레임워크와 일치하는 문법규약들을 포함한다. IMS 웹서비스 베이스 프로파일은 각각 다른 소프트웨어와 벤더들의 플랫폼 상에서 웹서비스 기반 표준 구현에서의 상호운용성을 증진한다. 베이스 프로파일은 핵심 웹서비스 표준 집합과 알려진 웹서비스 표준들의 구현에서 흔히 경험하는 문제들에 초점을 맞춘다. IMS 웹서비스 베이스 프로파일은 웹서비스를 지원하는 플러그 앤 플레이 아키텍처를 만들거나 완전한 상호운용성을 보장하는 것을 목표로 하지는 않는다. IMS 웹서비스 베이스 프로파일은 어플리케이션 계층에서의 상호운용성, 특히 웹서비스를 통해 노출되는 동작들에 대한 설명을 다룬다. IMS 웹서비스 베이스 프로파일은 낮은 계층 프로토콜의 상호운용성은 충분하다고 가정한다. 이 문서는 IMS 웹서비스 베이스 프로파일에 대한 확장 방법을 포함한 권고사항들과 활용사례들을 포함하고 있다. 이러한 확장은 오류 처리, 보안, 매니페스트, 콘텍스트와 라우팅 등 추상 프레임워크의 일반 서비스 계층에 대한 웹서비스 바인딩 생성의 가이드를 제시한다. IMS GLC는 W3C에서 개발한 웹서비스 표준과 규격을 더 구체화하기 위해 베이스 프로파일을 기반으로 하여 보완적인 프로파일들을 정의한다. 그러므로, 이 문서는 IMS 웹서비스 확장 프로파일들과 IMS 웹서비스 WSDL 바인딩 가이드라인과 함께 읽어야 한다. 앞서 언급한 두 가지 문서들을 작성할 때 참조한 용어는 프로젝트 헌장 원본에 정의되어 있다. 5. 표준개발 참여자 이 규격의 초안은 IMS Korea 표준화 포럼 활동으로 작성되었으며, 규격 개발에 참여한 전문가는 다음과 같다.

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

성 명

근 무 처

직 위

조용상

 한국교육학술정보원

팀장

김종현

 계원디자인예술대학

교수

김현진

 한국교원대학교

교수

정광식

 한국방송통신대학교

교수

황대준

 성균관대학교

교수

고영승

 (주)디유넷

대리

이정우

 (주)포씨소프트

차장

장근원

 (주)크레듀

과장

정호원

 (주)씨티유니온

차장

지승환

 테크빌닷컴(주)

차장

최성기

 SK C&C

과장

권영진

 한국교육학술정보원

연구원

최미애

 한국교육학술정보원

연구원