這個專案的功能是使用webservice方式完成兩個系統間的資料互動，使用的框架是axis2。簡單的總結一下專案中的幾個問題：
開發客戶端時要設定訪問超時時間
使用axis生成的webservice客戶端預設的訪問超時時間比較短，如果服務端的處理時間比較長，就會發生客戶端訪問超時的現象，所以一定要修改一下客戶端的超時時間，以免發生明明服務呼叫成功，但是卻由於執行時間比較長，而導致客戶端顯示服務呼叫失敗的情況。
注意訪問服務失敗時的業務處理
就像在事務執行過程中發生異常需要進行事務回滾一樣，假如服務呼叫失敗，一定要對失敗的情況進行處理，始終保持兩個系統中的資料是一致的。
記錄好日誌
兩個系統之間的資料互動是比較麻煩的一件事，特別是兩個廠家共同開發互動介面的情況更是如此，因為使用webservice方式互動比較不穩定，網路因素，雙方系統的因素等等，所以說，一定要把每次互動的結果都記錄到日誌中，以免出了問題時不好界定責任。
測試服務是否正常可以使用專門的工具soapui
webservice呼叫的成功與否，跟服務端和客戶端都有關係，測試服務端是否正常時可以使用乙個專門的測試工具——soapui。如果使用soapui測試服務端正常，則webservice的問題一般出現在客戶端。
該重構時就重構
專案完成後，對自己的**並不是很滿意，可讀性比較差。由於開始認為專案比較小，沒有引起足夠的重視，但是使用者需求的需求卻變的很頻繁，並且都是每次加一點小功能，所以基本都是在原有的邏輯中加點**，以至於改著改著發現**很臃腫了。等客戶需求基本穩定後，需要對專案中的幾個部分進行重構，以免日後的維護成本過高。
git flow工作流總結
寫在前面 文章的出處是由於作者本人對於gitlab 以及sourcetree的使用實在是摸不著頭腦，所以決定將各個地方詳細的截圖下來 因為我找的資料裡面對我來說都是不夠用的 由於在學校的時候沒有接觸過git，所以實習有些不適應，就這些天的使用就行相關的總結。現在在實習公司用的gitlab sourc...
Git Flow工作流總結
gitflow 工作流定義了乙個圍繞專案發布的嚴格分支模型。雖然比功能分支工作流複雜幾分，但提供了用於乙個健壯的用於管理大型專案的框架。gitflow 工作流沒有用超出功能分支工作流的概念和命令，而是為不同的分支分配乙個很明確的角色，並定義分支之間如何和什麼時候進行互動。除了使用功能分支，在做準備 ...
activiti工作流總結
一 概念 1 工作流 workflow 就是 業務過程的部分或整體在計算機應用環境下的自動化 它主要解決的是 使在多個參與者之間按照某種預定義的規則傳遞文件 資訊或任務的過程自動進行，從而實現某個預期的業務目標，或者促使此目標的實現 2 工作流管理系統 workflow management sys...