WebService 관련 개념

1. 머리말

한동안 WebService(웹 서비스)에 대해 많이 들어보셨을 것입니다. 많은 컴퓨터 저널, 서적, 웹 사이트에서 WebService 기술을 언급하고 홍보하는 경우가 많았습니다. 구성 요소. 하지만 WebService가 실제로 신흥 유망 기술이라는 점을 인정해야 합니다. 그렇다면 WebService란 정확히 무엇일까요? 언제 사용해야 합니까?

현재 애플리케이션 개발은 점차 완전히 다른 두 가지 경향을 보여 왔습니다. 하나는 브라우저 기반 씬 클라이언트 애플리케이션이고 다른 하나는 브라우저 기반 리치 클라이언트 애플리케이션(RIA)입니다. 물론 후자의 기술이 상대적으로 더 유행합니다( 현재 인기 있는 Html5 기술과 같은) 여기서는 주로 전자에 대해 이야기합니다.

브라우저 기반 씬 클라이언트 애플리케이션은 씬 클라이언트가 더 나은 사용자 인터페이스를 제공하기 때문이 아니라 데스크톱 애플리케이션 게시에 드는 높은 비용을 피하기 때문입니다. 데스크톱 응용 프로그램을 게시하는 데는 응용 프로그램 설치 및 구성 문제와 클라이언트와 서버 간의 통신 문제로 인해 비용이 많이 듭니다. 기존 Windows 리치 클라이언트 응용 프로그램은 DCOM을 사용하여 서버와 통신하고 원격 개체를 호출합니다. 대규모 네트워크에서 DCOM이 제대로 작동하도록 구성하는 것은 매우 어려운 작업이며 많은 IT 엔지니어에게는 악몽이기도 합니다. 실제로 많은 IT 엔지니어는 LAN에서 DCOM을 실행하는 것보다 브라우저로 인해 발생하는 기능적 제한을 견디는 편을 선호합니다. 클라이언트와 서버 간의 통신 문제와 관련하여 완벽한 솔루션은 HTTP 프로토콜을 사용하여 통신하는 것입니다. 이는 웹 브라우저를 실행하는 모든 시스템이 HTTP 프로토콜을 사용하기 때문입니다. 동시에 현재의 많은 방화벽은 HTTP 연결만 허용하도록 구성되어 있습니다. 많은 상용 프로그램이 직면하는 또 다른 문제는 다른 프로그램과의 상호 운용성입니다. 모든 응용 프로그램이 COM 또는 .NET 언어를 사용하여 작성되고 모두 Windows 플랫폼에서 실행된다면 세상은 평화로울 것입니다. 그러나 실제로 대부분의 비즈니스 데이터는 여전히 메인프레임에 VSAM(비관계형 파일) 형식으로 저장되어 있으며 COBOL 언어로 작성된 메인프레임 프로그램을 통해 액세스됩니다. 더욱이 많은 상용 프로그램은 C++, Java, Visual Basic 및 기타 다양한 언어로 계속해서 작성되고 있습니다. 이제 가장 단순한 프로그램을 제외한 모든 프로그램은 다른 이기종 플랫폼에서 실행되는 애플리케이션과 데이터를 통합하고 교환해야 합니다. 이러한 작업은 일반적으로 파일 전송 및 분석, 메시지 대기열, IBM의 APPC(Advanced Program to Program Communication)와 같은 특정 상황에만 적합한 API 등 특수한 방법으로 수행됩니다. 이전에는 플랫폼, 구성요소 모델, 프로그래밍 언어에 독립적인 애플리케이션 통신 표준이 없었습니다. 웹 서비스를 통해서만 클라이언트와 서버는 두 프로그램의 플랫폼 및 프로그래밍 언어에 관계없이 HTTP를 사용하여 자유롭게 통신할 수 있습니다.

2. WebService란 무엇인가요?

간단히 말해서 WebService는 프로그래밍 언어와 운영 체제 플랫폼을 넘나드는 원격 호출 기술입니다.

소위 교차 프로그래밍 언어 및 교차 운영 플랫폼은 서버 프로그램이 Java로 작성되고 클라이언트 프로그램이 다른 프로그래밍 언어로 작성될 수 있으며 그 반대의 경우도 가능하다는 것을 의미합니다! 교차 운영 체제 플랫폼은 서버 프로그램과 클라이언트 프로그램이 서로 다른 운영 체제에서 실행될 수 있음을 의미합니다.

소위 원격 호출은 한 컴퓨터 A의 프로그램이 다른 컴퓨터 B의 개체를 호출할 수 있는 방법입니다. 예를 들어 UnionPay에서 쇼핑몰에 제공하는 POS 카드 스와이프 시스템과 POS 쇼핑몰 내 기계이체 이체메소드를 호출하는 코드는 실제로 은행서버에서 실행됩니다. 또 다른 예로 Amazon, 일기예보 시스템, Taobao, Xiaonei.com, Baidu 등은 자사의 시스템 서비스를 웹 서비스 서비스 형태로 노출하여 제3자 웹사이트 및 프로그램에서 이러한 서비스 기능을 호출할 수 있도록 하여 시장 점유율을 확대하고 있습니다. 더 큰 개념에서 자체 시스템 효율성은 소위 SOA 애플리케이션입니다.

사실 WebService는 표면적으로는 웹을 통해 호출할 수 있는 API를 외부에 노출하는 애플리케이션입니다. 프로그래밍 방법을 사용하여 웹을 호출합니다. 이 WebService를 클라이언트라고 부르는 애플리케이션을 호출하고, 이 WebService를 제공하는 애플리케이션을 서버라고 부릅니다. 더 깊은 관점에서 보면 WebService는 상호 운용 가능한 분산 애플리케이션을 구축하기 위한 새로운 플랫폼이자 표준 집합입니다. 이는 애플리케이션이 웹에서 상호 운용성을 달성할 수 있는 방법을 정의합니다. 웹 서비스 표준을 통해 이러한 서비스를 쿼리하고 액세스할 수 있는 한 원하는 언어와 플랫폼에서 웹 서비스를 작성할 수 있습니다.

WebService 플랫폼에는 분산 애플리케이션을 생성하기 위한 일련의 프로토콜이 필요합니다. 모든 플랫폼에는 데이터 표현 방법과 유형 시스템이 있습니다. 상호 운용성을 달성하려면 WebService 플랫폼은 다양한 플랫폼, 프로그래밍 언어 및 구성 요소 모델의 다양한 유형 시스템과 통신하기 위한 표준 유형 시스템을 제공해야 합니다. 웹 서비스 플랫폼은 고객이 웹 서비스를 호출할 수 있는 충분한 정보를 얻을 수 있도록 웹 서비스를 설명하는 표준을 제공해야 합니다. 마지막으로 이 웹 서비스를 원격으로 호출할 수 있는 방법이 있어야 합니다. 이 방법은 실제로 원격 프로시저 호출 프로토콜(RPC)입니다. 상호 운용성을 달성하려면 이 RPC 프로토콜은 플랫폼과 프로그래밍 언어에 독립적이어야 합니다.

3. 웹서비스 플랫폼 기술

XML+XSD, SOAP, WSDL은 웹서비스 플랫폼을 구성하는 3대 기술이다.

3.1, XML + 객체의 반환 결과는 무엇입니까). XML은 WebService 플랫폼에서 데이터를 표현하기 위한 형식입니다. XML의 주요 장점은 생성 및 구문 분석이 쉽다는 것 외에도 플랫폼 독립적이고 공급업체 독립적이라는 것입니다. 기술적인 우월성보다 관련성이 없는 것이 더 중요합니다. 소프트웨어 공급업체는 경쟁사가 발명한 기술을 선택하지 않을 것입니다.

XML은 데이터 표현 문제를 해결하지만 표준 데이터 유형 세트를 정의하지 않고 이 데이터 유형 세트를 확장하는 방법도 정의하지 않습니다. 예를 들어, 정수는 정확히 무엇을 나타냅니까? 16비트, 32비트, 64비트? 이러한 세부 사항은 상호 운용성을 달성하는 데 중요합니다. XSD(XML 스키마)는 이 문제를 구체적으로 해결하는 표준 집합입니다. 이는 표준 데이터 유형 세트를 정의하고 이 데이터 유형 세트를 확장하는 언어를 제공합니다. WebService 플랫폼은 XSD를 데이터 유형 시스템으로 사용합니다. 특정 언어(예: VB.NET 또는 C#)를 사용하여 웹 서비스를 구성하는 경우 WebService 표준을 준수하려면 사용하는 모든 데이터 유형을 XSD 유형으로 변환해야 합니다. 사용하는 도구가 자동으로 이 변환을 완료했을 수도 있지만 필요에 맞게 변환 프로세스를 수정할 가능성이 높습니다.

3.2, SOAP

WebService가 HTTP 프로토콜을 통해 요청을 보내고 결과를 받을 때 전송된 요청 내용과 결과 내용은 XML 형식으로 캡슐화되고 일부 특정 HTTP 메시지 헤더가 설명에 추가됩니다. HTTP 메시지의 콘텐츠 형식 이러한 특정 HTTP 메시지 헤더와 XML 콘텐츠 형식은 SOAP 프로토콜입니다. SOAP는 웹 서비스를 호출하기 위한 표준 RPC 방법을 제공합니다.

SOAP 프로토콜 = HTTP 프로토콜 + XML 데이터 형식

SOAP 프로토콜은 SOAP 메시지의 형식을 정의합니다. SOAP 프로토콜도 HTTP 프로토콜을 기반으로 합니다. .XML은 SOAP입니다. 비유하자면, HTTP는 일반 고속도로이고, XML은 중앙의 녹색 격리 벨트와 양쪽 가드레일이며, SOAP는 격리 벨트와 가드레일을 추가하여 일반 고속도로를 변형한 고속도로입니다.

3.3, WSDL

우리가 물건을 사러 가게에 갈 때처럼 먼저 그 가게에 무엇이 있는지 알고 나서 구매를 하는 것이 기업이 하는 일이다. 광고 포스터를 올립니다. WebService 서비스를 호출하려면 먼저 WebService 클라이언트가 서비스의 주소가 어디에 있는지, 서비스에서 어떤 메서드를 호출할 수 있는지 알아야 합니다. 따라서 WebService 서버는 먼저 WSDL을 통해 자신의 홈 페이지를 설명해야 합니다. 외부에서 호출할 수 있는 서비스, 서비스란 무엇인지(서비스의 메서드는 무엇인지, 메서드에서 허용하는 매개변수는 무엇인지, 반환 값은 무엇인지), 서비스의 네트워크 주소를 나타내는 데 사용되는 URL 주소입니다. , 서비스는 어떻게 호출되나요?

WSDL(Web Services Description Language)은 웹 서비스와 해당 기능, 매개변수 및 반환 값을 설명하는 데 사용되는 XML 기반 언어입니다. WebService 클라이언트와 서버가 모두 이해할 수 있는 표준 형식입니다. WSDL은 XML을 기반으로 하기 때문에 기계 읽기와 사람 읽기가 모두 가능하며 이는 큰 이점입니다. 최신 개발 도구 중 일부는 웹 서비스를 기반으로 WSDL 문서를 생성할 수 있을 뿐만 아니라 WSDL 문서를 가져와 해당 WebService를 호출하는 프록시 클래스 코드를 생성할 수도 있습니다.

WSDL 파일은 웹 서버에 저장되며 URL 주소를 통해 접근할 수 있습니다. 클라이언트는 WebService 서비스를 호출하기 전에 서비스의 WSDL 파일 주소를 알아야 합니다. WebService 서비스 제공자는 두 가지 방법으로 WSDL 파일 주소를 노출할 수 있습니다. 1. 찾을 수 있도록 UDDI 서버에 등록합니다. 2. 클라이언트 호출자에게 직접 알려줍니다.

4. 웹 서비스 개발

웹 서비스 개발은 서버 측 개발과 클라이언트 측 개발

4.1. 🎜> 회사 넣기 내부 시스템의 업무 방식을 원격 협력 단위 및 개인이 호출할 수 있도록 WebService 서비스로 공개합니다. (일부 WebService 프레임워크의 도움으로 비즈니스 개체를 WebService 서비스에 쉽게 게시할 수 있습니다. Java의 일반적인 WebService 프레임워크에는 axis, xfire, cxf 등이 포함됩니다. Java ee 서버는 일반적으로 JBoss와 같은 WebService 서비스 게시도 지원합니다.)

4.2. 클라이언트 개발

다른 사람이 게시한 WebService 서비스 호출 대부분의 사람들은 일기예보 WebService 서비스를 호출하는 등 이 분야의 개발에 참여합니다. (정적으로 호출되는 프록시 클래스 코드를 생성하려면 WSDL2Java와 같은 제조업체의 도구를 사용하고, 제조업체에서 제공하는 클라이언트 프로그래밍 API 클래스를 사용하고, SUN의 초기 표준 jax-rpc 개발 키트를 사용하고, SUN의 최신 표준 jax-ws 개발 키트를 사용하십시오. 물론 SUN ORACLE에 인수됨)

4.3.

호출하는 WebService의 작동 원리 클라이언트의 경우 wsdl 파일의 URL 주소를 이러한 다양한 WebService 클라이언트 API에 전달합니다. 기본 프록시 클래스를 호출하면 웹 서비스 서비스에 액세스할 수 있습니다. 프록시 클래스는 클라이언트의 메소드 호출을 SOAP 형식의 요청 데이터로 변환하여 HTTP 프로토콜을 통해 전송하고, 수신된 SOAP 데이터를 반환 값으로 반환합니다. 서버의 경우 다양한 WebService 프레임워크의 핵심은 원격 호출 클라이언트가 http 프로토콜을 통해 비누 형식으로 요청 데이터를 보내면 데이터를 분석하고 어떤 메소드를 호출할지 파악합니다. 이 개체를 만들고 해당 메서드를 호출한 다음 메서드에서 반환된 결과를 비누 형식의 데이터로 패키징하고 http 응답 메시지를 통해 클라이언트에 다시 보냅니다.

5. 적용 가능한 경우

1. 방화벽 간 통신

애플리케이션이 수천 명의 사용자를 보유하고 전 세계에 배포되는 경우 클라이언트와 클라이언트 간의 관계 서버 그들 사이의 통신은 까다로운 문제가 될 것입니다. 일반적으로 클라이언트와 서버 사이에 방화벽이나 프록시 서버가 있기 때문입니다. 이 경우 DCOM을 사용하는 것은 그리 간단하지 않으며 일반적으로 그렇게 많은 사용자에게 클라이언트 프로그램을 게시하는 것이 편리하지 않습니다. 전통적인 접근 방식은 브라우저를 클라이언트로 사용하고, 많은 ASP 페이지를 작성하고, 최종 사용자에게 응용 프로그램의 중간 계층을 노출하도록 선택하는 것입니다. 그 결과 개발이 어렵고 프로그램을 유지 관리하기가 어렵습니다. 중간 계층 구성 요소가 WebService로 대체되면 사용자 인터페이스에서 중간 계층 구성 요소를 직접 호출할 수 있습니다. 대부분의 사람들의 경험으로 볼 때, 사용자 인터페이스와 중간 계층 사이에 많은 상호 작용이 있는 애플리케이션에서 WebService의 구조를 사용하면 사용자 인터페이스 프로그래밍에 소요되는 개발 시간을 20% 절약할 수 있습니다.

2. 애플리케이션 통합

엔터프라이즈급 애플리케이션 개발자는 기업이 다양한 언어로 작성되고 다양한 플랫폼에서 실행되는 다양한 프로그램을 통합하는 경우가 많다는 것을 모두 알고 있으며, 이러한 통합에는 많은 비용이 듭니다. 개발 노력. 애플리케이션은 종종 IBM 메인프레임에서 실행되는 프로그램에서 데이터를 얻거나 메인프레임 또는 UNIX 애플리케이션으로 데이터를 보내야 합니다. 동일한 플랫폼에서도 서로 다른 소프트웨어 공급업체가 생산한 다양한 소프트웨어를 통합해야 하는 경우가 많습니다. WebService를 통해 다양한 구조의 애플리케이션을 쉽게 통합할 수 있습니다.

3. B2B 통합

WebService를 사용하여 애플리케이션을 통합하면 회사의 내부 비즈니스 처리를 더욱 자동화할 수 있습니다. 하지만 거래가 공급업체와 고객에 걸쳐 회사의 경계를 넓히면 어떻게 될까요? 기업 간 비즈니스 거래 통합을 흔히 B2B 통합이라고 합니다. WebService는 성공적인 B2B 통합의 핵심입니다. WebService를 통해 기업은 주요 비즈니스 애플리케이션을 지정된 공급업체 및 고객에게 "노출"할 수 있습니다. 예를 들어, 전자 주문 시스템과 전자 송장 발행 시스템을 "노출"함으로써 고객은 전자적으로 주문을 보낼 수 있고 공급자는 원자재 구매 송장을 전자적으로 보낼 수 있습니다. 물론 이것은 새로운 개념은 아니며, EDI(Electronic Document Interchange)는 오랫동안 이랬습니다. 그러나 WebService의 구현은 EDI보다 훨씬 간단하고 WebService는 인터넷에서 실행되며 전 세계 어디에서나 쉽게 구현될 수 있으므로 운영 비용이 상대적으로 저렴합니다. 그러나 WebService는 EDI와 같은 문서 교환이나 B2B 통합을 위한 완벽한 솔루션은 아닙니다. WebService는 B2B 통합의 핵심 부분일 뿐이며 통합을 위해서는 다른 많은 부분이 필요합니다.

WebService를 사용하여 B2B 통합을 구현하는 가장 큰 장점은 상호 운용성을 쉽게 얻을 수 있다는 것입니다. 비즈니스 로직이 "노출"되어 WebService가 되는 한, 지정된 파트너는 시스템이 실행되는 플랫폼이나 사용하는 개발 언어에 관계없이 이러한 비즈니스 로직을 호출할 수 있습니다. 이는 B2B 통합에 소요되는 시간과 비용을 크게 줄여 EDI를 감당할 수 없는 많은 중소기업이 B2B 통합을 달성할 수 있도록 해줍니다.

4. 소프트웨어 및 데이터 재사용

소프트웨어 재사용은 큰 주제이며 재사용 형태가 다양하며 재사용 정도도 다양합니다. 가장 기본적인 형태는 소스코드 모듈이나 클래스 수준의 재사용이고, 그 중 하나는 바이너리 형태의 컴포넌트 재사용이다. WebService 애플리케이션은 비즈니스 수준의 재사용을 달성하기 위해 표준 방법을 사용하여 다른 애플리케이션에서 사용할 기능과 데이터를 "노출"할 수 있습니다.

6. 적용할 수 없는 경우

1. 독립형 애플리케이션

현재 기업과 개인은 여전히 ​​많은 데스크톱 애플리케이션을 사용하고 있습니다. 그 중 일부는 단순히 컴퓨터의 다른 프로그램과 통신하기만 하면 됩니다. 이 경우 WebService를 사용하지 않고 로컬 API를 사용하는 것이 가장 좋습니다. COM은 작고 빠르기 때문에 이러한 상황에서 작업하는 데 이상적입니다. 동일한 서버에서 실행되는 서버 소프트웨어도 마찬가지입니다. COM이나 다른 로컬 API를 직접 사용하여 애플리케이션 간에 호출하는 것이 가장 좋습니다. 물론 이러한 상황에서도 WebService를 사용할 수 있지만 너무 많이 소비할 뿐만 아니라 어떤 이점도 가져오지 않습니다.

2. LAN의 동형 애플리케이션

많은 애플리케이션에서 모든 프로그램은 VB 또는 VC로 개발되고 모두 Windows 플랫폼에서 COM을 사용하며 모두 동일한 LAN에서 실행됩니다. 예를 들어, 서로 통신해야 하는 두 개의 서버 응용 프로그램이 있거나 LAN의 다른 서버 프로그램에 연결하려는 Win32 또는 WinForm 클라이언트 프로그램이 있습니다. 이러한 프로그램에서는 DCOM을 사용하는 것이 SOAP/HTTP보다 훨씬 더 효율적입니다. 마찬가지로, .NET 프로그램이 LAN의 다른 .NET 프로그램에 연결하려는 경우 .NET Remoting을 사용해야 합니다. 흥미롭게도 .NETremoting에서는 SOAP/HTTP를 사용하여 WebService 호출을 수행하도록 지정할 수도 있습니다. 그러나 TCP를 통해 직접 RPC 호출을 수행하는 것이 훨씬 효율적이므로 더 좋습니다.

WebService 개념과 관련된 더 많은 기사를 보려면 PHP 중국어 웹사이트를 주목하세요!