Enabling Web Services
Phillip J. Windley, Ph.D.

11. Enabling Web Services.pdf

- Web Services is used to describe the ability to easily link programs and data from various sources in a way that creates a new look at the data or even a new application.
- we should do so in a way that gives that data a unique name and preserves the structure of the data in a way that’s easy to use.
- Enabling web services requires that we make data available for use by applications without knowing a priori exactly how that data will be used.

1. Every data record and collection is a resource.
2. Every resource should have a URI.
3. Cool URI’s don’t change.
4. Data queries on existing resources should be done with a GET.
5. Use POST to create new resources.
6. Preserve the structure of data until the last possible moment (i.e. return
XML).
7. Make XML Schemas available online for your XML.
8. Make data available in multiple flavors.
9. Use Metadata (RDF) for XML.
10. Document your service API using WSDL, WRDL, or some other standard.
11. Advertise the presence of the data using WSIL.
12. Adhere to data standards such as RSS where available.
13. Use HTTP authentication as much as possible.

Introduction to Web Services Architecture

10. Introduction to Web Services Architecture.pdf

1. Abstract

2. Web services overview

- A Web service is an interface that describes a collection of operations that are network-accessible through standardized XML messaging.

3. Applying Web services standards to a business scenario

WSDL(Web Services Description Languages)
KNUG(Korea .NET User Group) 자료

5. WSDL(knug).pdf

제3절 WSDL(Web Services Description Languages)
- WSDL은 메시지의 형태를 기술하기 위한 표준

3.1.1 WSDL의 필요성
- WSDL은 웹 서비스를 정의하고 접근하는 방법을 기술하는 XML 기반 언어
 * SOAP 메시지는 WSDL이 없다면, 그 메시지가 정확하게 기술되었는지 파악할 수 없음
 * SOAP 메시지는 다양한 메시지 교환 패턴(message exchange pattern)을 지원하기 때문에, 반드시 어떠한 메시지 패턴을 따르는지 기술
 * SOAP 메시지를 기술하는 XSD는 웹 서비스를 접근하는 방법에 관하여 아무런 언급이 없음
- WSDL은 웹 서비스를 정의하고 호출하는 것과 관련된 모든 정보들을 사전에 미리 XML로 정의
 * 외부로 공개된 모든 기능들의 기술하는 인터페이스 정보
 * 메시지의 응답과 요청에 관련된 데이터 타입의 정보
 * 전송 프로토콜에 관한 SOAP 메지시의 바인딩 정보
 * 서비스의 위치에 관한 정보

3.2.2 WSDL의 전체적인 구조

(1) WSDL의 전체적인 모습
- WSDL은 웹 서비스를 기술하는 XML Schema 문서들의 계층적인 관계로 구성
- WSDL 문서는 서비스 인터페이스(service interface) 부분과 서비스 구현(service implementation) 부분으로 구분되어 UDDI에 저장
 * 서비스 인터페이스 부분 : 웹 서비스에 대한 추상적인 정의와 서비스에서 사용되는 타입에 관한 상세 정보를 포함
  → import, types, message, portType, binding 요소들이 포함
 * 서비스 구현 부분 : import, types, message, portType, binding 요소들이 포함
  → 서비스 인터페이스를 구현한 service에 대한 설명(description)을 포함

2.3.3 WSDL의 구성요소들에 대한 세부설명

(1) 데이터 정보 인코딩
- WSDL은 해당 네트워크 서비스의 인코딩 방식에 상관없이 데이터의 형태를 표현
- WSDL은 XSD를 사용함으로써 데이터의 논리적인 모델을 기술
- 전송 프로토콜로 SOAP을 사용할 경우, 메시지 설계를 아래와 같이할 것을 권장
 * 요소 중심의 설계
 * 서비스와 관계된 데이터만을 메시지로 표현
 * 배열의 경우는 SOAP 표준에서 정의된 배열 인코딩 스키마

(3) portType 요소
① Request-Response RPC 방식
② One-Way Document 방식
③ Solicit-Response 방식
④ Notification 방식

2.4.4 요약
- WSDL은 웹 서비스 인터페이스에 관한 상세 정보를 기술하기 위한 표준
- 일반적인 네트워크 서비스를 명세하기 위한 표준으로 사용
- WSDL은 SOAP 프로토콜과 마찬가지로 다양한 기존에 존재하는 전송 프로토콜들과 바인딩될 수 있으며 데이터 인코딩 방식에서 독립적으로 설계

SOAP(Simple Object Access Protocols)
KNUG(Korea .NET User Group) 자료

4. SOAP(knug).pdf

제2절 SOAP(Simple Object Access Protocols)

과거의 분산컴퓨팅 환경의 프로토콜 기술
- DCOM(Distributed Component Object Model)
- CORBA(Common Object Request Broker Architecture)
- IIOP(Internet Inter-ORB Protocol)
- RMI(Remote Methods Invocations)

분산 환경
- 인터넷에 연결될 수 있는 모든 기기들이 상호 운용될 수 있는 환경
- 어떠한 하드웨어나 플랫폼에 독립적으로 공개된 환경
- 어떠한 프로그래밍 언어나 플랫폼, 하드웨어의 중심적인 사고를 벗어나 서비스가 중심이 되는 시대

2.2.1 SOAP 프로토콜의 필요성
- SOAP은 인터넷에서 양 끝단간 데이터나 혹은 XML 메시지를 교환할 수 있는 프로토콜
- XML이 없는 특정한 지점간의 연결
 * 문제점 : 상호운용성(Interoperability), 보안 문제, 성능(Performance), 확장성(Scalability)
- XML 기반 접근 방법
 * 각 장치간에 전송되는 메시지와 변환 작업을 전송계층(transport layer)과 별도로 어플리케이션 계층의 프로토콜 (application-level protocol)에서 처리한다면 보다 더 편리

2.2.2 SOAP의 메시지 전달 모델
- SOAP은 각 접점의 종단점(endpoints)에 의해서 메시지가 처리
- 종단점은 중개자(intermediary)의 역할을 수행

2.2.3 SOAP 프로토콜의 구조
- SOAP의 디자인 목적은 단순함(Simplicity)과 확장성(Extensibility)
- SOAP의 가장 중요한 개념은 메시지를 전달할 때, XML을 사용한다는 점
- SOAP Envelope
 * 선택적인(optional) SOAP Header와 반드시 포함되는 SOAP BODY로 구성
- SOAP Header
 * 만약 포함된다면 반드시 SOAP Envelope의 자식요소(child element)로 선언
- SOAP Body
 * 절차지향 메시지와 문서지향 메시지
- SOAP Fault
 * SOAP 메시지에서 클라이언트에게 에러 메시지를 전송하는 영역
 * 예외 처리 부분

2.2.4 SOAP 프로토콜의 아름다움 - 확장 가능한 프로토콜
- SOAP 1.1 버전의 경우 전송 프로토콜로 SMTP나 FTP와 같은 프로토콜을 사용할 수 있는 가능성
- SOAP 메시지가 특정한 전송 프로토콜에 의하여 전달될 수 있는 것을 프로토콜 바인딩(Protocol Binding)

2.2.5 SOAP 프로토콜의 장점과 미래
- SOAP 프로토콜의 장점
 * SOAP은 프로그래밍 언어에 상관없이 작성
 * 기존 프로토콜을 재사용할 수 있으며 내부 메커니즘을 개발자들이 알 필요가 없다
 * 배치가 손쉽다
 * 기존의 산업 표준들을 재활용한다
 * 개발자들은 XML을 숙지할 필요가 없다
 * 어느 환경에도 상관없이 동작할 수 있는 상호운영성을 제공
- SOAP 프로토콜의 미래
 * 보안
 * 성능
 * 바이너리 데이터(Binary Data) : 구조화된 이미지 파일(JPEG, GIF 등) → MIME or DIME or MTOM
 * 경로 : SOAP 스팩은 경로에 관한 메커니즘이 존재하지 않는다
   + WS-Routing 사용

2.2.6 요약
- 웹 서비스에서 메시지의 전달에만 중점
- SOAP Header에 다양한 부가적인 정보들을 삽입할 수 있는 SOAP 확장 메커니즘(extensibility mechanism)을 제공