webservice反編譯

A. 織夢的函數定義在哪裡，怎麼快速查出來路：CheckChannel（）,怎樣能得到函數源碼或定義在哪個文件，批量得

織夢的CMS里邊有Webservice 所以你看到有些東西 可能不在文件夾里 我給你一個DLL反編文件，他可以把所有的DLL開源的東西都反編譯出來 你網路一下叫 Reflector 也就是說使用這個這些代碼都是你的了

B. .NET 編譯出來的DLL文件，如何才能不被反編譯

1.有那種代碼混亂器，其實也就是改改類名字等，常用的有
DotFuscator, .NET Reactor, xenocode 。。。你可以自己搜索下載了
2.當代碼量很大的時候，反編譯去讀MSIL的代碼也是很辛苦的，工程量很大
3.一般.net寫的程序都是基於web的，放在伺服器上，WebService，所以盜版破解也顯得不是那麼有意義了。。。

友情提醒：事先備份好你的代碼！

C. android webservice 登錄安全問題：

這幾個文本框調用webservice參數，你可以傳遞參數，然後執行Web服務XML解析就可以知道

D. ESB有哪些優缺點

一、ESB優點
1、 不需要寫大量的代碼

Esb產品採用了可配置的方式，用戶無需寫大量的代碼，通過esb產品就可以很輕松地實現數據的流轉整合。傳統寫代碼的方式，在控制數據整合時，需要寫大量的jdbc或者其他相關的代碼，工作量巨大，而且容易出錯；而採用esb產品的話，所有工作都是通過配置方式實現的，不需寫代碼或者只需少量的代碼即可實現相關功能，大大提高了工作效率。

2、 屏蔽了底層實現

數據傳輸和整合不僅僅是寫jdbc代碼這么簡單，對於不是直接操作資料庫的情況，如採用webservice介面或者jms、socket等方式的情況，用戶還需掌握這些底層技術，增加了技術復雜度，帶來了額外的學習成本；而通過esb產品，用戶只需不同的組件跟流程通過配置就可實現相關功能，無需關心底層的技術實現。

3、 准確性高

寫代碼的方式需要在代碼中指定操作哪些數據源，哪些用戶，哪些表，取哪些欄位，只要發生一個小的錯誤就可能導致數據傳輸的失敗或者數據的不準確；而esb產品採用可配置的方式，所有跟數據操作相關的元素都由esb產品來獲取，用戶只需簡單選擇即可，避免了錯誤的發生，可以達到百分之百的准確。

4、 豐富的協議

Esb產品中包括各種常用或者不常用的傳輸協議，用戶可以根據實際情況選擇使用，可以應付各種不同的項目情況。
5、 豐富的行業積累

Esb產品作為一個產品化的產物，不僅僅是解決一些基礎的問題，產品自身還會根據在項目中的應用不斷完善和發展。Esb產品會把各種行業解決方案中用到的內容逐漸豐富到產品中，隨著項目的增多，行業的增多，esb產品的功能也越來越豐富，可以應對不同行業的不同需求。

6、 可維護性高

寫代碼的方式，如果需求等方面出現變動，就需要修改相應代碼，少則可能幾處，多則可能十幾處幾十處，給維護工作帶來了很大的不便，中間的任何疏漏都可能導致錯誤的發生；esb產品採用組件實現，即使需求發生變化，只需修改幾個組件即可，既減少了維護的工作量又增加了可靠性。

7、 安全性高

寫代碼的方式很少考慮安全性方面的要求，代碼只滿足了基本的需求，但是安全性不高；esb產品是成熟的全面的產品，不僅實現功能，還包括安全性方面的內容，比如在數據傳輸中採用安全性的協議，對傳輸的數據進行備份，對傳輸過程進行日誌記錄，即使在復雜的網路情況下也能保證數據安全傳輸，即使出現問題也能通過日誌和備份進行分析查找並恢復，將損失降到最低。

8、 性能高

Esb產品充分考慮性能問題，在性能方面做了大量優化，可以極大提高傳輸效率，這是寫代碼所無法比擬的。

9、 監控管理

Esb產品包括監控平台，可以通過監控平台查詢已做的操作，正在運行中的操作及出錯的操作，及時掌握整個數據傳輸中的情況，還可以看到當前資源消耗的情況，快速找出瓶頸所在。監控平台還有統計分析功能，方便用戶直觀的掌握整體情況，這些都是寫代碼所不能實現的。
二、esb缺點
依賴於Weblogic

重量級的統一消息格式：
通過反編譯OSB的源碼，可以看出OSB將各種協議（HTTP,WS,JMS…）接入的消息統一轉換為SOAP Message，再通過Xquery Engine對SOAP Message進行XML操作。
以下場景其缺點可立即顯現：
1.HTTP下的大數據包
2.JMS Object類型的大數據包（最新版本OSB才支持JMS Object類型，之前只支持JMS Text類型
依據：
對大數據包進行XML操作比較耗CPU
將大的Object轉換為XML是個繁重的操作

E. WebService介面調用時，出現java.lang.RuntimeExcep異常是怎麼回事

關於這個錯誤，在開發調試過程中可以先通過輔助工具來觀察它原始的 xml 內容是什麼樣的，這段 xml內容中包括一個 fault相關聯的 xml 標簽，裡面記錄著異常消息的原始文本，不管是哪個 web service API 它們要處理的 XML 內容是完全相同的標准。

但是如果這個異常是在你這個客戶端本身拋出的而不是從遠程服務端返回的那就復雜些，需要看其它的日誌。像很多開源的軟體都有一套日誌，比如假設它使用了 log4j 啥的，我們就可以配置一個 log4j.properties 並把 org.apache.cxf 的 logger category 啟用 all 或 debug 級別的日誌輸出，這也是一個觀察 CXF 中間如何處理一個例外情況的分析方法。實在不行就找 CXF 的源碼或反編譯這個異常 Stack Trace 中提到的那幾個類猜測一下可能的原因。

F. 怎麼寫好Java(或者Java web)代碼

作為一個Java開發攻城獅（lao si ji），我可以負責任地告訴你，多看多寫~
首先，鑒於題主你說你是剛接觸地階段，我並不推薦你你上來就要寫工業級或者企業級的代碼，當下的話應該是迅速積累項目經驗，快速掌握java web的開發流程為主，可以網上看看什麼視頻教程，有些還是能學到規范的。
分享一下我的經歷吧~
讀大學的時候我接一些外包【朋友介紹】，一開始也很虛啊，覺得這里不對，那裡不對的。寫得多了，慢慢理解整個開發流程後，就覺得也就是增刪改查嘛，沒什麼的。每次都要寫，好麻煩啊，既然這樣，不如自己造一些輪子，後來就是項目多了，又造了一些輪子，然後做了系列的封裝。期間穿插讀了 重構和effective java兩本書，代碼方法保持整潔，但一些代碼上還是不規范。
再後來，學習了java的一些高級特性，反射、自省【提高了寫代碼250%的效率】以及參考了部分阿里的規范，感覺逐漸能寫出比以前看上去優雅的代碼了。
接下來的一段時間，因為興趣的原因，研究了一下三大框架，自己強行擼了三個閹割版。回去看源碼的時候，發現spring寫得真的太優雅了，然後又小小改了一下風格。
最後，出來工作了，哦謝特~ 大家寫得什麼鬼啊~ 什麼規范都不參照~ 簡直內心爆炸，一萬點傷害~ 好吧，我還是照著我原先的思路，搞一搞~
所以說，工業級、企業級代碼不是每個公司都有，但是對自身有要求是好事啊~ 你也別急，慢慢寫，也能逐漸規范起來~ 只是現在，不合適~ 加油~
還有問題的話，歡迎聯系我~