웹 서비스는 개방형 XML(표준 범용 마크업 언어의 하위 집합) 표준을 사용할 수 있는 플랫폼 독립적이고 낮은 결합, 자체 포함, 프로그래밍 가능 웹 기반 애플리케이션입니다. 분산되고 상호 운용 가능한 애플리케이션을 개발하기 위해 이러한 애플리케이션을 검색, 조정 및 구성합니다.
웹 서비스 기술을 사용하면 별도의 특수 타사 소프트웨어나 하드웨어 없이도 서로 다른 시스템에서 실행되는 다양한 애플리케이션이 데이터를 교환하거나 서로 통합할 수 있습니다. 웹 서비스 사양에 따라 구현된 응용 프로그램은 사용하는 언어, 플랫폼 또는 내부 프로토콜에 관계없이 서로 데이터를 교환할 수 있습니다. 웹 서비스는 네트워크에서 사용할 수 있고 특정 비즈니스 기능을 수행할 수 있는 독립적이고 자체 설명적인 모듈입니다. 웹 서비스는 일부 기존 산업 표준과 표준 범용 마크업 언어의 하위 집합인 XML 및 HTTP와 같은 기존 기술을 기반으로 하기 때문에 배포하기도 쉽습니다. 웹 서비스는 애플리케이션 인터페이스 비용을 줄여줍니다. 웹 서비스는 기업 전체 또는 여러 조직 전체에 걸쳐 비즈니스 프로세스를 통합하기 위한 공통 메커니즘을 제공합니다.
분산 애플리케이션 생성을 실현하려면 웹 서비스 플랫폼이 일련의 프로토콜을 채택해야 합니다. 모든 플랫폼에는 데이터 표현 방법과 유형 시스템이 있습니다. 상호 운용성을 달성하려면 웹 서비스 플랫폼은 다양한 플랫폼, 프로그래밍 언어 및 구성 요소 모델의 다양한 유형 시스템과 통신하기 위한 표준 유형 시스템을 제공해야 합니다. 이러한 프로토콜은 다음과 같습니다.
XML은 전자 문서를 구조화하기 위해 표시하는 데 사용되는 마크업 언어로, 웹 서비스 플랫폼에서 데이터를 표현하기 위한 기본 형식입니다. 생성 및 분석이 용이할 뿐만 아니라 XML의 주요 장점은 플랫폼과 공급업체에 독립적이라는 것입니다. XML은 W3C 사양의 문법 요구 사항을 따르고, 형식과 내용을 분리하고, 자체 설명이 좋고, 확장이 용이하며, 풍부한 타사 개발 라이브러리를 갖추고 있어 서로 다른 아키텍처의 시스템 간 정보 전송에 매우 적합합니다. XML 응용 프로그램이 점점 더 널리 보급됨에 따라 XML은 많은 응용 프로그램 시나리오에서의 장점으로 인해 사실상의 데이터 교환 표준이 되었습니다. XML은 W3C(World Wide Web Consortium)에서 작성되었습니다. W3C에서 개발한 XML SchemaXSD는 표준 데이터 유형 세트를 정의하고 이 데이터 유형 세트를 확장하는 언어를 제공합니다.
웹 서비스 플랫폼은 XSD를 데이터 유형 시스템으로 사용합니다. VB.NET 또는 C#과 같은 언어를 사용하여 웹 서비스를 구성하는 경우 웹 서비스 표준을 준수하려면 사용하는 모든 데이터 유형을 XSD 유형으로 변환해야 합니다. 서로 다른 플랫폼과 서로 다른 소프트웨어를 사용하는 서로 다른 조직 간에 데이터를 전달하려면 무언가로 포장해야 합니다. 이것은 SOAP와 같은 프로토콜입니다.
SOAP는 XML(표준 범용 마크업 언어의 하위 집합) 인코딩된 정보를 교환하는 데 사용되는 경량 프로토콜입니다. 사용자 간의 데이터는 웹 서비스의 주류 구현 형태입니다. 여기에는 세 가지 주요 측면이 있습니다. XML 봉투는 정보 내용을 설명하고 내용을 처리하는 방법, 프로그램 개체를 XML 개체로 인코딩하는 규칙, 원격 프로시저 호출(RPC) 구현을 위한 규칙을 정의하는 프레임워크를 정의합니다. SOAP는 다른 전송 프로토콜을 통해 실행될 수 있습니다.
SOAP는 메시지 내용, 보낸 사람, 수락하고 처리할 사람, 처리 방법을 설명하는 HTTP 프로토콜 기반 프레임워크를 정의합니다. SOAP 봉투(Envelop)를 정의하여 데이터 형식을 표준화하고, 정보 교환을 위해 봉투에 XML 데이터를 캡슐화하며, 이기종 시스템 간의 상호 운용성을 가능하게 합니다.
웹 서비스는 "소프트웨어-소프트웨어 대화"를 통해 서로 다른 시스템이 서로 호출할 수 있음을 실현하여 소프트웨어 애플리케이션, 웹 사이트 및 다양한 장치 간의 비호환성을 깨고 "웹 기반의 원활한 통합"이라는 목표를 달성하고자 합니다.
웹 서비스 설명 언어 WSDL은 기계가 읽을 수 있는 방식으로 제공되는 공식 설명 문서이며 XML(표준 범용 마크업 언어의 하위 집합)을 기반으로 웹 서비스 및 해당 기능을 설명하는 데 사용됩니다. , 매개변수 및 반환 값. WSDL은 XML을 기반으로 하기 때문에 기계와 사람이 모두 읽을 수 있습니다.
UDDI의 목적은 전자상거래에 대한 표준을 확립하는 것입니다. UDDI는 웹 서비스에 대한 웹 기반 분산 정보 등록 센터 구현 표준 집합이며 이를 가능하게 하는 구현 표준 집합도 포함합니다. 귀하가 제공하는 웹 서비스를 등록하여 다른 회사가 액세스 프로토콜의 구현 표준을 확인할 수 있습니다.
웹 서비스 자체는 실제로 애플리케이션 간의 통신을 구현합니다. 애플리케이션 간 통신을 달성하기 위해 RPC(원격 프로시저 호출)와 메시지 전달이라는 두 가지 방법을 사용할 수 있습니다. RPC를 사용할 때 클라이언트의 개념은 일반적으로 원격 개체를 인스턴스화하고 해당 메서드와 속성을 호출하여 서버에서 원격 프로시저를 호출하는 것입니다. RPC 시스템은 일종의 위치 투명성을 달성하려고 시도합니다. 서버는 원격 개체의 인터페이스를 노출하고 클라이언트는 이러한 개체의 인터페이스가 로컬에서 사용되는 것처럼 작동합니다. 이렇게 하면 기본 정보가 숨겨지고 클라이언트에서는 해당 정보가 필요하지 않습니다. 물체가 어느 기계에 있는지 알아보세요.
강점 1: 방화벽을 통한 통신
응용 프로그램이 수천 명의 사용자를 보유하고 전 세계에 배포된다면 클라이언트는 서버와 통신하게 됩니다. 까다로운 문제가 됩니다. 일반적으로 클라이언트와 서버 사이에 방화벽이나 프록시 서버가 있기 때문입니다. 이 경우 DCOM을 사용하는 것은 그리 간단하지 않으며 일반적으로 그렇게 많은 사용자에게 클라이언트 프로그램을 게시하는 것이 편리하지 않습니다. 전통적인 접근 방식은 브라우저를 클라이언트로 사용하고, 많은 ASP 페이지를 작성하고, 최종 사용자에게 응용 프로그램의 중간 계층을 노출하도록 선택하는 것입니다. 그 결과 개발이 어렵고 프로그램을 유지 관리하기가 어렵습니다.
중간 계층 구성 요소를 WebService로 대체하면 중간 계층 구성 요소를 사용자 인터페이스에서 직접 호출할 수 있으므로 ASP 페이지를 만드는 단계가 생략됩니다. WebService를 호출하려면 MicrosoftSOAP Toolkit이나 .NET과 같은 SOAP 클라이언트를 직접 사용하거나 자체 개발한 SOAP 클라이언트를 사용한 후 애플리케이션에 연결할 수 있습니다. 개발 주기를 단축할 뿐만 아니라 코드 복잡성을 줄이고 애플리케이션의 유지 관리 가능성을 향상시킵니다. 애플리케이션은 중간 계층 구성 요소를 호출할 때마다 해당 "결과 페이지"로 이동할 필요가 없습니다.
기업 수준의 애플리케이션 개발자는 기업이 다양한 언어로 작성되고 다양한 플랫폼에서 실행되는 다양한 프로그램을 통합해야 하는 경우가 많으며 이러한 통합에는 많은 개발 노력이 필요하다는 것을 모두 알고 있습니다. 애플리케이션은 종종 IBM 메인프레임에서 실행되는 프로그램에서 데이터를 얻거나 메인프레임 또는 UNIX 애플리케이션으로 데이터를 보내야 합니다. 다양한 소프트웨어 공급업체가 제공한 경우에도 다양한 소프트웨어를 동일한 플랫폼에 통합해야 하는 경우가 많습니다. 다른 애플리케이션은 표준 방법을 사용하여 WebService를 통해 노출된 기능과 데이터에 액세스할 수 있습니다.
강점 2: 애플리케이션 통합
기업 수준 애플리케이션 개발자는 기업이 다양한 언어로 작성된 다양한 프로그램을 통합하고 다양한 플랫폼에서 실행되는 경우가 많다는 것을 모두 알고 있으며, 이러한 통합에는 많은 개발 노력이 필요합니다. 애플리케이션은 종종 IBM 메인프레임에서 실행되는 프로그램에서 데이터를 얻거나 메인프레임 또는 UNIX 애플리케이션으로 데이터를 보내야 합니다. 다양한 소프트웨어 공급업체가 제공한 경우에도 다양한 소프트웨어를 동일한 플랫폼에 통합해야 하는 경우가 많습니다. 다른 애플리케이션은 표준 방법을 사용하여 WebService를 통해 노출된 기능과 데이터에 액세스할 수 있습니다.
예를 들어 고객 정보, 배송 주소, 수량, 가격, 결제 방법 등을 포함하여 고객의 새로운 주문을 로그인하는 데 사용되는 주문 실행 프로그램도 있습니다. 실제 상품을 보내십시오. 두 프로그램은 서로 다른 소프트웨어 공급업체에서 제공됩니다. 새로운 주문이 도착하면 주문 입력 프로그램은 주문 실행 프로그램에 상품을 보내라고 알립니다. 주문 실행 프로그램 위에 WebService 계층을 추가함으로써 주문 실행 프로그램은 "AddOrder" 기능을 "노출"할 수 있습니다. 이런 방식으로 새로운 주문이 도착할 때마다 주문 로그인 프로그램은 이 기능을 호출하여 상품을 보낼 수 있습니다.
기능 3: B2B 통합
WebService를 사용하여 애플리케이션을 통합하면 회사의 내부 비즈니스 처리를 더욱 자동화할 수 있습니다. 하지만 거래가 공급업체와 고객에 걸쳐 회사의 경계를 넓히면 어떻게 될까요? 기업 간 비즈니스 거래 통합을 흔히 B2B 통합이라고 합니다.
WebService는 성공적인 B2B 통합의 핵심입니다. WebService를 통해 기업은 주요 비즈니스 애플리케이션을 지정된 공급업체 및 고객에게 "노출"할 수 있습니다. 예를 들어, 전자 주문 시스템과 전자 송장 발행 시스템을 "노출"함으로써 고객은 전자적으로 주문을 보낼 수 있고 공급자는 원자재 구매 송장을 전자적으로 보낼 수 있습니다. 물론 이것이 새로운 개념은 아니며, EDI(Electronic Document Interchange)는 오랫동안 그래왔습니다. 그러나 WebService의 구현은 EDI보다 훨씬 간단하고 WebService는 인터넷에서 실행되며 전 세계 어디에서나 쉽게 구현될 수 있으므로 운영 비용이 상대적으로 저렴합니다. 그러나 WebService는 EDI와 같은 문서 교환이나 B2B 통합을 위한 완벽한 솔루션은 아닙니다. 통합을 위해서는 WebService 외에도 많은 다른 구성 요소가 필요합니다.
WebService를 사용하여 B2B 통합을 구현하는 가장 큰 장점은 상호 운용성을 쉽게 얻을 수 있다는 것입니다. 비즈니스 로직이 "노출"되어 WebService가 되는 한, 지정된 파트너는 시스템이 실행되는 플랫폼이나 사용하는 개발 언어에 관계없이 이러한 비즈니스 로직을 호출할 수 있습니다. 이는 B2B 통합에 소요되는 시간과 비용을 크게 줄여 EDI를 감당할 수 없는 많은 중소기업이 B2B 통합을 달성할 수 있도록 해줍니다.
소프트웨어 및 데이터 재사용
"소프트웨어 재사용은 형태와 구현 정도가 다양한 중요한 주제입니다." 가장 기본적인 형태는 소스코드 모듈이나 클래스 수준의 재사용이고, 또 다른 형태는 바이너리 형태의 컴포넌트 재사용이다.
현재 테이블 컨트롤이나 사용자 인터페이스 컨트롤과 같은 재사용 가능한 소프트웨어 구성 요소가 시장의 큰 점유율을 차지하고 있습니다. 이러한 유형의 소프트웨어 재사용은 코드로 제한되고 데이터를 재사용할 수 없기 때문에 매우 제한적입니다. 그 이유는 컴포넌트, 심지어 소스 코드까지 공개하는 것이 더 쉽지만, 자주 변경되지 않는 정적 데이터가 아닌 이상 데이터를 공개하는 것은 그리 쉽지 않기 때문입니다.
코드를 재사용하는 동안 webService는 데이터 뒤의 코드도 재사용할 수 있습니다. WebService를 사용하면 더 이상 이전처럼 제3자로부터 소프트웨어 구성 요소를 구입하여 설치할 필요가 없으며, 원격 WebService를 직접 호출하기만 하면 애플리케이션에서 이러한 구성 요소를 호출할 수 있습니다. 예를 들어, 사용자가 애플리케이션에 입력한 주소를 확인하려면 해당 주소를 해당 WebService로 직접 보내기만 하면 됩니다. 이 WebService는 거리 주소, 시, 도, 우편번호 및 기타 정보를 확인하는 데 도움이 됩니다. 주소가 해당 우편번호 지역에 있나요? WebService 제공자는 이용 시간이나 횟수에 따라 서비스 요금을 청구할 수 있습니다. 컴포넌트 재사용을 통해 이러한 서비스를 구현하는 것은 불가능합니다. 이 경우 주소, 시, 도, 우편번호 등의 정보가 포함된 데이터베이스를 다운로드하여 설치해야 하며, 이 데이터베이스는 실시간으로 업데이트될 수 없습니다.
소프트웨어 재사용의 또 다른 상황은 여러 애플리케이션의 기능을 통합하는 것입니다. 예를 들어, 사용자가 FedEx 패키지 확인, 주식 시장 상황 확인, 일정 관리, 온라인 영화 티켓 구매 등을 할 수 있도록 LAN에 포털 애플리케이션을 구축하려고 합니다. 현재 웹에는 많은 응용 프로그램 제공자가 있으며 이들 모두 해당 응용 프로그램에 이러한 기능을 구현했습니다. WebService를 통해 이러한 기능을 "노출"하면 이러한 모든 기능을 포털 사이트에 쉽게 통합하고 사용자에게 통일되고 친숙한 인터페이스를 제공할 수 있습니다.
향후에는 많은 애플리케이션이 WebService를 사용하여 현재의 컴포넌트 기반 애플리케이션 구조를 컴포넌트/WebService 하이브리드 구조로 확장할 것입니다. 애플리케이션에서 타사 WebService가 제공하는 기능을 사용하거나 자체 애플리케이션을 추가할 수 있습니다. WebService를 통해 타인에게 제공되는 기능입니다. 두 경우 모두 코드와 코드 뒤의 데이터를 재사용할 수 있습니다.
단점 1: 독립형 애플리케이션
현재 기업과 개인은 여전히 많은 데스크톱 애플리케이션을 사용하고 있습니다. 그 중 일부는 단순히 컴퓨터의 다른 프로그램과 통신하기만 하면 됩니다. 이 경우 로컬 API를 사용하고 WebService를 사용하지 않는 것이 좋습니다. COM은 작고 빠르기 때문에 이러한 상황에서 작업하는 데 이상적입니다. 동일한 서버에서 실행되는 서버 소프트웨어도 마찬가지입니다. 애플리케이션 간에 호출을 수행하려면 COM 또는 기타 로컬 API를 직접 사용하는 것이 가장 좋습니다. WebService도 이러한 시나리오에 적합하지만 많은 리소스를 소비하며 실질적인 이점을 얻지 못합니다.
약점 2: LAN의 동형 응용 프로그램
많은 응용 프로그램에서 모든 프로그램은 VB 또는 VC로 개발되고 모두 Windows 플랫폼에서 COM을 사용하며 모두 동일한 LAN에서 실행됩니다. 예를 들어, 서로 통신해야 하는 두 개의 서버 응용 프로그램이 있거나 LAN의 다른 서버 프로그램에 연결하려는 Win32 또는 WinForm 클라이언트 프로그램이 있습니다. 이러한 프로그램에서는 DCOM을 사용하는 것이 SOAP/http보다 훨씬 더 효율적입니다. 마찬가지로, .NET 프로그램이 LAN의 다른 .NET 프로그램에 연결하려는 경우 .NET Remoting을 사용해야 합니다. 흥미롭게도 .NET Remoting에서는 SOAP/http를 사용하여 WebService 호출을 수행하도록 지정할 수도 있습니다. 그러나 TCP를 통해 직접 RPC 호출을 수행하는 것이 훨씬 효율적이므로 더 좋습니다.
간단히 말하면, 애플리케이션 구조 관점에서 WebService보다 더 효과적이고 실행 가능한 다른 방법이 있는 한 WebService를 사용하지 마세요.
웹 서비스를 통해 서로 다른 프로젝트 간 인터페이스 동원을 구현하고 객체 데이터를 전송합니다~
1, pom
<!--webservice-->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web-services</artifactId>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-frontend-jaxws</artifactId>
<version>3.1.12</version>
</dependency>
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-transports-http</artifactId>
<version>3.1.12</version>
</dependency>2, config 구성 클래스
package com.guor.config;
import com.guor.service;
import com.guor.service.implImpl;
import org.apache.cxf.Bus;
import org.apache.cxf.bus.spring.SpringBus;
import org.apache.cxf.jaxws.EndpointImpl;
import org.apache.cxf.transport.servlet.CXFServlet;
import org.springframework.boot.web.servlet.ServletRegistrationBean;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import javax.xml.ws.Endpoint;
@Configuration
public class CxfConfig {
@Bean
public ServletRegistrationBean createServletRegistrationBean() {
return new ServletRegistrationBean(new CXFServlet(), "/WebService/*");
}
@Bean(name = Bus.DEFAULT_BUS_ID)
public SpringBus springBus() {
return new SpringBus();
}
@Bean
public WebService myService() {
return new WebServiceImpl();
}
@Bean
public Endpoint endpoint() {
EndpointImpl endpoint = new EndpointImpl(springBus(), myService());
endpoint.publish("/api");
return endpoint;
}
}3, 인터페이스
package com.guor.service;
import com.guor.entity.dto.User;
import javax.jws;
@WebService(name = "WebService", // 暴露服务名称
targetNamespace = "http://service.guor.com"// 命名空间,一般是接口的包名倒序
)
public interface WebService {
User sendInfo(User user);
}package com.guor.service.impl;
import com.guor.entity.dto.User;
import com.guor.service;
import org.springframework.stereotype.Service;
import javax.jws;
@WebService(serviceName = "WebService", // 与接口中指定的服务name一致
targetNamespace = "http://service.guor.com", // 与接口中的命名空间一致,一般是接口的包名倒
endpointInterface = "com.guor.service"// 接口地址
)
@Service
public class WebServiceImpl implements WebService {
@Override
public User sendInfo(User user) {
return user;
}
}1. 동일한 인터페이스를 만듭니다
package com.guor.service;
import com.guor.entity.dto.User;
import javax.jws;
@WebService(name = "WebService", // 暴露服务名称
targetNamespace = "http://service.guor.com"// 命名空间,一般是接口的包名倒序
)
public interface WebService {
User sendInfo(User user);
}2.
위 내용은 웹 서비스가 springboot 프로젝트 간 인터페이스 호출 및 객체 전송을 구현하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
