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è)組織模式。
2009年10月7日 #
@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
很久沒有動手寫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交互標準。
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í)行,否則,當主線程結(jié)束后,子線程也將結(jié)束。
需求:
系統(tǒng)A與系統(tǒng)B分別部署在不同域的兩臺服務(wù)器中,但它們的身份都統(tǒng)一在身份認證服務(wù)器中;身份認證信息以Session方式存貯于各自系統(tǒng)中,并輔以cookie進行使用。
當用戶在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作為身份標識,因此,需要用戶在瀏覽器中允許使用cookie的設(shè)置;
2)由于在iframe中進行跨域重定向,因此需在IE安全中的跨域瀏覽子框架項設(shè)為啟用:
4、源碼文件:
……
在windows下進行j2ee項目開發(fā)和部署時,常需要對系統(tǒng)存在問題進行更深入的分析。由此,實時的javacore就是分析的最佳方式之一。但如何以最方便直接的方式產(chǎn)生javacore文件,就是這項工作必需做的準備工作了。
1、通過dos窗口,進入至jdk安裝目錄下的bin目錄中;
2、運行jconsole.exe,并設(shè)置信息輸出的目標文件,以便于分析,否則將直接輸出至屏幕上;
3、連接正在運行的目標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
在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ù)。
消息中心中間件,包括消息總線和消息客戶端兩部分:消息客戶端負責業(yè)務(wù)類消息實例的產(chǎn)生、發(fā)送消息實例到消息總線、接收從消息總線轉(zhuǎn)發(fā)而來的消息實例、將收到的消息實例交由其載體應(yīng)用系統(tǒng)進行與之對應(yīng)的業(yè)務(wù)處理等活動;消息總線負責接收從消息客戶端產(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)化處理、日志記錄等也在配置中心進行配置和管理。
在消息中間件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)境中。
在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)準確及時的發(fā)出執(zhí)行指令操作,完成其所需的業(yè)務(wù)活動來看,網(wǎng)絡(luò)方面和系統(tǒng)和硬件方面都不存在問題。
2、在外網(wǎng)環(huán)境下,直接進行各消息客戶端和消息總線的服務(wù)的檢測,所發(fā)請求都能夠正確的到達指定目標,WEBService的響應(yīng)也正常且正確,也就是說,各應(yīng)用系統(tǒng)加載的消息服務(wù)運行也正常。
3、根據(jù)本次檢測需要,另行開發(fā)消息中心專用檢測工具,為本次和今后的行的消息中心檢測和問題分析,作好更充分的準備。
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)建和緩存,以提升消息中心資源利用率,并提升其訪問性能。
當存在多網(wǎng)絡(luò)用戶訪問時,可能因消息中心存貯的WEBService連接并不是其用戶所使用的那個網(wǎng)絡(luò)的WEBService服務(wù)地址,此時,消息肯定是無法送達至此用戶所需要的目標的。因此,報”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ù)器的,當然,消息無法發(fā)送至目標就成為必然了。
既然已經(jīng)找到問題,那就動手,將消息中心的配置信息指向應(yīng)用服務(wù)器后,重啟應(yīng)用系統(tǒng)后測試,問題果然解決!
通過應(yīng)用服務(wù)器進行后臺自動處理的,進行HTTP或WEBService活動,其目標必需是它能夠訪問的有效地址!這個問題在以前也曾經(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é)省大量的工作量。