javascript
使用Spring Webservices构建SOAP Webservices代理模块
前一段時間，我想看看使用Spring Web Services編寫Web服務代理（wsproxy）有多么容易。 所以，我想我會在Github上分享結果。 可以隨意使用它 （Apache v2許可證）或將其用作自己開發的基礎。 本文的其余部分將解釋該思想，如何使用Spring Web服務構建它以及有關如何使用當前實現的簡短指南。
在此上下文中，wsproxy是中央肥皂感知訪問層，可在系統之間中繼消息。 這種中繼在兩個方向上起作用。 對于內部托管的服務（入站模式），對于外部托管的服務，我們都是客戶端（出站模式）。 可以將其與傳統的HTTP正向/反向代理進行比較，但它無需在應用程序傳輸上進行操作，而是在堆棧中上移了一層，處理應用程序消息。 在這種情況下，肥皂。
在出站模式下，我們的內部服務（通常）將wsproxy用作http轉發代理。 然后它將處理將收到的消息傳遞到實際目標。 對于入站模式，該模塊將充當反向代理，接受來自外部客戶端的傳入消息，并將其中繼到我們的內部服務。
在繼續之前，請先介紹一下正向/反向代理：
除了指定目標URL外，轉發代理是客戶端顯式配置的內容。 客戶端的http堆棧將消息發送到配置的代理，并通過http標頭（主機標頭）發送實際所需目標主機的主機/端口。 然后，代理將請求轉發到所需的目標主機/端口，并將響應返回給客戶端。 因此，代理從http Host標頭中組成目標URL的主機和端口。 對于路徑，它將使用從客戶端收到的請求中的路徑。 反向代理的行為（從客戶端的角度而言）是實際的目標服務器。 客戶端不知道任何代理，也不需要配置任何特殊的東西。 客戶端用作目標URL的是反向代理的URL。 反向代理將能夠攔截來自客戶端的消息，并將其轉發到網絡中的實際目標。 反向代理將需要額外的配置，例如目標服務的URL（主機，端口和可能的路徑），因為無法從請求或HTTP標頭中推斷出主機/端口。
使用此模塊時，仍然可以在邊界上實現實際的HTTP反向代理，以實現TLS卸載或其他傳輸目的。 對于外部入站流量（來自發往內部服務的外部客戶端的消息），wsproxy模塊將只是進入請求中的第二個反向代理。 對于內部出站流量（來自內部客戶端的消息，這些消息發往外部端點），http反向代理的URL將被配置為wsproxy模塊上該特定服務的目標URL。
具有這種肥皂感知性的wsproxy的特征之一是集中關注點。 目的是可以攔截通過的肥皂流量。 通過這種方式，我們可以實現諸如審核日志記錄，監視，訪問控制，消息安全性之類的功能……這樣，我們就可以創建一個集中的位置來處理這些需求，而不必針對每個應用程序重新實現它們。
我之所以選擇Spring Web服務，是因為沒有復雜的基礎架構或設計需要理解。 它也非常可擴展，并且可以根據我們的要求在適當的級別上重復使用。
但是，此時我還應該指出，現有的解決方案也可以做到這一點，甚至更多。 它們通常以xml安全網關的名義出現，并以軟件包或功能齊全的設備的形式出現。 與往常一樣，與自己編寫某些東西相比，您應該超過這些現有解決方案的好處。 事實是，它們不是免費提供的（至少可以說），并且您仍然需要具有正確技能的人員來配置和維護它們。 正如我們將看到的，只需一點代碼（并在Spring Web Services的幫助下）即可輕松滿足我們的要求，從而為我們提供所需的所有控制。
對于這些要求，我考慮到了以下開箱即用的要求，因此很容易擴展設計：
- 對于標準用法，出站模式需要免費配置。 這意味著當需要訪問新的外部服務時，我們的代理應該中繼消息而無需進行額外的配置
- 通過網關的消息需要記錄。 如果沒有額外的配置，則默認情況下應記錄整個消息。 （可選）我們需要能夠配置更細粒度的特定服務需要記錄的部分
- 對于（主要是外部）出站通信，我們應該能夠配置正向代理或使用預先配置的主機（現有的反向代理或實際端點）覆蓋目標
- 萬一沒有用于卸載出站安全傳輸的外部反向代理，該模塊必須能夠通過安全傳輸轉發消息。 對于入站安全傳輸，我們將通過運行模塊的容器來處理此問題。 所以這超出了模塊的范圍
- 能夠應用和處理消息的完整性/機密性
組件設計如下所示：
有3個主要組成部分。 終結點 （圖中的全部終結點），它將充當發送到wsproxy的消息的接收者。 轉發器 ，它將轉發消息到目標。 最后，攔截器鏈是掛鉤，我們可以在其中攔截發送/接收的消息并對其進行處理。
這3個組件由Spring Web Services提供。 終點是實現org.springframework.ws.server.endpoint.MessageEndpoint能夠接收原始有效載荷的org.springframework.ws.server.endpoint.annotation.Endpoint。 轉發器使用org.springframework.ws.client.core.WebServiceTemplate ，攔截器鏈是org.springframework.ws.client.support.interceptor.ClientInterceptor和/或org.springframework.ws.server.EndpointInterceptor，具體取決于它們需要哪一邊發揮作用（稍后再介紹）。 為了消息安全，我們將使用WSS4J，但這只是攔截器的實現，因此不是新組件。
重要的是要意識到有兩個攔截器鏈。 從wsproxy的角度來看，我們將第一個稱為“入站鏈”。 這是在客戶端和wsproxy之間進行的操作。 “出站鏈”是在wsproxy和目標端點之間運行的鏈。 因此，如果我們有一個內部客戶端通過wsproxy訪問外部端點，則wsproxy收到消息后，將調用入站鏈。 從wsproxy將消息中繼到目標端點的那一刻起，將調用出站鏈。 Spring有兩個接口來區分攔截器在哪個“側面”上運行（攔截器還可以實現兩個接口，從而使其能夠在兩個側面上都起作用）。 org.springframework.ws.server.EndpointInterceptor在端點側運行，對于wsproxy而言是入站的。 org.springframework.ws.client.support.interceptor.ClientInterceptor在客戶端運行，因此對于wsproxy來說是出站的。 順便說一句; 我們使用入站和出站，而不是原始的Spring命名（客戶端/端點），以避免混淆。 正如您現在所注意到的，wsproxy也是端點和客戶端。 但是，當我們提到“客戶端”時，是指實際的服務客戶端，而“端點”是實際的目標服務。
該模塊本身將作為典型的Spring應用程序在標準JEE servlet容器上運行。 對于所有入站流量，都使用容器中的http（或https）連接器。 對于所有出站流量，使用WebServiceTemplate并在其內部配置了commons httpclient，如果需要，我們可以將其同時用于http和https。 服務識別以“ doclit”樣式完成。 這意味著我們采用主體的第一個元素，包括其名稱空間。 這表示為QName 。 此標識非常重要，因為我們將基于每個服務進行配置，例如轉發代理，轉發協議，端點URL映射，特定記錄器等。
夠了。 讓我們帶這個寶貝去兜風吧！ 在您選擇的IDE中導入項目，請確保將其導入為Maven項目，因為Maven必須過濾文件active_environment.properties （通過默認配置文件自動完成）。 然后，我們將：
- 設置一個基于普通獨立肥皂的端點
- 部署wsproxy
- 使用Web服務客戶端通過代理模塊訪問端點
為了引導簡單端點，在測試源中預見到一個類SimpleEndpoint ，該類使用JDK內部JAX-WS和http服務器來引導Web服務端點：
public class SimpleEndpoint {public static void main(String args[]) {Endpoint.publish("http://localhost:9999/simple", new SimpleWebServiceEndpoint());}@WebServicepublic static class SimpleWebServiceEndpoint {public Date getCurrentDate(String randomParameter) {return new Date();}} }只需將其作為新的Java應用程序運行，它將一直運行，直到進程被殺死。 通過將項目部署到您選擇的服務器（我將使用Tomcat7）來啟動wsproxy，不需要任何額外的配置。 對于客戶端，我們將使用soap-ui（如果愿意，也可以使用cURL）。 在soap-ui中，我們首先必須創建項目。 我們基于測試服務公開的WSDL（可從http：// localhost：9999 / simple？WSDL訪問）進行此操作。 接下來，我們必須將wsproxy模塊配置為soap-ui中的HTTP轉發代理：
如果需要， 在項目中也可以使用soap-ui項目。 別忘了啟用上述代理設置，它們不會保存為項目的一部分。
重要提示：如果您要開始一個新項目，請不要忘記再次禁用代理設置。 soap-ui將使用代理設置來處理標準的http流量，而不僅用于soap / http。 例如; 當基于WSDL URL創建新項目時，soap-ui還將使用http代理設置來檢索WSDL。 由于wsproxy模塊不是純HTTP代理（而是肥皂代理），因此它將不允許非肥皂流量通過。
我們需要配置的最后一件事是soap-ui中的目標URL。 默認情況下（至少在tomcat上）部署wsproxy模塊，該上下文根以文件名命名。 在我們的情況下，這意味著該模塊在以下位置可訪問：http：// localhost：8080 / ws-proxy /
有兩種選擇：
- 而是將模塊部署在應用程序服務器（/）的根目錄下。 在這種情況下，無需將任何內容更改為目標URL。 目標網址將與沒有代理模塊時將使用的網址相同
- 使用選擇的上下文根，但是在這種情況下，您必須在上下文根之前添加目標URL
在第二種情況下，這意味著我們必須將建議的目標URL從“ http：// localhost：9999 / simple”更改為“ http：// localhost：9999 / ws-proxy / simple ”。
發生的是soap-ui將請求發送到代理設置中指定的主機/端口（因此，它不會將請求發送到localhost：9999，而是發送到localhost：8080）。 但是，路徑保留了下來。 該請求實際上通過路徑“ ws-proxy / simple”發送到localhost：8080。 通過將模塊部署在“ ws-proxy”下，您現在可以了解為什么必須在此路徑前綴。 如果路徑以“ simple”開頭，則將得到404。路徑的其余部分對于基礎結構并不重要，因為Spring調度程序servlet（配置可以在WsProxyWebApplicationInitializer中找到）綁定到“ / *”。 因此，每種情況下，servlet都會處理每個后續路徑。
為了能夠將消息轉發到實際目標，模塊將計算目標URL：
- 首先根據服務標識（有效負載根元素+名稱空間）檢查給定端點是否有預先配置的目標URL。 這是在EndpointTargetUrlMapping中配置的，我們將在后面看到。
- 如果未找到任何內容，請檢查是否存在http Host標頭，并將host：port用作目標服務器。 對于路徑，請使用請求中存在的路徑，但減去在其中部署此模塊的上下文根（如果有）
后者意味著在我們的示例中，模塊部署在“ ws-proxy”下，請求路徑為“ ws-proxy / simple”，這將導致目標URL為“ http：// localhost：999 / simple”。執行請求，我們將得到以下答案：
在wsproxy日志文件中，我們可以看到截獲的請求和響應正在記錄：
51948 [http-bio-8080-exec-5] DEBUG be.error.wsproxy.interceptors.internalchain.LoggingInterceptor - SID:{http://wsproxy.error.be/}getCurrentDate INBOUND SIDE Request:<?xml version="1.0" encoding="UTF-8" standalone="no"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsp="http://wsproxy.error.be/"><soapenv:Header/><soapenv:Body><wsp:getCurrentDate><!--Optional:--><arg0>?</arg0></wsp:getCurrentDate></soapenv:Body> </soapenv:Envelope>51949 [http-bio-8080-exec-5] DEBUG be.error.wsproxy.core.ForwardingClient - Using information from Host header as hostname/port 51949 [http-bio-8080-exec-5] DEBUG be.error.wsproxy.core.ForwardingClient - Got webservice forwarding request, sending to:http://localhost:9999/simple 51981 [http-bio-8080-exec-5] DEBUG be.error.wsproxy.core.ForwardingClient - Using interceptors:[class be.error.wsproxy.interceptors.externalchain.HttpRequestHeaderTransfererInterceptor] 51981 [http-bio-8080-exec-5] DEBUG be.error.wsproxy.core.ForwardingClient$3 - Opening [org.springframework.ws.transport.http.HttpComponentsConnection@1dd5e19a] to [http://localhost:9999/simple] 51991 [http-bio-8080-exec-5] DEBUG be.error.wsproxy.core.ForwardingClient - Forwarding (http://localhost:9999/simple) done. 51994 [http-bio-8080-exec-5] DEBUG be.error.wsproxy.interceptors.internalchain.LoggingInterceptor - SID:{http://wsproxy.error.be/}getCurrentDate INBOUND SIDE Response:<?xml version="1.0" encoding="UTF-8" standalone="no"?> <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"><S:Body><ns2:getCurrentDateResponse xmlns:ns2="http://wsproxy.error.be/"><return>2013-10-28T15:55:29.717+01:00</return></ns2:getCurrentDateResponse></S:Body> </S:Envelope>在默認設置中，默認日志記錄發生在入站側。 入站攔截器在這里配置：
@Configuration public class InboundInterceptors {@Autowiredprivate PayloadRootAnnotationMethodEndpointMapping catchAllEndpointMapping;@Autowiredprivate MessageDispatcher messageDispatcher;@Configurationpublic static class FirstInlineInterceptors {@Beanpublic DelegatingSmartSoapEndpointInterceptor loggingInterceptor() {return new DelegatingSmartSoapEndpointInterceptor(new LoggingInterceptor());}}@Configurationpublic static class ServiceSpecificInterceptors {}@Configurationpublic static class LastInLineInterceptors {} } 如果要在出站側也配置此日志記錄攔截器，則可以將它們添加到OutboundInterceptors中 。 LoggingInterceptor都實現EndpointInterceptor和ClientInterceptor 。 為了滿足我們的要求，還有一個攔截器，該攔截器能夠基于XPath表達式記錄片段。 LoggingXPathInterceptor是特定于服務的，因此，我們會將其添加到ServiceSpecificInterceptor中。 不同之處在于，特定于服務的攔截器使用PayloadRootSmartSoapEndpointInterceptor ，我們需要提供命名空間和有效負載根元素來標識服務。 配置的攔截器將僅針對該服務被調用。 首次使用和最后使用
DelegatingSmartSoapEndpointInterceptor ，將為任何請求調用。
當我們在soap-ui中再次執行請求時，我們可以看到將請求參數和響應值提取到日志文件中：
DEBUG be.error.wsproxy.interceptors.internalchain.LoggingXPathInterceptor - SID:{http://wsproxy.error.be/}getCurrentDate XPATHID:requestParameter VALUE:? DEBUG be.error.wsproxy.interceptors.internalchain.LoggingXPathInterceptor - SID:{http://wsproxy.error.be/}getCurrentDate XPATHID:responseParameter VALUE:2013-10-28T16:50:29.537+01:00WebServiceMessageXPathExpressionMetaData默認情況下在肥皂主體（有效負載）上運行，并將給定的XPath視為強制性（但非阻塞性）。 要查看其他選項，請檢查WebServiceMessageXPathExpressionMetaData上的javadoc。
可以配置的屬性位于包be.error.wsproxy.configuration.properties中 。 存在以下類：
- 端點協議映射
- EndpointTargetUrlMapping
- 轉發代理
- 密鑰庫
通過默認的Maven過濾器Maven啟用的默認Spring配置文件“本地”將通過以下屬性文件解析它們：
wsproxy_local_demo.properties 。 配置始終存儲為簡單的字符串，以便在例如JNDI環境中輕松進行外部化。 從EndpointProtocolMapping開始，前三個屬性確定如何轉發消息：
在上述情況下，由于我們的內部客戶端將模塊用作轉發代理，因此從Host參數自動推導出了目標URL。 由于主機參數不包含有關協議的任何概念，因此默認情況下，wsproxy會將http假定為轉發協議。 如果沒有負責減輕TLS負擔的反向代理，則可以要求代理模塊通過https轉發。 您可以通過將特定服務的協議映射設置為https來做到這一點：
endpoint.protocol.mapping={namespace}payloadRootElementLocalName=https,...EndpointTargetUrlMapping允許直接定義目標URL。 在外部客戶端將訪問我們的內部服務的情況下，這是必需的。 在這種情況下，無法再推導目標URL。 外部客戶端將不會使用我們的模塊作為轉發代理，但是該消息只會作為實際服務最終出現在我們的模塊上。 然后，模塊需要知道將消息轉發到的位置：
endpoint.target.url.mapping={namespace}payloadRootElementLocalName=http(s)://host:port/path,....這也可以用于一起覆蓋目標URL。 轉發器將首先查看是否有為給定服務定義的顯式URL，如果是，則將為該URL賦予優先級。
當wsproxy模塊需要通過http轉發代理進行通信才能到達目標時，可以配置ForwardProxy。 也可以基于每個服務進行配置。
請記住，前向代理不會改變目標URL的計算方式。 如果使用該設置，則消息將轉發到已配置的代理，而不是直接訪問目標URL：
密鑰庫指向包含商店位置，商店密碼，密鑰別名和密鑰密碼的密鑰庫配置。 當我們要應用消息安全性時將使用它們，我們將在后面討論。
keystores.location=${project.root.dir}/config/test-keystores keystore=${keystores.location}/keystore.jks keystore.password=changeme key.alias=mykey key.password=changeme truststore=${keystores.location}/truststore.jks truststore.password=changeme為了滿足最后一個要求（完整性/機密性），我們將通過Spring Wss4jSecurityInterceptor使用WSS4J。 在我們的示例中，如果我們有內部客戶端訪問外部服務，則需要在出站側配置此攔截器。 我們將執行的步驟：
- 設置安全的基于獨立Soap的端點
- 為給定服務配置具有消息安全性的wsproxy
- 部署wsproxy
- 使用Web服務客戶端通過代理模塊訪問端點
對于安全端點，可以使用JAXWS和WSIT預測SimpleSecuredEndpoint 。 可以在META-INF / wsit-be.error.wsproxy.SimpleSecuredEndpoint $ SimpleWebServiceEndpoint.xml中找到WSIT配置，以在端點上啟用消息完整性。
public class SimpleSecuredEndpoint {public static void main(String args[]) throws IOException {// Set WSIT_HOME manually, we're only using this for testing purposes. This way we can have a dynamic path based// on the project location in filesystem to resolve the keystores via the WSIT configuratin in META-INFSystem.setProperty("WSIT_HOME", new ClassPathResource("").getFile().getParent() + "/../config/test-keystores/");Endpoint.publish("http://localhost:9999/simple", new SimpleWebServiceEndpoint());}@WebService(serviceName = "SimpleEndpoint")@Addressing(enabled = false, required = false)public static class SimpleWebServiceEndpoint {public Date getCurrentDateSecured(String randomParameter) {return new Date();}} }重要： JDK附帶的JAXWS實現不包含WSIT。 它只是JAXWS RI。 為了使它起作用，您必須自己下載最新的Metro版本，它將所有內容捆綁在一起。 參見Metro主頁 。 下載Metro后，運行SimpleSecuredEndpoint并附帶已認可的系統屬性： -Djava.endorsed.dirs = / path_to_metro / lib 。 這將確保從外部庫中使用整個JAXWS實現。 當一切運行正常時，您會看到一條線：
INFO: WSP5018: Loaded WSIT configuration from file: file:/home/koen/.... 。
WSS4J攔截器的配置可在OutboundInterceptors中實現消息完整性：
在第6行和第7行，我們將自定義攔截器添加到ForwardingClient使用的攔截器列表中。 我們還在出站上添加了LoggingInterceptor，以便可以看到受保護的消息傳出和傳入。要測試消息安全配置，請部署wsproxy并使用soap-ui觸發請求。 soap-ui設置與非安全端點的設置沒有什么不同。
重要提示： C14N似乎有問題。 當請求正常發送時，WSIT將抱怨計算的摘要與消息中的摘要不匹配。 我將對此進行進一步調查，但這似乎是WSIT而不是WSS4J的問題，因為當soap-ui配置為安全客戶端并直接與端點進行通信而不是使用wsproxy模塊時，也會發生相同的問題。 要解決此問題并查看測試工作，請刪除soap Body起始元素和有效負載根起始元素之間的換行。 還要刪除皂體末端元素和有效負載根末端元素之間的換行符：
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsp="http://wsproxy.error.be/"><soapenv:Header/><soapenv:Body><wsp:getCurrentDateSecured><!--Optional:--><arg0>?</arg0></wsp:getCurrentDateSecured></soapenv:Body> </soapenv:Envelope>如果需要， 在項目中也可以使用soap-ui項目。 別忘了啟用代理設置，如前所述，它們不會保存為項目的一部分。
結果：
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:exc14n="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:xs="http://www.w3.org/2001/XMLSchema"><S:Header/><S:Body wsu:Id="_5002"><ns2:getCurrentDateSecuredResponse xmlns:ns2="http://wsproxy.error.be/"><return>2013-10-29T14:26:25.789+01:00</return></ns2:getCurrentDateSecuredResponse></S:Body> </S:Envelope>wsproxy在轉發請求時增加了消息安全性，而在返回響應時將其刪除了，這并不奇怪。 如果我們查看wsproxy日志文件，首先將看到在inboud端輸入的請求：
34 [http-bio-8080-exec-3] DEBUG be.error.wsproxy.interceptors.logging.LoggingInterceptor - SID:{http://wsproxy.error.be/}getCurrentDate INBOUND SIDE Request:<?xml version="1.0" encoding="UTF-8" standalone="no"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsp="http://wsproxy.error.be/"><soapenv:Header/><soapenv:Body><wsp:getCurrentDateSecured><!--Optional:--><arg0>?</arg0></wsp:getCurrentDateSecured></soapenv:Body> </soapenv:Envelope>該請求被保護并轉發到端點：
394 [http-bio-8080-exec-3] DEBUG be.error.wsproxy.interceptors.logging.LoggingInterceptor - SID:{http://wsproxy.error.be/}getCurrentDate OUTBOUND SIDE Request:<?xml version="1.0" encoding="UTF-8" standalone="no"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsp="http://wsproxy.error.be/"><soapenv:Header><wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" soapenv:mustUnderstand="1"><wsu:Timestamp wsu:Id="TS-518848887F924441AB13830540361321"><wsu:Created>2013-10-29T13:40:36.130Z</wsu:Created><wsu:Expires>2013-10-29T13:45:36.130Z</wsu:Expires></wsu:Timestamp><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="SIG-518848887F924441AB13830540361916"><ds:SignedInfo> ...從端點接收到安全響應；
524 [http-bio-8080-exec-3] DEBUG be.error.wsproxy.interceptors.logging.LoggingInterceptor - SID:{http://wsproxy.error.be/}getCurrentDate OUTBOUND SIDE Response:<?xml version="1.0" encoding="UTF-8" standalone="no"?> <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:exc14n="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:xs="http://www.w3.org/2001/XMLSchema"><S:Header><wsse:Security S:mustUnderstand="1"><wsu:Timestamp xmlns:ns15="http://www.w3.org/2003/05/soap-envelope" xmlns:ns16="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512" wsu:Id="_3"><wsu:Created>2013-10-29T13:40:36Z</wsu:Created><wsu:Expires>2013-10-29T13:45:36Z</wsu:Expires></wsu:Timestamp><ds:Signature xmlns:ns15="http://www.w3.org/2003/05/soap-envelope" xmlns:ns16="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512" Id="_1"><ds:SignedInfo> ...安全信息得到處理和驗證。 如果可以，則剝離安全信息并返回響應（在這種情況下，返回給我們的客戶端soap-ui）：
567 [http-bio-8080-exec-3] DEBUG be.error.wsproxy.interceptors.logging.LoggingInterceptor - SID:{http://wsproxy.error.be/}getCurrentDate INBOUND SIDE Response:<?xml version="1.0" encoding="UTF-8" standalone="no"?> <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:exc14n="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" xmlns:xs="http://www.w3.org/2001/XMLSchema"><S:Header/><S:Body wsu:Id="_5002"><ns2:getCurrentDateSecuredResponse xmlns:ns2="http://wsproxy.error.be/"><return>2013-10-29T14:40:36.357+01:00</return></ns2:getCurrentDateSecuredResponse></S:Body> </S:Envelope>到目前為止，已經完成了所有模擬內部客戶端訪問外部服務的測試。 如果您想使用模塊做逆運算； 服務外部客戶端訪問內部托管的服務，情況更多。 對于模塊將轉發到的每個內部托管服務，您必須使用endpoint.target.url.mapping配置參數注冊目標URL。 攔截器繼續以相同的方式工作，但是請記住，例如，出于消息安全性，您可能希望在入站側配置Wss4jSecurityInterceptor，因為在這種情況下，入站側是面向外部的一側。 在入站和出站側為不同的服務配置Wss4jSecurityInterceptor沒問題； 所有配置均基于每個服務。
例如：服務x（由名稱空間和有效負載根元素標識）是內部托管服務。 服務y是內部客戶端要訪問的外部服務。 為了保護內部服務x，我們將在InboundInterceptors配置中添加Wss4jSecurityInterceptor作為服務特定的入站攔截器。 因此，此攔截器將僅在wsproxy端點上處于活動狀態（僅服務于入站側，在此示例中為面向外部的側），并且僅對于服務x有效。 為了保護對服務y的調用，我們將在OutboundInterceptors中注冊Wss4jSecurityInterceptor，為wsproxy模塊發送到外部服務y的消息增加消息安全性。
好的，就是這樣！ 如果這對您有用，或者您有改進的想法，請隨時給我留言。
翻譯自: https://www.javacodegeeks.com/2013/11/building-a-soap-webservices-proxy-module-using-spring-webservices.html
總結
以上是生活随笔為你收集整理的使用Spring Webservices构建SOAP Webservices代理模块的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 基于注释的Spring MVC Web应
- 下一篇： 编程linux系统哪个版本好（编程lin