웹 서비스 기본 개념
웹 서비스는 XML 웹 서비스라고도 합니다. 웹 서비스는 인터넷이나 인트라넷의 다른 시스템에서 전달된 요청을 받을 수 있는 경량의 독립 통신 기술입니다. 예: SOAP를 통해 웹을 통해 전달되고 WSDL 파일을 사용하여 설명되며 UDDI를 통해 등록되는 소프트웨어 서비스입니다.
XML: (Extensible Markup Language) 확장 가능한 마크업 언어. 단기 임시 데이터 처리와 World Wide Web을 위한 Soap의 기반이 됩니다.
Soap: (Simple Object Access Protocol) 단순 객체 액세스 프로토콜. XML Web Service의 통신 프로토콜입니다. 사용자가 UDDI를 통해 WSDL 설명 문서를 찾으면 SOAP를 통해 생성된 웹 서비스에서 하나 이상의 작업을 호출할 수 있습니다. SOAP는 XML 문서 형식의 메서드 호출을 위한 사양으로, HTTP(S) 또는 SMTP와 같은 다양한 기본 인터페이스를 지원할 수 있습니다.
WSDL: (웹 서비스 기술 언어) WSDL 파일은 SOAP 메시지 세트와 이를 교환하는 방법을 설명하는 XML 문서입니다. 대부분의 경우 소프트웨어에 의해 자동으로 생성되고 사용됩니다.
UDDI(Universal Description, Discovery, and Integration)는 주로 웹 서비스 제공자와 사용자를 대상으로 하는 새로운 프로젝트입니다. 사용자는 웹 서비스를 호출하기 전에 서비스에 어떤 비즈니스 메소드가 포함되어 있는지 확인하고, 호출된 인터페이스 정의를 찾고, 서버 측에서 소프트웨어를 컴파일해야 합니다. UDDI는 시스템이 이를 기반으로 해당 서비스를 찾도록 안내하는 메커니즘입니다. 설명 문서. UDDI는 SOAP 메시징 메커니즘(표준 XML/HTTP)을 사용하여 등록 정보를 게시, 편집, 탐색 및 찾습니다. XML 형식을 사용하여 다양한 유형의 데이터를 캡슐화하고 이를 등록 센터로 보내거나 등록 센터에서 필요한 데이터를 반환합니다.
호출 원리:
웹 서비스에는 두 가지 의미가 있습니다. 1. 단일 엔터티로 캡슐화되어 네트워크에 게시되는 기능 모음을 의미합니다. . 함수 집계가 호출된 후 제공되는 서비스입니다. 간단히 말해서 웹 서비스는 URL 리소스이며 클라이언트는 요청된 서비스가 어떻게 구현되는지 알지 않고도 프로그래밍 방식으로 서비스를 요청할 수 있습니다. 이는 기존 분산 구성 요소 개체 모델과 다릅니다.
웹 서비스의 아키텍처는 웹 서비스 제공자, 웹 서비스 요청자, 웹 서비스 중개자의 세 가지 역할과 게시, 검색, 바인딩의 세 가지 작업을 기반으로 구축됩니다. 간단히 말해서, 웹 서비스 제공자는 웹 서비스의 소유자이며 다른 서비스 및 사용자에게 자신의 기능을 제공하기 위해 인내심을 갖고 기다립니다. 웹 서비스 요청자는 웹 서비스 기능의 사용자이며 SOAP 메시지를 사용하여 제공합니다. 웹 서비스 요청자는 서비스를 얻기 위해 요청을 보냅니다. 웹 서비스 중개자의 역할은 웹 서비스 요청자를 적절한 웹 서비스 제공자(일반적으로 UDDI)와 연결하는 것입니다. 이 세 가지 역할은 논리적 관계에 따라 구분됩니다. 실제 애플리케이션에서는 역할 간에 중복이 있을 수 있습니다. 웹 서비스는 웹 서비스 제공자, 웹 서비스 요청자 또는 둘 다일 수 있습니다. 웹 서비스 역할 간의 관계를 보여줍니다. 그 중 "공개"는 특정 웹 서비스의 존재 및 관련 정보를 사용자 또는 다른 서비스에 알리는 것이며 "찾기(발견)"는 적절한 웹 서비스를 찾는 것입니다. "는 공급자와 요청자 사이에 일종의 연결을 설정하는 것입니다.
그림 2-1 웹 서비스 아키텍처
완전한 웹 서비스 구현은 다음 단계를 포함합니다.
◆ 웹 서비스 제공 개발자는 웹 서비스를 설계 및 구현하고, 올바르게 디버깅된 웹 서비스를 웹 서비스 중개자를 통해 게시하고 이를 UDDI 등록 센터에 등록합니다.
◆ 웹 서비스 요청자는 웹 서비스 중개자에게 특정 정보를 요청합니다. 서비스 중개자는 요청에 따라 UDDI 등록 센터에 질의하여 요청자에 대한 요청에 맞는 서비스를 찾습니다. (Discovery)
◆ 웹 서비스 중개자는 조건에 맞는 웹 서비스 설명 정보를 반환합니다. 웹 서비스 요청자 정보는 WSDL로 작성되며 웹 서비스를 지원하는 다양한 시스템에서 읽을 수 있습니다. (Discovery)
◆ 웹 서비스 중개자로부터 반환된 설명 정보를 사용하여 해당 SOAP를 생성합니다. 메시지를 웹 서비스 제공자에게 전송하여 웹 서비스 호출 구현(Binding)
◆ 웹 서비스 제공자는 SOAP 메시지에 따라 해당 웹 서비스를 실행하고 서비스 결과를 웹 서비스로 반환합니다. 요청자. (바인딩)
호출 방법:
1. Net(C#)에서 GET/POST/SOAP를 사용하여 WebService를 동적으로 호출하는 간단하고 유연한 방법
웹 서비스 호출
1).httpget
2).httppost
3).httpsoap
soap의 장점은 구조화된 데이터를 전송할 수 있다는 점입니다. 두 사람은 할 수 없습니다.
그런데 비누는 결국 HTTP를 이용해 XM을 전송합니다
보안:
웹서비스는 편리한 서비스로 다양한 분야에서 활용되며, 해커들의 별미가 되기도 했습니다. 여기에서는 웹 서비스 보안에 대해 현재 개선할 수 있는 사항을 간략하게 소개합니다.
웹서비스의 보안은 크게 다음의 3가지 측면으로 나누어집니다.
전송 SSL/HTTPS는 데이터를 전송하지 않고 연결을 암호화합니다
메시지 데이터 암호화(XML 암호화) 디지털 서명(XML-DSIG)
기본 아키텍처 애플리케이션 서비스 보안 메커니즘 활용
전송 보안은 다음을 사용하여 웹 서비스 애플리케이션에 추가하는 가장 쉬운 방법입니다. 기존 SSL 및 HTTPS 프로토콜을 사용하면 연결 과정에서 쉽게 보안을 얻을 수 있습니다.
그러나 이 보안 구현 방식에는 두 가지 약점이 있습니다. 첫째, 데이터 자체의 보안이 아닌 데이터 전송의 보안만 보장할 수 있으며, 데이터가 특정 위치에 도달하면 누구나 볼 수 있습니다. 웹 서비스에서는 데이터 조각이 여러 위치에 도달할 수 있지만 모든 수신자가 이 데이터를 볼 수는 없습니다. 둘째, 데이터의 어느 부분을 보호할지 선택할 수 없으며 이러한 선택성은 웹 서비스에서도 자주 사용됩니다.
두 번째 보호 계층은 메시지 자체를 보호하는 것입니다. 기존 XML 보안 확장 표준을 사용하여 디지털 서명 기능을 구현하면 메시지가 특정 당사자로부터 전송되고 수정되지 않았음을 확인할 수 있습니다. XML 파일의 암호화 기술은 웹 서비스의 보안을 더욱 강화합니다. 데이터 전송 후 수신자가 볼 수 있는지 여부를 사용자 정의할 수 있어 전송 후 보안도 더욱 향상됩니다. . 예: SAML 및 WS-Security.
마지막 보호 계층은 기본 아키텍처의 보안에 의존하며, 이는 운영 체제 및 일부 미들웨어의 보호에서 더 많이 나옵니다. 예를 들어, J2EE에서는 웹 서비스를 호스팅하는 애플리케이션 서버입니다. 현재 많은 J2EE 애플리케이션 서버는 최근 J2SE 1.4에 추가된 JAAS(Java Authentication and Authorization Service)를 지원합니다. 웹 서비스를 호스팅하는 서버를 사용하여 일부 보안 메커니즘을 구현하는 것은 당연합니다. 기본 아키텍처의 보안을 활용하는 또 다른 방법은 웹 서비스 사용자와 작성자가 보안 신뢰를 얻어야 하는 보안을 담당하는 독립적인 서버를 만드는 것입니다.
특징:
웹 서비스의 주요 목표는 크로스 플랫폼 상호 운용성입니다. 이러한 목표를 달성하기 위해 웹 서비스는 XML(Extensible Markup Language) 및 XSD(XML Schema)와 같은 플랫폼 독립적이고 소프트웨어 공급업체에 독립적인 표준을 기반으로 하며 상호 운용 가능하고 분산된 애플리케이션을 만들기 위한 새로운 플랫폼입니다. 따라서 웹 서비스를 사용하면 많은 장점이 있습니다.
1. 방화벽을 통한 통신
애플리케이션이 수천 명의 사용자를 보유하고 전 세계에 배포되는 경우 클라이언트 간 통신이 필요합니다. 그리고 서버 통신은 까다로운 문제가 될 것입니다. 일반적으로 클라이언트와 서버 사이에 방화벽이나 프록시 서버가 있기 때문입니다. 전통적인 접근 방식은 브라우저를 클라이언트로 사용하고, 많은 ASP 페이지를 작성하고, 최종 사용자에게 응용 프로그램의 중간 계층을 노출하도록 선택하는 것입니다. 그 결과 개발이 어렵고 프로그램을 유지 관리하기가 어렵습니다. 클라이언트측 코드가 더 이상 HTML 형식에 크게 의존하지 않는다면 클라이언트측 프로그래밍은 훨씬 더 간단해질 것입니다. 중간 계층 구성 요소가 웹 서비스로 대체되면 중간 계층 구성 요소를 사용자 인터페이스에서 직접 호출할 수 있으므로 ASP 페이지를 만드는 단계가 필요하지 않습니다. 웹 서비스를 호출하려면 Microsoft SOAP Toolkit이나 .net 등의 SOAP 클라이언트를 직접 사용하거나 자체 개발한 SOAP 클라이언트를 사용한 후 애플리케이션에 연결할 수 있습니다. 개발 주기를 단축할 뿐만 아니라 코드 복잡성을 줄이고 애플리케이션의 유지 관리 가능성을 향상시킵니다. 동시에 애플리케이션은 더 이상 중간 계층 구성 요소를 호출할 때마다 해당 "결과 페이지"로 이동할 필요가 없습니다.
2. 애플리케이션 통합
기업 수준의 애플리케이션 개발자는 기업이 다양한 언어로 작성되고 다양한 플랫폼에서 실행되는 다양한 프로그램을 통합하는 경우가 많다는 것을 모두 알고 있으며 이러한 통합에는 많은 비용이 듭니다. 개발 노력. 애플리케이션은 호스트에서 실행되는 프로그램에서 데이터를 얻거나 호스트 또는 다른 플랫폼 애플리케이션으로 데이터를 보내야 하는 경우가 많습니다. 동일한 플랫폼에서도 서로 다른 소프트웨어 공급업체가 생산한 다양한 소프트웨어를 통합해야 하는 경우가 많습니다. 웹 서비스를 통해 애플리케이션은 표준 방법을 사용하여 다른 애플리케이션에서 사용할 기능과 데이터를 "노출"할 수 있습니다.
XML 웹 서비스는 느슨하게 결합된 환경에서 표준 프로토콜(HTTP, XML, SOAP 및 WSDL)을 사용하여 메시지를 교환하는 기능을 제공합니다. 메시지는 구조화되거나 유형화되거나 느슨하게 정의될 수 있습니다.
3. B2B 통합
B2B는 Business to Business를 말하며, 다른 기업과 거래하는 기업, Business(일반적으로 Business를 지칭함) to Business 전자상거래, 즉 Business to Business를 말합니다. 비즈니스는 인터넷을 통해 제품, 서비스 및 정보를 교환합니다. 일반인의 용어로 말하면, 전자상거래 거래의 공급과 수요 측면이 모두 상인(또는 기업, 회사)이며, 이들이 인터넷 기술이나 다양한 비즈니스 네트워크 플랫폼을 사용하여 비즈니스 거래 과정을 완료하는 것을 의미합니다.
웹 서비스는 성공적인 B2B 통합의 핵심입니다. 웹 서비스를 통해 기업은 주요 비즈니스 애플리케이션을 지정된 공급업체 및 고객에게 간단히 "노출"할 수 있습니다. 웹 서비스는 인터넷에서 실행되며 전 세계 어디에서나 쉽게 구현할 수 있으며 운영 비용도 상대적으로 낮습니다. 웹 서비스는 B2B 통합의 핵심 부분일 뿐이며, 통합을 위해서는 다른 많은 부분이 필요합니다. 웹 서비스를 사용하여 B2B 통합을 구현하는 가장 큰 장점은 상호 운용성을 쉽게 얻을 수 있다는 것입니다. 비즈니스 로직이 "노출"되어 웹 서비스가 되는 한, 지정된 파트너는 시스템이 실행되는 플랫폼이나 사용하는 개발 언어에 관계없이 이러한 비즈니스 로직을 호출할 수 있습니다. 이를 통해 B2B 통합에 소요되는 시간과 비용이 크게 절감됩니다.
4. 소프트웨어 및 데이터 재사용
웹 서비스는 코드 재사용을 허용하면서 코드 뒤의 데이터를 재사용할 수 있습니다. 웹 서비스를 사용하면 더 이상 이전처럼 제3자로부터 소프트웨어 구성 요소를 구입하여 설치할 필요가 없으며, 원격 웹 서비스를 직접 호출하기만 하면 응용 프로그램에서 이러한 구성 요소를 호출할 수 있습니다. 소프트웨어 재사용의 또 다른 상황은 여러 애플리케이션의 기능을 통합하고 웹 서비스를 통해 이를 "노출"하는 것입니다. 이러한 모든 기능을 포털 사이트에 쉽게 통합하고 사용자에게 통일되고 친숙한 인터페이스를 제공할 수 있습니다. 귀하의 애플리케이션에서 타사 웹 서비스가 제공하는 기능을 사용할 수도 있고, 웹 서비스를 통해 다른 사람에게 자체 애플리케이션 기능을 제공할 수도 있습니다. 두 경우 모두 코드와 코드 뒤의 데이터를 재사용할 수 있습니다.
위의 논의에서 볼 수 있듯이 Web Service는 Web을 통한 상호 운용이나 원격 호출을 수행할 때 가장 유용합니다. 그러나 웹 서비스가 전혀 이점을 제공하지 못하는 경우도 있습니다. 웹 서비스에는 다음과 같은 단점이 있습니다.
1. 독립 실행형 애플리케이션
현재 기업과 개인은 여전히 많은 것을 사용하고 있습니다. 데스크탑 애플리케이션. 그 중 일부는 시스템의 다른 프로그램과만 통신하면 됩니다. 이 경우에는 웹 서비스를 사용하지 않고 로컬 API를 사용하는 것이 가장 좋습니다. COM은 작고 빠르기 때문에 이러한 상황에서 작업하는 데 이상적입니다. 동일한 서버에서 실행되는 서버 소프트웨어도 마찬가지입니다. 물론 이러한 상황에서도 웹 서비스를 사용할 수 있지만 이는 너무 많은 비용을 소모할 뿐만 아니라 어떠한 이점도 가져오지 못합니다.
2. LAN의 일부 애플리케이션
많은 애플리케이션에서 모든 프로그램은 Windows 플랫폼에서 COM을 사용하고 동일한 LAN에서 실행됩니다. 이러한 프로그램에서는 DCOM을 사용하는 것이 SOAP/HTTP보다 훨씬 더 효율적입니다. 마찬가지로, .net 프로그램이 LAN의 다른 .net 프로그램에 연결하려는 경우 .net Remoting을 사용해야 합니다. 실제로 .net Remoting에서는 SOAP/HTTP를 사용하여 웹 서비스 호출을 수행하도록 지정할 수도 있습니다. 그러나 TCP를 통해 직접 RPC 호출을 수행하는 것이 훨씬 효율적이므로 더 좋습니다.
1.3.XML 웹 서비스의 응용
1. 초기 XML 웹 서비스는 일반적으로 주가, 일기예보, 스포츠 경기 결과 등 응용 프로그램에 쉽게 통합될 수 있는 정보 소스입니다. , 등. .
2. 기존 애플리케이션을 XML Web Services로 제공하면 새롭고 더욱 강력한 애플리케이션을 구축하고 XML Web Services를 구성 요소로 활용할 수 있습니다.
예를 들어, 사용자는 다양한 공급업체로부터 가격 정보를 자동으로 가져오는 조달 애플리케이션을 개발하여 사용자가 공급업체를 선택하고 주문을 제출한 다음 제품을 받을 때까지 배송을 추적할 수 있습니다. 웹에서 서비스를 제공하는 것 외에도 공급자의 응용 프로그램은 XML Web Service를 사용하여 고객의 신용을 확인하고 지불금을 징수하며 화물 회사와의 화물 절차를 처리할 수도 있습니다.
SOAP 메시지 형식:
<?xml version="1.0"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope"
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Header>
<m:Trans xmlns:m="http://www.w3schools.com/transaction/"
soap:mustUnderstand="1">234
</m:Trans>
</soap:Header>
<soap:Body>
<m:GetPrice xmlns:m="http://www.w3schools.com/prices">
<m:Item>Apples</m:Item>
</m:GetPrice>
</soap:Body>
</soap:Envelope>웹 서비스의 작동 원리와 관련된 더 많은 기사를 보려면 다음을 참고하세요. PHP 중국어 웹사이트!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
