1、websphere 怎麼看命令行 日誌
最近領導安排兼職維護Webshere中間件，對這種中間件絲毫不了解，特別是日誌，看著全是亂碼，不知道代表啥意思，在網上查了一下，與大家分享
看websphere日誌，我們一般看兩種，一個是SystemOut.log，另一個是SystemErr.log這兩個是最常見的日誌，怎麼看呢？需要注意一下標志位：
F ：致命消息
E ：錯誤消息
W ：警告信息
A ：審計消息
I ：參考消息
C ：配置消息
D ：詳細消息消息
O ：通過用戶應用程序或內部組件直接寫入SystemOut.log
R : 通過用戶應用程序或內部組件直接寫入SystemErr.log
Z : 表明不可識別的類型的佔位符
此時我們再去看SystemOut.log、SystemErr.log日誌文件，會發現常見的只有R（用戶應用程序或內部組件直接寫入）和O（用戶應用程序或內部組件直接寫入）兩種類型，有時偶爾會出現一個I（參考消息），那麼我們在日常巡檢過程中只需查看有無其它類型標志位信息即可！
2、websphere 證書安裝 ikeyman警告
我也碰到同樣的問題了，再安裝了一遍GSK也沒用
3、一個關於websphere的菜鳥問題
隨著Internet網路的迅速發展，基於互聯網的企業應用要求軟體平台具有開放性、分布性和平台無關性。於是就相繼出現了RPC/COM/CORBA等技術，但這些技術在實際應用中存在著許多不足和局限。它們的特定協議難以通過防火牆，因而不適於Web上的應用開發。為了進一步開發基於Web的應用，出現了Sun公司的Sun ONE（Open Net Environment 開發網路環境）和Microsoft公司的.NET等Web 服務技術體系。
Sun ONE體系結構以Java語言為核心，包括J2SE/J2EE/J2ME和一系列的標准、技術及協議。它包括Sun獨有的iPlanet軟體系列，其中有在市場上受歡迎的LDAP目錄伺服器軟體，以及Forte for Java——便於在任何環境下書寫Java 語言的軟體工具。我們很容易就能從網上免費獲得和使用包括Java 集成開發環境、Java資料庫和中間件（Application Server）伺服器等產品，以及它們的源代碼。Sun ONE更接近或能滿足互聯網在智能化Web服務方面對分布性、開發性和平台無關性的要求。
隨著Java技術的不斷發展，它根據市場進一步細分為:針對企業網應用的J2EE（Java 2 Enterprise Edition）、針對普通PC應用的J2SE（Java 2 Standard Edition）和針對嵌入式設備及消費類電器的J2ME（Java 2 Micro Edition）三個版本。本文就Sun ONE的Java核心應用——J2SE/J2EE/J2ME作一些介紹。
J2EE技術應用
J2EE是Sun公司推出的一種全新概念的模型，比傳統的互聯網應用程序模型更有優勢。
J2EE模型
J2EE的應用編程模型（J2EE Blueprints）提供了一種用於實施基於J2EE多層應用的文檔和實例套件的體系模型，簡化了這項復雜的工作。它被開發人員用作設計和優化組件，以便開發人員從策略上對開發工作進行分工。
J2EE應用編程模型要求開發者將自己的工作分成兩類：商業邏輯和表示邏輯，其餘則由系統資源自動處理，不必為中間層管道進行編碼。這樣，開發人員就能將更多的時間花在商業邏輯和表示邏輯上。對重視縮短項目周期的公司來說，這種轉變深受歡迎。
J2EE平台
J2EE平台是運行J2EE應用的標准環境，由J2EE部署規范（一套所有J2EE平台產品都必須支持的標准）、IETF標准集和CORBA標准組成。最新的J2EE平台還添加了JavaBean組件模型。開發人員可以利用JavaBean組件模型來自定義Java類實例，並可通過已定義的事件訪問Java類。
J2EE支持EJB，因此開發人員可以執行多用戶交易功能。當在J2EE伺服器上運行時，Enterprise JavaBeans將應用邏輯分成可再利用和可擴展的代碼段。Enterprise JavaBeans並不是新特徵，但是通過定義標准客戶端和服務API，J2EE增強了它的能力和可移植性。
EJB在伺服器的一個容器內運行，提供所有典型的中間層服務，如事務管理、安全、遠程客戶連接、生存周期管理和資料庫連接緩沖。為了讓事務系統在存在EJB容器的情況下運行，開發人員只需在部署描述文件中定義Beans的事務屬性即可。
J2EE通過定義一組標準的結構來實現它的優勢，例如：
1.J2EE Application Programming Model，是一種用於開發多層次、瘦型客戶用戶程序的標准設計模型；
2. J2EE Platform，是一個標準的平台，用來整合J2EE的應用程序，並指定一系列的介面和方法；
3. J2EE Compatibility Test Suite，是一套兼容測試組件，用來檢測產品是否同J2EE平台兼容；
4.J2EE Reference Implementation，用來示範J2EE的能力。
J2EE伺服器
Sun的J2EE伺服器通過Java 命名和目錄介面（JNDI）、認證、HTTP及與Enterprise JavaBeans兼容的能力，提供命名和目錄服務。JNDI是Java平台的一種標准擴展版，向企業內的命名和目錄服務提供具有Java功能的，帶有統一介面的應用，包括LDAP。
J2EE伺服器還利用了Java Servlet技術。Java Servlet可以看作是運行在伺服器上的一個小程序，它向開發人員提供以組件為基礎創建基於Web應用的、獨立於平台的方法。它不像利用CGI那樣具有性能局限。Java Servlet是一種擴展Web伺服器功能的簡單技巧。由於它是用Java編寫的，因而能夠訪問整個Java API庫，也包括用於訪問企業資料庫的JDBC API。
JSP是Java Servlet的一種擴展。Java Servlet提供開發和顯示來自伺服器的互動式Web頁。如今JSP又有了進一步的改進，它使得創建和支持靜態模板和動態內容相結合的HTML和XML頁面更加容易。
安全性
J2EE平台定義了一種標準的公開存取控制規則，當程序在企業平台上開發時就已被程序師定義和解釋了。J2EE也需要提供一個標準的注冊機制，以便應用程序不會將這些注冊機制和邏輯相混合，從而使相同的工作執行於大量的不同環境中時並不需要改變源代碼。例如：J2EE應用程序開發人員可以指定幾個安全級別，當用戶訪問數據時，他們可寫出代碼來檢查當前用戶許可權的級別。在開發階段，開發人員賦予多組用戶適當的安全級，使應用程序在執行限制操作之前能夠容易的判斷限制級。
J2EE 平台是Java技術企業級應用的最佳平台，它可以讓程序員迅速、快捷地開發和分布企業級應應用程序。以下便是它的相關技術：
1.Enterprise JavaBeans Architecture，企業級JavaBeans 定義了一個應用程序介面。它可以使程序員迅速開發、發布和管理跨平台的、基於組件的企業級應用程序。
2.JavaServer Pages，JSP 技術提供了一種簡單、快速的方法來創建動態網頁。通過它，可以快速地開發基於Web的應用程序，並且這些應用程序都是與平台無關的。因為JSP與ASP很相似，所以熟悉ASP的人學習它就很容易了。
3.Java Servlet，提供了應用程序介面。通過它可以簡單快速地開發並擴展伺服器功能。就發展趨勢來看，它將來有可能取代CGI。
4.J2EE Connector，提供了一種標准結構來聯接不同的企業信息平台。
5.Java Naming and Directory Interface(JNDI)，在Java 平台與商業信息之間，JNDI提供了統一、無縫的標准化連接。通過使用JNDI，程序員可以在企業多命名與目錄服務之間傳送Java 應用程序。
6.Java Interface Definition Language(JIDL),通過使用CORBA，可以提供協同工作的能力。JIDL包括一個IDL-to-Java 編譯器和支持IIOP（Internet Inter-Orb Protocol）的ORB。
7.JDBC,幾乎是為所有的資料庫提供了統一的介面，同時可以創建高級工具和介面。
8.Java Message Service(JMS)，它幾乎規范了所有企業級消息服務，如可靠查詢、發布消息、訂閱雜志等各種各樣的PUSS/PULL技術的應用，並且為它們提供了一個標准介面。
9.Java Transaction API(JTA)，為分布式系統中可處理的應用程序規定了一個高級的管理規范。
10.JavaMail,JavaMail應用程序介面提供了一整套模擬郵件系統的抽象類。通過JavaMail，可以創建郵件或消息應用程序。
11.RMI-IIOP,使用它就可以只用Java 技術和Java RMI介面開發客戶機與伺服器的遠程介面。
J2EE使用固定的文件格式捆綁某個模塊：用.ear文件捆綁J2EE應用程序；用.jar捆綁Enterprise Bean。例如，一個.ear文件包含一個.xml文件作為其分布描述，還包含一個或多個.jar和.war文件；一個.jar文件除了包含它的分布描述外，還包含了作為Enterprise bean的.class文件。
J2EE應用程序的開發階段分為四步：1.Enterprise Bean創建；2.Web Component創建；3.J2EE應用程序裝配；4.J2EE應用程序分布。以下是J2EE兼容產品部分列表：
BEA WebLogic Server 6.0、Borland App Server、HP Bluestone Total-e-Server、IBM WebSphere Application Server、IONA iPortal Application Server、iPlanet Application Server、Macromedia JRun Server、Oracle 9i Application Server、SilverStrean Application Server、Sybase EAServer、TogetherSoft ControlCenter、Java 2 SDK Enterprise Edition。
J2ME技術的應用
J2ME（Java 2 Platform Micro Edition）是為無線電子市場所設計的，包括JVM規范和API規范。其API規范是基於J2SE（Java 2 Standard Editon)的。J2ME 定義了一套合適的類庫和虛擬機技術。這些技術可以使用戶、服務提供商和設備製造商通過物理（有線）連接或無線連接，按照需要隨時使用豐富的應用程序。
J2ME又被稱為Java 2 微型版，被使用在各種各樣的消費電子產品上，例如智能卡、手機、PDA、電視機頂盒等方面。當然了，J2ME也提供了Java語言一貫的特性，那就是跨平台和安全網路傳輸。它使用了一系列更小的包，而且Javax.microedition.io 為J2SE包的子集。J2ME可以升級到J2SE和J2EE。
在J2ME出現之前，我們更多接觸到的是Java卡（Java Card）、嵌入式Java（Embedded Java）和實時Java（Real Time Java）等。其中Java卡是針對SIM卡、智能卡等設備而定製的最小Java子集，比J2ME還要小，移植性也不強。嵌入式Java則針對特殊用戶自行配置Java類庫和VM（Virtual Machine，虛擬機）。它對資源需求極小，可運行在無圖形用戶介面和網路的設備上，可以添加用戶專用的API，但是它就無法移植。實時Java是由IBM領導的實時定製Java專家組負責實施的，現在還在不斷完善中。不過，從嚴格意義上來說，它們都不是真正的J2ME。
像其它版本一樣，J2ME具有很多Java技術特性，主要有：
1.可以在各種支持Java的設備上運行；
2.代碼短小；
3.充分利用Java語言的優勢；
4.安全性好；
5.用J2ME實現的應用可以方便地升級到J2SE、J2EE。
J2ME的配置和框架
為了支持用戶和嵌入式市場提出的靈活性和可定製性要求，J2ME被設計得更加模塊化和可縮放化。J2ME在設備原有的操作系統上建造了3層軟體來實現這種要求：
1.JVM層，這層基於宿主操作系統，按照某一種J2ME的配置，實現了JVM。
2.配置層，這層對於用戶可見度要低一些，但對框架層非常重要。它針對「水平」市場的需求，定義了Java虛擬機的最小功能集和Java類庫的最小集合。在某種意義上，配置層定義了開發者在所有設備上都可以使用Java特性和類庫的「最小公分母」。
3.框架層，這層對於用戶和應用程序提供者來說是最常見的。它針對「垂直」市場的需求，定義了Java虛擬
嘟嘟廣州社區為你解答
4、websphere application server 如何使用命令形式部署應用?
哥指的的是非圖形界面安裝吧！要用-silent命令；
下面是給你截取的一部分內容：
參照www.ibm.com.cn文檔。
關於本任務靜默安裝使用安裝向導以靜默方式安裝產品，無需圖形用戶界面。靜默安裝使安裝程序讀來自您提供的文件的所有響應，而不顯示向導界面。要在靜默安裝期間指定非預設選項，必須使用響應文件。要以靜默方式安裝，必須接受協議選項中的許可協議。
過程
登錄至操作系統。 另外，選擇一個允許所有者讀/寫文件的 umask，並允許其他用戶按照主要的系統策略來訪問這些文件。對於 root 用戶，建議選擇 umask 022。對於非 root 用戶，可以根據用戶是否共享組而選擇使用 umask 002 或 022。要驗證 umask 設置，發出以下命令：umask要將 umask 設置設置為 022，發出以下命令：umask 022 在 Windows 系統上安裝時，如果您的安裝者用戶帳戶具有下列高級用戶許可權，那麼將自動創建 Windows 服務來自動啟動應用程序伺服器：作為操作系統的一部分作為服務登錄例如，在某些 Windows 系統上，單擊管理工具 > 本地安全策略 > 用戶許可權指定來設置高級選項。有關更多信息，請參閱 Windows 文檔。 如果打算將應用程序伺服器作為 Windows 服務來運行，那麼不要使用包含空格的用戶標識來進行安裝。無法驗證帶有空格的用戶標識。不允許這樣的用戶標識來繼續安裝。要解決此問題，請使用不包含空格的用戶標識來安裝。
將響應文件作為 myoptionsfile 復制到磁碟驅動器並定製它。請參閱定製響應文件 。原始文件的名稱為responsefile.nd.txt 。不要將選項行添加到包括以下參數的任何一個概要文件創建響應文件：-silent-silent 參數不是必需的。如果它存在於這些任何一個文件中，那麼在靜默安裝產品期間此文件無法創建概要文件。
發出正確的命令以使用定製響應文件。 例如，發出以下命令： mnt_cdrom/WAS/install -options /tmp/WAS/myoptionsfile.txt -silent "disc_drive_D:\WAS\install" -options "C:\temp\WAS\myoptionsfile.txt" -silent
responsefile.nd.txt
使用靜默安裝方式來安裝 WebSphere Application Server Network Deployment 指的是使用一個文件來提供安裝選項，而無須用戶交互。要配置安裝，請在發出安裝命令前更改響應文件中的選項。靜默安裝方式不接受交互安裝選項。要在靜默安裝期間指定非預設選項，必須使用響應文件。要以靜默方式安裝，必須接受協議選項中的許可協議。驗證是否提供了必需的磁碟空間。 請參閱iSeries 先決條件 ，以了解更多信息。 請參閱為產品安裝准備操作系統 ，以了解更多信息。因為 選項的值是 false，所以不要使用產品光碟上提供的預設響應文件來安裝產品。復制該文件，以將值更改為 true。
響應文件的位置樣本選項響應文件的名稱為 responsefile.nd.txt。 該文件位於產品光碟、定製安裝包（CIP）或所下載安裝映像上的 WAS 目錄中。
創建操作環境使用響應文件安裝產品會在預設情況下創建操作環境。安裝程序將執行以下操作：安裝新的產品代碼。創建預設概要文件。可以使用以下任何可用方法來創建更多概要文件： 使用概要管理工具。 請參閱使用圖形用戶界面來創建概要文件 。使用 manageprofiles 命令。請參閱manageprofiles 命令 的描述。使用帶有 createProfile="true" 選項的響應文件進行安裝，並選擇單元概要文件、Deployment Manager 概要文件、定製概要文件或帶有 -OPT profileType="profile_type" 選項的獨立應用程序伺服器概要文件。
使用響應文件進行安裝將產品光碟上 WAS 目錄中的 responsefile.nd.txt 文件復制到系統上您可輕松找到的位置。編輯此文件以定製安裝的值。例如，將該文件另存為 myresponsefile.txt。開始安裝。例如： install -options /tmp/WAS/myresponsefile.txt -silent
install -options C:\temp\WAS\myresponsefile.txt -silent
install -options /MYDATA/myresponsefile.txt安裝後，請檢查日誌以確定安裝是否成功。
5、WebSphere Application Server V8.5 帶來了哪些新特性
WAS V8.5 的提供了以下三個方面的新特性：
應用程序和服務的快速交付
改進操作效率和可靠性
增強的安全性和操控性
接下來，將從以上三個方面，分別向您介紹 WAS V8.5 的新特性。
應用程序和服務的快速交付
WAS
能夠協助企業通過快速創新性的應用程序提供給用戶豐富用戶體驗。開發者可以利用 WAS
支持的廣泛的開源編程模型並利用現有的開發技能來快速開發應用程序。該功能使得開發者能夠將項目求與編程模型和開發者技能相匹配。WAS
還能夠通過鼓勵復用和延長現有應用程序模塊來加速應用程序的交付。
下面的這些 WAS V8.5 的新特性能夠幫助快速交付析的應用程序和服務：
Liberty profile
擴展的工具及工具包
OSGI 編程模型的增強
支持 Java 7
Migration toolkit 的增加
Web 2.0 和 Mobile 工具集
Service Component Architecture OASIS 編程模型實現
回頁首
Liberty Profile
WAS
V8.5 中包含了 Liberty Profile，它是一款模塊化、動態性的應用伺服器概要文件。Liberty Profile
是兩種特定用例來設計的：開發者和輕量級生產運行時環境。對於開發者來說，它專注於開發者最經常進行的工作，使得開發者能夠盡可能快速且簡單地完成這些工
作。對於具有 Liberty Profile 可支持特性的生產環境來說，它提供了一個動態，低運行時內存消耗的，能夠使系統資源最大化的生產環境。
Liberty Profile 具有如下特點：
可以看作是開發文件的這樣的簡單可共享的配置，它使一個單獨的 XML 文件，或是通過引用的形式使用多個 XML 文件，通過它能夠在開發團隊中簡單地共享和復用配置信息；
動態運行時環境，填加特性或是更新配置，不需要重啟應用伺服器；
輕量級運行時環境，只需占很小的內存，開發者和管理員能夠根據應用程度的需要來細粒度的定義需要哪些特性，去除了由於不需要或未使用的特性所帶來的開銷；
可以通過 IBM Installation Manager 來安裝或者簡單地通過解壓一下壓縮文件來安裝；
簡化的布署方式，包括解壓一個包含了伺服器、應用程序和配置文件的壓縮包的方式來布置，通過托拽的方式來安裝應用程序，大大簡化了開發和測試流程；
與 WAS full profile 環境具有高度的保真性，它們具有同樣的容器和服務質量，這使得應用程序很容易的就可以從開發環境遷移到具有高服務質量的生產環境；
與 Network Deployment 作業管理器集成，您可以選擇通過作業管理器來進行伺服器的生命管理。
使用
WebSphere Developer Tools，您創建這樣的一個輕量級的應用務器配置就是簡單的幾個滑鼠操作。這個簡單靈活的配置存儲於
server.xml 文件中，它包含了伺服器運行時的配置。您可以使用 XML 編輯器或是 Eclipse-based 編輯器來直接對
server.xml 進行編輯。
這個簡單的配置列出來伺服器中安裝的特性。通過僅指定需要的特性，Liberty Profile
提供了應用程序所需的最小的運行時消耗。您可以通過集成開發工具（IDE）或者命令行來管理伺服器的生命周期，您可以通過客兩種方式簡單快速地創建、啟動
以及停止服務，或是獲取伺服器裝態。
對於團隊開發來說，Liberty Profile
提供對共享配置片斷的支持，這使得您能夠將應用程序與配置一起來維護，並共享給開發團隊。這種共享式配置減少了由於單一修改並將訪修改復制整個開發團隊所
帶來的開銷。例如，如果您有一個 50
人的開發團隊，現在您需要對一個數據源的定義進行行修改，這樣一個對於共享配置文件的改動，能夠自動的被所有的程序員獲取，而不是需要所有 50
個開發者手動地將這一變化在他們各自的配置中進行修改。您也可將一個配置好的 Liberty
伺服器與應用程序和配置文件一起打包，然後分發給團隊中其它程序員或者直接交給測試團隊或生產環境。
Liberty Profile
提供了多種應用程序的布署方式。您可以將應用程序的定義填加到 server.xml
文件中或者直接將應用扔到「監控」目錄中。伺服器自動的獲取取這些改動並將新加入的應用程序布署到運行時環境中。卸載應用程序，就是簡單地將應用程序的定
義從 server.xml 中去除或是從監控目錄中刪除。
您可以選擇通過 WAS ND 中的作業管理器來集中管理 Liberty Profile 伺服器的生命周期。作業管理器以無代理的方式通過系統用戶賬號來管理伺服器，包括啟動和停止伺服器實例。
Liberty Profile 不需要任何修改是就一個安全的伺服器。所有開放的埠都是本機，默認不開啟任何的遠程管理。Liberty Profile 支持下面的安全特性：
ssl-1.0，包含在 SSL 特定代碼中；
appSecurity-1.0，包括了所有的安全服務，認證注冊、授權，以及基於 Web 的安全代碼；
zosSecurity-1.0，包括了 SAF 注冊和授權代碼。
通過添加 ssl-1.0 特性就能啟用
SSL，SSL 在 sever.xml 中提供了 keyStore 密碼。在伺服器啟動時就會生成證書。您可使用安全工具來生成自簽署證書。更高級的
SSL 配置通 endpoint SSL 配置來實現。應用安全性，appSecurity-1.0，能夠使用簡單的基於 XML 的注冊，LDAP
注冊或是系統授權（SAF）注冊。
Liberty Profile 還能夠與 Webphere eXtreme Scale 和
IBM DataPower XC10 無縫的集成來提供彈性緩存功能。單獨的 Liberty Profile 伺服器就能夠通過 WebSphere
eXtreme Scale Grid 來維持 HTTP Session Failover 和高可用性。
關於 Liberty Profile 的更多內容，請參考 WAS V8.5 新特性專區中 《新一代輕量級應用伺服器 — WebSphere Liberty Profile Server 介紹》、 《 WebSphere Application Server V8.5 之 Liberty 安全特性》、 《利用 Liberty 構建高可用環境》 中的具體介紹
回頁首
擴展的工具和工具包
IBM
Rational Application Developer （以下簡稱 RAD）仍然是開發團隊在 WAS
上進行軟體開發時最受歡迎且功能豐富的開發解決方案。RAD 為開發者提供了單一的開發環境，有助於簡化和加速設計和編寫，以及測試 WebSphere
應用程序，和，維護這些用程序的核心工作。RAD 和 WAS 在技術和標準的定位策略是同步的，包括 Java EE 標准、SOA、Web 和
Web 2.0、Portal，和 OSGi 編程模型。
除了 RAD 以外，開發人員現在還可以使用 WebSphere
Application Server for Developer 作為測試將來會布署到 WAS 上的應用程序的運行時環。WAS for
Devloper 是免費的開發者桌面版。WebSphere Application Server Developer Tools for
Eclipse 使得在 Eclipse 開發環境構建和布署應用程序到 WAS 運行時環境進行測試變成了一件很容易的事情。
回頁首
OSGi 編程模型的增強
WAS V8.5 中 OSGi 應用程序的管理控制台補充了之的的命令行控制台。通過管理控制台，您可查看應用程序，包，服務，以及依賴關系。除此之外，您還可以查看 shared bundle space 以及查看 content bundles。
在
WAS V8.5 中，可以在 OSGi 應用程序中使用 EJB。EJB 打包布署到 EAR 文件或是 WAR 文件中，然後可以作為 OSGi
應用程序中的一部分來使用。每一個模塊都有它自己的 classloader，而且，默認地使用 parent-first
授權模型。該模型提供了模塊性，是現有技術的補充，與 OSGi 聯合使用 EJB 容器來進行類載入和生命周期管理。OSGi
生命周期管理允許原地更新和擴展。EJB 能夠在 OSGi Service Registry 中作為服務來發布，客戶端不需要了解該服務是由 EJB
來實現的。
現在您能夠在 OSGi 應用程序的 Blueprint XML 文件中配置 bean 安全性，這樣這個 bean
的方法就只有被賦予某個角色的用戶才能夠訪問。您可配置 bean 級別的安全性以便某一個角色能夠被賦予訪問訪 bean 的所有方法。您可以配置
method 級別的安全，這樣不同的角色會被賦予訪問特性方法的許可權。
關於 WAS V8.5 中 OSGi 新特性的更多內容，請參考 《 WebSphere Application Server V8.5 中 OSGi 新特性》 中的具體介紹。
回頁首
支持 Java 7
應用程序開發者現在能夠布署於 WAS V8.5 上的應用程序中使用 Java 7 的特性了。這使得無論是開發環境，還是生產環境都選擇最適合的 Java 版本。
WAS
V8.5 默認的底層 JVM 與 WAS V8.0 一樣，都是 Java
6。這有利於保持企業應用程序在應用伺服器版本間保持穩定性。然而，您可以通過 WAS v8.5 的可選擇 JDK 特性來選擇使用 Java
7，以便使用 Java 7 的新特性。
回頁首
Migration Toolkit 增強
WAS
V8.5 使得應用程序的在 WAS 版本間，或是其它的 Java EE 應用伺服器的遷移變得容易。Application Migration
Toolkit 能夠幫助您將應用程序從 WAS 的舊版本遷移到新的版本，也能夠將應用程序從 Tomcat，Oracle 和 JBoss 向
WAS 進行遷移。
Application Migration Toolkit
分析應用程序源代碼，找出其中潛在的遷移問題，包括已去除或不推薦使用的特性、行為變化、JRE 5 和 JRE 6 的差別，以及 Java EE
規范的改進和增強。您可以查看這些潛在的遷移問題，在某些地方，Application Migration Toolkit
能夠幫您進行快速修改。Application Migration Toolkit
在不能提供快速修改的地方，會提供修改的建議，幫助您進行代碼的修改。
Application Migration Toolkit 能夠作為插件安裝到 Eclipse 或是 RAD 中，可以在 IBM 的網站上免費下載得到：
http://www.ibm.com/developerworks/websphere/downloads/migtoolkit/
回頁首
Web 2.0 和 Mobile Toolkit
使
用 Web 2.0 和 Mobile Toolkit，WAS 開發人員能夠構建和部署使用如，HTML5、CSS3 和 Java Script
這樣的標准 Web 技術開發的移動應用程序。這些應用程序能夠運行於多種移動平台，包括
iOS，安卓，以及黑莓。在這些平台上的用戶體驗基本一致，並且支持觸碰操作。
2.0 和 Mobile Toolkit 簡化了向
Java Web 應用程序中填加 Ajax 桌面和移動用戶介面以及 REST web services。Web 2.0，如 Ajax 和
REST 技術能夠幫助開發者開發出更加互聯和互動的應用程序，能夠帶來更大的客戶滿意度，提高用戶生產率，和改善的用戶決策。
回頁首
改進的操作效率和可靠性
WAS 提供了業界領先的性能，操作靈活性和可靠性。客戶可以利用 WAS 的高性能來整合工作負載，降低管理開銷，這樣可在損失系統性能的前提下降低 TCO。WAS 傳統的支持能夠幫助客戶維持交易的一致性和整體的可靠性，降低由於系統宕機帶來的業務損失的可能性。
WAS V8.5 下面的特性能夠改進操作效率和可靠性：
智能管理
彈性的消息架構
回頁首
智能管理
管
能管理的功能被引入到了 WAS V8.5 中，它提供了一套虛擬架構，該架構重新定義了 Java EE
資源和應用程序的傳統定義以及它們之間的關系。這個應用程序的架構虛擬化有助於產品以最優化的方式來自動運行，提高了服務質量。通過這套帶有工作負載管理
的自操作環境的引入，您能使用更少的硬體來完成更多工作，降低 TCO。
智能管理提高了您的中間件環境能夠提供的服務質量。可配置的操作策略管理著應用程序的健康和性能。總之，智能管理能讓您體驗到這種自配置、自保護、自愈以及自優化的自動的中間件環境的優勢。
接下來，將向您介紹由 WAS V8.5 所提供的智能管理的概述。
應用程序版本管理
應
用程序版本管使得您能夠在不間斷對外服務的前提下，進行應用程序的更新。訪特性使得您能夠以一種不間斷的方式來布署產品應用程序。使用該特性，您可在生產
環境驗證新的應用程序而不會影響到終端客戶，這樣您就可以在不影響客戶訪問的情況下來對應用程序進行升級了。您也可以同時運行同一個應用程序的不同版本，
並把不同的用戶轉發到不同的版本。
應用程序版本管理有如下的優勢：
更新應用程序或環境不間斷對外服務；
同時運行同一應用程序的不同版本；
在將用戶請求轉發到應用程序的新版本之前，能夠在生產環境中對它進行驗證；
減少生產環境硬體花銷和降低宕機時間；
不間斷服務地輕松的地進行操作系統和 WebSphere 環境進行更新；
批量的進行應用程序更新。
在 WAS V8.5 中，您可以安裝同一應用程序的多個版本，它們叫做應用程序版本，定義哪一個版本是激活狀態並處理請求。一個應用程序版本，可以是以下三種狀態的任一種：
非激活狀態，意思是該版本目前已安裝但是不可用。
激活狀態，意思是該版本已安裝並且在運行應用伺服器上處於活動狀態處理請求。
驗證狀態，用於測試用途，請求可以選擇性發到該應用程序版本上來。
智能路由
智
能路由通過確保關鍵業務能夠被保證最高優先順序的方式來提高服務質量。發送到應用程序的請求是按優先順序排序的，而且是按照管理員事先定義的規則來進行轉發
的。定義規則的一種方式是採用服務策略。服務策略定義了如何根據請求的屬性，如 URI，客戶端名字，或是 HTTP
頭，來對進入的請求進行分類。您也可以通過這些屬性來對請求的重要性進行區分。
當進入的請求被處理時，用務策略被用於根據目標伺服器的需求和資源使用情況來決定將請求放入隊列以及在隊列中停留多久。通過這種方式，您可以給在您網站上購買商品的客戶更高的許可權，而給只是瀏覽商品的客戶稍低些的許可權。
通過服務策略，您可以分類、按優先順序地、智能地路由工作負載。您也可以按需的調整資源以便能夠達到服務策略的定義。服務策略可以看作是運行應用在業務和 IT 之間達成服務級別協議的技術實現。
應用伺服器健康管理
您
可以通過健康管理來根據預先設定的健康條件來自動的監控應用伺服器的健康狀況，當系統的健康狀況違返的健康條件，系統就會自動的採取措施。您可以監控應用
伺服器的狀態、感知問題，然後在系統出現宕機之前採取措施。健康管理監控和管理子系統根據用戶定義的健康策略來不斷的監控伺服器的運行狀態，來發現由於用
戶應用程序問問題導致的系統惡化。
健康策略設計用於發現潛在問題，並在問題發生時採取糾正措施。它可以幫助在發生嚴重問題之前發現問題，或
者通知管理員或者主動採取糾正措施。智能管理帶有一些預先定義的健康條件，如內存過量使用和請求或響應時間過長等等，來定義健康策略。您也可以根據伺服器
通過 PMI ， MBean Opertation 所收集到的性能條件，來自己定義定製的健康策略。
當
健康策略被違返時，糾正措施就能夠自動生效。糾正措施用於避免問題或是幫助進行問題診斷。預定義的措施包括了通知管理員，發送 SNMP
郵件，重啟伺服器，將伺服器置成維護模式，以及生成 Java Core 文件或是 Heap Dump
文件以用於問題診斷。您也可以定義自定義的的措施。糾正措施可以自動執行，也可以以一種
受同監控的模式來觸發。受同監控的模式需要管理員允許才可進行。
性能管理
性能管理是通過一套自優化的中間件架構來實現的。動態集群能夠根據用戶的響應期望來自動地、動態地增加或減少集群成員來為集群擴容或減容。您可以利用過載保護來限制隨需應變路由器向應伺服器轉發請求，以避免內存耗盡或 CPU 耗盡，或者兩者同時被耗盡。
在
靜態集群環境中，每一個應用程序都有確定數量的應用伺服器，整個環境要能夠處理在高峰訪問時期望的工作負載。這樣環境意味著，在非高峰時段，系統是沒有被
充分利用的。通常情況下，企業都有不只一個重要的應用程序。很有可能有多個應用程序，是在一天中的不同時候達到高峰訪問。通過動態集群，您可以通過將非高
峰時候的應用程序的系統資源轉移給高峰時候應用程序使用的方式，來使您的系統更有效率。
過載保護通過監控應用伺服器的內存和 CPU 的使用情況，然後調整發到應用伺服器上的請求，以避免內存或處理器被過度使用。內存載載保默認是禁用的。啟用該特性需要配置 autonomic request flow manager (ARFM)。
對
於動態集群來說，您可以指定最大堆使用百分比，以避免出現內存溢出錯誤。對於 CPU 過載保護，您可以指定最大 CPU 使用率，以避免由於 CPU
耗盡造成的各種各樣的錯誤。您也可設定一個拒絕策略用，訪策略可以拒絕不是已有會話的 HTTP 和 SIP 請求，用於防止 CPU 過載。
消息架構的彈性
WAS V8.5 在消息引擎方面（bus）提供了如下的關鍵性增強：
當遇到不能恢復的故障時，智能消息引擎會嘗試停止而不是讓整個 JVM 崩潰。
在一段可配的時間斷後，智能消息引擎能夠再次自啟用。在故障修復之後，智能消息引擎可以根據需要再次啟動以備後用。
智能消息引擎將用於記錄消息傳遞數的 re-delivery count 持久化到資料庫中，這樣即使消息引擎重新啟動，消息數也不會丟失，可以避免應用再次處理同一條消息。
回頁首
增強的安全性和操控性
WAS V8.5 帶來了良好的安全性或操控性，幫助企業降低運營成本，提高敏捷性。WAS 支持安全規范和細粒度的安全控制來幫助管理員高效地根據業務的需要來保護應用環境。
WAS V8.5 提供了如下的增強的安全性和操控性：
可選擇的 JDK
批處理的增強
通過檢查點來進行安全審計
跨組件跟蹤
可選擇 JDK
前面提到您可以通過特性擴展的方式來
將 Java 7 安裝到現有的 WAS 之上。然後，您可以通過可選擇 JDK 特性在 Java 6 和 Java 7
之間自由的切換。除此之外，在 IBM iSeries 和 IBM z/OS 平台上，您還可以在 32 位和 64 位的 JDK 之間進行切換。
您可以通過以下方式來為您的拓撲配置 JDK：
管理控制台
wsadmin AdminTask 命令
manageSDK 命令行工具
在您的拓撲中，可以某些結點使用默認的 SDK，而其它結點採用 Java 7。您可以通過命令行工具來為您的應用伺服器或者集群來指定 JDK 的版本。
除了使用 RAD，您還可以使用 Apache Ant 或 Maven 來構建或測試 Java 7 應用程序。
批處理的增強
WAS 處理的傳統的 Java EE 應用程序的類型多為處理短時少量的交易單元。大多數情況下，請求僅需要幾秒的處理時間即可完成。但是，有很多應用程序要處理那種計算和資源密集型的批處理操作。
WAS 中的批處理功能擴展了應用伺服器在處理傳統 OLTP 應用程序的同時去適應那種需要批處理應用程序。批處理應用程序可能需要幾個小時甚至幾天來完成，運行時會使用大量的內存和處理器資源。
WAS 提供了一個基於 Web 的控制台，叫做作業管理控制台。通過這個控制台，你可以提交作業，監控作業的執行，對作業進行一些操作，和查看作業日誌。
WAS V8.5 要現有批處理特性的基礎上，通過集成了 WebSphere Compute Grid V8 的批處理功能來提供了一套完整的企業級的 Java 批處理解決方案。WAS V8.5 包括了如下的批處理特性：
能夠與企業級調度器的集成
支持並行批處理作業
內存過載保護
Job Log SPI
混合批處理作業類型
在 z/OS 上支持 COBOL
支持 OSGi 批處理應用程序
支持自定義記錄處理策略
記錄統計
作業和作業步監控器
關於 WAS V8.5 中關於批處理的新特性，請參考 《 WebSphere Application Server V8.5 中 Batch 新特性》 中的具體介紹。
通過檢查點來進行安全審計
在多應用伺服器環境下保持環境的一致性，和在必要時對於出現的問題進行診斷，作為系統管理員來說，知道對系統和環境進行的每個更改對於 在多應用伺服器環境下來是非常重要的。
Repository 檢查點是在配置更改發生前對 Repository 進行快照。您可以在進行配置更改之前創建 Repository 檢查點，這樣在必要的時候可輕松的回退這些更改。您可以選擇以兩種 Repository 檢查點：
完全檢查點是對整個配置 Repository 的完整的快照，包含了應用程序和 connecters。使用完全檢查點能夠將配置回退到生成快照的這個時間點。
增量檢查點是整個配置快照的一部分。它用於將配置回退到前一個在狀態。這類檢查點就是配置的小的，增量的版本。
在 WAS V8.5 中，您可以您想對配置變化進行審計，您就可以增量檢查點中抽取進行變更過的文件之前和之後的版本，通過文件對比工具對比。
您可以配置每次配置變化時，自動生成增量檢查點。您也可以指定生成增量檢查點的個數。當達到這個限制後，新生成的檢查點就會替換點舊的檢查點。
跨組件跟蹤
跟
組件跟蹤日誌中加入注釋，以便服務於同一個請求的多個線程、進程，甚至是伺服器都能夠被標識為同一個工作單元。它用助於幫助發現問題的根源，使得管理員和
客戶服務團隊能了解到一個請求，當它跨越線程、進程邊界，或者是跨越 WAS
和其上的堆棧產品的時候，這樣一個端到端的流程，有助於定位到底是哪個組件導致請求失敗的。
跨組件跟蹤是 WAS 是日誌和跟蹤框架提供的一個功能。對於像 SOA 這種使用分布式應用支撐架構的應用程序來說跨組件跟蹤是很有用的一個特性，因為它用助於在多服務跨系統的環境中定位問題。
跨
組件跟蹤在每一條由 HPEL 生成的日誌和跟蹤條目上都添加一個 request ID。只要日誌和跟蹤屬於同一個請求，它們就會被加上相同的
request
ID。跨組件跟蹤通常還會為請求在日誌里添加上開始和結束，它用標記請求從當前線程轉移到其它的線程或進程上去了，或者由其它的線程或進程上返回了。這個
跟蹤對於顯示控制權從如何應用伺服器轉到了應用程序上是很有用的。
您可以使用 HPEL 的 logviewer 工具來查看和根據 reqest ID 來過濾日誌和跟蹤。您還可以通過 IBM Support Assistant 中的 Cross Component Viewer 來查看和過濾日誌。
6、Apusic 應用伺服器的性能如何？ 同等環境下和Weblogic、WebSphere、Jboss比較，純Web應用下，和tomcat比？
金蝶Apusic應用伺服器6.0新特性
在金蝶Apusic應用伺服器6.0舊有版本的基礎上，金蝶Apusic應用伺服器6.0具備了更多的新的特性和對以前特性的增強，情況如下。
對RIA（Rich Internet Application）的更全面支持
金蝶Apusic應用伺服器6.0在JSF 1.2及標准EL的基礎上作了重要擴充，在容器級別提供JSF 託管Bean與JPA實體、Spring Bean之間的雙向注入管理，結合全球獨創的OperaMasks SDK及一體化開發與管理環境OperaMasks Studio，真正實現基於Java EE技術RIA應用開發的全生命周期管理。
提供增強SOA基礎設施
金蝶Apusic應用伺服器6.0在5.0的基礎上，進一步強化了SOA基礎設施能力，實現對SCA/SDO技術的良好支持，並實現對第三方Web Services框架的良好兼容性，為面向SOA系統提供更為平滑的支撐能力。
實現增強的可靠性
金蝶Apusic應用伺服器6.0不僅支持應用的垂直擴展和水平擴展，並且能夠適應復雜環境下系統的擴展需求，提供配對演算法、全復制演算法等，實現對F5、Radware等硬體負載均衡設備及常規Web Server的全面兼容。
性能優化及提升
金蝶Apusic應用伺服器6.0在5.0的基礎上，進行了大量性能優化工作，包括靜態資源緩存、NIO InputStream演算法及長連接管理優化、HTTP 304演算法優化、GZIP演算法優化、Chunked演算法優化等。經優化後，性能提升明顯，服務的載入時間、JSP頁面的編譯時間等大大縮短。
安全性能增強
金蝶Apusic應用伺服器6.0在安全性方面作了重要增強，實現對多種安全身份管理及第三方安全產品的可插拔式支持，並實現對多認證中心、級聯證書的全面支持。
更全面的兼容性支持
金蝶Apusic應用伺服器6.0實現對第三方應用伺服器上開發的應用更好的兼容性，提供可配置的類載入策略、更寬松的TLD驗證、可插拔的JSP編譯器、可配置的中文編碼支持策略等非常實用、有針對性的功能，幫助第三方應用無縫遷移到金蝶Apusic應用伺服器6.0。
7、如何調整websphere類載入策略
javax.xml.namespace.QName: method getPrefix()Ljava/lang /String; not found，這句話，就是告訴你是哪個文件在載入的時候出了問題，根據這個報錯，找到對應jar包拷貝到WebSphere5.1的WebSphere\AppServer\lib下面，重啟WebSphere就好了。