二．業(yè)務邏輯層
多層應用模型中的業(yè)務邏輯層被用于封裝應用業(yè)務邏輯，包括獨立于應用界面的業(yè)務組件，通過應用服務器中的組件容器提供運行時環(huán)境。 Enterprise JavaBeans?（以下稱EJB)是J2EE?應用中的業(yè)務邏輯層的組件模型。Apusic應用服務器提供了對EJB2.0規(guī)范的完全實現(xiàn)，同時提供了相關的特有特性，以簡化對J2EE應用邏輯層的開發(fā)、部署、管理和維護。
Apusic應用服務器中的EJB容器提供對EJB的生存周期管理、緩存、持久性和事務管理等服務，Apusic提供三種類型的EJB的支持：Session Bean、Entity Bean和Message-driven Bean。 同時提供了相關的一些特性，如CMR、EJB QL等，為提高應用執(zhí)行的效率，還提供了新的Local接口。
1．Entity Bean
Entity Bean被用于表示應用中的業(yè)務實體，通常與數(shù)據(jù)庫或傳統(tǒng)應用中的業(yè)務數(shù)據(jù)實體保持映射關系，可以理解為數(shù)據(jù)庫或傳統(tǒng)應用中的業(yè)務數(shù)據(jù)實體在內存中的對象表示方式。
Apusic應用服務器支持新的容器管理關系模型(CMR)和Entity Bean的查詢語言EJB QL。
(1) 容器管理持久性（Container Managed Persistence）指由EJB容器處理Entity Bean需要的對數(shù)據(jù)庫的訪問。使Entity Bean可以脫離特定類型的數(shù)據(jù)庫，從而具有更高的靈活性。
(2) 容器管理關系（Container Managed Relation）
容器管理關系用于對實體數(shù)據(jù)對象之間關系的管理。
容器管理持久性的Entity Bean有以下四種容器管理關系：
·? one-to-one，一個Bean的單個實例關聯(lián)另一個Bean的單個實例；
·? one-to-many，一個Bean的單個實例關聯(lián)另一個Bean的多個實例；
·? many-to-one，一個Bean的多個實例關聯(lián)另一個Bean的單個實例；
·? many-to-many，一個Bean的多個實例關聯(lián)另一個Bean的多個實例；
容器管理關系的方向可以是雙向或單向。在一個雙向的關系中，涉及的Bean都有一個關系域與另外的Bean關聯(lián)，通過關系域，可以從一個Bean的實例中訪問關聯(lián)的Bean對象，反之亦可。在一個單向的關系中，只有一個Bean擁有關聯(lián)其他Bean的關系域，只能從這個Bean的實例訪問被關聯(lián)的Bean對象，而不可從被關聯(lián)的Bean對象訪問到這個實例。
(3)EJBQL
對于容器管理持久性的Entity Bean，需要在部署描述中定義抽象模式的名字。這些名字將可以通過使用Enterprise JavaBeas? Query Language（EJB? QL）編寫的查詢語句進行引用。例如，必須為每一個finder方法定義一個EJB QL查詢語句，通過此語句定義當此finder方法被調用時，容器執(zhí)行的查詢。
另外在Apusic的自有特性中提供了對從EJBQL中查詢出的對象進行排序的功能，即擴展的了EJBQL的語句提供了Order By語句可以進行排序。

2．Session Bean
Session Bean通常被用于實現(xiàn)業(yè)務過程邏輯，通過對Entity Bean的操作完成業(yè)務過程并封裝過程邏輯。 盡管在需要的情況下，Session Bean可以有保持數(shù)據(jù)到持久存儲機制的能力,如數(shù)據(jù)庫，但Session Beans不是持久的。
相對于表示業(yè)務實體的Entity Bean，Session Bean的生存時間要短，大致等于于一個客戶端會話的延續(xù)時間。例如，客戶通過瀏覽器，訪問與Session Bean表示的相關業(yè)務過程，或通過一個Java應用程序" title="應用程序">應用程序或者是Applet訪問的相關業(yè)務過程的持續(xù)時間，或其它Enterprise Bean訪問此業(yè)務過程的持續(xù)時間。
Session Bean是非持久的，其狀態(tài)不被保存到持久存儲機制（如數(shù)據(jù)庫、文件系統(tǒng)）中，盡管Session Bean本身可以執(zhí)行對數(shù)據(jù)庫的操作，但它并不是一種持久對象的表示。
Session Bean表示客戶端與應用之間的會話。會話由客戶端與組件之間的交互組成，一般表現(xiàn)為一系列的方法調用" title="方法調用">方法調用。
根據(jù)Session Bean保持會話狀態(tài)的方式，可分為狀態(tài)的和無狀態(tài)的Session Bean。

（1）無狀態(tài)（Stateless）的Session Bean，會話狀態(tài)只會在單個方法調用中被保持，一旦方法調用結束，組件將丟棄方法調用過程中保持的狀態(tài)，不保持跨越方法調用的會話狀態(tài)。
(2)對于有狀態(tài)（Stateful）的Session Bean，在整個會話期間，特定組件實例將保持與某個特定客戶端之間跨越方法調用的會話狀態(tài)。

3．Message-driven Bean
Message-driven Bean 是EJB2.0規(guī)范中新增的一個enterprise bean 類型，通常被用于異步接收從客戶端發(fā)送的消息，觸發(fā)相應的業(yè)務處理過程。
Message-Driven Bean 作為EJB2.0規(guī)范中新增的一個enterprise bean 類型，除得到應用服務器管理的事務，安全和資源訪問的服務之外，同時作為 JMS消息系統(tǒng)中的消息使用者 （Message Consumer）接收并處理應用消息。
通過消息機制而非直接的方法調用，客戶端可以繼續(xù)執(zhí)行而不必等待服務器的運行結果，服務器可以選擇在方法調用完成后通知客戶，而消息機制本身保證了信息傳輸?shù)目煽啃裕?同時使用消息域(Message Domain)中的消息類型模型以達到事件廣播的機制。
(1) Message-driven Bean 作為一般的JMS 使用者(consumer)
作為一種具有JMS使用者(consumer)功能的Enterprise Bean組件模型，Message-Driven Bean由EJB容器進行管理，具有一般的JMS使用者(consumer)所不具有的優(yōu)點，如對于一個Message-driven Bean，容器可創(chuàng)建多個實例來處理大量的并發(fā)消息，而一般的JMS使用者 (consumer)開發(fā)時則必須對此進行處理才能獲得類似的功能。同時Message-Driven Bean可取得EJB所能獲得的標準服務，如容器管理事務等服務。
(2) Message-driven Bean 與其他Enterprise Bean
作為Enterprise Bean組件模型之一，Message-driven Bean，具有一些與Session Bean 和Entity Bean相同的方法，但由于Message-driven Bean本身不處理客戶端調用，也無會話狀態(tài)，客戶只能通過向與Message Driven Bean關聯(lián)的隊列或主題發(fā)送消息從而與Message-driven Bean 進行交互，因此，Message-driven Bean 與Session Bean 和Entity Bean之間最大的不同之處在于Message-Driven Bean不具有組件接口及Home接口。
另外，Message-driven Bean異步地處理隊列（Queue）或主題(Topic)中的消息，而非方法調用。

4．Apusic專有特性
除了對EJB2.0規(guī)范的實現(xiàn)，Apusic應用服務器中的EJB容器和相關系統(tǒng)服務還提供了一些高端增值特性，通過這些增值特性，使得面向Apusic應用服務器的業(yè)務邏輯層的開發(fā)、部署、運行和維護變得更加方便、高效和可靠。
（1）實例池
通過圖形化的配置工具或簡單修改組件配置文件，Apusic應用服務器可以預先裝載指定數(shù)量的對象實例到實例池中，使對客戶請求進行響應的過程更加高效。
（2）CMP Entity Bean自動升遷
對于一個按照EJB1.1規(guī)范編寫的CMP Entity Bean，應用服務器在運行時將其自動升級到EJB2.0，使按照EJB1.1規(guī)范編寫的EJB可以使用EJB2.0規(guī)范中提供的Lazy Loading和Smart Update技術以提高應用執(zhí)行的效率，同時降低已有應用在維護上的成本。
（3）熱部署
為提高企業(yè)應用開發(fā)、調試和維護的效率，Apusic應用服務器提供了熱部署的功能。在運行時，可以動態(tài)地部署和修改應用中的應用程序，無需停止和重新啟動服務器即可應用新的改動。
（4）自動遷移及部署
不同的應用服務器廠商提供的基于J2EE?規(guī)范實現(xiàn)的應用服務器的不同，使得多數(shù)企業(yè)應用在不同的服務器之間遷移時，需要改動一些配置，提高了應用移植的成本，Apusic應用服務器提供了自動遷移和部署的能力，對于面向其他非Apusic應用服務器開發(fā)的企業(yè)應用，可以不改動應用程序，而由應用服務器自動完成移植的工作并部署到應用服務器，大大降低了應用移植的成本。
目前對于面向Weblogic8.1和J2EE?RI開發(fā)的企業(yè)應用，可以直接使用這項功能，Apusic應用服務器還將在此項功能上添加對當前其他主流應用服務器的支持。
（5）自動生成查詢
為提高面向CMP Entity Bean的開發(fā)效率和降低開發(fā)的難度，Apusic應用服務器可為CMP Entity Bean自動生成缺省的finder query。

三. 數(shù)據(jù)層
Apusic應用服務器模型中的數(shù)據(jù)層提供企業(yè)應用對關系型數(shù)據(jù)庫和傳統(tǒng)企業(yè)應用數(shù)據(jù)的高效而可靠的訪問。使得企業(yè)應用可以通過JDBC實現(xiàn)對關系型數(shù)據(jù)庫安全、可靠而且高效的訪問。目前Apusic應用服務器提供了對最新的JDBC3.0版本的支持。任意合法的J2EE?編程模型都可以從Apusic應用服務器數(shù)據(jù)庫連接池中獲得對關系型數(shù)據(jù)庫的連接。
按照J2EE?的規(guī)范，Entity Bean被設計為與數(shù)據(jù)庫直接交互的最佳模型，但在實際的企業(yè)運用開發(fā)中，任何一種編程模型都有可能直接與數(shù)據(jù)庫進行交互，針對這種情形，Apusic應用服務器提供了很多功能或特性，使對數(shù)據(jù)層訪問的開發(fā)更為簡單同時達到更為高效而安全的目標。
·? JDBC結果集緩存
對于Session Bean、JSP、Servlets為主的J2EE應用中，頻繁訪問數(shù)據(jù)庫而缺少對應的數(shù)據(jù)緩存等機制，往往會成為企業(yè)應用的瓶頸。因此，Apusic應用服務器提供了JDBC結果集緩存技術，通過將數(shù)據(jù)庫返回的結果集保存在內存中可以大幅提高應用系統(tǒng)的性能，同時，使用結果集緩存對應用開發(fā)者是完全透明的，保證了應用的可移植特性。
·? JDBC語句緩存
對于Session Bean、JSP、Servlets為主的J2EE應用中，頻繁訪問數(shù)據(jù)庫而缺少對應的數(shù)據(jù)緩存等機制，往往會成為企業(yè)應用的瓶頸。因此，Apusic應用服務器提供了JDBC語句緩存技術，同時使用預編譯的查詢語句，提高應用程序訪問數(shù)據(jù)庫的效率。
·? 連接池
對于復雜的企業(yè)應用而言，對數(shù)據(jù)庫連接池的可靠、效率，成本都有著極高的要求，Apusic應用服務器提供了對連接資源的優(yōu)化，使有限的數(shù)據(jù)庫連接資源得到最大程度的利用，同時，對于應用錯誤使用連接造成的死鎖" title="死鎖">死鎖或阻塞，提供了死鎖檢測的技術，而以上的特性對于用戶而言是完全透明的。

四．安全服務
對于企業(yè)應用而言，應用服務器所能提供的安全方面的功能是保證企業(yè)應用數(shù)據(jù)完整、邏輯完整和減少被入侵可能的 重要特性，針對多層的分布式企業(yè)應用的安全要求，Apusic應用服務器提供了可靠高效的安全構架。同時，為應用程序的加密需求提供了一個安全、強壯、高效的JCE(Java Cryptography Extension)提供者。

?
?????????????????????????????????????? 圖二　Apusic服務器數(shù)據(jù)安全功能的架構
·? 身份鑒定
Apusic應用服務器提供了面向用戶、調用過程和客戶端調用等方式的身份鑒定，通過使用用戶名和密碼、證書等等方式，將合法的應用用戶和調用程序區(qū)別于非法的入侵者。
·? 授權
授權是使企業(yè)應用的完整性和安全性得以保證的重要因素，Apusic應用服務器對企業(yè)應用的授權策略提供了易于配置和修改的方法與工具，同時提供了可靠安全的授權機制。
·? 加密
對于企業(yè)應用中的敏感數(shù)據(jù)的保存和交換，Apusic提供了高效可靠的加密機制。
Apusic 安全服務提供了數(shù)字簽名、消息摘要、消息鑒別碼、RSA 非對稱加密、序列密碼加密、分組密鑰密碼加密、密鑰生成、密鑰交換等常用的算法。
·? 安全數(shù)據(jù)存儲
對于系統(tǒng)中的關鍵數(shù)據(jù)，如消息、用戶信息等等，Apusic提供了極安全的內部保護存儲機制。
Apusic 應用服務器的加密算法完全是自主實現(xiàn)的，一舉打破國際對中國加密算法位數(shù)的限制。國內企業(yè)，政府部門等使用Apusic 應用服務器會更加安全可靠。
Apusic應用服務器同時提供了對JSSE的實現(xiàn)。

五．事務服務
J2EE中對于事務的處理是分布式的，Apusic完全提供對XA事務的支持，顯示對大型企業(yè)應用的支持。
為了簡化開發(fā)者對事務的處理，Apusic應用服務器在EJB容器中提供容器管理事務（Container Managed Transaction），應用開發(fā)者使用EJB管理數(shù)據(jù)即自動獲得了事務的保證，由于EJB容器對數(shù)據(jù)庫的管理是分布式的開發(fā)者又由此自動獲得了對應用開發(fā)較為困難的分布事務管理能力，這一切都由應用服務器完成。
為保證應用數(shù)據(jù)和業(yè)務邏輯的的完整性，除了提供完全符合規(guī)范和強壯的事務管理器之外，Apusic應用服務器對Entity Bean中特別是CMP類型的組件，提供了強壯而靈活的事務構架。
·? 死鎖檢測
能夠根據(jù)資源等待圖自動檢測出死鎖狀態(tài)，當事務發(fā)生死鎖時將其中一個事務回滾，以釋放事務所占用的資源，使其他事務能夠繼續(xù)執(zhí)行。
·? 并發(fā)控制
提供了靈活和強壯的EJB并發(fā)控制機制，單獨分離出了并發(fā)控制部分，可以使用插件的形式同時提供多種并發(fā)控制協(xié)議。
·? JMS全局事務
提供了一個作為事務性資源管理器的JMS 提供者(Provider)，允許從JSP，Servlet， EJB 等應用組件中對JMS 進行事務性的訪問。同時，從一個單一事務邊界中允許多個應用組件訪問JMS 提供者。

六．名字服務
由于J2EE應用的關鍵特性是分布式的，其提供的服務可能分布在任何一個機器或網(wǎng)絡，應用的開發(fā)統(tǒng)一通過JNDI（Java Naming and Directory Interface）來獲得服務，開發(fā)者在開發(fā)時可以不用關心服務的物理所在。
Apusic完全支持使用JNDI，并且開發(fā)完成后，部署者(Deployer)可以在部署工具中配置應用所需要的環(huán)境、資源、服務，使應用獲得所需的分布式服務，完成最終生產(chǎn)環(huán)境的建立。

七．Web Services
Apusic應用服務器實現(xiàn)了對Web Services的支持。Apusic Web Services 是一個開放的遵循業(yè)界標準的Web Services實現(xiàn)，主要實現(xiàn)了以下 的Web Services相關規(guī)范：
.?JAX-RPC1.0
.?JAXM1.1
.?SAAJ1.1
.?JAXR1.0
.?SOAP1.1
.?SOAP with Attachments
.?WSDL1.1
.?UDDI2.0
Apusic Web Services支持和其他Web Services產(chǎn)品的交互，包括Weblogic和.Net。
八．與CORBA的互操作
CORBA（Common Object Request Broker Architecture, 公共對象請求代理體系結構）是由OMG（對象管理組織，Object Management Group）提出的應用軟件體系結構和對象技術規(guī)范，被廣泛的用來開發(fā)分布式系統(tǒng)。Apusic應用服務器完整的實現(xiàn)了CORBA-EJB映射規(guī)范，因此可以和CORBA對象進行互相調用。CORBA和EJB的互操作規(guī)范包含以下四個方面：
.?EJB接口到CORBA接口的映射；
.?JNDI名字到CORBA名稱服務（CosNaming ）的映射；
.?EJB和CORBA之間的事務傳播；
.?EJB和CORBA之間的安全傳播。
Apusic應用服務器實現(xiàn)了RMI-IIOP（Internet Inter-ORB Protocol）協(xié)議，能夠在多個Apusic服務器實例之間傳播事務、安全等上下文信息（Context）。