Web Service是一個平台獨立的，低耦合的，自包含的、基於可編程的web的應用程序，可使用開放的XML（標準通用標記語言下的一個子集）標準來描述、發布、發現、協調和配置這些應用程序，用於開發分散式的互動操作的應用程式。
Web Service技術， 能使得運行在不同機器上的不同應用無須借助附加的、專門的第三方軟體或硬件， 就可相互交換數據或集成。依據Web Service規範實施的應用之間， 無論它們所使用的語言、 平台或內部協定是什麼， 都可以相互交換資料。 Web Service是一種可用於網路的自包含、自描述模組，可執行具體的業務功能。 Web Service也很容易部署， 因為它們基於一些常規的產業標準以及已有的一些技術，諸如標準通用標記語言下的子集XML、HTTP。 Web Service減少了應用介面的花費。 Web服務提供了一種通用機制，用於整合整個企業甚至多個組織之間的業務流程。
要實現分散式應用程式的創建，Web Service平台必須採用一套協定。任何平台都有它的資料表示方法和類型系統。要實現互通性，Web Service平台必須提供一套標準的類型系統，用於溝通不同平台、程式語言和元件模型中的不同類型系統。這些協定有：
XML是一種用於標記電子檔案使其具有結構性的標記語言，是Web Service平台中表示資料的基本格式。除了易於建立和易於分析外，XML主要的優點在於它既與平台無關，又與廠商無關。 XML遵循 W3C 規範的語法要求，形式與內容分離，具有良好的自描述性，同時易於擴展，擁有豐富的第三方開發庫，非常適合在不同架構的系統之間進行資訊傳輸使用。隨著XML的應用越來越廣泛，在許多應用場景下，XML憑藉其優點已成為事實上的資料交換標準。 XML是由萬維網協會(W3C)創建，W3C制定的XML SchemaXSD定義了一套標準的資料類型，並給出了一種語言來擴展這套資料類型。
Web Service平台是用XSD來當作資料型別系統的。當你用某種語言如VB. NET或C# 來建構一個Web Service時，為了符合Web Service標準，所有你所使用的資料型別都必須轉換成XSD型別。如想讓它使用在不同平台和不同軟體的不同組織間傳遞，還需要用某些東西將它包裝起來。這種東西就是一種協議，如 SOAP。
SOAP即簡單物件存取協定(Simple Object Access Protocol)，它是用來交換XML（標準通用標記語言下的子集）編碼資訊的輕量級級協議，能夠在不同資訊系統之間交換結構化數據，是Web Service的一種主流實現形式。它有三個主要面向：XML-envelope為描述資訊內容和如何處理內容定義了框架，將程式物件編碼成為XML物件的規則，執行遠端過程呼叫(RPC)的約定。 SOAP可以運作在任何其他傳輸協定上。
SOAP基於HTTP協定定義了一個框架，描述訊息中的內容是什麼、是誰發送的、誰應接受並處理它以及如何處理它們。它透過定義SOAP信封（Envelop）來實現資料格式的標準化，將XML資料封裝於信封之中進行資訊交互，使得異構的系統間能夠進行互通。
Web Service 希望實現不同的系統之間能夠以“軟體-軟體對話”的方式相互調用，打破了軟體應用、網站和各種設備之間的格格不入的狀態，實現“基於Web無縫集成”的目標。
Web Service描述語言WSDL 就是用機器能閱讀的方式提供的一個正式描述文件而基於XML（標準通用標記語言下的一個子集）的語言，用於描述Web Service及其函數、參數和傳回值。因為是基於XML的，所以WSDL既是機器可閱讀的，也是人可閱讀的。
UDDI 的目的是為電子商務建立標準；UDDI是一套基於Web的、分散式的、為Web Service提供的、資訊註冊中心的實現標準規範，同時也包含一組使企業能將自身提供的Web Service註冊，以使別的企業能夠發現的存取協議的實現標準。
Web Service本身其實是在實作應用程式間的通訊。我們可以使用兩種方式來實現應用程式之間的通訊：遠端過程呼叫（RPC）和訊息傳遞。使用RPC的時候，客戶端的概念是呼叫伺服器上的遠端過程，通常方式為實例化一個遠端物件並呼叫其方法和屬性。 RPC系統試圖達到一種位置上的透明性：伺服器暴露出遠端物件的接口，而客戶端就好像在本地使用的這些物件的介面一樣，這樣就隱藏了底層的信息，客戶端也就根本不需要知道對像是在哪台機器上。
長項1：跨防火牆的通訊
如果應用程式有成千上萬的用戶，而且分佈在世界各地，那麼客戶端和伺服器之間的通訊將是一個棘手的問題。因為客戶端和伺服器之間通常會有防火牆或代理伺服器。在這種情況下，使用DCOM就不是那麼簡單，通常也不便於把客戶端程式發佈到數量如此龐大的每一個用戶手中。傳統的做法是，選擇用瀏覽器作為客戶端，寫下一大堆ASP頁面，把應用程式的中間層暴露給最終用戶。這樣做的結果是開發難度高，程式很難維護。
如果中間層元件換成WebService的話，就可以從使用者介面直接呼叫中間層元件，從而省掉建立ASP頁面的那一步。要呼叫WebService，可以直接使用MicrosoftSOAPToolkit或.NET這樣的SOAP客戶端，也可以使用自己開發的SOAP客戶端，然後把它和應用程式連接起來。不僅縮短了開發週期，還減少了程式碼複雜度，並能夠增強應用程式的可維護性。應用程式無需每次呼叫中間層元件時都導航到對應的「結果頁」。
企業級的應用程式開發者都知道，企業裡經常都要把用不同語言寫成的、在不同平台上運行的各種程式整合起來，而這種整合將花費很大的開發力量。應用程式經常需要從運行在IBM主機上的程式中取得資料；或把資料傳送到主機或UNIX應用程式中去。各種軟體通常需要在同一平台上集成，即使它們來自不同的軟體廠商。其他應用程式可以使用標準方法來存取透過WebService公開的功能和資料。
長項2：應用程式整合
企業級的應用程式開發者都知道，企業裡常常都要把用不同語言寫成的、在不同平台上運行的各種程式整合起來，而這種整合將花費很大的開發力量。應用程式經常需要從運行在IBM主機上的程式中取得資料；或把資料傳送到主機或UNIX應用程式中去。各種軟體通常需要在同一平台上集成，即使它們來自不同的軟體廠商。其他應用程式可以使用標準方法來存取透過WebService公開的功能和資料。
例如，有一個訂單登入程序，用於登入從客戶來的新訂單，包括客戶資訊、發貨地址、數量、價格和付款方式等內容；還有一個訂單執行程序，用於實際貨物發送的管理。這兩個程式來自不同軟體廠商。當有新訂單到達時，訂單登入程序將會通知訂單執行程序發送貨物。透過在訂單執行程序上面增加一層WebService，訂單執行程序可以把「AddOrder」函數「暴露」出來。這樣，每當有新訂單到來時，訂單登入程序就可以呼叫這個函數來發送貨物了。
長項3：B2B的整合
用WebService整合應用程序，可以讓公司內部的商務處理更加自動化。但當交易跨越供應商和客戶、突破公司的界線時會怎麼樣呢？跨公司的商務交易整合通常叫做B2B整合。
WebService是B2B整合成功的關鍵。透過WebService，公司可以把關鍵的商務應用程式「暴露」給指定的供應商和客戶。例如，把電子下單系統和電子發票系統「暴露」出來，客戶就可以以電子的方式發送訂單，供應商則可以以電子的方式發送原料採購發票。當然，這並不是新的概念，EDI(電子文檔交換)早就是這樣了。但是，WebService的實作要比EDI簡單得多，而且WebService運行在Internet上，在世界任何地方都可輕易實現，其運作成本就相對較低。不過，WebService並不像EDI那樣，是文件交換或B2B整合的完整解決方案。要實現集成，除了WebService，還需要許多其他組成部分。
用WebService來實現B2B整合的最大好處在於可以輕易實現互通性。只要把商務邏輯「揭露」出來，成為WebService，就可以讓任何指定的合作夥伴呼叫這些商務邏輯，而不管他們的系統在什麼平台上運行，使用什麼開發語言。這樣就大幅減少了花在B2B整合的時間和成本，讓許多原本無法承受EDI的中小企業也能實現B2B整合。
軟體與資料重複使用
"Software reuse is a significant topic with many forms and varying degrees of implementation."。最基本的形式是原始碼模組或類別一級的重用，另一種形式是二進位形式的元件重用。
目前，像是表格控制項或使用者介面控制項這樣的可重複使用軟體元件，在市場上都佔有很大的份額。重複使用這類軟體的限制非常大，因為它僅限於程式碼，而資料是不能重複使用的。原因在於，發布元件甚至原始碼都比較容易，但要發布資料就沒那麼容易，除非是不會經常變化的靜態資料。
重複使用程式碼的同時，webService也能夠重複使用資料背後的程式碼。使用WebService，再也不必像以前那樣，要先從第三方購買、安裝軟體元件，再從應用程式中呼叫這些元件；只需要直接呼叫遠端的WebService就可以了。舉個例子，要在應用程式中確認用戶輸入的地址，只需把這個地址直接發送給相應的WebService，這個WebService就會幫你查閱街道地址、城市、省區和郵政編碼等信息，確認這個地址是否在相應的郵遞區號區域。 WebService的提供者可以採用按時間或按使用次數的方式對該服務進行收費。這樣的服務要透過元件重用來實現是不可能的，那樣的話你必須下載並安裝好包含街道地址、城市、省區和郵遞區號等資訊的資料庫，而且這個資料庫還是不能即時更新的。
另一種軟體重用的情況是，把好幾個應用程式的功能整合起來。例如，要建立一個區域網路上的入口網站應用，讓使用者既可以查詢聯邦快遞包裹，查看股市行情，又可以管理自己的日程安排，還可以在線購買電影票。現在Web上有許多應用程式供應商，都在其應用中實現了這些功能。一旦他們把這些功能都透過WebService「暴露」出來，就可以非常容易地把所有這些功能都整合到你的入口網站中，為使用者提供一個統一的、友善的介面。
將來，許多應用程式都會利用WebService，把目前基於元件的應用程式結構擴展為元件/WebService的混合結構，可以在應用程式中使用第三方的WebService提供的功能，也可以把自己的應用程式功能透過WebService提供給別人。兩種情況下，都可以重複使用程式碼和程式碼背後的資料。
短處1：單機應用程式
目前，企業和個人也使用著許多桌面應用程式。其中一些只需要與本機上的其它程式通訊。在這種情況下，最好使用本機API，避免使用WebService。 COM非常適合在這種情況下工作，因為它既小又快。運行在同一台伺服器上的伺服器軟體也是這樣。最好直接用COM或其它本地的API來進行應用程式間的呼叫。雖然WebService也適用於這些情境，但這會消耗很多資源，並且不會有任何實質的收益。
短處2：區域網路的同構應用程式
在許多應用程式中，所有的程式都是用VB或VC開發的，都在windows平台下使用COM，都運行在同一個區域網路上。例如，有兩個伺服器應用程式需要相互通信，或有一個Win32或WinForm的客戶程式要連接區域網路上另一個伺服器的程式。在這些程式裡，使用DCOM會比SOAP/http有效得多。與此相類似，如果一個.NET程式要連接到區域網路上的另一個.NET程序，則應該使用.NETremoting。有趣的是，在.NETremoting中，也可以指定使用SOAP/http來進行WebService呼叫。不過最好還是直接透過TCP進行RPC調用，那樣會有效得多。
總之，只要從應用程式結構的角度來看，有別的方法比WebService更有效、更可行，那就不要用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、webservice工具類別
/**
* 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;
}
}以上是webservice怎麼實作springboot專案間接口呼叫與物件傳遞的詳細內容。更多資訊請關注PHP中文網其他相關文章！
