WebサービスがSpringbootプロジェクト間のインターフェイス呼び出しとオブジェクト転送を実装する方法

1. Baidu Encyclopedia

Web サービスは、オープン XML (標準ユニバーサル マークアップ言語) 標準のサブセットを使用できる、プラットフォームに依存しない、低結合の自己完結型のプログラム可能な Web ベースのアプリケーションです。分散型の相互運用可能なアプリケーションを開発するために、これらのアプリケーションの説明、公開、検出、調整、および構成を行います。

Web サービス テクノロジを使用すると、別のマシン上で実行されているさまざまなアプリケーションが、追加の専用のサードパーティ ソフトウェアやハードウェアを必要とせずにデータを交換したり、相互に統合したりすることができます。 Web サービス仕様に従って実装されたアプリケーションは、使用する言語、プラットフォーム、内部プロトコルに関係なく、相互にデータを交換できます。 Web サービスは、ネットワーク上で使用でき、特定のビジネス機能を実行できる自己完結型の自己記述モジュールです。 Web サービスは、標準のユニバーサル マークアップ言語に基づく XML や HTTP のサブセットなど、従来の業界標準や既存のテクノロジーに基づいているため、展開も簡単です。 Web サービスは、アプリケーション インターフェイスのコストを削減します。 Web サービスは、企業全体、さらには複数の組織全体にわたってビジネス プロセスを統合するための共通メカニズムを提供します。

2. Web サービスのテクニカル サポート

分散アプリケーションの作成を実現するには、Web サービス プラットフォームは一連のプロトコルを採用する必要があります。どのプラットフォームにも、そのデータ表現方法と型システムがあります。相互運用性を実現するには、Web サービス プラットフォームは、異なるプラットフォーム、プログラミング言語、およびコンポーネント モデルで異なる型システムを通信するための標準型システムを提供する必要があります。これらのプロトコルは次のとおりです。

1、XML、および XSD

XML は、電子ドキュメントをマークして構造化するために使用されるマークアップ言語であり、Web サービス プラットフォームでデータを表現するための基本形式です。 XML の主な利点は、作成と分析が簡単であることに加えて、プラットフォームにもベンダーにも依存しないことです。 XML は W3C 仕様の文法要件に従っており、フォームとコンテンツが分離されており、適切な自己記述があり、拡張が容易で、サードパーティの開発ライブラリが豊富にあるため、異なるアーキテクチャのシステム間の情報送信に非常に適しています。 XML のアプリケーションがますます普及するにつれて、XML は多くのアプリケーション シナリオにおける利点により、事実上のデータ交換標準になりました。 XML は World Wide Web Consortium (W3C) によって作成されました。W3C によって開発された XML SchemaXSD は、標準データ型のセットを定義し、このデータ型セットを拡張する言語を提供します。
Web サービス プラットフォームは、データ型システムとして XSD を使用します。 VB.NET や C# などの言語を使用して Web サービスを構築する場合、Web サービス標準に準拠するには、使用するすべてのデータ型を XSD 型に変換する必要があります。異なるプラットフォームや異なるソフトウェア上の異なる組織間で配信したい場合は、それを何かでラップする必要もあります。これはSOAPのようなプロトコルです。

2. SOAP

SOAP は、Simple Object Access Protocol であり、XML (標準ユニバーサル マークアップ言語のサブセット) でエンコードされた情報を交換するための軽量プロトコルです。異なる情報システム間の構造化データは、Web サービスの主流の実装形式です。 XML エンベロープには、情報コンテンツとコンテンツの処理方法を記述するためのフレームワーク、プログラム オブジェクトを XML オブジェクトにエンコードするためのルール、およびリモート プロシージャ コール (RPC) を実装するための規約という 3 つの主な側面があります。 SOAP は他のトランスポート プロトコル上で実行できます。

SOAP は、メッセージの内容、メッセージの送信者、メッセージを誰が受け入れて処理するか、およびメッセージの処理方法を記述する HTTP プロトコルに基づくフレームワークを定義します。 SOAP エンベロープ (Envelop) を定義することでデータ形式を標準化し、情報交換のために XML データをエンベロープにカプセル化し、異種システム間の相互運用性を可能にします。
Web Service は、異なるシステムが「ソフトウェアとソフトウェアの対話」を通じて相互に呼び出しできることを実現し、ソフトウェア アプリケーション、Web サイト、さまざまなデバイス間の非互換性を解消し、「Web ベースのシームレスな統合」を実現したいと考えています。

3. WSDL

Web サービス記述言語 WSDL は、機械可読な方法で提供される正式な記述ドキュメントであり、XML (標準汎用マークアップ言語のサブセット) に基づいています。 Web サービスとその関数、パラメータ、戻り値について説明します。 WSDL は XML に基づいているため、機械でも人間でも可読です。

4. UDDI

UDDI の目的は、電子商取引の標準を確立することです。UDDI は、Web サービス用の一連の Web ベースの分散型情報登録センター実装標準です。には、企業が提供する Web サービスを登録して、他の企業が Web サービスを発見できるようにするアクセス プロトコルの実装標準のセットが含まれています。

5. RPC の呼び出しとメッセージング

Web サービス自体は、実際にはアプリケーション間の通信を実装します。アプリケーション間の通信を実現するには、リモート プロシージャ コール (RPC) とメッセージ パッシングという 2 つの方法を使用できます。 RPC を使用する場合、クライアントの概念は、通常はリモート オブジェクトをインスタンス化し、そのメソッドとプロパティを呼び出すことによって、サーバー上のリモート プロシージャを呼び出すことです。 RPC システムは、一種の位置透過性を実現しようとします: サーバーはリモート オブジェクトのインターフェイスを公開し、クライアントはこれらのオブジェクトのインターフェイスがローカルで使用されているかのように動作します。これにより、基礎となる情報が隠蔽され、クライアントはそれを必要としません。オブジェクトがどのマシン上にあるかを把握します。

3. Web サービス アプリケーションのシナリオと欠点

1. Web サービス アプリケーションのシナリオ

強み 1: ファイアウォールを越えた通信
アプリケーションが数千のユーザーが世界中に分散している場合、クライアントとサーバー間の通信は厄介な問題になります。通常、クライアントとサーバーの間にはファイアウォールまたはプロキシ サーバーが存在するためです。この場合、DCOM の使用はそれほど単純ではなく、クライアント プログラムを多数のユーザーに公開するのは通常は不便です。従来のアプローチでは、ブラウザをクライアントとして使用し、多くの ASP ページを作成し、アプリケーションの中間層をエンド ユーザーに公開することを選択します。その結果、開発が困難になり、プログラムの保守も困難になります。

中間層コンポーネントを WebService に置き換えると、中間層コンポーネントをユーザー インターフェイスから直接呼び出すことができるため、ASP ページを作成する手順が不要になります。 WebService を呼び出すには、MicrosoftSOAP Toolkit や .NET などの SOAP クライアントを直接使用することも、独自に開発した SOAP クライアントを使用してアプリケーションに接続することもできます。開発サイクルが短縮されるだけでなく、コードの複雑さが軽減され、アプリケーションの保守性も向上します。アプリケーションは、中間層コンポーネントを呼び出すたびに、対応する「結果ページ」に移動する必要がありません。

エンタープライズレベルのアプリケーション開発者は皆、企業ではさまざまな言語で書かれ、さまざまなプラットフォームで実行されるさまざまなプログラムを統合する必要があり、この統合には多大な開発時間がかかることを知っています。アプリケーションは多くの場合、IBM メインフレーム上で実行されているプログラムからデータを取得したり、メインフレームまたは UNIX アプリケーションにデータを送信したりする必要があります。多くの場合、さまざまなソフトウェアは、異なるソフトウェア ベンダーから提供されている場合でも、同じプラットフォームに統合する必要があります。他のアプリケーションは、標準メソッドを使用して、WebService を通じて公開される機能とデータにアクセスできます。

強み 2: アプリケーションの統合
エンタープライズ レベルのアプリケーション開発者は、企業がさまざまな言語で書かれたアプリケーションを統合し、さまざまなプラットフォームで実行する必要があることがよくあることを知っています。が統合されており、この統合には多大な開発労力がかかります。アプリケーションは多くの場合、IBM メインフレーム上で実行されているプログラムからデータを取得したり、メインフレームまたは UNIX アプリケーションにデータを送信したりする必要があります。多くの場合、さまざまなソフトウェアは、異なるソフトウェア ベンダーから提供されている場合でも、同じプラットフォームに統合する必要があります。他のアプリケーションは、標準メソッドを使用して、WebService を通じて公開される機能とデータにアクセスできます。

たとえば、顧客情報、配送先住所、数量、価格、支払方法などを含む顧客からの新しい注文をログインするための注文ログイン プログラムや、顧客管理のための注文実行プログラムもあります。実際の商品の発送。 2 つのプログラムは異なるソフトウェア ベンダーから提供されています。新しい注文が到着すると、注文入力プログラムは注文実行プログラムに商品を送るように通知します。注文実行プログラムの上に WebService の層を追加することにより、注文実行プログラムは「AddOrder」関数を「公開」できます。このようにして、新しい注文が到着するたびに、注文ログイン プログラムはこの関数を呼び出して商品を発送できます。

強み 3: B2B 統合
WebService を使用してアプリケーションを統合すると、企業の内部業務処理をより自動化できます。しかし、取引がサプライヤーと顧客にまたがり、企業の境界を押し広げたらどうなるでしょうか?企業間のビジネス取引の統合は、B2B 統合と呼ばれることがよくあります。

WebService は B2B 統合を成功させる鍵です。 WebService を通じて、企業は主要なビジネス アプリケーションを指定されたサプライヤーや顧客に「公開」できます。たとえば、電子注文システムと電子請求システムを「公開」することで、顧客は注文を電子的に送信でき、サプライヤーは原材料購入請求書を電子的に送信できます。もちろん、これは新しい概念ではなく、EDI (Electronic Document Interchange) は昔からこのようなものでした。ただし、WebService の実装は EDI よりもはるかに簡単で、WebService はインターネット上で動作し、世界中のどこにでも簡単に実装できるため、運用コストが比較的低くなります。ただし、WebService は、EDI のようなドキュメント交換や B2B 統合のための完全なソリューションではありません。統合を実現するには、WebService に加えて、他の多くのコンポーネントが必要です。

WebService を使用して B2B 統合を実装する最大の利点は、相互運用性を簡単に実現できることです。ビジネス ロジックが「公開」されて Web サービスになる限り、指定されたパートナーは、システムがどのプラットフォームで実行されているか、または使用している開発言語に関係なく、これらのビジネス ロジックを呼び出すことができます。これにより、B2B 統合に費やす時間とコストが大幅に削減され、EDI を用意できない多くの中小企業が B2B 統合を実現できるようになります。
ソフトウェアとデータの再利用

「ソフトウェアの再利用は、さまざまな形式とさまざまな程度の実装がある重要なトピックです。」最も基本的な形式はソース コード モジュールまたはクラス レベルの再利用であり、もう 1 つの形式はバイナリ形式のコンポーネントの再利用です。

現在、テーブル コントロールやユーザー インターフェイス コントロールなどの再利用可能なソフトウェア コンポーネントが市場の大きなシェアを占めています。このタイプのソフトウェアの再利用は、コードに限定され、データを再利用できないため、非常に制限されます。その理由は、コンポーネントやソースコードさえも公開するのは簡単ですが、頻繁に変更されない静的データでない限り、データを公開するのはそれほど簡単ではないからです。

コードを再利用する際、webService はデータの背後にあるコードも再利用できます。 WebService を使用すると、以前のようにサードパーティからソフトウェア コンポーネントを購入してインストールし、アプリケーションからこれらのコンポーネントを呼び出す必要がなくなり、リモート WebService を直接呼び出すだけで済みます。たとえば、ユーザーがアプリケーションに入力した住所を確認するには、その住所を対応する Web サービスに直接送信するだけでよく、この Web サービスを使用すると、番地、市、県、郵便番号などの情報を確認して、住所を確認できます。住所は該当する郵便番号の地域ですか？ WebService のプロバイダーは、時間または使用回数に基づいてサービスの料金を請求できます。このようなサービスをコンポーネントの再利用で実装することは不可能であり、その場合は住所、市、県、郵便番号などの情報を含むデータベースをダウンロードしてインストールする必要があり、このデータベースはリアルタイムで更新できません。

ソフトウェア再利用のもう 1 つの状況は、複数のアプリケーションの機能を統合することです。たとえば、LAN 上にポータル アプリケーションを構築して、ユーザーが FedEx の荷物を確認したり、株式市場の状況を確認したり、自分のスケジュールを管理したり、オンラインで映画のチケットを購入したりできるようにするとします。現在、Web 上には多くのアプリケーション ベンダーがあり、そのすべてがこれらの機能をアプリケーションに実装しています。 WebService を通じてこれらの機能を「公開」すると、これらすべての機能をポータル サイトに簡単に統合でき、統一された使いやすいインターフェイスをユーザーに提供できます。

将来的には、多くのアプリケーションが WebService を使用して、現在のコンポーネントベースのアプリケーション構造をコンポーネント/WebService のハイブリッド構造に拡張することになります。アプリケーション内でサードパーティの WebService によって提供される機能を使用することも、次のこともできます。独自の機能を追加する アプリケーションの機能は、WebService を通じて他のユーザーに提供されます。どちらの場合も、コードとその背後にあるデータは再利用できます。

2. Web サービスのデメリット

デメリット 1: スタンドアロン アプリケーション

現在、企業や個人は依然として多くのデスクトップ アプリケーションを使用しています。それらの中には、マシン上の他のプログラムと通信するだけで十分なものもあります。この場合、WebService の使用を避け、ローカル API を使用することをお勧めします。 COM は小さくて高速であるため、この状況での作業に最適です。同じサーバー上で実行されているサーバー ソフトウェアについても同様です。アプリケーション間で呼び出しを行うには、COM またはその他のローカル API を直接使用するのが最善です。 WebService もこれらのシナリオには適していますが、大量のリソースを消費するため、実質的なメリットは得られません。

弱点 2: LAN における同形アプリケーション
多くのアプリケーションでは、すべてのプログラムは VB または VC で開発され、すべて Windows プラットフォームで COM を使用し、同じ LAN 上で実行されます。たとえば、相互に通信する必要がある 2 つのサーバー アプリケーションがあるか、LAN 上の別のサーバー プログラムに接続したい Win32 または WinForm クライアント プログラムがあるとします。これらのプログラムでは、SOAP/http よりも DCOM を使用した方がはるかに効率的です。同様に、.NET プログラムが LAN 上の別の .NET プログラムに接続する場合は、.NET リモート処理を使用する必要があります。興味深いことに、.NET リモート処理では、SOAP/http を使用して WebService 呼び出しを行うように指定することもできます。ただし、TCP 経由で直接 RPC 呼び出しを行う方がはるかに効率的です。

つまり、アプリケーション構造の観点から WebService よりも効果的で実現可能な他の方法がある限り、WebService を使用しないでください。

4. Web サービス コードの例

異なるプロジェクト間のインターフェイスのモバイル化を実現し、Web サービスを通じてオブジェクト データを転送します~

サーバー側プロジェクト コード

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、Web サービス ツール クラス

 /**
     * webservice接口地址
     */
    private static String address = "http://10.4.66.7:9992/MyProject/WebService/api?wsdl";

    /**
     * 通过webservice发送EC企业信息
     * @param User
     * @return
     */
    public static User sendInfo(User user) {
        try {
            // 代理工厂
            JaxWsProxyFactoryBean jaxWsProxyFactoryBean = new JaxWsProxyFactoryBean();
            // 设置代理地址
            jaxWsProxyFactoryBean.setAddress(address);
            //添加用户名密码拦截器
            //jaxWsProxyFactoryBean.getOutInterceptors().add(new LoginInterceptor("root","admin"));;
            // 设置接口类型
            jaxWsProxyFactoryBean.setServiceClass(class);
            // 创建一个代理接口实现
            WebService service = (WebService) jaxWsProxyFactoryBean.create();

            return service.sendInfo(user);
        } catch (Exception e) {
            return null;
        }
    }

以上がWebサービスがSpringbootプロジェクト間のインターフェイス呼び出しとオブジェクト転送を実装する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。