時間轉眼過去一年多了 ,我離開 H公司也已經一年多了 .往事不堪回首 ,世事也總是以成敗論英雄的 ,因爲我知道前面的一個接口項目先後導致 3個人離職 ,2個人被處罰 ;而這個項目只有我一個人 ,在項目割接的當天我總算不辱使命完成了 ;我既是成功者 ,也是失敗者 ;我證明了自己是可以笑着離開 H公司的 .其實我一直不太想寫出來 ,畢竟申請離職也不是一件很光彩的事情 .
2006年是全國號碼百事通風起雲涌的一年 ,而 Z電信公司正是第一個勇於吃螃蟹的人且率業界之先的公司 ;我就是 2006年初被派到 電信公司跟着另外一個項目經理討論接口需求的 (原因很簡單 ,爲了避免壟斷 ,Z電信公司把省中心業務給了 Q公司 ,而 12各地市給了 H公司 所以在省中心和地市之間需要通過 Web Service接口進行互連 ),其實在這之前的一年內我是做 BI和數據庫優化的 ,對於所謂的接口和 114是一竅不通的 .估計看出了點苗頭 ,項目經理當了甩手掌櫃 ,只好由我一個人來負責此事了 . Z ,
2月
8號
,春節還沒過完
,我便來到了
H市
,經過反覆的討論和調研
,其實我做的工作只是號碼百事通業務的一部分
,即實現對現有知識庫的智能訪問
,當然訪問是需要通過接口來完成的
,此外還要實現一定的功能
,例如發送短信
,來電轉接
,記錄計費信息
,當然也是通過接口來實現
.
其實我很早就已經有了初步的想法 ,最簡單的就是我自動生成存儲過程和自動生成 html網頁 (其實基本上已經實現了 ),但是瞭解到存儲過程需要在友商的數據庫中創建 ,以及考慮到相關的風險和雙方的劍拔弩張的氣氛 ,這顯然是不可能實現的任務 .現在只能自己另闢蹊徑建一個獨立的 Web Server服務器 ,通過正在流行的 Web Service接口來實現這一切功能了 .
上述的圖片顯示的框架源於我對 BI和數據庫的理解 ,只要有一個開放的數據字典 ,基本上就可以實現任何的自定義查詢和自定義組合 如果複雜一點的話 ,甚至可以實現一套簡單的報表系統 .正是基於這樣的想法和相關數據結構開始和 Q公司談相關的接口 .但是有幾個問題一直纏繞着我 : ;
1. 採用什麼樣的 WEB服務器 ,Tomcat還是 Resin
2. 採用什麼樣的編程工具 ,Jbuilder還是 Eclipse?
3. Web Service接口到底是什麼 ,如何完成發佈和調用
4. 採用什麼樣的 Java框架 (Struct還是 Spring還是純粹的 JSP)
5. Ajax技術
6. 關於樹型目錄的實現 (需要高效 ,無延遲 )
7. 最難纏的還是和 Q公司的談判和交流 (要面對對方 5,6人的輪番轟炸 )
也許對於 java高手而言這根本不算什麼 ,可對於我而言 ,那簡直是一場噩夢 ,我的 Java水平和 HTML水平僅限於寫一些簡單的 JSP頁面和 JavaBean完成簡單的封裝 ,我自認爲自己水平最高的還是 HTML和 javascript水平 ,不管多麼複雜的頁面和 frame我都可以整理出一個頭緒出來 .我從來不是一個唯工具論者 ,我相信任何工具都只是手段 ,而條條馬路都可以通向羅馬的 .可惜給我留的時間太短了 ,只有 3周的時間 .說真的 ,那時候天天對着西湖的美景 ,沒有一絲絲觀看的心情 ,真的想撲通一聲跳下去 ,一了百了 .
言規正傳首先需要確定系統大體的架構 ,Tomcat和 Eclipse都是開源的架構 ,不涉及到版權和費用 ,從網上 down的 Tomcat,呵呵 ,如果 Z電信公司知道了非要氣個半死不可 .按照從網上搜索的資料把 Tomcat和 Eclipse環境配置完畢 ,然後按照公司的 java高手指點 ,配置 框架 . Spring
關於 Spring框架的配置
Spring 是一個開源框架，是爲了解決企業應用程序開發複雜性而創建的。框架的主要優勢之一就是其分層架構，分層架構允許您選擇使用哪一個組件，同時爲 J2EE 應用程序開發提供集成的框架。
其實在這樣的小型系統裏 ,它提供了一個便於調試和控制的開關 ;至少在本文中 ,是爲了解決無法使用接口環境進行調試的時候 ,改用數據庫接口方式 .
<!-- ======= 如果是和 soap 接口連接，請去掉該 bean 的註釋 ===========-->
<bean id="QueryData" class="com.xxx.yyy.inf.SoapInterface">
<property name="endpoint">
<value>http://192.168.1.2/Forxxx/ForQuery.asmx</value>
</property>
<property name="nameSpace">
<value>http://tempuri.org/</value>
</property>
</bean>
<!-- =========== 如果是和 db 接口連接測試 , 請去掉該 bean 的註釋 =====-->
<!--
<bean id="QueryData" class="com.xxx.yyy.inf.DBInterface">
<property name="dataSource">
<ref local="DataSource"/>
</property>
</bean>
-->
關於樹型目錄的框架
嚴格說來寫一個樹型目錄的架構是一項非常複雜的工作 ,樹型目錄的實現有兩種方式 :全部畫出所有的樹節點和當觸發時實時畫出下一層節點。前一種的實現相對簡單一些 ,但是當節點數量超過 1000之後 ,採用遞歸算法會導致頁面首次顯示時出奇的緩慢 ,我曾經做過對 js腳本和相應的存儲過程做過調優 ,但是效果還是不甚理想 ;觸發時才實時畫出下一層節點技術難度很高 ,還好公司有比較現成的框架 ,光 java類和接口就有 10幾個 ,完全閱讀並理解顯然是不現實的 ,只能通過摸索把先有的業務和原來的接口進行不斷的測試 ,花費了一天時間才得以完成 .
關於 Web Service
Web Service是一種可以接收從 Internet或者 Intranet上的其它系統中傳遞過來的請求，輕量級的獨立的通訊技術。總得來講它能夠突破平臺限制 ,穿越企業防火牆 ,通過開放的接口和認證實現信息的共享和傳遞 .
WSDL
對於商業用戶來說，要找到一個自己需要使用的服務，他必須知道如何來調用。 WSDL (Web Services Description Language) 規範是一個描述接口，語義以及 Web服務爲了響應請求需要經常處理的工作的 XML文檔。這將使簡單地服務方便，快速地被描述和記錄。
對於 .Net的 WSDL調用來說是很簡單的 ,例如一個簡單的 VBS腳本
Dim obj
set obj=createobject("MSSOAP.SoapClient30")
obj.MSSoapInit "QueryService.wsdl"
MsgBox obj.getPhoneByName("0578", "XXX 單位 ",10)
但是對於 java而言調用一個 .Net產生的 WSDL簡直被折磨了半死 ,Q公司又不肯提供技術支持 ,不斷的進行調試跟蹤最後才發現是一個 setEncodingStyle參數設置的問題 .
public class CpSpInterface {
protected Log logger = LogFactory.getLog(this.getClass());
private String endpoint = "http://192.168.1.2/Service1.asmx";
private String nameSpace = "GetSPInfo";
public String callGetIndexByType(String strTypeID, String strParaList,String strResultType)
{
String ret = "<?xml version="1.0" encoding="gb2312" ?><root status="1" lines="0"></root>";
try {
String methodName = "GetIndexByType";
Service service = new Service();
Call call = (Call) service.createCall();
call.setTimeout(new Integer(120000));
call.setTargetEndpointAddress(new java.net.URL(endpoint));
call.setUseSOAPAction(true);
call.setSOAPActionURI(nameSpace + "/GetIndexByType");
call.setOperationStyle(org.apache.axis.constants.Style.WRAPPED);
call.setEncodingStyle("literal");
call.setOperationName(new QName(nameSpace, methodName));
StringHolder holder = new StringHolder("0");
// Set Call Parameter
call.addParameter(new QName(nameSpace, "strTypeID"),
Constants.XSD_STRING, ParameterMode.IN);
………… 略
//Set back Parameter
call.setReturnType(Constants.XSD_STRING);
ret = (String) call.invoke(new Object[] { strTypeID, strParaList,
strResultType });
ret = ret.replaceAll("utf-8","gb2312");
logger.debug("ret = "+ret);
logger.info("return errorcode = " + holder.value);
} catch (Exception e) {
logger.error("Error " + e);
}
return ret;
}
}
關於 Ajax
單純從 Ajax本身來說，其最主要不過就是解決在網頁上一個無刷新獲取數據的問題，再加上減少了數據的傳輸量，將數據解析的工作推到了客戶端，的確能解決很多傳統的問題，很方便的實現一些動態效果。 Ajax的應用本來是爲了增強用戶體驗 ,於是就有了一個新的名詞 WEB2.0.
其實在該系統的應用很簡單即獲取到 COM組件傳過來的主叫號碼和被叫號碼 ,記錄到 Session中 ,具體的 JSP頁面是一個非常簡單的頁面 ,就不必再寫了 ,呵呵
Xh = new ActiveXObject(“Microsoft.XMLHTTP");
var link = "./beginSession.do?callID="+callid+"&callerNo="+callerno+"&calleeNo="+calleeno;
關於交流
其實整個系統過程中 ,最頭疼的問題還是和 Q公司的交流 ,Q公司是一家新型的在電信領域剛剛展露頭腳的公司 ,面對這樣一個揚名立萬的機會 ,當然不會錯過了 ,於是派了 40個現場人員進行現場開發 ,真不知道他們的項目成本控制是怎麼做的 ;而我方總計也只有 3個人 ,參與接口的討論最多也只有 2個人 ;每次都要面對對方嗡嗡的一羣人的輪番轟炸 ;最後不得已拉着 Z電信公司一起參與討論 .還好對方也有很多的軟肋 (雙方都要提供一些接口 ),才不至於被折磨的太慘 .
2006年 2月 28日 ,是個特殊的日子 ,當天下午 Q公司終於把接口調試完畢 ,當天晚上我也把相應的功能完善起來 ,終於到了一個 milestone.彷佛經歷了一場噩夢 .連續 3周的時間 ,每天從早 9點到晚上 3點不停的寫代碼 ,調試代碼 ,查詢資料 ,討論需求 ;極度厭煩了這樣的生活 ,最後終於藉口身體不好 ,倉惶逃離了這個地方 ,把工作交接給一位新來的同事 ,他又繼續維護了 6個月 .我回去後休整了 1個多月 ,身體仍然比較虛弱 ,再過了一個月就黯然離職了
補記 :時年 6月份便發生了一幕慘劇 ,一位同事因過勞而死 …不知道我再呆上幾個月 ,輪到的是不是我 …
