lbom

昨日年終總結(jié)會，公司總裁給出IT產(chǎn)業(yè)未來發(fā)展的幾個新趨勢，值得我們這些從事軟件工作的人員沉思，現(xiàn)對他的發(fā)言摘錄如下：
1）管理虛擬化：有形的組織型管理和虛擬的IT流程管理相結(jié)合管理模式；
2）制造虛擬化：由生產(chǎn)線工人和由程序控制的機器人相結(jié)合的生產(chǎn)模式；
3）渠道虛擬化：由實體銷售店和虛擬的網(wǎng)上銷售相結(jié)合的渠道管理模式；
4）服務(wù)虛擬化：實體保養(yǎng)維修和遠程診斷，軟件更新相結(jié)合的服務(wù)模式；
5）組織虛擬化：垂直的組織機構(gòu)和橫向的項目型組織機構(gòu)相結(jié)合的企業(yè)組織模式。

今天，花費1個小時，研究了一下在Windows下，使用Telent登錄至UNIX的腳本，現(xiàn)將其貼下，以供下次使用（tt.bat）

 

 

@echo off
echo set sh=WScript.CreateObject("WScript.Shell") >telnet_tmp.vbs

echo WScript.Sleep 3000 >>telnet_tmp.vbs
rem ----------------UNIX IPAddress
echo sh.SendKeys "open 10.0.18.100{ENTER}" >>telnet_tmp.vbs

echo WScript.Sleep 3000 >>telnet_tmp.vbs
rem ----------------userID
echo sh.SendKeys "root{ENTER}" >>telnet_tmp.vbs

echo WScript.Sleep 3000 >>telnet_tmp.vbs
rem ----------------password
echo sh.SendKeys "root{ENTER}" >>telnet_tmp.vbs

echo WScript.Sleep 3000 >>telnet_tmp.vbs

echo sh.SendKeys "ls {ENTER}">>telnet_tmp.vbs

start telnet

cscript //nologo telnet_tmp.vbs

rem del telnet_tmp.vbs

 

1)啟動LiveWriter客戶端

2)添加Blog帳戶:

3)設(shè)置日志類型：

4)連接測試

很久沒有動手寫WebService了，這次，借項目間隙，對系統(tǒng)進行一個小改造，將一部分功能使用WS進行封裝，為下一步異構(gòu)系統(tǒng)集成打下基礎(chǔ)。

但在WS化時，由于日久生疏，一個小小的WS化變動，卻花了整整好幾天時間！為此，狠下以來，將其過程進行記錄，以便下次參考。

 

WS整體流程：

以下分別介紹：

1、設(shè)計和實現(xiàn)WebService服務(wù)端功能組件，用于統(tǒng)一處理針對本應(yīng)用系統(tǒng)所需進行WebService化的邏輯實現(xiàn)。并將系統(tǒng)邏輯處理中的對象轉(zhuǎn)成序列化后的String對象，以符合WebService交互標(biāo)準(zhǔn)。

2、根據(jù)SBPApi.java，生成WSDL等：通過Eclipse右鍵菜單中的WebService-->Create Web Service項。完成后，會在web目錄下建立wsdl目錄和SBPApi.wsdl，在WEB-INF目錄下建立（改寫）server-config.wsdd等文件,并完成對web.xml的修改。其操作流程示如下：

3、根據(jù)SBPApi.wsdl，生成WebService客戶端開發(fā)包和部署文件：

1)為不影響已有項目，可另建java Web項目；

2）將wsdl目錄復(fù)制至新項目對應(yīng)的web目錄下；

3）通過eclipse已提供的webService插件（右鍵）功能，生成客戶端開發(fā)包所各文件。此時，所生成的文件與服務(wù)端對象文件結(jié)構(gòu)一至。

4）調(diào)整關(guān)聯(lián)引用文件，將其調(diào)整至客戶端開發(fā)包，從而避免與服務(wù)器端的引用路徑重復(fù)而引發(fā)不便，并將服務(wù)器SDK中已有文件刪除。

5）建立客戶端的快速使用代理SBPClient.java，對WebService服務(wù)端交互工作的SBPApiSoapBindingStub.java進行客戶端封裝，并根據(jù)服務(wù)端中交互對象進行反向工程，其示例結(jié)構(gòu)如下：

6）將clientApi下的所有文件打包后，加入測試項目進行測試。此時，因客戶端所使用的服務(wù)端對象未包含在WebService客戶端開發(fā)包中，因此需要將服務(wù)端對象也一同打包。

7）測試。

4、開發(fā)環(huán)境：Eclipse3.3.1.1 + JDK1.5.06 + Apache Axis version: 1.4

在一次基于多線程的編碼測試中，發(fā)現(xiàn)繼承Runnable接口的線程實現(xiàn)類在運行時并未按預(yù)計啟動多線程，經(jīng)分析和比較后，找出問題所現(xiàn)，現(xiàn)將其記錄下來，以供分享。

Java中，多線程編程中的線程編寫，有兩種方式，即擴展Thread基類或繼承Runnable接口；例如：

public class T extends Thread {

public void run() {

……

}

}

public class R implements Runnable {

public void run() {

……

}

}

對于擴展Thread的實現(xiàn)類T，可以使用T.start()來啟動此線程；如

public static void main(String[] args) {

Thread t = new T();

t.start();

}

但對于繼承Runnable接口的實現(xiàn)類R，因接口中并沒有提供直接啟動線程的start()方法，只有一個線程主邏輯運行的run()方法。此時，如執(zhí)行run()，會因為R.run()只是作為此線程實現(xiàn)類的一個方法，并未在主線程之外，啟動另一個線程，從而導(dǎo)致R.run()阻斷主線程繼續(xù)向下執(zhí)行；并未達到多線程運行的目的。

錯誤啟動代碼如下：

public static void main(String[] args) {

R r = new R();

r.run();

}

那么，如何使用另外線程來啟動繼承Runnable接口的實現(xiàn)類呢？以下就是它的正確的使用方式：

public static void main(String[] args) {

R r = new R();

Thread t = new Thread(r);

t.start();

}

此時，需注意，在主線程執(zhí)行時，需等待子線程執(zhí)行，否則，當(dāng)主線程結(jié)束后，子線程也將結(jié)束。

需求：

系統(tǒng)A與系統(tǒng)B分別部署在不同域的兩臺服務(wù)器中，但它們的身份都統(tǒng)一在身份認證服務(wù)器中；身份認證信息以Session方式存貯于各自系統(tǒng)中，并輔以cookie進行使用。

當(dāng)用戶在A系統(tǒng)登錄后，訪問B系統(tǒng)時，由于是跨域訪問，導(dǎo)致身份信息不能正確的傳遞到B系統(tǒng)中，從而致使用戶需在B系統(tǒng)中重新登錄。

解決方案：

處理這類跨域訪問時，我們最先使用從B系統(tǒng)向C通過HttpRequest(類AJAX請求)的方式獲取身份信息，此方式好處是同步處理，方便用使用；但其限制諸多，如需設(shè)置信任站點、用戶訪問確認等，甚至，在對應(yīng)用服務(wù)器作了一次安全升級后，根本無法訪問了。因此，需另行開辟途徑，于是，在同事建議下，我們使用IFrame內(nèi)嵌跨域驗證網(wǎng)頁，來解決此問題。

1、原理設(shè)計：用戶在訪問B系統(tǒng)時，先使用一內(nèi)置的iframe，并將iframe的src指向身份認證服務(wù)器系統(tǒng)代理驗證接口；如果用戶已經(jīng)在A系統(tǒng)中進行過登錄，即A域了中已存在著身份認證信息后，身份認證服務(wù)器中也將具有其身份信息將其附帶著身份認證信息后重定向訪問B系統(tǒng)代理接口；B系統(tǒng)代理驗證接口在接收到由A系統(tǒng)傳遞而來的身份認證信息后，通過身份認證服務(wù)器驗證后，在B系統(tǒng)所在域重建身份認證信息。

2、實現(xiàn)邏輯貼碼：

1）B系統(tǒng)代理驗證接口：

（1）IFrame邏輯貼碼：

（2）JS檢測是否通過認證邏輯貼碼：

2）身份認證服務(wù)器端接口（JSP）：

3、注意事項：

1）由于身份認證中心使用cookie作為身份標(biāo)識，因此，需要用戶在瀏覽器中允許使用cookie的設(shè)置；

2）由于在iframe中進行跨域重定向，因此需在IE安全中的跨域瀏覽子框架項設(shè)為啟用：

4、源碼文件：

……

在windows下進行j2ee項目開發(fā)和部署時，常需要對系統(tǒng)存在問題進行更深入的分析。由此，實時的javacore就是分析的最佳方式之一。但如何以最方便直接的方式產(chǎn)生javacore文件，就是這項工作必需做的準(zhǔn)備工作了。

1、通過dos窗口，進入至jdk安裝目錄下的bin目錄中；

2、運行jconsole.exe，并設(shè)置信息輸出的目標(biāo)文件，以便于分析，否則將直接輸出至屏幕上；

3、連接正在運行的目標(biāo)jvm；

4、連接后的jconsole如下：

5、通過通過Ctrl+Break組合鍵，產(chǎn)生javacore至指定文件中。

6、下一步就是對所產(chǎn)生的javacore文件進行具體的分析和使用了。

某日，公司進行年度一次的體檢！

在連續(xù)查出10個脂肪肝后，醫(yī)生對第11個進來檢查的人說：“等會，我們的B超機好像出問題了，等檢修后再進行”

這是一個真實的事件，我們這些IT行業(yè)的從業(yè)人員，多坐少動，壓力大，時間長，導(dǎo)致體質(zhì)差的邊醫(yī)生都懷疑機器了！

唉！

一、項目建立及應(yīng)用實現(xiàn)

1、建立J2ME項目

2、在完成開發(fā)后，進入Application Descriptor編輯界面

3、因默認情況下，Application Descriptor文件中未定義MIDlet啟動對象，因此需使用EditPlus或記事本等文本編輯器，編輯Application Descriptor文件（位于項目根目錄下），并添加以下項目，如：

4、運行Application Descriptor編輯界面中的Lanuch as enumlated Java ME JAD，進行測試

5、在步驟4之后，會在項目根目錄下的.mtj.tmp中生成LaunchFromJAD子目錄，其中的worm.jad和worm.jar即是手機程序的安裝文件

6、將worm.jad和worm.jar復(fù)制至手機中，運行worm.jad進行安裝后，即可使用

二、問題分析：

1、如報【文件不完整】錯誤，則檢查worm.jad中的項目是否完整。在Eclipse中使用Lanuch as enumlated Java ME JAD測試通過，并自動生成的此文件，一般都是完整的，不需作任何修改。

2、如報【版本錯誤】，則檢查您在Eclipse中使用的的模擬器版本是否是您手機所支持的，出現(xiàn)此錯誤后，將模擬器版本調(diào)低試試。其位置如下

三、開發(fā)環(huán)境：

1、java JDK1.6.0_10；

2、EclipseV3.3.1.1；

3、sun公司J2ME-WTK開發(fā)包：sun_java_wireless_toolkit-2_5_2-ml-windows.exe

4、Eclipse移動應(yīng)用開發(fā)包：eclipseme.feature_1.7.9_site.zip

 

 

消息中心產(chǎn)品簡介

產(chǎn)品簡介

在XXX產(chǎn)品框架中，我們根據(jù)產(chǎn)品發(fā)展規(guī)劃和業(yè)務(wù)領(lǐng)域需要，使用基于JMS技術(shù)，通過應(yīng)用WEBService，開發(fā)了消息中心中間件（簡稱MC）。通過消息中間件，我們可以實現(xiàn)各系統(tǒng)間的異步數(shù)據(jù)交換和事務(wù)處理、執(zhí)行不需前臺使用人員干預(yù)的如后臺業(yè)務(wù)和數(shù)據(jù)同步工作，也可用來處理一些受到安全和其它一些因素制約，導(dǎo)致無法直接通過數(shù)據(jù)庫或應(yīng)用系統(tǒng)進行處理的受限業(yè)務(wù)。

消息中心中間件，包括消息總線和消息客戶端兩部分：消息客戶端負責(zé)業(yè)務(wù)類消息實例的產(chǎn)生、發(fā)送消息實例到消息總線、接收從消息總線轉(zhuǎn)發(fā)而來的消息實例、將收到的消息實例交由其載體應(yīng)用系統(tǒng)進行與之對應(yīng)的業(yè)務(wù)處理等活動；消息總線負責(zé)接收從消息客戶端產(chǎn)生并發(fā)送而來的消息實例、消息重建、根據(jù)消息配置進行消息實例重建,將重建后的消息實例轉(zhuǎn)發(fā)至對應(yīng)的消息客戶端等活動。

消息客戶端與XXX各應(yīng)用系統(tǒng)集成在一起，并通過應(yīng)用系統(tǒng)開放WEBService端口進行消息的發(fā)送和接收等，從而避免單獨部署和發(fā)布所帶來的困難和額外資源消耗。消息總線可單獨部署，也可和消息客戶端一樣，與XXX應(yīng)用系統(tǒng)集成部署，在XXX產(chǎn)品框架下，有且只需要一套消息總線即可滿足需要。消息配置中心，其作用包括配置和管理消息中心各組成部分的部署方式和訪問信息，以此將消息中心各部有機的聯(lián)系起來；同時，各消息業(yè)務(wù)應(yīng)用，也使用配置文件進行配置化管理，并與消息中心各組成部分進行關(guān)聯(lián)配置，從而形成一個統(tǒng)一且開放的整體；其它的如性能優(yōu)化處理、日志記錄等也在配置中心進行配置和管理。

應(yīng)用現(xiàn)狀

在消息中間件V1.0版本開發(fā)完成后，我們即將其投入實用。在XXX各分子系統(tǒng)這近一年時間的運行和使用過程中，消息中心很好的完成了預(yù)定任務(wù)，其可靠性、可擴展性和適用性得到很好的驗證。以此為據(jù)，通過使用消息中心，開發(fā)出基于消息中心的客戶化應(yīng)用和業(yè)務(wù)活動也在持續(xù)的增加中，到現(xiàn)在為止，已經(jīng)有包括網(wǎng)絡(luò)檢測、信息同步、配置更新、電子目錄樹更新、權(quán)限同步等諸多應(yīng)用是基于消息中心應(yīng)用開發(fā)，并很好的使用在XXX各分子系統(tǒng)的測試和內(nèi)網(wǎng)正式環(huán)境中。

問題出現(xiàn)、描述、分析與處理記錄

問題出現(xiàn)

在XXX系統(tǒng)正式接入外網(wǎng)后，通過對業(yè)務(wù)進行跟蹤，發(fā)現(xiàn)外網(wǎng)用戶（系統(tǒng)）所產(chǎn)生的消息實例無法正常的到達指定的消息總線及消息客戶端。最主要的體現(xiàn)是權(quán)限同步消息應(yīng)用無法正常完成的問題，導(dǎo)致外網(wǎng)用戶權(quán)限未得到及時更新。對此過程中消息中心所涉及部分進行分析發(fā)現(xiàn)：所有的權(quán)限同步消息實例在產(chǎn)生后，不能正常的將此消息實例發(fā)送至消息總線，分析失敗原因，只有一種，那就是”connect time out”。從此信息可看出，應(yīng)該是外網(wǎng)系統(tǒng)所發(fā)出的消息無法通過WEBService送達指定的消息總線接收端所至。但從內(nèi)網(wǎng)發(fā)出的同一類消息，其發(fā)送和接收卻又都是正常的。

分析過程記錄

1、先分析我們系統(tǒng)的整體部署方式，如下圖所示：

根據(jù)外網(wǎng)用戶可正常登錄和訪問系統(tǒng)，并可通過系統(tǒng)準(zhǔn)確及時的發(fā)出執(zhí)行指令操作，完成其所需的業(yè)務(wù)活動來看，網(wǎng)絡(luò)方面和系統(tǒng)和硬件方面都不存在問題。

2、在外網(wǎng)環(huán)境下，直接進行各消息客戶端和消息總線的服務(wù)的檢測，所發(fā)請求都能夠正確的到達指定目標(biāo)，WEBService的響應(yīng)也正常且正確，也就是說，各應(yīng)用系統(tǒng)加載的消息服務(wù)運行也正常。

3、根據(jù)本次檢測需要，另行開發(fā)消息中心專用檢測工具，為本次和今后的行的消息中心檢測和問題分析，作好更充分的準(zhǔn)備。

4、通過檢測工具，發(fā)現(xiàn)，外網(wǎng)環(huán)境下，消息客戶端和消息總線之間不能夠聯(lián)通，從而找到問題所出：即不知是何原因，導(dǎo)致外網(wǎng)消息與外網(wǎng)的消息總線間聯(lián)絡(luò)不通！

5、對外網(wǎng)用戶消息產(chǎn)生和發(fā)送的過程和邏輯實現(xiàn)進行分析：我們發(fā)現(xiàn)，為了滿足應(yīng)用系統(tǒng)外網(wǎng)訪問的需要，我們對消息系統(tǒng)配置信息中服務(wù)地址的ServerName進行了偽處理，即在運行時，根據(jù)用戶瀏覽器的請求頭來判斷用戶使用的是哪一個WEB服務(wù)器地址，并將此地址動態(tài)的代替消息配置中的各ServerName信息，從而保證各使用用戶只能夠訪問其指定的WEB服務(wù)器，從而避免因WEB服務(wù)器的不匹配而影響其訪問速度、處理效率等故障的發(fā)生。此方式已在我部門多套同時服務(wù)于內(nèi)外網(wǎng)絡(luò)的系統(tǒng)中得到可靠的驗證。

那么，會不會因為ServerName在動態(tài)解釋過程中，因多并發(fā)情況下，因后訪問者將前訪問者的ServerName改寫而導(dǎo)致錯誤的解釋，即將不同網(wǎng)絡(luò)用戶的消息地址進行張冠李戴而導(dǎo)致消息無法正常發(fā)送呢？

分析消息中心各部分WEBService生成和使用機制：因系統(tǒng)的并發(fā)性要求較高，在高峰期其在線用戶可達3000人，并發(fā)用戶在300以上，且系統(tǒng)穩(wěn)定性要求極高。為提高系統(tǒng)的性能和穩(wěn)定性，在系統(tǒng)啟動時即將消息中心各部的WEBService連接進行創(chuàng)建和緩存，以提升消息中心資源利用率，并提升其訪問性能。

當(dāng)存在多網(wǎng)絡(luò)用戶訪問時，可能因消息中心存貯的WEBService連接并不是其用戶所使用的那個網(wǎng)絡(luò)的WEBService服務(wù)地址，此時，消息肯定是無法送達至此用戶所需要的目標(biāo)的。因此，報”connect time out”錯誤就成必然的了。

既然已找到問題的可能原因，我們立即進行著手分析和解決：根據(jù)部署要求，我們對對消息服務(wù)連接服務(wù)進行了升級，即將服務(wù)請求進行分類處理和實現(xiàn)，并在消息配置中對所使用的部署方式、代理實現(xiàn)后，交由測試人員進行部署和測試。

測試結(jié)果：令人失望的是，此問題依然存在！在通過外網(wǎng)WEB服務(wù)器訪問的系統(tǒng)，其消息還是無法發(fā)送至消息總線。由此得知，此種分析方向是錯誤的！

至此，好像已經(jīng)走入了死區(qū),能想到的方式都已經(jīng)想到了，但問題到底出在哪呢？

問題解決

在一次與同事聊天的過程中，忽然想到一個問題，那就是：我們的消息的產(chǎn)生和應(yīng)用都是由應(yīng)用系統(tǒng)和與之集成在一起的消息客戶端自動產(chǎn)生和處理的，此過程中完全不受人工干預(yù)和影響。而應(yīng)用系統(tǒng)是部署在應(yīng)用服務(wù)器中，WEB服務(wù)器僅是用來處理用戶的HTTP請求à將此請求轉(zhuǎn)發(fā)至對應(yīng)的應(yīng)用服務(wù)器后à將應(yīng)用服務(wù)器的響應(yīng)返回給用戶。

在此過程中WEB服務(wù)器并未對用戶業(yè)的http請求進行過任何業(yè)務(wù)上的處理！那么，問題會不會出在WEB服務(wù)器端呢？檢查一下消息中心的配置不管是使用ServerName還是寫死IP和域名，我們的消息中心配置的地址都是指向WEB服務(wù)器。而在應(yīng)用系統(tǒng)發(fā)現(xiàn)消息時，其所在位置是應(yīng)用服務(wù)器。而應(yīng)用服務(wù)器是無法直接訪問部署于外網(wǎng)IP中的WEB服務(wù)器的，當(dāng)然，消息無法發(fā)送至目標(biāo)就成為必然了。

既然已經(jīng)找到問題，那就動手，將消息中心的配置信息指向應(yīng)用服務(wù)器后，重啟應(yīng)用系統(tǒng)后測試，問題果然解決！

通過應(yīng)用服務(wù)器進行后臺自動處理的，進行HTTP或WEBService活動，其目標(biāo)必需是它能夠訪問的有效地址！這個問題在以前也曾經(jīng)碰到過，只是由于時間隔得太久，且這些場景應(yīng)用出現(xiàn)太少，而導(dǎo)致再次發(fā)生。

補充與心得

1、    基于應(yīng)用系統(tǒng)或后臺自動觸發(fā)的一些業(yè)務(wù)邏輯，如其中存在著系統(tǒng)間相互訪問或遠程調(diào)用等，必需以應(yīng)用系統(tǒng)自身為根，進行連接測試；通過外層包裝或其它代理，進行訪問時，必需先剝離過外層包裝或其它代理后，再進行連接測試，并以測試結(jié)果，作為決策的依據(jù)！此舉適用于各類系統(tǒng)的架構(gòu)設(shè)計和邏輯實現(xiàn)過程中。

2、    基于中間件產(chǎn)品應(yīng)用，及時開發(fā)與之配套的檢測和使用工具，是一件必不可少的工作，此舉將為后期的實施和問題分析節(jié)省大量的工作量。