WebService學習筆記
|
版本 |
日期 |
|
1.0 |
|
Created by
1 WebService概念:
1.1 術語(資料摘要)
Ø web Service
Web Service是使應用程序可以以與平臺和編程語言無關的方式進行相互通信的一項技術。Web 服務是一個軟件接口，它描述了一組可以在網絡上通過標準化的 XML 消息傳遞訪問的操作。它使用基於 XML 語言的協議來描述要執行的操作或者要與另一個 Web 服務交換的數據。一組以這種方式交互的 Web 服務在面向服務的體系結構（Service-Oriented Architecture，SOA）中定義了特殊的 Web 服務應用程序
Ø SOAP
SOAP（Simple Object Access Protocol ）簡單對象訪問協議是在分散或分佈式的環境中交換信息並執行遠程過程調用的輕量級協議，是一個基於XML的協議。使用SOAP，不用考慮任何特定的傳輸協議（最常用的還是HTTP協議），可以允許任何類型的對象或代碼，在任何平臺上，以任何一種語言相互通信。
SOAP包括四個部分：SOAP封裝(envelop)，封裝定義了一個描述消息中的內容是什麼，是誰發送的，誰應當接受並處理它以及如何處理它們的框架；SOAP編碼規則（encoding rules），用於表示應用程序需要使用的數據類型的實例；SOAP RPC表示(RPC representation)，表示遠程過程調用和應答的協定；SOAP綁定（binding），使用底層協議交換信息。
應用中比較關注的是envelop，由一個或多個Header和一個Body組成。
SOAP在可互操作的基礎 Web 服務協議棧中的位置：
Ø Axis
Axis本質上就是一個SOAP引擎（Apache Axis is an implementation of the SOAP），提供創建服務器端、客戶端和網關SOAP操作的基本框架。但Axis並不完全是一個SOAP引擎，它還包括：
是一個獨立的SOAP服務器。
是一個嵌入Servlet引擎（例如Tomcat）的服務器。支持WSDL。
提供轉化WSDL爲Java類的工具。
提供例子程序。
提供TCP/IP數據包監視工具
Ø AXIS的幾種服務類型
AXIS有四種service styles，分別是：RPC, Document, Wrapped, 和Message。最常用的就是RPC和Message。
RPC：在AXIS中是一個默認選項。當你部署的時候使用下列兩種方式： 或則 ，它遵循SOAP RPC和編碼規則。每個RPC都包括一個表示名稱的外部接點和一些表示參數的內部接點。AXIS會根據規則將一個XML（WSDL文件）文件轉化成一個JAVA對象，並對對想賦上在文件中描述的值。也可以根據規則將一個JAVA對象轉化成XML文件。
Document
適合於老的XML schema。
Wrapped
和DOCUMENT一樣，適合於老的XML schema。
在大多書情況下，你不許要擔心是DOCUMENT服務還是WRAPPED服務。
Message
以這種方式部署的話，會使AXIS失去意義，它使你的代碼真正的用XML形式，而不需要轉化成JAVA對象。以這種方式部署的有以下四種服務方法：
public Element [] method(Element [] bodies);
public SOAPBodyElement [] method (SOAPBodyElement [] bodies);
public Document method(Document body);
public void method(SOAPEnvelope req, SOAPEnvelope resp);
幾種服務類型的主要區別：
基於RPC(遠程過程調用)方式，這也是Web服務最常用的方式。面向消息/文檔的的類型跟RPC不同的是它提供了一個更底層的抽象，要求更多的編程工作。客戶端可以傳入任何的XML文檔，得到的響應不一定是SOAPEnvelope，可以返回任何它所需要的東西，甚至不返回。雖然這對開發者來說非常的靈活，但是這種通訊類型在實際的應用中並不常見。面向消息/文檔的Web服務主要適合於下面幾種情況，比如批量處理，基於表單的數據導入，有需要返回非XML數據時，Web服務器實現中要求直接訪問傳輸層等等
Ø WSDL
Web服務的接口定義語言，由Ariba、Intel、IBM、MS等共同提出，通過WSDL，可描述Web服務的三個基本屬性：
·服務做些什麼——服務所提供的操作（方法）
·如何訪問服務——和服務交互的數據格式以及必要協議
·服務位於何處——協議相關的地址，如URL
WSDL文檔以端口集合的形式來描述Web服務，WSDL 服務描述包含對一組操作和消息的一個抽象定義，綁定到這些操作和消息的一個具體協議，和這個綁定的一個網絡端點規範。
WSDL在Web 服務概念性協議棧中的位置
Ø WSDD
WSDD就是WEB服務分佈描述（Web Service Deployment Descriptor）, 它定義了WEB服務的接口，如服務名、提供的方法、方法的參數等信息。
Ø UDDI
UDDI就是統一描述、發現和集成（Universal Description, Discovery, and Integration）。UDDI用於集中存放和查找WSDL描述文件，起着目錄服務器的作用。
Web 服務中的角色、操作和構件：
* 服務提供者。從企業的角度看，這是服務的所有者。從體系結構的角度看，這是託管訪問服務的平臺。
* 服務請求者。從企業的角度看，這是要求滿足特定功能的企業。從體系結構的角度看，這是尋找並調用服務，或啓動與服務的交互的應用程序。服務請求者角色可以由瀏覽器來擔當，由人或無用戶界面的程序（例如，另外一個 Web 服務）來控制它。
* 服務註冊中心。這是可搜索的服務描述註冊中心，服務提供者在此發佈他們的服務描述。在靜態綁定開發或動態綁定執行期間，服務請求者查找服務並獲得服務的綁定信息（在服務描述中）。對於靜態綁定的服務請求者，服務註冊中心是體系結構中的可選角色，因爲服務提供者可以把描述直接發送給服務請求者。同樣，服務請求者可以從服務註冊中心以外的其它來源得到服務描述，例如本地文件、FTP 站點、Web 站點、廣告和服務發現（Advertisement and Discovery of Services，ADS）或發現 Web 服務（Discovery of Web Services，DISCO）。
1.2 WebService用途
Ø 異構平臺或分佈式平臺遠程調用
2 WebService實例
2.1 Axis包介紹
Axis是一個實現WebService的Framework，Apache Web Services Project（http://ws.apache.org ）的一個子項目
2.1.1 Axis1.4(Axis中最後Release版本)
2.1.1.1 基本概念
Ø Axis部署方式有兩種:
1,axis最方便的發佈WebServices的方法是把你的.java改成.jws的放到Web發佈文件夾下的根目錄下,此方法叫即時部署
注意：在你寫的類中不能有具體包的信息，因爲這正是Axis即時部署不支持的
2, 通過WSDD自定義部署
2.1.1.2 Axis自帶web分析
Ø 下載axis1.4
Ø 啓動tomcat
Ø 拷貝webapps/axis到tomcat/ webapps中,tomcat自動部署web module
Ø 訪問: http://localhost:8080/axis/ ,一般可以正常訪問到Apache-AXIS主頁,並可以點擊list察看已發佈的web service
Ø 重點:
1,webservice只需要在一個web container中配置即可
2,axis自帶web.xml中的配置:
一個servlet監聽器:
三個servlet,其中紅色是主控程序
servlet的映射地址:
3,axis自帶的webservice在哪配的?
可能是寫到 org.apache.axis.transport.http.AxisServlet 中的
2.1.1.3 編寫自己的webservice
下面是如何自己編寫併發佈一個web service的過程:
服務器測試環境:
|
Web Server |
描述 |
|
Tomcat4.1 |
端口:8080 程序列表: 1,一個java普通類Class1.class:web service的主要調用類 有三個方法 2,WEB-INFO/ server-config.wsdd :對上面類的wsdd配置描述 |
|
Weblogic8.1 |
端口:7001 程序列表: 1,一個client的jsp文件,遠程調用8080端口的webservice類中的方法 |
2.1.1.3.1 編寫並部署服務器的webservice
1,新建一個類,如圖:
其中有三個方法,兩個簡單方法和一個返回類型爲自定義類的方法.
寫方法 test3的原因主要是要研究webservice如何傳遞自定義類以及如何在異構平臺上傳遞和接收自定義類.
package com.bell.ws;
public class Class1 {
public Class1() {
}
public String test1(String p1){
return "test1:"+p1;
}
public void test2(){
System.out.println("i'm test2");
}
public MyVO test3(MyVO myvo){
return myvo;
}
}
2, 在WEB-INF目錄下加入一個server-config.wsdd。這是WebServices的發佈描述文件，作用類似於web.xml。它有自己的格式
其內容如下:
<?xml version="1.0" encoding="UTF-8"?>
<deployment xmlns="http://xml.apache.org/axis/wsdd/" xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
<service name="Class1" provider="java:RPC">
<parameter name="allowedMethods" value="*"/>
<parameter name="className" value="com.bell.ws.Class1"/>
</service>
</deployment>
重啓tomcat後,就可以看到剛剛發佈的service了:
但這時點進wsdl時會出錯:原因: server-config.wsdd中未加全內容
把內容加全後,測試成功:
<?xml version="1.0" encoding="UTF-8"?>
<deployment xmlns="http://xml.apache.org/axis/wsdd/"
xmlns:java="http://xml.apache.org/axis/wsdd/providers/java"
xmlns:handler="http://xml.apache.org/axis/wsdd/providers/handler"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
name="defaultClientConfig" xsi:type="deployment">
<globalConfiguration name="defaultClientConfig">
<parameter name="disablePrettyXML" value="true"/>
<parameter name="dotNetSoapEncFix" value="true"/>
<requestFlow name="RequestFlow1" type="">
<handler name="Handler1" type="java:org.apache.axis.handlers.JWSHandler">
<parameter name="scope" value="session"/>
</handler>
<handler name="Handler2" type="java:org.apache.axis.handlers.JWSHandler">
<parameter name="scope" value="request"/>
<parameter name="extension" value=".jwr"/>
</handler>
</requestFlow>
</globalConfiguration>
<handler name="URLMapper" type="java:org.apache.axis.handlers.http.URLMapper"/>
<handler name="LocalResponder" type="java:org.apache.axis.transport.local.LocalResponder"/>
<handler name="Authenticate" type="java:org.apache.axis.handlers.SimpleAuthenticationHandler"/>
<transport name="http" type="">
<parameter name="qs:list" value="org.apache.axis.transport.http.QSListHandler"/>
<parameter name="qs:method" value="org.apache.axis.transport.http.QSMethodHandler"/>
<parameter name="qs:wsdl" value="org.apache.axis.transport.http.QSWSDLHandler"/>
<requestFlow name="RequestFlow1" type="">
<handler name="Handler1" type="URLMapper"/>
<handler name="Handler2" type="java:org.apache.axis.handlers.http.HTTPAuthHandler"/>
</requestFlow>
</transport>
<transport name="local" type="">
<responseFlow name="ResponseFlow1" type="">
<handler name="Handler1" type="LocalResponder"/>
</responseFlow>
</transport>
<service name="Class1" provider="java:RPC">
<parameter name="allowedMethods" value="*"/>
<parameter name="className" value="com.bell.ws.Class1"/>
</service>
</deployment>
成功頁面
2.1.1.3.2 編寫客戶端程序調用遠程webservice
Ø 在上面webservice發佈成功的前提下,編寫客戶端程序進行遠程調用:
<%@ page import="org.apache.axis.client.Call,org.apache.axis.client.Service,org.apache.axis.encoding.XMLType,org.apache.axis.utils.Options" %>
<%@ page import="javax.xml.namespace.QName,javax.xml.rpc.ParameterMode" %>
<%
try {
Service service = new Service();
Call call = (Call) service.createCall();
call.setTargetEndpointAddress( new java.net.URL("http://localhost:8080/axis/services/Class1") );
call.setOperationName( new QName("http://ws.mstar.org", "test1") );
call.addParameter( "arg1", XMLType.XSD_STRING, ParameterMode.IN);
call.setReturnType( org.apache.axis.encoding.XMLType.XSD_STRING );
String ret = (String) call.invoke( new Object[] { "first test!" } );
System.out.println("You typed : " + ret);
out.println("ret"+ret);
} catch (Exception e) {
// e.printStackTrace();
System.err.println(e.toString());
}
%>
正常調用的結果頁面如下:
2.1.1.3.3 編寫返回複合類型的webservice
上面我們返回的只是簡單的string型字串,下面舉例說明如何返回複合類型的webservice:
還是使用上面的Class1.java,其中方法test3是返回的MyVO類型:
對server-config.wsdd進行配置:
目前會出現:
java.io.IOException: No serializer found for class com.bell.ws.MyVO in registry
org.apache.axis.encoding.TypeMappingDelegate@38fb59
2.1.2 Axis2
2.2 Jbuilder2006實現WebService
2.3 疑問
1,安全問題
2,有狀態會話問題等等
3,如何跨平臺返回複雜類型
4,即然java源文件+wsdd文件即可部署web service,jbuilder中生成的一堆文件是幹嘛用的?
3 WebService開發經驗(網上摘抄)
摘自網址:http://www.javaeye.com/topic/73047
去年，在一個大型項目(1500w)中用到Web Services，現在項目進入了尾聲，所以對以前的開發經歷做一個總結。
我想大家一定會問？爲什麼你們項目中要用到Web Services，因爲客戶有如下需求：
1、客戶要求項目用C/S架構，並且服務器端是IBM那一套：WebSphere AppServer＋DB2＋AIX5.3＋RS/6000。
2、最終用戶上報數據，因爲網絡原因，譬如Modem上網，可以離線操作，等填寫了幾十張報表後，可以一次提交。同時，在登錄時，可以將服務端數據同步到本地Access或MSSQL數據庫，這樣提高客戶端響應速度。
3、由於有些報表以後可能需要修改，或添加一些新報表，又不想重新開發，這樣客戶那邊工作人員可以通過客戶端自定義。
如果有以上需求，我想大家應該都比較認同這種異構分佈式解決方案：客戶端用C# .Net開發，通過Web Services調用服務器端Java組件。
其實，上面的解決方案太過於理想，最後我們不得不面對殘酷的現實：三種客戶端中的兩種最後被迫改爲B/S。
在項目中，我主要負責Web Services和服務器端組件開發中所遇到的種種問題，相當於技術支持吧，以及部分模塊的開發。
以下是我們開發中遇到的實際問題，雖然最終都一一解決，但遇到了幾個無法突破的瓶頸：客戶端不穩定，客戶端響應遲緩，後期測試和維護困難巨大。
一、異構平臺的Web Services兼容性
開發過程中，我們用Axis做Web Services引擎，Tomcat做容器。因爲我們只有IBM提供的RAD6.0的60天試用版。該工具超級佔內存，用內置的WebSphere開發測試極其緩慢，嚴重影響開發效率，經過我初期試用後，基本廢棄了。推薦項目組二三十開發人員用Lomboz eclipse3.12開發，基本滿意。
由於Axis是一個嵌入式引擎，所以可以將其打包到最終的WebSphere AppServer（WAS）上，也就是說，我們沒有用到WAS提供的Web Services引擎，這引出了後面會談到的一個問題：Web Services安全性怎麼部署？
用Axis時，Axis一直都有一個bug或是說缺陷，官方文檔也詳細註明，只是我們當時沒有發現而走了很多彎路：用Axis發佈的Web Services給.net客戶端調用時，必須用RPC風格，不能用Web Services標準的跨平臺風格Document，而後者是Lomboz axis插件的默認方式。也就是說，我們發佈的Web Services總是莫名其妙的不好用。我們用JBuilder2007自帶的Axis插件發佈，竟然非常順利。
二、Web Services開發中服務器端組件問題
我們服務器端開發，是用Spring＋Hibernate，在Spring的Service層上再封裝一層，也就是façade模式了，該façade直接發佈爲Web Services，必須經過這個轉換，一是因爲性能，二是因爲Hibernate的複雜Model對象，在wsdl描述後，被.net客戶端識別有些問題，List、Map也會有問題，總之這些對象太複雜了，我們包裝成簡單的VO對象。
另外一個問題是，我們的service方法，如果直接給WebWork這樣的框架在服務端用的的話，是不會出問題，當提供給.net客戶端用時，就會出現lazy loading的錯誤，因爲.net客戶端不能接收Proxy對象，必須將數據全部load出來，但這時Hibernate的session已經關閉。項目組很多人遇到這些問題，最後大家不約而同的全部用eager模式，導致了最後的惡果：嚴重的的性能問題。由於我不是leader，所以當時這個問題發現了，也沒法要求別人，畢竟很大的一個團隊。
切身體會：一個團隊，如果不熟悉Hibernate就隨便上，技術風險非常大。Hibernate帶來的開發效率，是以團隊成員掌握它爲前提。
當然，性能問題不只是由Hibernate引起，Web Services本身的性能也非常嚴重：XML的序列化和反序列化耗時，XML文件的膨脹導致的網絡傳輸，HTTP的無狀態導致網絡IO性能。切身體會：如果系統必須用分佈式，而不是追求所謂的SOA架構，Web Services應該是下下策，因爲還有很多協議和方式可以選擇：IIOP、RMI、Hessian、burlap、RPC，另外，做系統集成還有Message方式。
Web Services開發中其它問題比較少，因爲Web Services本身不用編程，只是部署的事情，開發工具和服務器會自動爲我們做，我們只需要理解SOAP引擎的原理和使用就夠了，真的遇到問題，可以通過Axis的TcpMonitor監視SOAP數據包。
開發過程中，.net客戶端那邊，VSStudio做得很智能，它會根據wsdl文件生成我們所要的一切，當然，wsdl文件的變化，會導致VSStudio重新生成所有的類和接口，也很耗時，並且容易出問題。
三、Web Services的安全問題
當時解決Web Services安全問題，花了我將近一個月的時間，主要是學習和處理如下四個問題：
XML和Web Services安全規範
WAS的 Web Services引擎的安全部署
Axis和參考的Xfire引擎的Web Services安全
.net客戶端WSE3.0的安全以及和WAS的通訊
最後這些問題基本上都解決了，不過還是沒有用上，因爲在我們已經開發的幾種客戶端和服務器端部署上很麻煩，還要測試，另外，客戶也沒法驗收這個啊。
當然，我們還回避了一個嚴肅的問題：我們的Web Services是發佈在Axis引擎上，還沒有移植到WAS的Web Services引擎，而發佈在這個平臺，必須有RAD這類開發工具支持，幾乎沒法手動做。WAS引擎的Web Services安全配置異常複雜：我們當時只配置了Authentication和Integration，沒有做Encryption，但完全夠用。我當時用Sun的NetBean開發工具發佈了一下Web Serivces，也是挺好用的，不過沒有配置安全。順便說一下，Sun的web Services引擎jwsdp2.0設計有點類似於EJB容器，很不好用，移植性特差。
我們當時用Axis引擎是1.3版本，而該版並不支持標準的OASIS的WS-Security，只有到2.0版纔開始，而且幾乎都是手寫配置文件。
WAS的Web Services安全配置，對照IBM的紅皮書，不是很難，但很複雜，安全相關的xml代碼都好幾百行，好幾個文件。配置過程中，和.net客戶端通訊時遇到一個問題，怎麼也不能互通，但.net和.net客戶端可以互通，Java和Java客戶端也可以互通,最後我通過攔截soap包,找到了解決辦法: 必須手動更改http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3 後的v3，IBM工具生成的是v1，這是標準不兼容引起的，因爲當時RAD是04年底,而微軟的WSE3.0比較新。後來發現這篇文章有相似的經歷：http://pluralsight.com/blogs/kirillg/archive/2005/04/13/7315.aspx
在處理Web Services安全過程中，我通過emule和IBM網站下載了上10本這方面的書籍，我覺得以下資料對我幫助最大：
Axis的若干文檔：Reference、developers-guide、architecture-guide等，非常詳細
IBM的紅皮書：《WebSphere Version 6 Web Services Handbook Development and Deployment.pdf》、《WebSphere Application Server V6 Security Handbook.pdf》，它專門講述了Web Services安全的原理和具體配置，非常深入淺出。
《Securing Web Services with WS-Security》：這本書很理論化，但我認爲非常好，雖然Amazon排行不高。
WSE3.0的MSDN文檔。
四、開發過程中的的溝通問題
這應該不是一個技術問題，而是一個軟件開發方法學的問題，但對整個軟件開發過程影響極大。
我們面對的現實：.net客戶端開發人員不懂服務器端Java，服務器端Java開發人員不懂.net。
除了技術壁壘外，還有業務銜接性的問題，因爲我們不是縱向分模塊開發，而橫向開發的前提是我們服務器端開發人員很熟悉業務，知道客戶端需要的接口，但實際上，業務主要由客戶端推動。所以，兩端的開發人員都遇到很大的溝通壁壘。
從技術的角度表達就是：客戶端開發人員需要的接口，服務器端開發人員不清楚；服務器端開發人員也不知道怎麼把握粒度。譬如，有個updateUser方法，但更新用戶信息時，可能需要更新很多信息：用戶信息、用戶角色、用戶所屬組….。loadUser時也有同樣的按需加載問題。
當然，從技術角度，開發Web Serivces有Bottom-up和Top-down兩種開發模式。我們選擇了前者，也是最常見的方式，也許用後者更適合我們的項目：從定義的wsdl文件開始，客戶端和服務器端開發都遵循它。但問題是：我們怎麼確定wsdl，也就是我們所要求的接口，因爲我們自己對業務都不是很熟。
五、客戶端和服務端開發測試方法
我們當時做得很笨，也最直接：等服務器端組件發佈完畢後，通知客戶端開發人員，然後客戶端開發人員通過VSStudio提供的Web Services生成工具，根據Axis發佈的wsdl文件，生成所需的.net對象，然後像本地調用一樣使用。
但問題是：
wsdl隨時都在變，這意味着客戶端生成的組件總在變化，經常出現編譯錯誤。
客戶端開發過程中遇到的問題，一會是客戶端自己，一會是服務器端組件：我要的方法包含的信息不夠啊。
服務器組件測試一次，起容器特慢，而且客戶端調用也慢。
我們的測試，最後走入了一個怎樣的泥潭：譬如測試一張報表，都是在客戶端手工填寫，然後觀察服務器端日誌和響應。有人會問，用LoadRunner或Function Tester這類自動測試工具不就ok了嗎？我都用過，它們對Web UI確實好用，後者對Swing客戶端也好用，但對.net客戶端，像是不太現實。
另外，Debug非常困難，因爲它要求兩端開發人員必須在一起密切配合。
我自己認爲的解決方案，但未必真的好用：
服務器端Service方法必須寫單元測試TestCase，可能代碼量非常大，測試好後方發佈爲Web Services。
同時，服務器端提供同一套接口的Mock實現，供客戶端開發測試，解決並行開發的問題。
六、其它問題
當然，上面的幾點，具體到細節，我都省略了，總之問題非常非常多：技術問題、管理問題、方法和過程問題。
特別提的一點是，我們幾乎開發了兩套“業務層＋持久化”解決方案，因爲離線客戶端也用了NHibernate持久化，這樣導致開發測試工作量巨大，就說一點吧:兩邊同步是通過打包的sql語句，通過SOAP傳輸，但Access和DB2的sql有不兼容問題，如果要兼容，就會以犧牲性能和靈活性爲代價。
另外，我們寫項目建議書時很被動，但也沒辦法，因爲有好幾家公司競爭。對我們影響極大的幾個問題：
1、IBM的WAS比起WebLogic Server易用性差遠了，導致部署時極其耗時。而且還有一些bug，譬如連接池資源，當時不得不和IBM工程師諮詢。實際上，我們只用到強大的WAS的一個非常小的部分：Web容器。
2、我們沒有針對WAS的開發工具RAD。但說實話，那試用版的RAD也是一個字：慢，而且安裝時超級大，約4個G。而且和我們已經在用的版本控制工具VSS沒法集成。
3、項目的C/S架構不是很合理，就是原來客戶的B/S架構，也運行挺好的，而且用asp，跑在一個pc server上。我們一定程度上爲了技術而技術。最後也達不到客戶需求：性能＋穩定。
4、自定義報表最後沒有投入使用，只是一個半成品。本來自定義報表就很難，要是容易，一個軟件外行人員，就可以把表現層到持久化輕鬆搞定，那一般MIS開發人員不要失業了，MDA也沒那麼強。很多OA平臺一直在解決這個問題，也沒有發現特別好用的。我們做技術調研期間試過MS的InfoPath和Adobe Designer，以及Excel Server，都不能滿足需求。
當然，這個子系統只是我們那個龐大系統的一個部分。上面也就算我做的一點點總結吧，也是教訓啊！不過，從個人角度考慮，學到的東西還是很多的。
這個子系統花去了我們將近200個人月，如果說那浪費的部分，估計至少是100個人月的工作量。是什麼導致？從我這篇文章只能窺其一角，因爲整個系統涉及CMS、OA、BI、E-commerce、GIS、IM、MIS。我自己總結一下，有以下原因：
1、項目建議書空洞，不切實際：公司也很無奈，客戶也不成熟。
2、需求調研後的需求分析閉門造車：客戶的合同是分階段，我們上交需求說明書後付20％款，上交設計書後又付20％。全一個瀑布開發，雖然按RUP文檔寫。到半年後的實際開發時，發現很多需求都不合理。
3、整個過程都沒有和客戶溝通，到最後開發完畢才讓客戶看，那時客戶也懵了：這不是我要的產品啊。改呀，改呀，熬夜啊。
4、項目團隊整體技術實力薄弱，當時調來做Java開發的人員，只有少數幾個以前做Java，大多數是臨時學。想起那Hibernate使用，心寒啊。另外，WAS問題、AIX問題在產品環境下都出來了：系統不穩定、宕機。
5、整個開發階段流程沒有把握好，像項目規範、測試方法、日誌、版本控制，這些後期都出現了，而且非常嚴重。就說那日誌吧，最後出問題都不知道怎麼查，日誌一遍混亂。
6、缺乏做大項目經驗，整個系統架構都比較鬆散，項目開始時很多都不知從何入手，也很倉促。
7、項目持續一年多，人都換了幾批了，工作交接很大問題。
.....
不過，說實話，項目團隊，特別是進公司一、兩年的員工都很努力，沒有人抱怨什麼，我和他（她）們一起合作，還是很開心的。
4 參考資料或網站:
WebService學習，開發總結
http://www.mohappy.com/blog/user1/261/archives/2006/2095.html
Axis初學手冊
http://www.blogjava.net/mstar/archive/2005/10/06/14870.aspx
