웹 서비스-퀵 가이드
다른 책과 다른 조직은 웹 서비스에 다른 정의를 제공합니다. 그중 일부는 여기에 나열되어 있습니다.
웹 서비스는 인터넷을 통해 자체적으로 사용할 수 있고 표준화 된 XML 메시징 시스템을 사용하는 소프트웨어입니다. XML은 웹 서비스에 대한 모든 통신을 인코딩하는 데 사용됩니다. 예를 들어 클라이언트는 XML 메시지를 보내 웹 서비스를 호출 한 다음 해당 XML 응답을 기다립니다. 모든 통신이 XML로 이루어지기 때문에 웹 서비스는 하나의 운영 체제 나 프로그래밍 언어에 묶여 있지 않습니다. Java는 Perl과 통신 할 수 있습니다. Windows 응용 프로그램은 Unix 응용 프로그램과 통신 할 수 있습니다.
웹 서비스는 제품, 프로세스 및 공급망을 생성하기 위해 네트워크를 통해 설명, 게시, 위치 지정 또는 호출 할 수있는 독립형 모듈 식 분산 동적 응용 프로그램입니다. 이러한 애플리케이션은 로컬, 분산 또는 웹 기반 일 수 있습니다. 웹 서비스는 TCP / IP, HTTP, Java, HTML 및 XML과 같은 개방형 표준을 기반으로 구축됩니다.
웹 서비스는 응용 프로그램 간 직접 상호 작용을 위해 인터넷을 사용하는 XML 기반 정보 교환 시스템입니다. 이러한 시스템에는 프로그램, 개체, 메시지 또는 문서가 포함될 수 있습니다.
웹 서비스는 응용 프로그램 또는 시스템간에 데이터를 교환하는 데 사용되는 개방형 프로토콜 및 표준 모음입니다. 다양한 프로그래밍 언어로 작성되고 다양한 플랫폼에서 실행되는 소프트웨어 응용 프로그램은 웹 서비스를 사용하여 단일 컴퓨터의 프로세스 간 통신과 유사한 방식으로 인터넷과 같은 컴퓨터 네트워크를 통해 데이터를 교환 할 수 있습니다. 이러한 상호 운용성 (예 : Java와 Python 또는 Windows와 Linux 응용 프로그램 간)은 개방형 표준을 사용하기 때문입니다.
요약하면 완전한 웹 서비스는 다음과 같은 서비스입니다.
인터넷 또는 사설 (인트라넷) 네트워크를 통해 사용 가능
표준화 된 XML 메시징 시스템을 사용합니다.
하나의 운영 체제 또는 프로그래밍 언어와 관련이 없습니다.
공통 XML 문법을 통해 자체 설명
간단한 찾기 메커니즘을 통해 검색 가능
웹 서비스의 구성 요소
기본 웹 서비스 플랫폼은 XML + HTTP입니다. 모든 표준 웹 서비스는 다음 구성 요소를 사용하여 작동합니다.
SOAP (Simple Object Access Protocol)
UDDI (Universal Description, Discovery and Integration)
WSDL (웹 서비스 기술 언어)
이러한 모든 구성 요소는 웹 서비스 아키텍처 장 에서 논의되었습니다 .
웹 서비스는 어떻게 작동합니까?
웹 서비스는 HTML, XML, WSDL 및 SOAP와 같은 개방형 표준을 사용하여 다양한 응용 프로그램 간의 통신을 가능하게합니다. 웹 서비스는-
데이터에 태그를 지정하는 XML
메시지를 전송하는 SOAP
서비스 가용성을 설명하는 WSDL.
Windows에서 실행되는 Visual Basic 프로그램에서 액세스 할 수있는 Solaris에서 Java 기반 웹 서비스를 빌드 할 수 있습니다.
또한 C #을 사용하여 JSP (JavaServer Pages)를 기반으로하고 Linux에서 실행되는 웹 애플리케이션에서 호출 할 수있는 Windows에서 새 웹 서비스를 빌드 할 수 있습니다.
예
간단한 계정 관리 및 주문 처리 시스템을 고려하십시오. 회계 담당자는 Visual Basic 또는 JSP로 구축 된 클라이언트 응용 프로그램을 사용하여 새 계정을 만들고 새 고객 주문을 입력합니다.
이 시스템의 처리 로직은 Java로 작성되고 정보를 저장하기 위해 데이터베이스와 상호 작용하는 Solaris 시스템에 상주합니다.
이 작업을 수행하는 단계는 다음과 같습니다.
클라이언트 프로그램은 계정 등록 정보를 SOAP 메시지로 묶습니다.
이 SOAP 메시지는 HTTP POST 요청의 본문으로 웹 서비스에 전송됩니다.
웹 서비스는 SOAP 요청의 압축을 풀고 애플리케이션이 이해할 수있는 명령으로 변환합니다.
애플리케이션은 필요에 따라 정보를 처리하고 해당 고객에 대한 새로운 고유 계정 번호로 응답합니다.
다음으로 웹 서비스는 응답을 다른 SOAP 메시지로 패키징하여 HTTP 요청에 대한 응답으로 클라이언트 프로그램으로 다시 보냅니다.
클라이언트 프로그램은 계정 등록 프로세스의 결과를 얻기 위해 SOAP 메시지의 압축을 풉니 다.
웹 서비스 사용의 이점은 다음과 같습니다.
네트워크에 기존 기능 노출
웹 서비스는 HTTP를 사용하여 원격으로 호출 할 수있는 관리 코드 단위입니다. 즉, HTTP 요청을 사용하여 활성화 할 수 있습니다. 웹 서비스를 사용하면 네트워크를 통해 기존 코드의 기능을 노출 할 수 있습니다. 네트워크에 노출되면 다른 응용 프로그램에서 프로그램의 기능을 사용할 수 있습니다.
상호 운용성
웹 서비스를 사용하면 다양한 응용 프로그램이 서로 통신하고 데이터와 서비스를 서로 공유 할 수 있습니다. 다른 애플리케이션도 웹 서비스를 사용할 수 있습니다. 예를 들어 VB 또는 .NET 응용 프로그램은 Java 웹 서비스와 통신 할 수 있으며 그 반대의 경우도 마찬가지입니다. 웹 서비스는 애플리케이션 플랫폼과 기술을 독립적으로 만드는 데 사용됩니다.
표준화 된 프로토콜
웹 서비스는 통신을 위해 표준화 된 산업 표준 프로토콜을 사용합니다. 네 가지 계층 (서비스 전송, XML 메시징, 서비스 설명 및 서비스 검색 계층)은 모두 웹 서비스 프로토콜 스택에서 잘 정의 된 프로토콜을 사용합니다. 이러한 프로토콜 스택의 표준화는 다양한 선택, 경쟁으로 인한 비용 절감, 품질 향상과 같은 많은 이점을 비즈니스에 제공합니다.
저비용 통신
웹 서비스는 SOAP over HTTP 프로토콜을 사용하므로 기존의 저렴한 인터넷을 사용하여 웹 서비스를 구현할 수 있습니다. 이 솔루션은 EDI / B2B와 같은 독점 솔루션에 비해 훨씬 저렴합니다. HTTP를 통한 SOAP 외에도 웹 서비스는 FTP와 같은 다른 신뢰할 수있는 전송 메커니즘에서도 구현 될 수 있습니다.
웹 서비스는 다음과 같은 특별한 행동 특성을 가지고 있습니다.
XML 기반
웹 서비스는 데이터 표현 및 데이터 전송 계층에서 XML을 사용합니다. XML을 사용하면 네트워킹, 운영 체제 또는 플랫폼 바인딩이 제거됩니다. 웹 서비스 기반 애플리케이션은 핵심 수준에서 상호 운용성이 뛰어납니다.
느슨한 결합
웹 서비스의 소비자는 해당 웹 서비스에 직접 연결되지 않습니다. 웹 서비스 인터페이스는 클라이언트가 서비스와 상호 작용하는 능력을 손상시키지 않고 시간이 지남에 따라 변경 될 수 있습니다. 긴밀하게 결합 된 시스템은 클라이언트와 서버 로직이 서로 밀접하게 연결되어 있음을 의미하며, 이는 한 인터페이스가 변경되면 다른 인터페이스도 업데이트되어야 함을 의미합니다. 느슨하게 결합 된 아키텍처를 채택하면 소프트웨어 시스템을보다 쉽게 관리 할 수 있고 서로 다른 시스템 간의 통합이 더 간단 해집니다.
거친 입자
Java와 같은 객체 지향 기술은 개별 메서드를 통해 서비스를 노출합니다. 개별 방법은 기업 수준에서 유용한 기능을 제공하기에는 너무 정밀한 작업입니다. Java 프로그램을 처음부터 빌드하려면 클라이언트 또는 다른 서비스에서 사용하는 대략적인 서비스로 구성되는 몇 가지 세분화 된 메소드를 작성해야합니다.
비즈니스와 이들이 노출하는 인터페이스는 대략적이어야합니다. 웹 서비스 기술은 적절한 양의 비즈니스 로직에 액세스하는 대략적인 서비스를 정의하는 자연스러운 방법을 제공합니다.
동기식 또는 비동기식 기능
동기화는 서비스 실행에 대한 클라이언트의 바인딩을 의미합니다. 동기식 호출에서 클라이언트는 계속하기 전에 서비스가 작업을 완료 할 때까지 차단하고 기다립니다. 비동기 작업을 통해 클라이언트는 서비스를 호출 한 다음 다른 기능을 실행할 수 있습니다.
비동기 클라이언트는 나중에 결과를 검색하는 반면, 동기 클라이언트는 서비스가 완료되면 결과를받습니다. 비동기 기능은 느슨하게 결합 된 시스템을 가능하게하는 핵심 요소입니다.
원격 프로 시저 호출 (RPC) 지원
웹 서비스를 통해 클라이언트는 XML 기반 프로토콜을 사용하여 원격 개체에서 프로 시저, 함수 및 메서드를 호출 할 수 있습니다. 원격 프로시 저는 웹 서비스가 지원해야하는 입력 및 출력 매개 변수를 노출합니다.
EJB (Enterprise JavaBeans) 및 .NET 구성 요소를 통한 구성 요소 개발은 지난 몇 년 동안 점차 아키텍처 및 엔터프라이즈 배포의 일부가되었습니다. 두 기술 모두 다양한 RPC 메커니즘을 통해 배포되고 액세스 할 수 있습니다.
웹 서비스는 기존 구성 요소의 서비스와 동등한 자체 서비스를 제공하거나 들어오는 호출을 EJB 또는 .NET 구성 요소의 호출로 변환하여 RPC를 지원합니다.
문서 교환 지원
XML의 주요 장점 중 하나는 데이터뿐만 아니라 복잡한 문서도 나타내는 일반적인 방법입니다. 이러한 문서는 현재 주소를 나타내는 것처럼 간단 할 수도 있고 전체 책이나 RFQ (견적 요청)를 나타내는 것처럼 복잡 할 수도 있습니다. 웹 서비스는 투명한 문서 교환을 지원하여 비즈니스 통합을 촉진합니다.
웹 서비스 아키텍처를 보는 방법에는 두 가지가 있습니다.
- 첫 번째는 각 웹 서비스 행위자의 개별 역할을 조사하는 것입니다.
- 두 번째는 새로운 웹 서비스 프로토콜 스택을 조사하는 것입니다.
웹 서비스 역할
웹 서비스 아키텍처에는 세 가지 주요 역할이 있습니다.
서비스 제공자
웹 서비스 제공자입니다. 서비스 제공자는 서비스를 구현하고 인터넷에서 사용할 수 있도록합니다.
서비스 요청자
이것은 웹 서비스의 모든 소비자입니다. 요청자는 네트워크 연결을 열고 XML 요청을 전송하여 기존 웹 서비스를 활용합니다.
서비스 레지스트리
이것은 논리적으로 중앙 집중화 된 서비스 디렉토리입니다. 레지스트리는 개발자가 새 서비스를 게시하거나 기존 서비스를 찾을 수있는 중앙 위치를 제공합니다. 따라서 회사 및 서비스에 대한 중앙 집중식 청산 소 역할을합니다.
웹 서비스 프로토콜 스택
웹 서비스 아키텍처를보기위한 두 번째 옵션은 새로운 웹 서비스 프로토콜 스택을 검사하는 것입니다. 스택은 여전히 진화하고 있지만 현재 4 개의 주요 계층이 있습니다.
서비스 운송
이 계층은 애플리케이션 간의 메시지 전송을 담당합니다. 현재이 계층에는 HTTP (Hyper Text Transport Protocol), SMTP (Simple Mail Transfer Protocol), FTP (파일 전송 프로토콜) 및 BEEP (Blocks Extensible Exchange Protocol)와 같은 최신 프로토콜이 포함됩니다.
XML 메시징
이 계층은 메시지를 양쪽 끝에서 이해할 수 있도록 공통 XML 형식으로 메시지를 인코딩하는 역할을합니다. 현재이 계층에는 XML-RPC 및 SOAP가 포함됩니다.
서비스 설명
이 계층은 특정 웹 서비스에 대한 공용 인터페이스를 설명합니다. 현재 서비스 설명은 WSDL (Web Service Description Language)을 통해 처리됩니다.
서비스 발견
이 계층은 서비스를 공통 레지스트리로 중앙 집중화하고 간편한 게시 / 찾기 기능을 제공합니다. 현재 서비스 검색은 UDDI (Universal Description, Discovery, and Integration)를 통해 처리됩니다.
웹 서비스가 발전함에 따라 추가 계층이 추가되고 각 계층에 추가 기술이 추가 될 수 있습니다.
다음 장에서는 웹 서비스의 구성 요소에 대해 설명합니다.
서비스 전송에 대한 몇 마디
웹 서비스 프로토콜 스택의 맨 아래는 서비스 전송입니다. 이 계층은 실제로 두 컴퓨터간에 XML 메시지를 전송하는 역할을합니다.
하이퍼 텍스트 전송 프로토콜 (HTTP)
현재 HTTP는 서비스 전송에 가장 많이 사용되는 옵션입니다. HTTP는 간단하고 안정적이며 널리 배포됩니다. 또한 대부분의 방화벽은 HTTP 트래픽을 허용합니다. 이를 통해 XMLRPC 또는 SOAP 메시지가 HTTP 메시지로 가장 할 수 있습니다. 이는 원격 애플리케이션을 통합하려는 경우 유용하지만 보안 문제가 많으므로 여러 보안 문제가 발생합니다.
BEEP (Extensible Exchange Protocol) 차단
이것은 HTTP에 대한 유망한 대안입니다. BEEP는 새로운 프로토콜을 구축하기위한 새로운 IETF (Internet Engineering Task Force) 프레임 워크입니다. BEEP는 TCP에 직접 계층화되며 초기 핸드 셰이크 프로토콜, 인증, 보안 및 오류 처리를 비롯한 여러 내장 기능을 포함합니다. BEEP를 사용하여 인스턴트 메시징, 파일 전송, 콘텐츠 신디케이션 및 네트워크 관리를 포함한 다양한 애플리케이션을위한 새로운 프로토콜을 만들 수 있습니다.
SOAP는 특정 전송 프로토콜에 연결되어 있지 않습니다. 실제로 HTTP, SMTP 또는 FTP를 통해 SOAP를 사용할 수 있습니다. 따라서 한 가지 유망한 아이디어는 BEEP보다 SOAP를 사용하는 것입니다.
지난 몇 년 동안 오늘날 웹 서비스 기술의 핵심을 구성하는 세 가지 기본 기술이 전세계 표준으로 등장했습니다. 이러한 기술은 아래에서 설명합니다.
XML-RPC
이것은 컴퓨터간에 정보를 교환하기위한 가장 간단한 XML 기반 프로토콜입니다.
XML-RPC는 XML 메시지를 사용하여 RPC를 수행하는 간단한 프로토콜입니다.
요청은 XML로 인코딩되고 HTTP POST를 통해 전송됩니다.
XML 응답은 HTTP 응답의 본문에 포함됩니다.
XML-RPC는 플랫폼에 독립적입니다.
XML-RPC를 사용하면 다양한 응용 프로그램이 통신 할 수 있습니다.
Java 클라이언트는 XML-RPC를 Perl 서버에 전달할 수 있습니다.
XML-RPC는 웹 서비스를 시작하는 가장 쉬운 방법입니다.
XML-RPC에 대한 자세한 내용은 XML-RPC 자습서를 참조하십시오 .
비누
SOAP는 컴퓨터간에 정보를 교환하기위한 XML 기반 프로토콜입니다.
SOAP는 통신 프로토콜입니다.
SOAP는 응용 프로그램 간의 통신을위한 것입니다.
SOAP는 메시지를 보내는 형식입니다.
SOAP는 인터넷을 통해 통신하도록 설계되었습니다.
SOAP는 플랫폼에 독립적입니다.
SOAP는 언어에 독립적입니다.
SOAP는 간단하고 확장 가능합니다.
SOAP를 사용하면 방화벽을 우회 할 수 있습니다.
SOAP는 W3C 표준으로 개발됩니다.
SOAP에 대한 자세한 내용은 SOAP 자습서를 참조하십시오 .
WSDL
WSDL은 웹 서비스와 이에 액세스하는 방법을 설명하는 XML 기반 언어입니다.
WSDL은 Web Services Description Language를 나타냅니다.
WSDL은 Microsoft와 IBM이 공동으로 개발했습니다.
WSDL은 분산 및 분산 환경에서 정보 교환을위한 XML 기반 프로토콜입니다.
WSDL은 웹 서비스를 설명하기위한 표준 형식입니다.
WSDL 정의는 웹 서비스에 액세스하는 방법과 수행 할 작업을 설명합니다.
WSDL은 XML 기반 서비스와 인터페이스하는 방법을 설명하는 언어입니다.
WSDL은 XML 기반 전 세계 비즈니스 레지스트리 인 UDDI의 필수 부분입니다.
WSDL은 UDDI가 사용하는 언어입니다.
WSDL은 'wiz-dull'로 발음되며 'WSD-L'로 표기됩니다.
WSDL에 대한 자세한 내용은 WSDL 자습서를 참조하십시오 .
UDDI
UDDI는 웹 서비스를 설명, 게시 및 찾기위한 XML 기반 표준입니다.
UDDI는 Universal Description, Discovery 및 Integration을 나타냅니다.
UDDI는 웹 서비스의 분산 레지스트리에 대한 사양입니다.
UDDI는 플랫폼 독립적 인 개방형 프레임 워크입니다.
UDDI는 SOAP, CORBA 및 Java RMI 프로토콜을 통해 통신 할 수 있습니다.
UDDI는 WSDL을 사용하여 웹 서비스에 대한 인터페이스를 설명합니다.
UDDI는 SOAP 및 WSDL에서 웹 서비스의 세 가지 기본 표준 중 하나로 간주됩니다.
UDDI는 기업이 서로를 발견하고 인터넷을 통해 상호 작용하는 방식을 정의 할 수있는 개방형 산업 이니셔티브입니다.
UDDI에 대해 자세히 알아 보려면 UDDI 튜토리얼을 방문하십시오 .
웹 서비스 아키텍처를 기반으로 웹 서비스 구현의 일부로 다음 두 가지 구성 요소를 만듭니다.
서비스 제공 업체 또는 게시자
웹 서비스 제공자입니다. 서비스 공급자는 서비스를 구현하고 인터넷 또는 인트라넷에서 사용할 수 있도록합니다.
.NET SDK를 사용하여 간단한 웹 서비스를 작성하고 게시합니다.
서비스 요청자 또는 소비자
이것은 웹 서비스의 모든 소비자입니다. 요청자는 네트워크 연결을 열고 XML 요청을 전송하여 기존 웹 서비스를 활용합니다.
또한 웹 서비스 요청자 두 개를 작성합니다. 하나는 웹 기반 소비자 (ASP.NET 응용 프로그램)이고 다른 하나는 Windows 응용 프로그램 기반 소비자입니다.
다음은 서비스 제공자로 작동하고 애플리케이션에서 사용할 웹 서비스로 두 가지 메소드 (add 및 SayHello)를 노출하는 첫 번째 웹 서비스 예제입니다. 웹 서비스에 대한 표준 템플릿입니다. .NET 웹 서비스는 .asmx 확장자를 사용합니다. 웹 서비스로 노출 된 메서드에는 WebMethod 특성이 있습니다. IIS 가상 디렉터리에이 파일을 FirstService.asmx로 저장합니다 (IIS 구성에 설명 된대로, 예 : c : \ MyWebSerces).
FirstService.asmx
<%@ WebService language = "C#" class = "FirstService" %>
using System;
using System.Web.Services;
using System.Xml.Serialization;
[WebService(Namespace = "http://localhost/MyWebServices/")]
public class FirstService : WebService{
[WebMethod]
public int Add(int a, int b) {
return a + b;
}
[WebMethod]
public String SayHello() {
return "Hello World";
}
}웹 서비스를 테스트하려면 게시해야합니다. 웹 서비스는 인트라넷이나 인터넷에 게시 할 수 있습니다. 이 웹 서비스는 로컬 컴퓨터에서 실행되는 IIS에 게시됩니다. IIS 구성부터 시작하겠습니다.
시작 → 설정 → 제어판 → 관리 도구 → 인터넷 서비스 관리자를 엽니 다.
기본 웹 사이트를 펼치고 마우스 오른쪽 단추로 클릭하십시오. 새로 만들기 & # rarr; 가상 디렉터리. 가상 디렉터리 생성 마법사가 열립니다. 다음을 클릭하십시오.
"Virtual Directory Alias"화면이 열립니다. 가상 디렉터리 이름을 입력하십시오. 예를 들어, MyWebServices입니다. 다음을 클릭하십시오.
"웹 사이트 콘텐츠 디렉토리"화면이 열립니다.
가상 디렉터리의 디렉터리 경로 이름을 입력합니다. 예를 들어, c : \ MyWebServices입니다. 다음을 클릭하십시오.
"액세스 권한"화면이 열립니다. 요구 사항에 따라 설정을 변경하십시오. 이 연습에 대한 기본 설정을 유지하겠습니다.
다음 버튼을 클릭하십시오. IIS 구성을 완료합니다.
완료를 클릭하여 구성을 완료하십시오.
IIS가 제대로 구성되었는지 테스트하려면 위에서 만든 가상 디렉터리 (C : \ MyWebServices)에 HTML 파일 (예 : x.html)을 복사합니다. 이제 Internet Explorer를 열고http://localhost/MyWebServices/x.html. x.html 파일이 열립니다.
Note− 작동하지 않으면 로컬 호스트를 컴퓨터의 IP 주소로 바꾸십시오. 그래도 작동하지 않으면 IIS가 실행 중인지 확인하십시오. IIS 및 가상 디렉터리를 다시 구성해야 할 수 있습니다.
이 웹 서비스를 테스트하려면 위에서 만든 IIS 가상 디렉터리 (C : \ MyWebServices)에 FirstService.asmx를 복사합니다. Internet Explorer에서 웹 서비스를 엽니 다 (http : //localhost/MyWebServices/FirstService.asmx). 웹 서비스 페이지가 열립니다. 페이지에는 애플리케이션에서 웹 서비스로 노출 된 두 가지 메소드에 대한 링크가 있어야합니다. 축하합니다! 첫 번째 웹 서비스를 작성했습니다!
웹 서비스 테스트
방금 본 것처럼 .NET Framework에서 웹 서비스를 작성하는 것은 쉽습니다. .NET 프레임 워크에서 웹 서비스 소비자를 작성하는 것도 쉽습니다. 그러나 조금 더 복잡합니다. 앞서 말했듯이 웹 기반 소비자와 Windows 애플리케이션 기반 소비자의 두 가지 유형의 서비스 소비자를 작성합니다. 첫 번째 웹 서비스 소비자를 작성하겠습니다.
웹 기반 서비스 소비자
아래와 같이 웹 기반 소비자를 작성하십시오. WebApp.aspx라고합니다. ASP.NET 응용 프로그램입니다. 웹 서비스의 가상 디렉터리 (c : \ MyWebServices \ WebApp.axpx)에 저장합니다.
이 응용 프로그램에는 추가 할 사용자로부터 번호를 가져 오는 데 사용되는 두 개의 텍스트 필드가 있습니다. 클릭하면 Add 및 SayHello 웹 서비스를 가져 오는 Execute 버튼이 있습니다.
WebApp.aspx
<%@ Page Language = "C#" %>
<script runat = "server">
void runSrvice_Click(Object sender, EventArgs e) {
FirstService mySvc = new FirstService();
Label1.Text = mySvc.SayHello();
Label2.Text = mySvc.Add(Int32.Parse(txtNum1.Text), Int32.Parse(txtNum2.Text)).ToString();
}
</script>
<html>
<head> </head>
<body>
<form runat = "server">
<p>
<em>First Number to Add </em>:
<asp:TextBox id = "txtNum1" runat = "server" Width = "43px">4< /asp:TextBox>
</p>
<p>
<em>Second Number To Add </em>:
<asp:TextBox id = "txtNum2" runat = "server" Width = "44px">5</asp:TextBox>
</p>
<p>
<strong><u>Web Service Result -</u></strong>
</p>
<p>
<em>Hello world Service</em> :
<asp:Label id = "Label1" runat = "server" Font-Underline = "True">Label< /asp:Label>
</p>
<p>
<em>Add Service</em> :
& <asp:Label id = "Label2" runat = "server" Font-Underline = "True">Label</asp:Label>
</p>
<p align = "left">
<asp:Button id = "runSrvice" onclick = "runSrvice_Click" runat = "server" Text = "Execute"></asp:Button>
</p>
</form>
</body>
</html>소비자가 생성 된 후에는 사용할 웹 서비스에 대한 프록시를 생성해야합니다. 이 작업은 추가 된 웹 서비스를 참조 할 때 Visual Studio .NET에서 자동으로 수행됩니다. 따라야 할 단계는 다음과 같습니다.
사용할 웹 서비스에 대한 프록시를 만듭니다. 프록시는 .NET SDK와 함께 제공되는 WSDL 유틸리티를 사용하여 생성됩니다. 이 유틸리티는 웹 서비스에서 정보를 추출하고 프록시를 만듭니다. 프록시는 특정 웹 서비스에 대해서만 유효합니다. 다른 웹 서비스를 사용해야하는 경우이 서비스에 대한 프록시도 만들어야합니다. Visual Studio .NET은 웹 서비스 참조가 추가 될 때 자동으로 프록시를 만듭니다. .NET SDK와 함께 제공되는 WSDL 유틸리티를 사용하여 웹 서비스에 대한 프록시를 만듭니다. 현재 디렉터리에 FirstSevice.cs 파일이 생성됩니다. 웹 서비스에 대한 FirstService.dll (프록시)을 만들기 위해 컴파일해야합니다.
c:> WSDL http://localhost/MyWebServices/FirstService.asmx?WSDL
c:> csc /t:library FirstService.cs컴파일 된 프록시를 웹 서비스의 가상 디렉터리 (c : \ MyWebServices \ bin)의 bin 디렉터리에 넣습니다. 인터넷 정보 서비스 (IIS)는이 디렉터리에서 프록시를 찾습니다.
이미했던 것과 같은 방식으로 서비스 소비자를 만듭니다. 웹 서비스 프록시의 개체는 소비자에서 인스턴스화됩니다. 이 프록시는 서비스와의 상호 작용을 처리합니다.
IE에 소비자의 URL을 입력하여 테스트합니다 (예 : http : //localhost/MyWebServices/WebApp.aspx).
Windows 응용 프로그램 기반 웹 서비스 소비자
Windows 응용 프로그램 기반 웹 서비스 소비자를 작성하는 것은 다른 Windows 응용 프로그램을 작성하는 것과 같습니다. 응용 프로그램을 컴파일 할 때 프록시 (이미 수행)를 만들고이 프록시를 참조하기 만하면됩니다. 다음은 웹 서비스를 사용하는 Windows 애플리케이션입니다. 이 응용 프로그램은 웹 서비스 개체 (물론 프록시)를 만들고 여기에 SayHello 및 Add 메서드를 호출합니다.
WinApp.cs
using System;
using System.IO;
namespace SvcConsumer {
class SvcEater {
public static void Main(String[] args) {
FirstService mySvc = new FirstService();
Console.WriteLine("Calling Hello World Service: " + mySvc.SayHello());
Console.WriteLine("Calling Add(2, 3) Service: " + mySvc.Add(2, 3).ToString());
}
}
}을 사용하여 컴파일하십시오 c:\>csc /r:FirstService.dll WinApp.cs. WinApp.exe가 생성됩니다. 응용 프로그램과 웹 서비스를 테스트하려면 실행하십시오.
이제 질문이 생깁니다.이 애플리케이션이 실제로 웹 서비스를 호출하는지 어떻게 확신 할 수 있습니까?
테스트는 간단합니다. 웹 서비스에 접속할 수 없도록 웹 서버를 중지하십시오. 이제 WinApp 애플리케이션을 실행하십시오. 런타임 예외가 발생합니다. 이제 웹 서버를 다시 시작하십시오. 작동합니다.
보안은 웹 서비스에 매우 중요합니다. 그러나 XML-RPC 나 SOAP 사양은 명시적인 보안 또는 인증 요구 사항을 만들지 않습니다.
웹 서비스에는 세 가지 특정 보안 문제가 있습니다.
- Confidentiality
- Authentication
- 네트워크 보안
기밀성
클라이언트가 XML 요청을 서버에 보내는 경우 통신이 기밀로 유지되도록 할 수 있습니까?
답은 여기에 있습니다-
- XML-RPC 및 SOAP는 주로 HTTP 위에서 실행됩니다.
- HTTP는 SSL (Secure Sockets Layer)을 지원합니다.
- 통신은 SSL을 통해 암호화 될 수 있습니다.
- SSL은 입증 된 기술이며 널리 배포됩니다.
단일 웹 서비스는 일련의 애플리케이션으로 구성 될 수 있습니다. 예를 들어, 하나의 대형 서비스가 다른 세 가지 애플리케이션의 서비스를 함께 묶을 수 있습니다. 이 경우 SSL은 적절하지 않습니다. 메시지는 서비스 경로를 따라 각 노드에서 암호화되어야하며 각 노드는 체인의 잠재적 인 약한 링크를 나타냅니다. 현재이 문제에 대해 합의 된 솔루션은 없지만 유망한 솔루션 중 하나는 W3C XML 암호화 표준입니다. 이 표준은 전체 XML 문서 또는 XML 문서의 일부만 암호화 및 해독하기위한 프레임 워크를 제공합니다. www.w3.org/Encryption 에서 확인할 수 있습니다.
입증
클라이언트가 웹 서비스에 연결하는 경우 사용자를 어떻게 식별합니까? 사용자가 서비스를 사용할 권한이 있습니까?
다음 옵션을 고려할 수 있지만 강력한 인증 체계에 대한 명확한 합의는 없습니다.
HTTP에는 기본 및 다이제스트 인증에 대한 기본 지원이 포함되어 있으므로 서비스는 현재 HTML 문서가 보호되는 것과 거의 동일한 방식으로 보호 될 수 있습니다.
SOAP 디지털 서명 (SOAP-DSIG)은 공개 키 암호화를 활용하여 SOAP 메시지에 디지털 서명합니다. 클라이언트 나 서버가 상대방의 신원을 확인할 수 있도록합니다. www.w3.org/TR/SOAP-dsig 에서 확인하십시오 .
OASIS (Organization for the Advancement of Structured Information Standards)는 SAML (Security Assertion Markup Language)에 대해 작업하고 있습니다.
네트워크 보안
현재이 문제에 대한 쉬운 답은 없으며 많은 논쟁의 대상이되었습니다. 현재 SOAP 또는 XML-RPC 메시지를 필터링하려는 의도가 있다면 콘텐츠 유형을 text / xml로 설정하는 모든 HTTP POST 요청을 필터링 할 수 있습니다.
또 다른 대안은 SOAPAction HTTP 헤더 속성을 필터링하는 것입니다. 방화벽 공급 업체는 현재 웹 서비스 트래픽을 필터링하도록 명시 적으로 설계된 도구를 개발하고 있습니다.
이 장에서는 웹 서비스와 관련된 모든 최신 표준에 대한 아이디어를 제공합니다.
수송
Blocks Extensible Exchange Protocol (이전 BXXP라고 함) 인 BEEP는 응용 프로그램 프로토콜을 구축하기위한 프레임 워크입니다. IETF에 의해 표준화되었으며 XML이 데이터에 대해 수행 한 작업을 인터넷 프로토콜에 대해 수행합니다.
BEEP (Extensible Exchange Protocol) 차단
메시징
이러한 메시징 표준 및 사양은 분산 된 분산 환경에서 정보를 교환하기위한 프레임 워크를 제공하기위한 것입니다.
SOAP 1.1 (주)
SOAP 1.2 (사양)
웹 서비스 첨부 파일 프로필 1.0
SOAP 메시지 전송 최적화 메커니즘
설명 및 발견
웹 서비스는 잠재적 사용자가 실행을 허용하기에 충분한 정보를 찾을 수있는 경우에만 의미가 있습니다. 이러한 사양 및 표준의 초점은 비즈니스, 조직 및 기타 웹 서비스 제공자의 설명과 발견을 지원하는 서비스 세트의 정의입니다. 그들이 제공하는 웹 서비스; 및 해당 서비스에 액세스하는 데 사용할 수있는 기술 인터페이스.
UDDI 3.0
WSDL 1.1 (주의)
WSDL 1.2 (작업 초안)
WSDL 2.0 (워킹 그룹)
보안
이러한 보안 사양을 사용하여 애플리케이션은 일반 웹 서비스 프레임 워크와 함께 작동하도록 설계된 보안 통신에 참여할 수 있습니다.
웹 서비스 보안 1.0
SAML (Security Assertion Markup Language)
조치
웹 서비스 관리 용이성은 웹 서비스 아키텍처 내에서 웹 서비스의 존재, 가용성, 상태, 성능, 사용뿐만 아니라 제어 및 구성을 검색하기위한 일련의 기능으로 정의됩니다. 웹 서비스가 비즈니스 운영에 보편화되고 중요 해짐에 따라 웹 서비스를 관리하고 구현하는 작업은 비즈니스 운영의 성공에 필수적입니다.
웹 서비스 분산 관리
이 자습서에서는 웹 서비스 사용 방법을 배웠습니다. 그러나 웹 서비스에는 WSDL, UDDI 및 SOAP와 같은 구성 요소가 포함되어 활성화에 기여합니다. 다음 단계는 WSDL, UDDI 및 SOAP를 배우는 것입니다.
WSDL
WSDL은 웹 서비스와 이에 액세스하는 방법을 설명하는 XML 기반 언어입니다.
WSDL은 웹 서비스에 대한 메시지 형식 및 프로토콜 세부 정보와 함께 웹 서비스를 설명합니다.
WSDL에 대한 자세한 내용은 WSDL 자습서를 참조하십시오 .
UDDI
UDDI는 웹 서비스를 설명, 게시 및 찾기위한 XML 기반 표준입니다.
UDDI에 대해 자세히 알아 보려면 UDDI 튜토리얼을 방문하십시오 .
비누
SOAP는 응용 프로그램이 HTTP를 통해 정보를 교환 할 수 있도록하는 간단한 XML 기반 프로토콜입니다.
SOAP에 대한 자세한 내용은 SOAP 자습서를 참조하십시오 .