⑴ WebService新手，請教WebService需要什麼包
webservice只是一套規范，你需要使用一個具體的框架：如 axis或者xfire，那麼你就知道你到底需要哪些包了。
你當前的問題是，少了mail.jar包。
這個包默認就包含在axis2中，但不是必須的，估計你的例子中調用到了這個包。
這個包和任何一個框架都沒有關系。
⑵ webservice有哪些框架
開發Web Service的幾個框架，分別為Axis，axis2，Xfire，CXF以及JWS。
XFire是與Axis2 並列的新一代WebService平台。他們有如下優點：
1、支持一系列Web Service的新標准--JSR181、WSDL2.0 、JAXB2、WS-Security等；
2、使用Stax解釋XML,性能有了質的提高。XFire採用Woodstox 作Stax實現；
3、容易上手，可以方便快速地從pojo發布服務；
4、Spring的結合；
5、靈活的Binding機制，包括默認的Aegis,xmlbeans,jaxb2,castor。
⑶ 如何使用Struts2框架發布webService
使用Struts2框架創建一個web工程，引入webservice所需的jar包，我用的是cxf的jar包，
關於Struts2和webService的整合核心是對於StrutsPrepareAndExecuteFilter這個類的修改，使訪問webservice的地址能夠繼續訪問servlet.
web.xml的修改。
<filter>
<filter-name>struts2</filter-name>
<filter-class>com.synjones.filter.ExtendStrutsFilter</filter-class>
</filter
<filter-mapping>
<filter-name>struts2</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<servlet>
<servlet-name>CXF</servlet-name>
<servlet-class>org.apache.cxf.transport.servlet.CXFServlet</servlet-class
</servlet>
<servlet-mapping
<servlet-name>CXF</servlet-name>
<url-pattern>/ws/*</url-pattern>
</servlet-mapping>
自定義過濾器StrutsPrepareAndExecuteFilter
import java.io.IOException;
import javax.servlet.FilterChain;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.http.HttpServletRequest;
import org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter;
public
class ExtendStrutsFilter extends StrutsPrepareAndExecuteFilter{
public void doFilter(ServletRequest req, ServletResponse res,FilterChain
chain) throws IOException, ServletException {
HttpServletRequest request = (HttpServletRequest) req; //不過濾的url,可以自行添加
if (request.getRequestURI().contains("/ws")) {
//System.out.println("使用自定義的過濾器");
chain.doFilter(req, res);
}else{
//System.out.println("使用默認的過濾器");
super.doFilter(request, res, chain);
}
}
}
其它的設置按照正常的webservice配置
⑷ java來做Web Service，用哪個框架最好
正好現在在學webService.可以共同進步啊
Web Services 框架如 Axis2、CXF 都是由現有的項目中逐漸演化而來的，Axis2 是由 Axis 1.x 系列演化過來，而 Apache CXF 則是由 Celtix 和 XFire 項目整合而生，並且剛剛發布了 2.0.2 的最新版本，不過仍是 Apache 的一個孵化項目。
Axis2 是對 Axis 進行了徹底的重寫的一個新項目了，它使用了新的模塊化架構，更方便於功能性的擴展等等。
Apache CXF 則是由 XFire 和 Celtix 兩個現有的項目進行了重組。
先比較一下它們的不同之處：
1、Apache CXF 支持 WS-Addressing、WS-Policy、WS-RM、WS-Security和WS-I BasicProfile
2、Axis2 支持 WS-Addressing、WS-RM、WS-Security和WS-I BasicProfile，WS-Policy將在新版本里得到支持
3、Apache CXF 是根據Spring哲學來進行編寫的，即可以無縫地與Spring進行整合
4、Axis2 不是
5、Axis2 支持更多的 data bindings，包括 XMLBeans、JiBX、JaxMe 和 JaxBRI，以及它原生的 data binding（ADB）。
6、Apache CXF 目前僅支持 JAXB 和 Aegis，並且默認是 JAXB 2.0，與 XFire 默認是支持 Aegis 不同，XMLBeans、JiBX 和 Castor 將在 CXF 2.1 版本中得到支持，目前版本是 2.0.2
7、Axis2 支持多種語言，它有 C/C++ 版本。
8、Apache CXF 提供方便的Spring整合方法，可以通過註解、Spring標簽式配置來暴露Web Services和消費Web Services
如何抉擇：
1、如果應用程序需要多語言的支持，Axis2 應當是首選了；
2、如果應用程序是遵循 Spring 哲學路線的話，Apache CXF 是一種更好的選擇，特別對嵌入式的 Web Services 來說；
3、如果應用程序沒有新的特性需要的話，就仍是用原來項目所用的框架，比如 Axis1，XFire，Celtrix 或 BEA 等等廠家自己的 Web Services 實現，就別勞民傷財了
因為CXF可以和Spring無縫的進行結合，而我的項目用到了spring ,所以我選的是CXF
⑸ web框架和apache的區別
現在流行webservice框架主要是Apache Axis2和Apache CXF。
Apache CXF是Codehaus XFire 的第二代產品，目前在不同框架中性能最佳，應該是開發者不錯的選擇，這與它本身的架構設計不無關系。相比其他框架，CXF具有幾個突出的特性：支持JAX-WS、Spring集成、Aegi數據綁定、支持RESTful services、支持WS-*、Apache協議、代碼實現簡潔。Apache Axis2是Apache Axis1的第二代產品，架構上也非常不錯，關鍵特性：支持各種規范、可插拔模塊化設計、支持熱部署等。與CXF相比性能也非常優異。
在服務端框架確定的場景下，最好是採用該框架生成客戶端代碼，這樣配合性能可達到更佳。在實際的項目中，開發者在選擇具體那個框架時，仍還需綜合評估框架的開發組織、產品路線圖、文檔化程度、應用廣泛度、與優異框架的集成度、靈活和擴展性等因素。
在具體項目的實現中，以前項目中用Axis2覺得不錯，但是在不同的項目中CXF又支持的比較好，所以這個還要看項目了。各有優點吧！（找到適合自己的，才是最好的）
⑹ grails框架配置webService
近期在項目中使用到了grails的webservice發布，總結如下：
一、axis2的配置
1、安裝axis2插件
命令：install-plugin axis2
2、服務類的使用
新建一個service，然後在服務類中加入下面一句就ok了
static expose=['axis2']
3、測試一下
try {
// 調用webservice傳遞數據,部分參數固化
RPCAxis rpcaxis = new RPCAxis();
String srvcUrl =" http://127.0.0.1:8080/gidms_sd/services/transfer ";
String namespace = " http://item.gidms.proct.lhcis.com ";
} catch (Exception e) {
e.printStackTrace();
return "exception";
}
rpcaxis類中的RPC4Axis2WithReturn方法如下：
public String RPC4Axis2WithReturn(String srvcUrl, String namespace,
String operation, String value) throws AxisFault {
// 操作的命名空間+操作名
QName qname = new QName(namespace, operation); // namespace與wsdl中的targetNamespace對應"
// 傳遞的參數對象集
Object param[] = new Object[] { value };
// 實例化遠程服務調用客戶端對象
RPCServiceClient client = new RPCServiceClient();
// 實例化Options對象
Options options = new Options();
// 設置Options對象的連接終端地址
options.setTo(new EndpointReference(srvcUrl));
// 設置Options對象的操作事件對象
options.setAction(operation);
//為了解決大訪問量超時問題
options.setTimeOutInMilliSeconds(600000L);
// 為遠程服務調用客戶端對象設置Options子對象
client.setOptions(options);
// 傳遞參數,調用服務,獲得返回值
Object[] result = client.invokeBlocking(qname, param,new Class[] { String.class });
// 清除
client.cleanupTransport();
return result[0].toString();
}
在打包過程中報一個錯誤：
[] Warning: C:\Users\Lenovo.grails\1.3.5\projects\utm-ncm\plugins\axis2-0.6.1\lib not found
導致這個問題的原因是，插件中一個指定打包地址填寫錯誤。修改插件中一個文件
C:\Users\當前用戶名.grails\1.3.5\projects\utm-ncm\plugins\axis2-0.7.0\scripts_Events.groovy
用記事本或其他文本編輯啊工具打開，將文件里0.6.1改為0.7.0，重新打包就可以。
原文
eventWarStart = { msg ->
}
修改後：
eventWarStart = { msg ->
}
⑺ webservice,soap,rest,wsdl,cxf等的關系是什麼
webservice是一種標准，他可以通過soap或rest的方式來實現。
其中SOAP是基於xml的交互，而rest是基於http協議的交互。
wsdl是webservice的描述語言，描述服務是怎麼回事，怎麼調用。
cxf是rest實現webservice的Apache框架，是對rest進行了封裝
⑻ 初步理解一下：SOA, SOAP, Web Service, WSDL等
什麼是SOA、SOAP?
SOA到底是什麼？
SOA（Service-Oriented Architecture）的定義是面向服務的架構，就是說將軟體按照功能設計成一個個服務，這些服務用標準的方式定義介面、並通過標準的協議進行調用。 SOA所定義的介面和調用方式是獨立於編程語言和運行平台的，廣義上講SOA可以基於不同的底層技術實現，比如CORBA和Web Services。但CORBA由於過於復雜和臃腫已很少使用，所以目前所說的SOA絕大多數是基於Web Services技術實現。在Web Services的實現方式下，SOA服務的介面用XML進行定義。
在SOA架構下，軟體開發從業務流程分析開始，使用組件化業務建模的方法識別和分析各種業務模型，將各種實踐融入其中，在這個基礎上建立用例，用例直接產 生BPEL，這些BPEL則可以被融入一個服務整合框架中，其描述了各種服務的信息，從而把ESB上的各個模塊統一起來，形成一個巨大的服務倉。
將中間層再進行抽離，在中間層作一個跨技術架構的元數據和業務邏輯，使之成為跨技術架構的、可長期繼承、並不斷積累的企業業務庫和最寶貴的信息資產，也就 是面向服務的組件庫，而且這個服務組件庫也可以被其它企業復用，且不依賴於任何一種技術架構。誇張一點說，如果所有軟體企業都使用SOA架構，那麼世界軟 件業將會發生徹底的改變。顯然，這樣一個框架不是一種產品，也不僅僅是一種技術，而是一種解決問題的方法論。
SOA可能應用於兩個場景：第一種是業務互通互聯；第二種是封閉交易系統，即將元數據和業務邏輯抽離，形成可復用。舉個例子，在第一種場景中，當不同企業 之間的業務需要相互調用，這時就可能採用SOA技術；在第二種場景中，在企業內部需要將系統進行遷移時，利用SOA技術定義的原有數據和業務流程，可以很 快完成。
SOA並不是一個新事物，IT組織已經成功建立並實施SOA應用軟體很多年了，BEA、IBM、等廠商看到了它的價值，紛紛跟進。SOA的目標在於讓IT 變得更有彈性，以更快地響應業務單位的需求，實現實時企業（Real-Time Enterprise，這是Gartner為SOA描述的願景目標）。而BEA的CIO Rhonda早在2001年6月就提出要將BEA的IT基礎架構轉變為SOA，並且從對整個企業架構的控制能力、提升開發效率、加快開發速度、降低在客戶 化和人員技能的投入等方面取得了不錯的成績。
SOA是在計算環境下設計、開發、應用、管理分散的邏輯（服務）單元的一種規范。這個定義決定了SOA的廣泛性。SOA要求開發者從服務集成的角度來設計 應用軟體，即使這么做的利益不會馬上顯現。SOA要求開發者超越應用軟體來思考，並考慮復用現有的服務，或者檢查如何讓服務被重復利用。SOA鼓勵使用可 替代的技術和方法（例如消息機制），通過把服務聯系在一起而非編寫新代碼來構架應用。經過適當構架後，這種消息機制的應用允許公司僅通過調整原有服務模式 而非被迫進行大規模新的應用代碼的開發，使得在商業環境許可的時間內對變化的市場條件做出快速的響應。
SOA也不僅僅是一種開發的方法論--它還包含管理。例如，應用SOA後，管理者可以方便的管理這些搭建在服務平台上的企業應用，而不是管理單一的應用模 塊。其原理是，通過分析服務之間的相互調用，SOA使得公司管理人員方便的拿到什麼時候、什麼原因、哪些商業邏輯被執行的數據信息，這樣就幫助了企業管理 人員或應用架構師迭代地優化他們的企業業務流程、應用系統。
SOA的一個中心思想就是使得企業應用擺脫面向技術的解決方案的束縛，輕松應對企業商業服務變化、發展的需要。企業環境中單個應用程序是無法包容業務用戶 的（各種）需求的，即使是一個大型的ERP解決方案，仍然不能滿足這個需求在不斷膨脹、變化的缺口，對市場快速做出反應，商業用戶只能通過不斷開發新應 用、擴展現有應用程序來艱難的支撐其現有的業務需求。通過將注意力放在服務上，應用程序能夠集中起來提供更加豐富、目的性更強的商業流程。其結果就是，基 於SOA的企業應用系統通常會更加真實地反映出與業務模型的結合。服務是從業務流程的角度來看待技術的--這是從上向下看的。這種角度同一般的從可用技術 所驅動的商業視角是相反的。服務的優勢很清楚：它們會同業務流程結合在一起，因此能夠更加精確地表示業務模型、更好地支持業務流程。相反我們可以看到以應 用程序為中心的企業應用模型迫使業務用戶將其能力局限為應用程序的能力。
企業流程（enterprise process）是流經企業框架的空氣，它賦予業務模型里的組件以生命，並更加清晰地定義了它們之間的關系。流程定義了同業務模型進行交互操作的專門方 法。例如，會計可能是企業服務系統的一個組件--但是將發票寄給客戶卻是一個業務流程。服務被定義用來支持業務流程，因而貫穿整個流程始終的是：各種服務 組件在流程和邏輯實現過程中的裝配操作。理解業務流程是定製服務的關鍵所在。
有利於企業業務的集成傳統的應用集成方法（點對點集成、企業消息匯流排或中間件的集成（EAI）、基於業務流程的集成）都很復雜、昂貴，並且不靈活。這些集 成方法難於快速適應基於企業現代業務變化不斷產生的需求。基於面向服務架構 (SOA) 的應用開發和集成可以很好的解決其中的許多問題。
SOA 描述了一套完善的開發模式來幫助客戶端應用連接到服務上。這些模式定製了系列機制用於描述服務、通知及發現服務、與服務進行通信。
不同於傳統的應用集成方法，在 SOA 中，圍繞服務的所有模式都是以基於標準的技術實現的。大部分的通信中間件系統，如 RPC、CORBA、DCOM、EJB 和 RMI，也同樣如此。可是它們的實現都不是很完美的，在權衡交互性以及標準定製的可接受性方面總是存在問題。SOA 試圖排除這些缺陷。因為幾乎所有的通信中間件系統都有固定的處理模式，如RPC 的功能、CORBA 的對象等等。然而，服務既可以定義為功能，又可同時對外定義為對象、應用等等。這使得 SOA 可適應於任何現有系統，並使得系統在集成時不必刻意遵循任何特殊定製。
SOA 幫助企業信息系統遷移到"leave-and-layer"架構之上，這意味著在不用對現有的企業系統做修改的前提下，系統可對外提供 Web 服務介面，這是因為它們已經被可以提供 Web 服務介面的應用層做了一層封裝，所以在不用修改現有系統架構的情況下，SOA 可以將系統和應用迅速轉換為服務。SOA 不僅覆蓋來自於打包應用、定製應用和遺留系統中的信息，而且還覆蓋來自於如安全、內容管理、搜索等 IT 架構中的功能和數據。因為基於 SOA 的應用能很容易地從這些基礎服務架構中添加功能，所以基於SOA的應用能更快地應對市場變化，為使企業業務部門設計開發出新的功能應用。
Soap是什麼？
SOAP 是Simple Object Access Protocol（簡單對象訪問協議）的縮寫。
SOAP是一個用於分布式環境的、輕量級的、基於XML進行信息交換的通信協議.
對於Soap的理解：
第一步理解：SOAP＝HTTP＋XML
第二步理解：SOAP把XML的使用代碼化為請求和響應參數編碼模式，並用HTTP作傳輸。
SOAP是把成熟的基於HTTP的WEB技術與XML的靈活性和可擴展性組合在了一起。
第三步理解：具體地講，一個SOAP實現可以簡單地看作遵循SOAP編碼規則的HTTP請求和響應。
注意：SOAP 是一個協議，與編程語言無關。實際上，許多語言已經開始支持 SOAP，如：Java，C，C＋＋以及JavaScript。
Soap的起源？Soap解決的問題？
SOAP最初由微軟發起研究，用以解決MTS/COM資源消耗大，不夠輕巧等問題，後逐漸被IBM等巨頭接納並加入研究，現已提交W3C，成為Web Service應用傳輸標准。SOAP技術主要用於實現大量異構程序和平台之間的互操作性，從而使存在的應用能夠被廣泛的用戶所訪問。
SOAP意思是簡單對象訪問協議（Simple Object Access Protocol）。的確如它的名字一樣，SOAP是很簡單的。它是一個基於XML的協議，允許程序組件和應用程序彼此使用一種標準的Internet協 議--HTTP來通訊。SOAP是一種獨立的平台，它不依賴程序語言，它是簡單的，彈性的，很容易擴展的。目前，應用程序能夠彼此使用一種基於DCOM和 CORBA技術的遠程過程調用（RPC）來進行相互通訊，但HTTP不被設計為這個目的。RPC在Internet上應用是非常困難的，它們會出現許多兼 容性和安全性的問題，因為防火牆和代理伺服器通常都會阻斷（block）這些類型的流量。應用程序之間最好的通訊方式是通過HTTP協議，因為HTTP是 支持所有Internet瀏覽器和伺服器的。基於這個目的，SOAP協議被創建出來。
SOAP（Simple Object Access Protocol ）簡單對象訪問協議是在分散或分布式的環境中交換信息的簡單的協議，是一個基於XML的協議，它包括四個部分：SOAP封裝(envelop)，封裝定義 了一個描述消息中的內容是什麼，是誰發送的，誰應當接受並處理它以及如何處理它們的框架；SOAP編碼規則（encoding rules），用於表示應用程序需要使用的數據類型的實例; SOAP RPC表示(RPC representation)，表示遠程過程調用和應答的協定;SOAP綁定（binding），使用底層協議交換信息。
雖然這四個部分都作為SOAP的一部分，作為一個整體定義的，但他們在功能上是相交的、彼此獨立的。特別的，信封和編碼規則是被定義在不同的XML命名空間(namespace)中，這樣使得定義更加簡單。
什麼是CXF？
Apache CXF = Celtix + XFire，Apache CXF 的前身叫 Apache CeltiXfire，現在已經正式更名為 Apache CXF 了，以下簡稱為 CXF。CXF 繼承了 Celtix 和 XFire 兩大開源項目的精華，提供了對 JAX-WS 全面的支持，並且提供了多種 Binding 、DataBinding、Transport 以及各種 Format 的支持，並且可以根據實際項目的需要，採用代碼優先（Code First）或者 WSDL 優先（WSDL First）來輕松地實現 Web Services 的發布和使用。目前它仍只是 Apache 的一個孵化項目。
Apache CXF 是一個開源的 Services 框架，CXF 幫助您利用 Frontend 編程 API 來構建和開發 Services ，像 JAX-WS 。這些 Services 可以支持多種協議，比如：SOAP、XML/HTTP、RESTful HTTP 或者 CORBA ，並且可以在多種傳輸協議上運行，比如：HTTP、JMS 或者 JBI，CXF 大大簡化了 Services 的創建，同時它繼承了 XFire 傳統，一樣可以天然地和 Spring 進行無縫集成。
CXF 包含了大量的功能特性，但是主要集中在以下幾個方面：
支持 Web Services 標准：CXF 支持多種 Web Services 標准，包含 SOAP、Basic Profile、WS-Addressing、WS-Policy、WS-ReliableMessaging 和 WS-Security。
Frontends：CXF 支持多種「Frontend」編程模型，CXF 實現了 JAX-WS API （遵循 JAX-WS 2.0 TCK 版本），它也包含一個「simple frontend」允許客戶端和 EndPoint 的創建，而不需要 Annotation 註解。CXF 既支持 WSDL 優先開發，也支持從 Java 的代碼優先開發模式。
容易 使用： CXF 設計得更加直觀與容易使用。有大量簡單的 API 用來快速地構建代碼優先的 Services，各種 Maven 的插件也使集成更加容易，支持 JAX-WS API ，支持 Spring 2.0 更加簡化的 XML 配置方式，等等。
支持二進制和遺留協議：CXF 的設計是一種可插撥的架構，既可以支持 XML ，也可以支持非 XML 的類型綁定，比如：JSON 和 CORBA。
我們來利用cxf創建一個簡單的webservice吧。
首先cxf 所需要的包：更具網站說明以下的包都是必須的，但是在我的實際項目中紅色部分的包並沒有用到。
大家可更具自己需求來添加適應的包。
cxf.jar
commons-logging.jar
geronimo-activation.jar (Or the Sun equivalent)//
geronimo-annotation.jar (Or the Sun equivalent)//
geronimo-javamail.jar (Or the Sun equivalent)//
neethi.jar
jaxb-api.jar
jaxb-impl.jar
stax-api.jar//
XmlSchema.jar
wstx-asl.jar
xml-resolver.jar
分布式應用程序和瀏覽器
研究一下當前的應用程序開發，你會發現一個絕對的傾向：人們開始偏愛基於瀏覽器的瘦客戶應用程序。這當然不是因為瘦客戶能夠提供更好的用戶界面，而是因為 它能夠避免花在桌面應用程序發布上的高成本。發布桌面應用程序成本很高，一半是因為應用程序安裝和配置的問題，另一半是因為客戶和伺服器之間通信的問題。
傳統的Windows富客戶應用程序使用DCOM來與伺服器進行通信和調用遠程對象。配置好DCOM使其在一個大型的網路中正常工作將是一個極富挑戰性的 工作，同時也是許多IT工程師的噩夢。事實上，許多IT工程師寧願忍受瀏覽器所帶來的功能限制，也不願在區域網上去運行一個DCOM。在我看來，結果就是 一個發布容易，但開發難度大而且用戶界面極其受限的應用程序。極端的說，就是你花了更多的資金和時間，卻開發出從用戶看來功能更弱的應用程序。不信？問問 你的會計師對新的基於瀏覽器的會計軟體有什麼想法：絕大多數商用程序用戶希望使用更加友好的Windows用戶界面。
關於客戶端與伺服器的通信問題，一個完美的解決方法是使用HTTP協議來通信。這是因為任何運行Web瀏覽器的機器都在使用HTTP協議。同時，當前許多防火牆也配置為只允許HTTP連接。
許多商用程序還面臨另一個問題，那就是與其他程序的互操作性。如果所有的應用程序都是使用COM或.NET語言寫的，並且都運行在Windows平台上， 那就天下太平了。然而，事實上大多數商業數據仍然在大型主機上以非關系文件(VSAM)的形式存放，並由COBOL語言編寫的大型機程序訪問。而且，目前 還有很多商用程序繼續在使用C++、Java、Visual Basic和其他各種各樣的語言編寫。現在，除了最簡單的程序之外，所有的應用程序都需要與運行在其他異構平台上的應用程序集成並進行數據交換。這樣的任 務通常都是由特殊的方法，如文件傳輸和分析，消息隊列，還有僅適用於某些情況的的API，如IBM的"高級程序到程序交流(APPC)"等來完成的。在以 前，沒有一個應用程序通信標准，是獨立於平台、組建模型和編程語言的。只有通過Web Service，客戶端和伺服器才能夠自由的用HTTP進行通信，不論兩個程序的平台和編程語言是什麼。
什麼是WebService?
Web services是建立可互操作的分布式應用程序的新平台。作為一個Windows程序員，你可能已經用COM或DCOM建立過基於組件的分布式應用程序。COM是一個非常好的組件技術，但是我們也很容易舉出COM並不能滿足要求的情況。
Web service平台是一套標准，它定義了應用程序如何在Web上實現互操作性。你可以用任何你喜歡的語言，在任何你喜歡的平台上寫Web service ，只要我們可以通過Web service標准對這些服務進行查詢和訪問。
Web service平台需要一套協議來實現分布式應用程序的創建。任何平台都有它的數據表示方法和類型系統。要實現互操作性，Web service平台必須提供一套標準的類型系統，用於溝通不同平台、編程語言和組件模型中的不同類型系統。在傳統的分布式系統中，基於界面 (interface)的平台提供了一些方法來描述界面、方法和參數（譯註：如COM和COBAR中的IDL語言）。同樣的，Web service平台也必須提供一種標准來描述Web service，讓客戶可以得到足夠的信息來調用這個Web service。最後，我們還必須有一種方法來對這個Web service進行遠程調用。這種方法實際是一種遠程過程調用協議(RPC)。為了達到互操作性，這種RPC協議還必須與平台和編程語言無關。
Web Service 是一種新的web應用程序分支，他們是自包含、自描述、模塊化的應用，可以發布、定位、通過web調用。Web Service可以執行從簡單的請求到復雜商務處理的任何功能。一旦部署以後，其他Web Service應用程序可以發現並調用它部署的服務。
Web Service是一種應用程序，它可以使用標準的互聯網協議，像超文本傳輸協議(HTTP)和XML，將功能綱領性地體現在互聯網和企業內部網上。可將Web服務視作Web上的組件編程。
1 歷史
web廣泛用到的技術：
◆TCP/IP：通用網路協議，被各種設備使用
◆HTML：通用用戶界面，可以使用HTML標簽顯示數據
◆Java：寫一次可以在任何地方運行的通用編程語言
◆XML ：通用數據表達語言，在web上傳送機構化數據的容易方法
他們的特點是其開放性，跨平台性，開放性正是Web services的基礎。
2 Web發展的趨勢
內容更動態化
◆帶寬Bandwidth更便宜，易於獲得
◆存儲器Storage更便宜，更易獲得
◆普遍式計算變得更加重要：大量的設備，例如行動電話，頁面，電腦，pc，已經在Internet上變得普遍，平台變得更多元化，象XML這樣的跨平台技術變得更重要
3 Web Services扮演什麼角色？
上述的這些趨勢意味著，更加智能的處理，操作和匯總內容變得十分重要。讓我們看看按照Web services角度所預示的四個趨勢：
◆內容更加動態：一個web service必須能合並從多個不同源來的內容，可以包括股票，天氣，新聞等，在傳統環境中的內容，如存貨水平，購物訂單或者目錄信息等，都從後端系統而來
◆帶寬更加便宜：web services可以分發各種類型的內容（音頻，視頻流等）
◆存儲更便宜: web services必須能聰明地處理大量數據，意味著要使用資料庫，LDAP目錄，緩沖，和負載平衡軟體等技術保持可擴展能力
◆普遍式計算更重要：web services不能要求客戶使用某一版本的windows的傳統瀏覽器，必須支持各種設備，平台，瀏覽器類型，各種內容類型。
4 兩種重要技術
要達到這樣的目標，Web services要使用兩種技術：
◆XML XML是在web上傳送結構化數據的偉大方式，Web services要以一種可靠的自動的方式操作數據，HTML不會滿足要求，而XML可以使web services十分方便的處理數據，它的內容與表示的分離十分理想
◆SOAP SOAP使用XML消息調用遠程方法，這樣web services可以通過HTTP協議的post和get方法與遠程機器交互，而且，SOAP更加健壯和靈活易用。
其他象UDDI和WSDL技術與XML和SOAP技術緊密結合用於服務發現。</SPAN>
組成Web service平台的這三個技術。
XML和XSD
可擴展的標記語言(XML)是Web service平台中表示數據的基本格式。除了易於建立和易於分析外，XML主要的優點在於它既是平台無關的，又是廠商無關的。無關性是比技術優越性更重要的：軟體廠商是不會選擇一個由競爭對手所發明的技術的。
XML解決了數據表示的問題，但它沒有定義一套標準的數據類型，更沒有說怎麼去擴展這套數據類型。例如，整形數到底代表什麼？16位，32位，還是 64位？這些細節對實現互操作性都是很重要的。W3C制定的XML Schema(XSD)就是專門解決這個問題的一套標准。它定義了一套標準的數據類型，並給出了一種語言來擴展這套數據類型。Web service平台就是用XSD來作為其數據類型系統的。當你用某種語言(如VB.NET或C#)來構造一個Web service時，為了符合Web service標准，所有你使用的數據類型都必須被轉換為XSD類型。你用的工具可能已經自動幫你完成了這個轉換，但你很可能會根據你的需要修改一下轉換 過程。
WSDL
你會怎樣向別人介紹你的Web service有什麼功能，以及每個函數調用時的參數呢？你可能會自己寫一套文檔，你甚至可能會口頭上告訴需要使用你的Web service的人。這些非正式的方法至少都有一個嚴重的問題：當程序員坐到電腦前，想要使用你的Web service的時候，他們的工具(如Visual Studio)無法給他們提供任何幫助，因為這些工具根本就不了解你的Web service。解決方法是：用機器能閱讀的方式提供一個正式的描述文檔。Web service描述語言(WSDL)就是這樣一個基於XML的語言，用於描述Web service及其函數、參數和返回值。因為是基於XML的，所以WSDL既是機器可閱讀的，又是人可閱讀的，這將是一個很大的好處。一些最新的開發工具 既能根據你的Web service生成WSDL文檔，又能導入WSDL文檔，生成調用相應Web service的代碼。
⑼ 使用webservice必需要用maven嗎
目前主要的java webservice框架剩下了axis2和cxf。本文對兩個框架的目標、標准支持、開發和部署等方面進行了簡單的對比。對於在現有web應用中發布webservice，本文建議使用cxf。 更進一步，本文介紹了cxf的嵌入式代碼和web容器兩種發布方式。
本文中的例子使用maven進行構建。
Table of Contents
1 對比Axis2和CXF
2 編寫服務類
3 以endpoint發布
4 在webapp中發布
1 對比Axis2和CXF
jws的發布對java webservice框架產生了巨大的影響，經過大浪淘沙，目前java開發webservice的框架主要包括axis2和cxf。
axis2和cxf都是apache旗下的產品，但是其目的不同，導致webservice開發方法也不一樣。兩個框架都得到了開發者的支持。有必要對二者進行以下對比。
Axis2 CXF
目標 WebService引擎 簡易的SOA框架，可以作為ESB
ws* 標准支持 不支持WS-Policy WS-Addressing，WS-Policy， WS-RM， WS-Security，WS-I Basic Profile
數據綁定支持 XMLBeans、JiBX、JaxMe 、JaxBRI、ADB JAXB, Aegis, XMLBeans, SDO, JiBX
spring集成 不支持 支持
應用集成 困難 簡單
多語言 支持C/C++ 不支持
部署 web應用 嵌入式
服務監控和管理 支持 不支持
結論：
如果希望以一種一致的方式實現webservice，特別是有跨語言的需求時，應該使用Axis2
如果需要在現有的java程序（包括web應用）中增加webservice支持，應該使用CXF
2 編寫服務類
從Java6開始，WebService API從Java EE復制到了Java SE。並遵循了一系列的標准，比如JSR181(Web Service 元數據），JSR224（JAX-WS,基於XML的WebService API），JSR67（SAAJ，SOAP附件標准）等。 並分別定義到javax.jws, javax.xml.ws 和 javax.xml.soap包中。
JSR181支持使用標注（annotation）來定義WebService。在javax.jws中主要的標注類包括：
標注 說明
WebService 將 Java 類標記為實現 Web Service，或者將 Java 介面標記為定義 Web Service 介面
WebMethod 定製Web Service方法
WebParam 定製Web Service方法的參數
WebResult 定製Web Service方法的返回值
SOAPBinding 指定WebService的SOAP映射樣式
使用標注可以在不改變代碼邏輯的前提下讓外部代碼能夠獲得更多的元數據。下面就用javax.jws定義的標注來聲明一個WebService:
創建maven工程
mvn archetype:create -DgroupId=com.mycompany -DartifactId=cxfdemo -DarchetypeArtifactId=maven-archetype-webapp
增加CXF依賴
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>apache-cxf</artifactId>
<version>${cxf.version}</version>
<type>pom</type>
</dependency>
配置jetty插件
復制代碼
<build>
<plugins>
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>maven-jetty-plugin</artifactId>
</plugin>
</plugins>
</build>
復制代碼
創建服務介面
復制代碼
package cxfdemo;
import javax.jws.WebService;
@WebService
public interface CXFDemo {
public String sayHello(String foo);
}
復制代碼
實現服務類
復制代碼
package cxfdemo;
import javax.jws.WebService;
@WebService()
public class CXFDemoImpl implements CXFDemo {
public String sayHello(String foo) {
return "hello "+foo;
}
}
復制代碼