作者: admin

  • Java基礎知識J2EE初學者需要注意的問題

    J2EE體系結構簡單介紹

    一、J2EE提出的背景

    1、企業級應用框架的需求

    在許多企業級應用中,例如數據庫連接、郵件服務、事務處理等都是一些通用企業需求模塊,這些模塊如果每次再開發中都由開發人員來完

    成的話,將會造成開發週期長和代碼可靠性差等問題。於是許多大公司開發了自己的通用模塊服務。這些服務性的軟件系列同陳為中間件。

    2、為了通用必須要提出規範,不然無法達到通用

    在上面的需求基礎之上,許多公司都開發了自己的中間件,但其與用戶的溝通都各有不同,從而導致用戶無法將各個公司不同的中間件組裝

    在一塊為自己服務。從而產生瓶頸。於是提出標準的概念。其實J2EE就是基於JAVA技術的一系列標準。

    注:中間件的解釋中間件處在操作系統和更高一級應用程序之間。他充當的功能是:將應用程序運行環境與操作系統隔離,從而實現應用程

    序開發者不必為更多系統問題憂慮,而直接關注該應用程序在解決問題上的能力。我們後面說到的容器的概念就是中間件的一種。

    二、相關名詞解釋

    容器:充當中間件的角色

    WEB容器:給處於其中的應用程序組件(JSP,SERVLET)提供一個環境,使JSP,SERVLET直接更容器中的環境變量接口交互,不必關注其它系

    統問題。主要有WEB服務器來實現。例如:TOMCAT,WEBLOGIC,WEBSPHERE等。該容器提供的接口嚴格遵守J2EE規範中的WEB APPLICATION標準

    。我們把遵守以上標準的WEB服務器就叫做J2EE中的WEB容器。

    EJB容器:Enterprise java bean容器。更具有行業領域特色。他提供給運行在其中的組件EJB各種管理功能。只要滿足J2EE規範的EJB放入

    該容器,馬上就會被容器進行高效率的管理。並且可以通過現成的接口來獲得系統級別的服務。例如郵件服務、事務管理。

    WEB容器和EJB容器在原理上是大體相同的,更多的區別是被隔離的外界環境。 WEB容器更多的是跟基於HTTP的請求打交道。而EJB容器不是

    。它是更多的跟數據庫、其它服務打交道。但他們都是把與外界的交互實現從而減輕應用程序的負擔。例如SERVLET不用關心HTTP的細節,

    直接引用環境變量session,request,response就行、EJB不用關心數據庫連接速度、各種事務控制,直接由容器來完成。

    RMI/IIOP:遠程方法調用/internet對象請求中介協議,他們主要用於通過遠程調用服務。例如,遠程有一台計算機上運行一個程序,它提供

    股票分析服務,我們可以在本地計算機上實現對其直接調用。當然這是要通過一定的規範才能在異構的系統之間進行通信。 RMI是JAVA特有

    的。

    JNDI:JAVA命名目錄服務。主要提供的功能是:提供一個目錄系統,讓其它各地的應用程序在其上面留下自己的索引,從而滿足快速查找和

    定位分佈式應用程序的功能。

    JMS:JAVA消息服務。主要實現各個應用程序之間的通訊。包括點對點和廣播。

    JAVAMAIL:JAVA郵件服務。提供郵件的存儲、傳輸功能。他是JAVA編程中實現郵件功能的核心。相當MS中的EXCHANGE開發包。

    JTA:JAVA事務服務。提供各種分佈式事務服務。應用程序只需調用其提供的接口即可。

    JAF:JAVA安全認證框架。提供一些安全控制方面的框架。讓開發者通過各種部署和自定義實現自己的個性安全控制策略。

    EAI:企業應用集成。是一種概念,從而牽涉到好多技術。 J2EE技術是一種很好的集成實現。

    三、J2EE的優越性

    1、基於JAVA技術,平台無關性表現突出

    2、開放的標準,許多大型公司已經實現了對該規範支持的應用服務器。如BEA ,IBM,ORACLE等。

    3、提供相當專業的通用軟件服務。

    4、提供了一個優秀的企業級應用程序框架,對快速高質量開發打下基礎

    四、現狀

    J2EE是由SUN公司開發的一套企業級應用規範。現在最高版本是1.4。支持J2EE的應用服務器有IBM WEBSPHERE APPLICATION SERVER,BEA

    WEBLOGIC SERVER,JBOSS,ORACLE APPLICATION SERVER,SUN ONE APPLICATION SERVER等。

  • CCNA Security Exam Tutorial: When It’s Good To Add Salt

    ITCERT提供的廣告:

    When you started studying for your CCNA certification exam, one of the very first things you learned was the major difference between the enable password and the enable secret – the enable secret is encrypted by default, where the enable password is just sitting there in clear text, waiting to be read!

    When you look at the enable secret in a Cisco router configuration, it looks like it would be impossible to guess. 640-802:Cisco Certified Network Associate(CCNA) After setting the enable secret on this router to the word security, here’s how it appears in the configuration:enable secret 5 $1$24me$gVFxUOI4gYp0IQbhtH8Rz0

    That password has been encrypted by MD5, the Message Digest 5 algorithm. The result of the MD5 algorithm being applied to the password is a 32-character hexadecimal value.

    That password is hard to guess, but not terribly hard to crack. Anyone looking over your shoulder would not be able to come up with that password, but there are readily-available password cracking software devices that can crack that encryption in a matter of minutes. That’s true of any MD5-encrypted password, not just those on Cisco routers.So what can we do about this? We can add SALT to our MD5.

    The salt itself is simply a string of random characters that are added to the encryption process. Salting makes it much more difficult for a hacker to come up with the password; each bit added by the salt process literally makes it twice as difficult for the password to be compromised. A recent Wikipedia entry states that if a password was one of 200,000 words, a 32-bit salt would require 800 trillion hashes for a full-blown brute force attack.

    The actual creation and application of a salt is beyond the scope of the CCNA Security exam, but once you’ve earned that valuable certification – or maybe while you’re preparing for it – do a Google search on “salt md5” and read up on this powerful security tool. In the meantime, look for more CCNA Security tutorials on the site you’re on now as well as my website!

    Chris Bryant, CCIE #12933, is the owner of The Bryant Advantage, home of over 100 free certification exam tutorials, including Cisco CCNA certification test prep articles. His exclusive Cisco CCNA study guide and Cisco CCNA training is also available! Visit his blog and sign up for Cisco Certification Central, a daily newsletter packed with CCNA, Network+, Security+, A+, and CCNP certification exam practice questions! A free 7-part course, “How To Pass The CCNA”, is also available, and you can attend an in-person or online CCNA boot camp with The Bryant Advantage!

  • 好用的 MS SQL 2005 字串加密應用 ( MD5 & SHA1 )

    部門最近決議,要將早期舊系統中使用者密碼的部分轉為加密字串,當然隨之而來的技術討論會議就開始了。
    有人質疑為什麼密碼一定要加密呢??這個問題牽扯到資訊安全的環節了。請想想以下情況:

     

     

     

     

    • 駭客入侵資料庫竊取資料
    • 公司內部有心人士將資料庫內容偷偷竊取
    • 網管人員偷偷使用主管級的帳密登入系統

    當一個公開的系統帳密完全外洩時,輕則系統下架不使用;重則公司或部門將面臨結束營業的情形 (TigerLin 朋友的公司曾經發生過,想當然爾…結束營業)。這就是一直強調密碼要編碼過的原因所在了。

    在找了 MSDN 相關文件之後發現…其實 SQL 2005 就有內建的函式可直接應用了,而且很方便的呢。不過…中間也是發生了一點插曲,折騰了一下才試出來 ^~^a …

    MS SQL 2005 字串加密函式 — HashBytes

    HashBytes提供的加密法有幾種 (MD2、MD4、MD5、SHA、SHA1 ),但最常使用的還是 MD5 與 SHA1。而整個使用過程的感覺來說,基本上還算簡單~只是有一些”眉角”要注意。首先先測試 HashBytes 運作是否合乎需求: 

     
    1 select hashbytes(‘MD5’,‘12345’as MD5,hashbytes(‘SHA1’,‘12345’as SHA1; 
       


      

     產生以下的結果

    MD5 SHA1
    0x827CCB0EEA8A706C4C34A16891F84E7B 0x8CB2237D0679CA88DB6464EAC60DA96345513964

    針對 HashBytes 的應用測試過程

    接下來開一個測試用的 Table 來試試轉換的結果如何:

     

     
    1 CREATE TABLE [dbo].[HashTest](  
    2 [INDEX_NO] [int] IDENTITY(1,1) NOT NULL,  
    3 [PassWD] [varchar](50) COLLATE Chinese_Taiwan_Stroke_CI_AS NOT NULL,  
    4 [HashedPW] [varchar](50) COLLATE Chinese_Taiwan_Stroke_CI_AS NULL,  
    5 CONSTRAINT [PK_HashTest] PRIMARY KEY CLUSTERED  
    6 (  
    7 [INDEX_NO] ASC 
    8 )WITH (IGNORE_DUP_KEY = OFFON [PRIMARY]  
    9 ON [PRIMARY]  
    10 GO 
       

     

    在 PassWD 欄位中輸入一些字串, HashedPW 保持空白,等等要看加密的結果是否正確

    INDEX_NO PassWD HashedPW
    1 test  
    2 test2  
    3 test3  

     然後將以 SHA1 加密過的字串更新到 HashedPW 看看 —

     
    1 update hashtest set hashedPW = HashBytes(‘SHA1’, PassWD) 
       

     咦??怎麼都變成亂碼了啊 O_o…這樣子根本不能用啊…再看了 MSDN 之後發現該函數的回傳值型態為 varbinary,並不是字串形態,所以要再使用 sys.fn_VarBinToHexStr() 進行轉換的動作 — 
      

    INDEX_NO PassWD HashedPW
    1 test 咐戔 L s???閨
    2 test2
    3 test3 >縛 鄀 o Y

     

     
    1 update hashtest set hashedPW = sys.fn_VarBinToHexStr(HashBytes(‘SHA1’, PassWD)); 
       

     

    輸出的結果就正確了 🙂

    INDEX_NO PassWD HashedPW
    1 test 0xa94a8fe5ccb19ba61c4c0873d391e987982fbbd3
    2 test2 0x109f4b3c50d7b0df729d299bc6f8e9ef9066971f
    3 test3 0x3ebfa301dc59196f18593c45e519287a23297589

     

    最後…改一下登入機制的驗證方式,修改比對的欄位後…原本明碼的密碼就可以隨風而逝了,需求達成~

  • SQL Server 2005 檢視表的不思議現象

     春天到了~俗話說「春天後母臉 — 說變就變」,那系統可以說是女人心 — 永遠都有可愛又難以捉模的時刻~ 咳咳咳…扯遠了…回到正題 ^^”。由於最近公司的 DB Server 進行升級,系統也將原本的 SQL 2000 升級至 2005,步驟在一般不過了:
    安裝 => 設定 => 升級 SP2 => 完成把原本的 MDF 掛載上去後,修改連線密碼,一切正常!!上線~隔天不思議的情形就發生了…網頁上顯示的資料居然都是最舊的!! What’s up !?!?

    將頁面上使用的 view 表以 SSMS 開啟,發現排序的指令沒有生效
    程式內使用的 SQL String 為 “Select * from vwTest”
    而 vwTest 內則有下 order by [dtDate] 的語法,恩恩~怎麼看都沒錯啊~
    切到檢視表設計下看…排序以及資料都是正常的!!好…看來是檢視表內的 order 語法無法在讀取檢視表 vwTest 的第一時間生效了…馬上進行 Troble Shooting!!

    在 Google 了一下之後,首先看到了微軟的 KB,裡面說到其症頭為 —

    The SELECT statement uses the TOP (100) PERCENT expression.
    ==> vwTest裡面的確有用到 TOP (100) PERCENT 的選取方式


    The SELECT statement uses the ORDER BY clause.
    ==> 也有使用 order 排序

    解決方式 —
    936305 Cumulative update package 2 for SQL Server 2005 Service Pack 2 is available

    安裝時明明有升級到 SQL 2005 SP2 … 現象卻依然持續的發生,只好繼續找了 T_T
    最後在國外的 SQL SERVER 為主題的 BLOG 中找到了一篇文章說明了因應的對策

    • 在Select語法的部分,將原本的 Select TOP (100) PERCENT 改為 Select TOP 2147483647
    • 有找到另外一種解法,將 Select 語法改為 Select TOP (99.999999999999)也是可行的,注意~小數點後面是 12 個 9 唷!

    我採用的方法是 12 個 9 的方法,將 vwTest 的語法修改之後並儲存,在開啟的同時…一切又回到美好的正常狀態了!這裡也有一個看起來頗奇怪的地方呢,不知道各位有沒有注意到,既然都選取 TOP 100 PERCENT 了,不就是選取全部了嗎?為什麼還要特別加上以百分比選取的語法呢?後來跟程式設計師討論了一下,可能是早期的程式產生器所產生的 VIEW 特有的現象,由於程式已經是 N 年前寫的,現在已經不可考了。但為了安全…輕易的把 TOP 100 PERCENT 拿掉又怕會有更不可思議的意外,因此暫且先用 14個 9 的選取方式代替。

    小插曲 — 針對 SQL 2005 SP2 的重大更新
    這一個更新是在找資料中看到的,標題很有趣的寫著 “A Service Pack for a Service Pack
    這個 hotfix 修正的可是一個大問題呢…”清除工作未在排定的時間間隔執行
    什麼 O_o…排定的工作不會執行,這可是大事,當然馬上把它下載到 SERVER 進行安裝
    有先發現總比到後面問題發生在處理好多了,這雖然是一個小插曲,卻是一個很大的意外收穫呢 ^^b

    參考資料:
    http://support.microsoft.com/kb/926292/en-us
    http://support.microsoft.com/kb/933508
    http://support.microsoft.com/kb/933508
    http://www.themssforum.com/SQLServer/Order-views/
    http://sqlblog.com/blogs/tibor_karaszi/archive/2007/11/28/sorted-views.aspx
    http://www.sqlmag.com/Article/ArticleID/95449/sql_server_95449.html

     

    來源:www.51-pass.com

  • IT & Program 那一方有優勢?

    某一天上班的時間,我正在規劃新的網路架構與DNS安全性的議題報告時,突然有一種很深的感慨…
    在近十年的工作資歷當中,IT相關的部份一直佔得很重,當然台灣企業來說不太像國外一樣分的那麼清楚,所以當IT的同時也兼著開發ERP系統,可以說是「IT為主 程式為輔」的界定吧^^b!之前在鈊象電子任職軟體設計師的時候,就一直覺得很吃力,雖然說寫程式是我的興趣,也算是專長之一,但跟極專業的軟體設計師比我當然還是差多了。有鑑於此在感觸的當下我把 MSN 的暱稱改為「當 IT 比當程式設計師有成就感多了!」~
    後來 Maduka 敲我的 MSN 時看到我的暱稱,只發出了一陣陰險的笑聲(XD),莫約十秒後他的暱稱變成「當程式設計師 比當 IT 有成就感多了!」。好吧~我被嗆了~哇哈~由於當下我沒想太多,看了笑一下之後我就繼續我的工作了。
    下班騎機車回來途中,腦袋一直運轉著下午的話題,分析到底是 IT 好還是 Program 好,後來發現…
    現在是網際網路發達的年代,如果今天程式寫的再好,那沒有好的 IT 架構也沒有用啊!舉個例子:
    ================================================
     今天公司有發送大量電子報的需求,RD部門已經將程式的效能、執行續、網路 I/O 相關的部份寫的非常好了!測試 1000 封發送速度極快,已經可以上線了!但正式運作時則經常發生以下情形 —
    01.退信率高
    02.發信時部門網路幾乎癱瘓
    03.發送到某個數量時 SMTP Server 主機會產生死當
    04.超過 10000 封以後寄信速度會只剩下 1 / 6
     
    從以上的情形看來是程式設計的問題嗎?為什麼在測試的時候很ok,一上線就變成這個樣子呢?
    會以電子報作為例子是因為這是個很典型的 程式 + IT 一起運作的例子 (我在某機公司就遇到這樣的情況),問題其實是出在 —
    01.DNS 無 MX 紀錄或是反解不正確
    02.網路架構層級太深,電子報的 Server 位於網路底層,但 SMTP Server 在網路的上層
    03.沒有調整 SMTP 工作階段的數量,大量發送的情況下 MTA 程式更是一個關鍵點
     
    讓我們來針對每一個問題作處理 (以下為 IT 部門的負責範圍) —

    1. DNS 的 MX 紀錄設定好,PTR紀錄設反解,如果要成功機率更高則加入 SPF Record 與 CallerID Record
    2. 可將 SMTP 放置到 DMZ 中,減少封包經由 NAT 轉換的損失,並將電子報主機移至跟 SMTP Server 同一個 Switch ( 視情況是否加入 DMZ)
    3. MTA來說,可以使用 Linux Base 的 Postfix,並參閱官方的設定說明 (建議發送 eDM 不要使用 IIS 的 SMTP)。

    ================================================
     
    由以上的例子可以看得出來,程式寫的好但是 IT 架構設計不良,程式的好無法顯現出來
    IT 架構設計優良,但是沒有好的程式來執行測試,那其價值也無法發揮
     
    最後,我的 MSN 參照「食神」中的撒尿牛丸改成「IT 與 Program 有什麼好爭的!混在一起搞個 ERP 不就得了!
    最後我的朋友也很欣然同意了我的說法了 ^^
     
    現在是團隊合作的時候,單兵作戰的時代已經過去了,唯有多方面的配合才能讓企業更加快速的成長
    願我的朋友們每一位都可以擔任團隊中的關鍵角色,你們一定可以的!GO~
  • 新時代新觀念 — DNS 與 Mail是密不可分的 (含Caller ID與SPF說明)

     由於現在的頻寬日益提昇,Mail Server軟體安裝的過程也可以說是點滑鼠即可完成
    很多朋友近期一直問我:「我家裏已經是光纖了!又是固定IP,那我申請一個Domain就可以架設Mail Server了吧~應該跟Web Server一樣簡單」
    其實…這樣的觀念是錯誤的!Web Server本身只需要A紀錄或是CNAME別名解析,指向到對的IP就可以了

    但Mail Server之間的交談要比Web的複雜,小弟在這裡列出幾項Mail Server必備的紀錄型態:
    MX紀錄:郵件交換紀錄,在2000以前SAPM不會太多的年代,如果沒有MX紀錄的話Server會去尋找A紀錄作查詢;但在2000年以後SPAM大量散發的年代,Mail Server沒有MX紀錄的話大多都是會被Block掉。
     
    SPF紀錄:全名為Sender Policy Framework,這算是一個比較新潮的紀錄型態,2003年SPAM最氾濫的年代由openspf組織制定,加入SPF紀錄的Mail Server可以降低被當成SAPM的風險。如要查詢或是產生SPF紀錄可以到 http://old.openspf.org/wizard.html?mydomain=microsoft.com 或是 微軟的CallerID小工具 會有精靈模式的工具幫助產生。
     
    CallerID紀錄:微軟推行的anti-spam的紀錄型態,原生格式為 XML,以microsoft.com為例
    ====================== 紀錄開始 ======================
    <ep testing=”true” xmlns=”http://ms.net/1“>
        <out>
            <m>
                <mx />
                <a>213.199.128.160</a>
                <a>213.199.128.145</a>
                <a>207.46.71.29</a>
                <a>194.121.59.20</a>
                <a>157.60.216.10</a>
                <a>131.107.3.116</a>
                <a>131.107.3.117</a>
                <a>131.107.3.100</a>
            </m>
        </out>
    </ep>
    ====================== 紀錄結束 ======================
    是不是感覺像在寫程式呢?其實這就是微軟所推行的CallerID紀錄的格式,不要懷疑~
    要產生相當簡單,可以到 微軟的CallerID小工具 ,除了可以產生SPF以外也可以產生CallerID紀錄。
     
     
    以上三個是針對Mail Server (無論是Exchange、Postfix等,都通用)重要的DNS紀錄
    下一篇文章將會寫出如何加入諸如SPF與CallerID特殊紀錄的方式。

  • 計算主機虛擬化後節省的電費

    因為工作上的需要,必須將 Server 整理並將占用空間減少,便開始著手進行虛擬化工程。公司有 18 台 伺服器,其中 7 台都是屬於「骨董」的 PC 了,規格大約是介於 P-II 233 ~ P-III 800 之間,記憶體最大也不超過 256M 的「PC Server」。這些主機除了效能不彰、硬碟會嘎嘎叫以外,重點還是…很熱,尤其是幾台 K7 的更是火熱的很,冷氣開放也壓不過那 CPU 熱情散發的氣息啊 Orz…

    咳咳…虛擬化不是該文的重點所以不詳述,切入主題!花了一些時間將低階的主機虛擬化到高階主機裡面後,主管便提出「變更後報告書」的需求,What??又是報告啊~好吧~沒寫過虛擬化變更的報告,就當練習好了~首先虛擬化第一個直覺想到的優點就是「省電」,恩恩~好~看看節省了多少電費,馬上到台電的網站查詢電費的計算方式!~

    查到的公式在設計到 EXCEL 裡面,填入一些必需的數字,恩…每一台主機的電費就出來了,加加總總後,再加上冷卻成本 (BTU) 節省的費用,乗上 12 個月就是這一次虛擬化所節省的費用~就這樣~算出來的數字就可以當作一個指標了 ^^b

    零件的耗電要怎麼查詢??經過 Google 一番,找到一個好站:http://www.journeysystems.com/?power_supply_calculator
    使用很簡單,點選下方那個大大的「Start the Calculator」後即會跳出一個 POPUP 視窗
    TigerLin 以 SERVER 為範例,這裡點選「SERVERS」 的 Botton計算電費-選擇平台類型

     

    選擇相關的配備,並按下「Find My Wattage!」系統就會建議使用至少幾瓦的 POWER,但 TigerLin 還是最自己稍微加總一下以取得較準確的耗電量。這裡要強調,新的零件大多都沒有內建在裡面,但是其標示的耗電量還是可以當作參考用,至少寫報告交差有個依據,個人 PC 誤差不會超過 100 元就不要太計較了啦 ^~^a計算電費-選擇零件

     

    最後再將所得的數字填入 EXCEL 中紅色欄位的地方,並參照裡面的用電度數範圍填入每度單價,即可大略算出每台主機的電費,報告有數字後也可安心交出去了 ^^b

    image

     

    因為 TigerLin 對 EXCEL 不是很熟…所以介面醜醜的也不太人性化…但至少還可以計算啦 XD
    按這裏從 SkyDrive 下載「計算電費小工具」

  • grepWin:Linux grep 指令的 GUI Interface For Windows

    之前操作Linux系統時常常會用到“grep”這個指令,當一個目錄的檔案數量眾多時,在Linux為了過濾目錄檔案名稱都會下“ls –al | grep config”,這樣檔案清單有符合“config”字串的才會被顯示,在操作設定檔察月的時候grep一樣是很好用。

    前幾天在Windows修改廠商的某個.NET專案,那個程式真的是寫得很…恩…古典又帶有初學者的味道Orz~這個專案中共連接了10個以上不同的DB ,一般來說將Connection String寫在Web config中,然後在.cs中呼叫定義的連線字串。這一個專案非常好樣的~原本廠商的程式設計師居然將10個DB的連線分佈在好幾百個不同的.cs中!!在這幾百個檔案中也不知道有幾個是所需要修改的檔案!!太可怕了…

    一般檔案數量少的話TigerLin會用Notepad++這套免費編輯工具一次拖進去進行修改,但這次光是用WINDOWS內建的搜尋介面–>內含文字功能我就要重複輸入N次做搜尋…聽起來一點都不SMART Orz~

    正當我在思索應該如何更Smart work時, Will推薦給我曙光般的工具– grepWin

    Google一下之後,在這裡下載完安裝後,試用了一下果然威力驚人!!更迷人的是還有整合滑鼠右鍵的ShellExtension功能(請看下圖)~ 

      12

     

    針對要進行搜尋的資料夾按下滑鼠右鍵,就會看到grepWin了,點一下滑鼠後即可進入GUI介面。這裡我使用了一個C#專案的資料夾,並以“NameSpace”進行測試搜尋,搜尋結果如下(順便附上常用欄位說明避免以後自己也忘了:P ):

    123
     

    太黯然太銷魂了~且還支援正規表示式,在搜尋比對過濾清單的過程中列出的清單準確度高,再搭配Notepad++真的是修改大量檔案必備的工具。還有一個小”眉角”要說明一下,請看下圖:

    124

    如果把grepWin下方的檔案清單權選拉到Notepad++後,拉到一般文字的編輯視窗會將檔案變成清單一般的輸出路徑;而拉到上方的Dock則會將所有拖曳的檔案全數開啟~就看各位的需求是怎樣了~最後要強調~正規表示式+ grepWin真的是超好用的啦^^b~推薦給各位~