WebService의 소개, 원리 및 사용

1부: 직관적인 개요

WebService의 여러 개념:

HTTP 프로토콜 기반 및 XML Framework를 통해 구현 /클라이언트와 서버 간 통신을 위한 구성 요소

두 가지 핵심 사항:

1. 서버에서 제공하는 기능을 xml로 설명합니다.

2. 첫 번째 단계에서 설명한 기능이 HTTP 프로토콜에 내장되어 있어 HTTP 프로토콜[소위 SOAP]을 통한 통신이 가능합니다.

도표는 다음과 같이 표현할 수 있습니다.

그림 1: WebService의 간략한 표현

이 두 기술을 사용하는 주요 목적은 다음과 같습니다.

1. 플랫폼, HTTP 프로토콜을 지원하는 호스트 및 서버는 통신 연결을 설정할 수 있으며 대부분의 호스트 및 서버(99.999% 이상)는 HTTP 프로토콜을 지원합니다. 일반적으로 서로 다른 대상 호스트 간의 통신은 방화벽을 통과해야 하며 특정 포트를 열어야 합니다. HTTP 프로토콜의 장점은 일반적으로 방화벽이 포트 80을 차단하지 않으므로 통신이 편리하고 안전하다는 것입니다.

2. 모든 언어에서 XML 텍스트 구문 분석을 지원합니다. 이는 서로 다른 언어 간의 통신 내용을 xml로 제한하기 위한 것입니다. 즉, Java로 개발된 서버는 C를 사용하여 클라이언트에 액세스할 수 있고 Java, VB 등을 사용하여 액세스할 수 있으며 그 반대의 경우도 마찬가지입니다.

2부: 기본 원리 및 아키텍처

물론 아키텍처는 우리가 언급한 다이어그램보다 더 복잡합니다. 위의 내용은 복잡하므로 실제 상황에서는 다음 사항을 고려해야 합니다.

서버(공급자)는 통일된 표준을 제공합니다. 서비스. 회사(예: 서버 제공업체)를 시작하는 것과 마찬가지로 회사 주소와 성격을 공상행정청에 등록하세요. 그 목적은 다른 사람이 회사의 서비스를 이용하기를 원할 경우 공상행정국을 통해 귀하의 주소를 알게 하려는 것입니다. 이러한 통일된 접근 방식은 회사가 제공하는 서비스를 필요로 하는 모든 기업과 모든 고객에게 편리합니다. 그리고 이 정보는 가능한 한 최대한 공개됩니다.

2. 고객(요청자)은 등록센터(Registry)에 가서 회사의 기본정보를 얻은 후 회사를 찾아 회사에서 제공하는 서비스를 이용합니다.

그림 2: 기본 웹 서비스 아키텍처 흐름도

위 그림에 주목하세요 기본 단계의 레이블은 다음과 같습니다

1. Provider 노드가 서비스를 제공한 후 먼저 Node Registry에 등록합니다

2 및 3. Requester 노드가 Registry로 이동합니다. 노드는 정보를 확인하고 필요한 Provider와 그것이 제공하는 서비스를 찾습니다

4. 요청자는 Provider가 제공하는 서비스를 사용합니다

자세한 소개는 다음을 참조하세요. 참조 [2], 다음은 기본적으로 이 참조에서 번역됩니다. Coming :

그림 3: 세부 단계 흐름도

위 그림의 내용 WebService의 전체 기본 프로세스를 완벽하게 제시합니다.

1. 클라이언트는 서비스가 필요하고 호출하고 싶지만 해당 서비스를 UDDI 레지스트리에서 찾을 수 있다는 것을 알고 있습니다. .

2. 물론 UDDI에는 Web Server A라는 서버가 이러한 서비스를 제공할 수 있다고 기록되어 있습니다.

3. 그래서 클라이언트는 웹 서버 A로 가서 정확한 호출 방법을 묻습니다.

4. 웹 서버 A는 클라이언트가 제안한 "정확한 메소드 쿼리"를 확인한 후 즉시 제공할 수 있는 다양한 메소드 인터페이스를 기록하는 WSDL에서 설명하는 xml 문서를 반환합니다.

5. 클라이언트는 이를 학습한 후 이러한 xml 인터페이스 메서드를 HTTP 요청으로 캡슐화하여 웹 서버 A로 보냅니다. 이러한 캡슐화 메서드는 기본적으로 HTTP 프로토콜을 충족하는 일부 SOAP 메시지 메시지인 표준 SOAP 메서드를 사용합니다.

6. 웹 서버 A도 HTTP 프로토콜의 SOAP 패킷에 응답하므로 양측의 요청과 응답이 완전히 원활하게 이루어집니다.

위에서 보는 것은 애플리케이션 회로도입니다. 더 자세히 살펴보면 다음과 같은 프로토콜 아키텍처 다이어그램을 찾을 수 있습니다.

그림 4: 프로토콜 구조

위에서 Discovery Service(UDDI)를 도입하고 서비스를 제공하는 등 많은 에너지를 소비했습니다. 인터페이스 설명(WSDL), 서비스 호출(SOAP) 및 전송(HTTP)의 전체 프로세스입니다. 그러므로 더 이상의 소개는 하지 않겠습니다. 이 기술의 핵심은 SOAP입니다.

3부: 웹서비스 실습

위 그림을 보면 참 복잡합니다. 실제로 SOAP+HTTP 프로토콜은 충분히 성숙되었으며, 이를 달성하는 데 도움이 되는 많은 도구가 있으므로 SOAP 변경 사항이 포함된 HTML 스크립트를 생성할 필요가 없습니다. 실제로 개발하는 것은 매우 간단합니다.

상황 A: 웹 서비스가 존재하는 것으로 알려져 있으며, 다음 단계를 통해 클라이언트 개발을 수행할 수 있습니다.

1. UDDI를 통해 위치를 찾습니다. 클라이언트 프로그램에 필요한 웹 서비스

2. WebService를 통해 WSDL 인터페이스 설명 파일을 찾습니다

3. 도구를 사용하여 2단계에서 얻은 WSDL 파일에서 클라이언트 스텁을 생성합니다. 본질적으로 코드, 즉 더미입니다. 이 스텁 코드를 클라이언트 프로그램에 병합합니다.

상황 B: 서버측 개발에서도 SOAP 구문 분석과 같은 번거로운 작업을 수행할 필요가 없으며 프레임워크가 이를 대신 수행합니다. 일반적인 단계는 다음과 같습니다.

1. WebServer가 제공해야 하는 모든 기능을 구현합니다

2. WSDL 파일(또는 IDL)을 사용하여 서버 스텁을 생성합니다. 외부로부터 요청을 받아 Web Server의 서비스 구현(구현 코드)으로 전달합니다. 서비스 구현 코드가 처리되어 결과가 생성되면 그 결과가 Server Stub으로 전달되고, Server Stub은 Server Stub + Server 구현을 결합하여 SOAP 응답을 생성할 수 있는 것을 웹 서비스 컨테이너(Web Service Container)라고 합니다. WebService로 전송된 HTTP 요청을 Server Stub으로 직접 전송하도록 합니다.

그림 5: 실제 애플리케이션의 호출

WebService의 소개와 원리, 사용법에 대한 자세한 내용은 PHP 중국어 홈페이지를 참고해주세요!