Đồ án xây dựng ứng dụng J2EE với Rational Rose và UML - 2 pot

Hình2.3:sơ đồ tầng Web tier
Business tier:
Business tier là một lớp logic dùng để thực hiện việc xử lý của hệ thống J2EE
server.

Hình2.4: sơ đồ tầng Business tier.
Hình vẽ minh họa cho ta thấy 1 Enterprise Bean có thể nhận dữ liệu từ client,
xử lý nó (nếu cần thiết) và gửi nó đến EIS tier (Enterprise Information System tier)
để lưu trữ. 1 Enterprise Bean cũng có thể nhận dữ liệu từ EIS tier, xử lý dữ liệu đó
(nếu cần thiết) và sau đó là gửi nó trở lại các chương trình client.
Có 3 loại Enterprise Bean: session bean, entity bean, message-driven bean.
Session Bean thể hiện cho một phiên dao dịch với client, với 1 client sẽ có 1
instance của session bean tương ứng, và instance này có thể lưu giữ các thông tin
của client đó. Tuy nhiên, khi phiên giao dịch kết thúc (client kết thúc việc thực thi),
các instance này cũng sẽ bị hủy. Ngược lại với session bean, entity bean có thể lưu
giữ lâu dài các thông tin về client. Còn message-driven bean là sự kết hợp giữa
sesssion bean và JMS message listener.
Enterprise Information System tier (EIS tier):
Lớp này thực hiện việc lưu trữ dữ liệu cho hệ thống J2EE, bao gồm cả các
interface để giao tiếp với các Database khác nhau, và giữa các OS khác nhau trong
việc quản lý và lưu trữ file…
Kiến trúc tổng thể của một hệ thống J2EE:
EJB container (Enterprise JavaBean container) quản lý việc thực thi của tất cả
các enterprise bean cho một ứng dụng J2EE. Các enterprise bean và container của
nó đều được chạy trên J2EE server.
Web container quản lý và thực thi của tất cả các trang JSP và các servlet cho
một ứng dụng J2EE. Các web component và container của nó đều được chạy trên
J2EE server.
Application client container quản lý và thực thi của tất cả các thành phần
application client cho một ứng dụng J2EE. Các application client và container của

nó đều được thực thi trên máy client.
Applet container chính là web browser (có các Java Plug-in) chạy trên máy
client.

Hình 2.5:kiến trúc tổng thể của hệ thống J2EE.
2.2. Giới thiệu dịch vụ JNDI (Java Naming and Directory Interface)
JNDI là dịch vụ đăng ký và truy tìm tên đối tượng chuẩn. Enterprise JavaBeans
dựa vào JNDI để truy tìm các thành phần phân tán thông qua mạng. JNDI là một
công nghệ chính yếu được yêu cầu cho mã khách kết nối đến một thành phần EJB.
Cách lấy một tham chiếu tới một home object thông qua dịch vụ JNDI được
trình bày ở hình 2.6 như sau:

Hình 2.6: lấy một tham chiếu đến một home object (Acquiring a reference to a
home object)
Hệ thống JNDI
Là một service trong hệ thống J2EE phục vụ cho việc đặt tên của các Object,
trong đó 1 object ta có thể xem như là module, một service để thực hiện một chức
năng nào đó. Với 1 object có thể có nhiều tên được tham khảo đến. Thông qua
JNDI, client hoặc EJB có thể truy xuất đến object thông qua tên mà không cần quan
tâm object đó nằm ở đâu trên mạng (khái niệm tương tự như việc đánh tên cho địa
chỉ IP).

Hình 2.7: sơ đồ client truy xuất đốI tượng thông qua tên
Một hệ thống JNDI bao gồm 3 phần chính yếu sau: lookup services, service
providers, và clients.
Trong đó lookup services đóng vai trò trung tâm, nó là cầu nối giữa service
providers và clients. Lookup services có nhiệm vụ quản lý các dịch vụ mà service
providers cung cấp, service providers cung cấp các dịch vụ cho hệ thống JNDI, còn
clients là người sử dụng các dịch vụ, sẽ kết hợp các dịch vụ với nhau để thực hiện
một công việc nào đó.

Khi một service provider “muốn” đưa ra một dịch vụ nào đó thì nó phải đăng ký
dịch vụ đó với lookup services. Khi một client muốn dùng một dịch vụ nào đó của
hệ thống thì nó sẽ phải “đề xuất yêu cầu” với lookup service, và các dịch vụ của hệ
thống có thể phục vụ cho client khi được lookup service cho phép.
Quá trình đăng ký một dịch vụ của service provider với lookup service được
thực hiện như sau (quá trình discovery): đầu tiên service proveider cần thông báo
cho lookup service biết ý định của mình bằng cách gửi broadcast một presence
announcement packet (dùng một well-known port). Khi loopkup service nhận được
một presence announcement packet (một packet có tính chất thông báo), nó sẽ mở
ra và phân tích packet này và lấy các thông tin về service provider và service mà
service provider muốn cung cấp. Nếu lookup services chấp nhận service này thì nó
sẽ mở cầu nối TCP đến IP và port do presence announcement packet cung cấp để
gửi đến đó một Object, object này được gọi là service registrar. Mục đích của
service registrar object là để tạo sự dễ dàng trong việc giao tiếp giữa service
providers và lookup services trong quá trình đăng ký service.
Khi lookup service chấp nhận một service mới bằng cách gửi lại cho service
providers một service registrar object, thì quá trình đưa một service vào lookup
service được thực hiện như sau (quá trình join): service providers sẽ gọi hàm
registrer() của service registrar object với thông số là một object, object này gọi là
service item, nó chứa tất cả các thông tin cần thiết cho một dịch vụ cần đưa vào hệ
thống JNDI. Khi quá trình đưa Service Item vào lookup service kết thúc thành công
thì ta có thể coi như quá trình đưa một service mới vào hệ thống JNDI thành công.
Service Item có bản chất là một container và nó chứa một số các Object khác,
trong đó chính yếu nhất là một object được đặt tên là service object. Đây là object
mà thông qua đó, client có thể tương tác với service. Ngoài ra, service item còn
chứa một số các Object thuộc tính khác như icon, GUIs… của service.
Trong service registrar object cũng còn có một method có tên là lookup() dành
cho client để yêu cầu lookup service kiểm tra tính tồn tại của 1 hoặc 1 số service
trong hệ thống JNDI. Và method này trả về service object cho client. Khi client gọi
một method trong service object thì service object đó sẽ kết nối trực tiếp với service

provider tương ứng để thực thi method (thông qua RMI)



Trong J2EE, JNDI được sử dụng bởi client để nhận ConnectionFactory object.
Có 2 loại kỹ thuật có thể dùng được cho JNDI lookup của ConnectionFactory
Object:
Dựa trên cơ sở của kỹ thuật Serialication: sử dụng java.io.Serializable.
Application server/component tạo ra một instance ManagedConnectionFactory.
Instance này được cấu hình bằng cách sử dụng các thông tin được lưu trong 1 file
cấu hình theo cú pháp của XML (các thông tin về server name, port, gateway…).
Bước kế tiếp là server/component tạo ra và thiết lập cấu hình cho một instance của
ConnectionManager và truyền instance này đến method createConnectionFactory
của ManagedConnectionFactory object. Khi server/component thực hiện JNDI
loookup thì nó sẽ trả về 1 ConnectionFactory object để sử dụng cho Connection
này.

Dựa trên cơ sở của kỹ thuật Referenceable: sử dụng
javax.naming.spi.ObjectFactory và javax.naming.Referenceable.
Application/Component tạo ra một Reference object. Reference này chứa tất cả các
thông tin mà application server/component cần để tạo và cấu hình cho một
ManagedConnectionFactory tương ứng. Reference này có thể chứa cặp <reference
name>/<logical name> được sử dụng để nhận các đặt tính của factory, reference
cũng có thể là một chuỗi nhị phân chứa các thông số dùng để thiết lập cho
ManagedConnectionFactory. Method getObjectInstance sẽ được gọi khi
component thực hiện thao tác loookup của ConnectionFactory.
Để loookup 1 object from naming service, ta sử dụng Context.lookup() với thông
số là tên của object mà ta muốn nhận
2.3. Giới thiệu về JDBC (Java Database Connectivity)
JDBC là một chuẩn mở rộng của Java cho việc truy cập dữ liệu, mà cho phép

người lập trình Java mã hóa đến giao diện lập trình ứng dụng cơ sở dữ liệu quan hệ
đồng nhất. Bằng cách dùng JDBC, người lập trình Java có thể trình diễn việc kết nối
cơ sỡ dữ liệu, xuất các câu lệnh SQL, kết quả của việc xử lý cơ sở dữ liệu, và nhiều
cách linh động liên quan khác. Clients lập trình đến JDBC API đồng nhất, cái này
được thực hiện bởi trình điều khiển JDBC (JDBC Driver), một trình điều hợp mà
biết cách làm thế nào giao tiếp đến cơ sở dữ liệu với cách độc quyền. JDBC tương
tự như chuẩn ODBC(Open Database Connectivity), và cầu nối thông qua hai thành
phần thao tác khá tốt là JDBC-ODBC. JDBC 2.0 chứa sự hỗ trợ cho sự thăm dò kết
nối cơ sở dữ liệu, tăng sự độc lập cơ sở dữ liệu đối với mã ứng dụng của bạn.

Hình 2.7: kết nốI cơ sở dữ liệu qua cầu nốI JDBC (Java Database
Connectivity)
2.4. Giới thiệu về RMI (Remote Method Invocation)
Mục đích là để tạo ra một Java distributed object model. Trong kiến trúc của
RMI, có một yếu tố khá quan trọng mà ta cần phải xác định rõ ràng, đó là việc định
nghĩa ra các method và việc thực thi các method đó là hoàn toàn khác nhau. RMI
cho phép ta định nghĩa 1 method với mã thực thi của nó trên 1 JVM (Java Virtual
Machine) và có thể gọi để thực thi method đó trên một JVM khác.


Hình 2.8: gọi thực thi phương thức thông qua RMI

RMI Architecture Layers: kiến trúc của RMI có thể phân vào 3 lớp sau:
 Stub and Skeleton layer: lớp này có nhiệm vụ giao tiếp trực tiếp với
chương trình ứng dụng, tiếp nhận các lời gọi method của server từ client.
 Remote Reference layer: lớp này quản lý các tham khảo được thiết lập
từ client đến remote object service trên server. Đây cũng là lớp dùng để thiết lập kết
nối từ client đến remote object service trên server.
 Transport layer: thiết lập kết nối TCP/IP giữa các máy với nhau trên
mạng để truyền dữ liệu khi lớp Remote Reference yêu cầu.

Kiến trúc 3 lớp của RMI được thể hiện như hình vẽ sau:



Hình 2.9: sơ đồ kiến trúc ba lớp của RMI
Làm thế nào một client có thể tìm ra một RMI remote service?
Client tìm remote service thông qua việc sử dụng naming or directory service, (1
naming or derectory service được chạy trên một well-known host và port). Trên
máy host, 1 chương trình server tạo ra một remote service bằng cách: đầu tiên nó
tạo ra một local object để thực thi service đó, sau đó nó export object đó đến RMI.
Khi một object được export, RMI tạo ra một listening service để chờ client kết nối
đến. Sau quá trình export, server đăng ký object đó trong RMI với một public name
và public name này có thể được client sử dụng để kết nối với object tương ứng.
RMI (Java Remote Method Invocation) system là một cơ cấu cho phép 1 object
trên 1 JVM (Java Virtual Machine) gọi method của 1 object trên 1 JVM khác. Bất
kỳ các object có method có thể được gọi “từ xa” đều phải thực thi (implement)
interface java.rmi.Remote. Khi 1 object được gọi, các giá trị truyền cho method
được gửi từ JVM cục bộ (JVM có chứa chương trình phát sinh lời gọi remote
method) đến JVM chứa object có method đó và kết quả trả về được gửi về lại cho
JVM cục bộ.
Để tạo nên 1 remote object, chương trình phải đăng ký object đó với RMI
registry. Chương trình phải cung cấp 1 cái tên cho object đó khi đăng ký. Khi một
chương trình nào đó muốn truy xuất đến 1 remote object, nó phải cung cấp cho RMI
system tên của object mà nó muốn truy xuất và hệ thống sẽ trả về cho chương trình
1 reference đến remote object đó (gọi là stub). Khi chương trình nhận được stub của
1 remote object thì nó có thể gọi các method của remote object đó có trong stub.
Chuỗi tên của 1 object được RMI register chấp nhận phải có cú pháp như sau
“rmi:hostname:port/remoteObjectName” trong đó hostname và port chỉ định máy
và port mà trên đó RMI registry đang chạy, và remoteObjectName là tên của remote
object được đăng ký. Chú ý rằng, hostname, port và tiếp đầu ngữ rmi là tuỳ chọn.

Nếu hostname không được đặt tả thì giá trị default là localhost, giá trị default của
port là 1099.
RMI được hỗ trợ bởi việc sử dụng Java Remote Method Protocol (JRMP) và
Internet Inter-ORB Protocol (IIOP). JRMP là đặt tả giao thức được thiết kế cho
RMI, còn IIOP là giao thức chuẩn cho việc giao tiếp giữa các CORBA object. RMI
trên IIOP cho phép các Java remote object không chỉ giao tiếp với các CORBA
object viết bằng Java mà còn bằng bất kỳ ngôn ngữ khác.
2.5.Tổng quan về Enterprise JavaBean(là thành phần chính trong đặc tả J2EE)
Enterprise JavaBean là mô hình lập trình ứng dụng đa tầng. Cấu trúc EJB là cấu
trúc Component để phát triển và triển khai các ứng dụng nghiệp vụ phân tán. Các
ứng dụng được viết với cấu trúc EJB có thể bảo mật đa người dùng, chia mức và
thực hiện giao tác. Những ứng dụng này có thể được viết một lần sau đó được triển
khai trên bất kỳ nền server nào mà hỗ trợ đặc tả EJB.
Môi trường mà các đối tượng Bean sẽ hoạt động gọi là trình chứa (Container).
Các trình chứa sẽ kiểm soát việc khởi tạo, cung cấp tài nguyên cho đối tượng, lưu
trữ phục hồi đối tượng.
EJB server cung cấp các dịch vụ hệ thống và quản lý Container(hình 2.10). EJB
server có khả năng cung cấp các dịch vụ giao tác và dịch vụ đăng ký và truy tìm tên
đối tượng (JNDI-Java Naming and Directory Interface). EJB object bao bọc các thể
hiện bean. Nó được sinh ra bởi các tiện ích của nhà cung cấp EJB Container. EJB
object cài đặt remote interface của bean.



Hình 2.10 Quan hệ giữa EJB server và EJB container

EJB home gần giống với EJB object, nó được tự động sinh ra khi cài đặt
enterprise bean trong Container. Nó cài đặt các phương thức được định nghĩa bởi
home interface và chịu trách nhiệm hỗ trợ container quản lý vòng đời bean. Kết hợp
với EJB container, EJB home chịu trách nhiệm tạo, đặt, và loại bỏ enterprise bean.

Khi phương thức tạo được gọi trên home interface thì EJB home tạo một thể hiện
của EJB object mà tham chiếu tới thể hiện bean có kiểu tương ứng. Khi thể hiện
bean được kết hợp với EJB object thì phương thức ejbCreate() tương ứng của thể
hiện đó sẽ được gọi. Khi hoàn thành phương thức ejbCeate(), EJB home trả lại tham
chiếu remote tới client cho EJB object. Sau đó client có thể làm việc trực tiếp với
EJB object bằng các phương thức nghiệp vụ.
Để cài đặt Enterprise JavaBean, chúng ta cần hai định nghĩa interface và một
hoặc hai lớp: Home interface: định nghĩa phương thức vòng đời của bean: tạo một
thể hiện bean mới, loại bỏ bean, và tìm kiếm bean.
Remote interface: để định nghĩa các phương thức nghiệp vụ, (mở rộng javax.ejb.
EJBObject-đối tượng này lại là mở rộng của java.rmi.Remote).
Bean class: cài đặt các phương thức nghiệp vụ của bean, không cài đặt các
phương thức của home interface và remote interface.
Primary key: là một lớp cực kỳ đơn giản, cung cấp con trỏ tới cơ sở dữ liệu. Chỉ
bean thực thể(entity bean) mới cần primary key.
Hoạt động: client không bao giờ tương tác trực tiếp với lớp bean mà nó luôn
luôn sử dụng các phương thức giao tiếp home interface và remote interface của
bean để thực hiện công việc của nó. Client sử dụng dịch vụ JNDI tham chiếu tới lớp
chủ. Lớp chủ sẽ triệu gọi phương thức tạo ra tham chiếu đến lớp giao tiếp của bean
rồi trả về trình khách. Trình khách triệu gọi bean thông qua lớp giao tiếp trung gian
mà do lớp chủ trả về. Lớp trung gian này là giao tiếp giữa trình chứa Container và
đối tượng bean thực sự.
Như ta đã giới thiệu ở trên, enterprise bean là một thành phần phần mềm ở phía
Server mà có thể triển khai trong một môi trường phân tán. Một enterprise bean có
thể gồm một hay nhiều các đối tượng java tại vì một thành phần có thể là nhiều hơn
một đối tượng đơn giản.
Có các loại Bean:(Type of Beans)
Session Beans:(Bean thao tác) chỉ có nhiệm vụ phục vụ trình khách trong một
phiên kết nối. Bean thao tác chỉ thực hiện các hành vi xử lý, tính toán đơn thuần
không đòi hỏi đến việc thể hiện dữ liệu. Các Session bean có thể dùng bởi một máy

khách tại một thời điểm, chúng không chia xẻ cho các máy khách khác. Khi máy
khách đang dùng một session bean máy khách đó là máy khách duy nhất giải quyết
session bean đó. Điều này trái ngược với entity bean, trạng thái của nó được chia xẻ
giữa các máy khách với nhau.
Trong session bean được chia làm hai loại: Stateful Session Bean và Stateless
Session Bean:
Stateful Session Bean: là các thành phần bean cần lưu lại kết quả hay vị trí giao
dịch trước đó để phục vụ cho các lần giao dịch tiếp theo - thường phục vụ cho
những thao tác đòi hỏi qua nhiều bước triệu gọi trước khi trả về kết quả cuối cùng.
Stateless Session Bean: là các thành phần bean không lưu lại trạng thái của giao
dịch trước đó để sử dụng lại cho lần giao dịch sau.
Session beans quản lý các xử lý nghiệp vụ. Các session bean có thể sử dụng
entity beans để thể hiện dữ liệu mà chúng dùng. Một điểm khác biệt giữa Session
Bean và Entity Bean là: Entity Bean có vòng đời lâu hơn Session Bean nhiều. Khi
ứng dụng Server bị sự cố thì Entity Bean có thể được xây dựng lại trong bộ nhớ
bằng cách đơn giản là đọc lại dữ liệu từ cơ sở dữ liệu bền vững.
Entity Bean:
Một phần cơ bản khác của một nghiệp vụ là bền vững dữ liệu mà xử lý nghiệp
vụ sử dụng. Entity Bean chính là một thành phần mà đại diện cho bền vững dữ liệu.
Entity Bean không chứa xử lý nghiệp vụ logic.
Có hai loại bean thực thể (entity bean)
Bean thực thể tự quản lý(Bean – Managed Persistent Entity Beans): là các thành
phần bean có khả năng tự truy vấn các hệ cơ sở dữ liệu để lấy về dữ liệu nó thể
hiện. BMP (Bean Managed Persistent) có những ưu điểm: mình có thể viết mã cho
các phương thức, nhất là các phương thức thao tác với nhiều bảng dữ liệu cùng một
lúc. Đồng thời sẽ tiện hơn khi tạo mới dữ liệu, vì ta có thể sử dụng định dạng
sequence – tăng tự động chỉ số id trong bảng dữ liệu. Nhưng có một nhựơc điểm là
sẽ tốn thời gian để viết, mà chính ta viết thì có thể bị lỗi.
Bean thực thể quản lý bởi trình chứa: (Container –Managed Persistent Entity
Beans)

Là các thành phần bean không cần sử dụng lệnh SQL để tìm kiếm hay tạo mới
dữ liệu mà chỉ cần khai báo các tên trường hay cột dữ liệu tương ứng với các bảng
trong hệ CSDL. Trình chứa sẽ tự động thực hiện công việc truy vấn dữ liệu giúp
thành phần bean. CMP(Container – Managed Persistent) lại có một ưu điểm rất lớn
là chúng ta không phải viết mã, trình chứa đã thực hiện điều này. Và như thế
chương trình không bao giờ có lỗi. Nhưng nó lại bất lợi ở chỗ: trường primary key
có kiểu java.math.BigDecimal nên không tận dụng được định dạng sequence của cơ
sở dữ liệu. Hơn nữa, khi chúng ta cần thao tác với nhiều bảng cùng một lúc(có sự
join giữa các bảng) thì sẽ phức tạp hơn- cần viết thêm lớp bean kết nối hai thực thể
bean của hai bảng dữ liệu kia.
Message – driven bean: xử lý các thông điệp ( message một cách không đồng
bộ. Nó tương tự như stateless session bean ở chỗ nó không lưu trữ trạng thái giao
dịch. Điểm khác với Session và Entity Bean là client không thể truy cập chúng qua
interface. Message – driven bean chỉ là một lớp bean, không có interface. Chỉ cần
một bean này nó vẫn có thể xử lý nhiều message từ nhiều hoặc một client. Bean này
là một khối mã ứng dụng mà có thể thực hiện khi message đến.
2.6. Phát triển các thành phần: (Developing Beans)
The Enterprise Bean class:
Đặc tả EJB định nghĩa vài giao tiếp chuẩn mà lớp bean có thể thực hiện. Sức
mạnh giao tiếp của lớp bean là trình bày các phương thức đảm bảo mà tất cả các
beans phải cung cấp, như đã định nghĩa bởi mô hình thành phần EJB. Trình chứa
gọi những phương thức đã yêu cầu để quản lý các bean và thay đổi bean đến các sự
kiện quan trọng.
Hầu hết các giao tiếp cơ bản của các lớp bean (cả session và entity bean) phải
thực hiện là:
public interface javax.ejb.EnterpriseBean extends java.io.Serializable
{ }
Source 3.1 javax.ejb.EnterpriseBean interface
The EJB object:
Khi một máy khách muốn dùng một thể hiện của một lớp enterprise bean, máy

khách đó không bao giờ triệu gọi phương thức đó một cách trực tiếp. Nói đúng hơn
là sự viện cầu bị ngăn chặn bởi trình chứa EJB và rồi chuyển giao cho thể hiện của
bean. Trình chứa EJB đang hoạt động như một tầng gián tiếp giữa mã khách và
bean. Tầng gián tiếp này biểu hiện như một đối tượng đơn nhận biết mạng, được gọi
là EJB object. EJB object là một đối tượng đại diện mà nhận biết về mạng, giao tác,
an ninh …Nó là một đối tượng thông minh biết làm thế nào để thực hiện logic trung
gian các yêu cầu tới trình chứa EJB trước khi một lời gọi phương thức được phục
vụ bởi một thể hiện của lớp bean. Một EJB object hoạt động hàn gắn giữa máy
khách và thành phần bean, và nó trình bày mỗi phương thức nghiệp vụ mà chính
bean đó biểu hiện. EJB object chuyển giao tất cả các yêu cầu máy khách đến bean.
EJB object là một thành phần vật lý của trình chứa (container).
The Remote Interface:
Để định nghĩa các phương thức nghiệp vụ. Các thành phần máy khách triệu gọi
phương thức trên EJB object, đúng hơn là chính các bean đó. Để thực hiện điều
này, EJB object phải định nghĩa từng phương thức nghiệp vụ mà các lớp bean biểu
hiện. Nhưng làm thế nào các công cụ tự động tạo ra EJB object biết phương thức
nào để định nghĩa? Câu trả lời là một giao tiếp đặc biệt mà nhà cung cấp bean viết.
Giao tiếp này sao lại tất cả các phương thức nghiệp vụ mà lớp bean tương ứng biểu
hiện. Giao tiếp này được gọi là remote interface.
Remote interface phải phù hợp với các luật mà đặc tả EJB định nghĩa.
Xem mã nguồn 3.2(Source 3.2)


Hình 2.11: sơ đồ gọi phương thức từ Client đến EJB objects
public interface javax.ejb.EJBObject extends java.rmi.Remote
{public abstract java.ejb.EJBHome getEJBHome() throws
java.rmi.RemoteException;
public abstract java.lang.object getPrimaryKey() throws
java.rmi.RemoteException;
public abstract void remove() throws

java.rmi.RemoteException,javax.ejb.RemoveException;
public abstract java.ejb.Handle getHandle() throws
java.rmi.RemoteException;
public abstract boolean isIdentical(javax.ejb.EJBObject) throws
java.rmi.RemoteException;}
Source 3.2 the javax.ejb.EJBObject interface
Mã khách muốn làm việc với các bean gọi các phương thức trong
javax.ejb.EJBObject. Mã khách có thể là ứng dụng stand-alone, applets, servlet
thậm chí cả các bean khác. Thêm vào đó, remote interface sao lại các phương thức
nghiệp vụ của bean. Khi một trình khách của bean triệu gọi bất kỳ phương thức
nghiệp vụ nào, EJB object sẽ chuyển giao phương thức đó tới sự thực hiện tương
ứng, sự thực hiện này cư trú bên trong các bean đó.
The Home Object:
Như chúng ta đã biết, mã client xử lý với EJB object và không bao giờ làm việc
trực tiếp với bean. Câu hỏi là làm thế nào trình khách đạt được tham chiếu tới EJB
object. Máy khách không thể thuyết minh EJB object một cách trực tiếp tại vì EJB
object có thể tồn tại trên một máy khác chứ không cùng trên máy client. Dường
như sự định vị EJB object là trong suốt, vì vậy máy khách sẽ không bao giờ nhận ra
chính xác EJB object cư trú nơi nào.
Để đạt được tham chiếu tới một EJB object, mã client yêu cầu một EJB object từ
một xí nghiệp EJB object (EJB object factory). Xí nghiệp này chịu trách nhiệm cho
sự thuyết minh EJB object. Đặc tả EJB gọi xí nghiệp này là một home object. Trách
nhiệm của home object là làm các việc sau:
+ Tạo EJB objects
+ Tìm các EJB object đang tồn tại
+ Hủy bỏ các EJB object.
Home object là một phần vật lý của trình chứa và được tự động tạo ra bởi công
cụ của nhà cung cấp trình chứa(container provider).
The Home Interface:
Chúng ta đã thấy home object là các xí nghiệp cho EJB object. Nhưng bạn phải

cung cấp thông tin cho trình chứa bằng đặc tả một home interface. Home interface
định nghĩa các phương thức đơn giản cho việc tạo, huỷ, tìm kiếm EJB object. Home
object của trình chứa thực hiện home interface cho chúng ta.
Vài phương thức mà đặc tả EJB yêu cầu các home interface phải hỗ trợ. Những
phương thức đã yêu cầu này được định nghĩa trong javax.ejb. EJBHome interface-
một home interface mà home interface của chúng ta phải thừa kế.
Javax.ejb. EJBHome được trình bày như sau:
Public interface javax.ejb.EJBHome extendx java.rmi.Remote
{public abstract EJBMetaData getEJBMeTaData() throws
java.rmi.RemoteException;
public abstract void remove(Handle handle) throws
java.rmi.RemoteException,
javax.ejb.RemoveException;
public abstract void remove(Object primaryKey) throws
java.rmi.RemoteException, javax.ejb.RemoveException; }
Source 3.3 The javax.ejb.EJBHome interface

Hình 2.12:sơ đồ yêu cầu tạo một EJB object từ Home objects
Giải thích quá trình làm việc của hình 2.11 và 2.12:
Khi phương thức tạo được gọi trên home interface từ trình khách thì EJB home
tạo một thể hiện của EJB object mà tham chiếu tới thể hiện bean có kiểu tương ứng.
Khi thể hiện bean được kết hợp với EJB object thì phương thức ejbCreate() tương
ứng của thể hiện đó sẽ được gọi. Khi hoàn thành phương thức ejbCeate(), EJB
home trả lại tham chiếu remote tới client cho EJB object, (hình 2.12) . Sau đó client
có thể làm việc trực tiếp với EJB object bằng các phương thức nghiệp vụ, (hình
2.11) .
PHẦN II PHÁT TRIỂN ỨNG DỤNG
Trong phần này sẽ xây dựng ứng dụng E-store để mô tả những kỹ thuật, công
nghệ trong việc phát triển ứng dụng theo công nghệ J2EE. Ứng dụng được mô tả
phân tích với use case và miền phân tích theo UML. Sau đó được thiết kế theo kiến

trúc MVC – Model-View-Controller. Cuối cùng sẽ cài đặt theo các tầng như sau:
 Tầng giao diện Web (Web tier):công nghệ JSP, JavaBean, Servlet
 Tầng nghiệp vụ (Business tier): công nghệ EJB (Enterprise Java Bean) phiên
bản 1.x
 Tầng EIS (Enterprise Information System tier)
Mục đích của phát triển ứng dụng này là:
 Tìm hiểu việc sử dụng UML để phân tích thiết kế ứng dụng theo hướng đối
tượng.
 Minh họa cách sử dụng Rational Rose
 Tìm hiểu công nghệ EJB, JSP, Servlet của đặc tả J2EE.





CHƯƠNG 3 PHÂN TÍCH MÔ TẢ YÊU CẦU TRƯỜNG HỢP NGƯỜI DÙNG
VÀ KỊCH BẢN ỨNG DỤNG
3.1. Mô tả kịch bản của ứng dụng
Ứng dụng này là một phần của hệ thống thương mại điện tử. Ứng dụng này đảm
trách chức năng chính trong cả hệ thống, cho phép khách hàng tìm chọn và đặt mua
hàng thông qua mạng. Vì khả năng và thời gian nên em chỉ tập trung vào phần ứng
dụng này.
Kịch bản mua hàng được mô tả theo trình tự sau:
1. Khách hàng truy cập vào trang chủ Web site của ứng dụng này. Nó cho phép
tìm sản phẩm thông qua giao diện tìm kiếm.
2. Bất cứ khi nào khách hàng cũng có thể đăng nhập vào hệ thống bằng cách
cung cấp một account và password. Nếu khách hàng chưa có account thì hệ thống
yêu cầu tạo mới account bất cứ khi nào.
3. Khách hàng duyệt qua danh mục hàng, khách hàng chọn loại hàng để hiển thị
danh sách tất cả các sản phẩm trong loại hàng đó.

4. Khách hàng chọn một sản phẩm cụ thể trong danh sách. Hệ thống hiển thị
thông tin về sản phẩm đã chọn như: sự mô tả về sản phẩm, hình ảnh, thông tin giá
cả. Mỗi sản phẩm có nhiều mục hàng, mỗi mục hàng được trình bày riêng biệt.
5. Khách hàng quyết định mua một mục hàng cụ thể
6. Khách hàng chọn mục hàng cần mua vào trong giỏ hàng. Nếu khách hàng
chưa đăng nhập vào hệ thống thì được hệ thống yêu cầu đăng nhập. Nếu khách hàng
chưa có tài khoản thì có thể tạo mới.
7. Khi khách hàng yêu cầu ghi tên trước khi rời hệ thống thì hệ thống sẽ hiển thị
các mục hàng đã chọn cùng với thông tin giá cả.
8. Khách hàng xác nhận hoá đơn, hệ thống thu thập thông tin về vận chuyển,
thanh toán cho hóa đơn.
9. Cuối cùng khách hàng xác nhận đơn đặt hàng và hệ thống chấp nhận việc phát
chuyển hóa đơn đi.
3.2. Phân tích yêu cầu trường hợp người dùng
Bước đầu tiên trong quá trình phân tích là ta định nghĩa các use case - những
chức năng yêu cầu hệ thống. Việc phân tích use case liên quan đến việc phân tích
những đặc tả của người sử dụng để phát hiện ra các use case, actor.
3.2.1. Xác định các Actor
Từ mô tả kịch bản của ứng dụng ta có được Actor là khách hàng (customer)
 Khách hàng là người cần tìm món hàng và đặt mua hàng trên mạng thông
qua hệ thống này.
3.2.2. Xác định các Use case
Qua quá trình khảo sát đặc tả ứng dụng có được các use case của phần ứng dụng
này như sau:
 Tạo tài khoản (create account)
 Cập nhật tài khoản (update account)
 Đăng nhập vào và thoát khỏi hệ thống (signin and off )
 Duyệt xem danh mục hàng (browse catalog): tìm kiếm danh mục(search
catalog), duyệt xem loại hàng (browse category), duyệt xem chi tiết sản
phẩm (browse product details), duyệt xem chi tiết mục hàng (browse Item

details)
 Chọn mua hàng vào giỏ (shopping cart): thêm và xoá mục hàng(add and
remove Item), cập nhật số lượng của mục hàng (update quantity item), đặt
mua mục hàng (order item)
 Gửi đơn mua hàng đến trung tâm xử lý đơn hàng (Send Purchase Order to
Order Fulfillment Center)

Hình 3.1: lược đồ các Use case của cả ứng dụng