CODEDY - Blog

 Stateful Session Beans

4.1 Giới thiệu

4.2 Lifecycle of a Stateful Session Bean

Các beans phiên trạng thái không sử dụng tổng hợp phiên bản Các phiên bản dành riêng cho một máy khách

cho toàn bộ ứng dụng Các cá thể bean bị xóa khỏi bộ nhớ khi chúng không

trong đối tượng EJB của người dùng vẫn được kết nối với các trường hợp Bean của ứng dụng khách được thụ động trước

chúng bị xóa khỏi bộ nhớ và khi đối tượng EJB hoạt động thì cá thể đó là

được kích hoạt để khôi phục trạng thái của nó Bộ chứa điều chỉnh các hoạt động khác nhau để quản lý Phiên trạng thái Beans

Sau đây là các bước được thực hiện bởi container:

+ Sử dụng hàm tạo mặc định để tạo một cá thể bean

+ Chèn các tài nguyên như kết nối cơ sở dữ liệu

+ Lưu cá thể bean trong bộ nhớ

+ Thực thi phương thức nghiệp vụ do khách hàng gọi ra

+ Chờ và thực hiện các yêu cầu khác

+ Passivates thể hiện bean khi máy khách không hoạt động

+ Kích hoạt cá thể bean khi nhận được cuộc gọi từ máy khách

+ Hủy một phiên bản bean khi bean không được gọi trong một khoảng thời gian

+ Yêu cầu xóa cá thể bean khỏi máy khách yêu cầu kích hoạt bean

ví dụ sau đó là sự phá hủy

Có ba trạng thái trong vòng đời của Phiên trạng thái beanz Does Not Exist Mothod-Raady, and Passive.

Fiqure 4.6 hiển thị các trạng thái khác nhau của một bean Phiên trạng thái.

4.2.1 Lifecycle Callback Methods

Sau đây là các chú thích gọi lại khác nhau được sử dụng trong beanz Stateful Session:

+ PestConstruct e Các phương thức gọi lại này được thực thi sau khi phiên đậu là instam

theo thời gian của container Chúng được sử dụng trong cả đậu Trạng thái và Phiên không trạng thái

Các phương thức PostConstruct có tiền tố là chú thích @PostConstruct

+ PreDestroy e Các phương thức gọi lại này được thực thi trước khi bean phiên bị loại bỏ

từ vùng chứa và chuyển sang trạng thái Không tồn tại Các phương pháp này cũng được sử dụng

bởi cả đậu Trạng thái và Phiên không trạng thái và có tiền tố là @PreDestroy

chú thích

+ PrePassivate e Các phương thức gọi lại này được phiên beanj sử dụng trước bean

được thụ động là quá trình chuyển đổi từ Trạng thái sẵn sàng sang Trạng thái bị động Họ

thực hiện tất cả các hoạt động cần thiết trước khi chuyển giao bean, chẳng hạn như duy trì

trạng thái của session bean đến bộ nhớ thứ cấp, v.v. Các phương thức này được chú thích

với chú thích @PrePassivate

+ PostActivate e Các phương thức gọi lại này được sử dụng để thực hiện các tác vụ sau

vùng chứa chuyển phiên bean từ trạng thái thụ động sang trạng thái hoạt động

các phương thức được chú thích bằng @posActivate annotation.

4.2.2 Programming Rules for Stateful Session Bean

Sau đây là các quy tắc được thực hiện bởi beanz Phiên trạng thái:

+ biểu tượng của bean Stateful Session phải là kiểu dữ liệu nguyên thủy của Java hoặc các đối tượng có thể nối tiếp.

+ Lớp bean của Stateful Session nên định nghĩa một phương thức có thể phá hủy bean trong lập trường của lớp bean bằng cách sử dụng annotatiom @Remotre.

+ Bean phiên trạng thái có các phương thức gọi lại vòng đời PostActivate và PrePassivate Phương thức PostActivate được gọi sau khi bean được đưa trở lại bộ nhớ và phương thức PrePassivate được gọi trước khi cá thể bean ở trạng thái thụ động.

4.2.3 Developing Stateful Session Bean

Một bean Stateful Session được tạo với giao diện từ xa để quản lý các sản phẩm trong danh mục.

Code Snippet 1: hiển thị mã cho lớp ProductCatalogEean lớp.

Code Snippet 1 :

Trong Đoạn mã 1, hai phương thức nghiệp vụ addProduct () và getProduct () đang được tạo Phương thức addProduct () được sử dụng để thêm các sản phẩm mới vào cổng mua sắm. Các sản phẩm được thêm vào cổng được lưu trữ trong danh sách mảng. Phương thức getProduct () truy xuất các sản phẩm được thêm vào ProductCatalogBeam. Các phương thức được thêm vào ProductCatalogBean được máy khách từ xa truy cập thông qua giao diện từ xa.

Đoạn mã 2 hiển thị giao diện từ xa cho ProductCatalogBean.

Code Snippet 2

hiển thị giao diện từ xa do nhà phát triển xác định với các nguyên mẫu phương pháp có thể được sử dụng như một phần của ứng dụng Giao diện từ xa đề cập đến tập hợp các phương pháp được cung cấp bởi session bean có thể được truy cập bởi các máy khách từ xa.lnthe code, một remoteclient of ProduccCatalogaean canaccessthe các phương thức addProduct() và getProducts (). Chú thích @Remote chỉ ra rằng các phương pháp này có thể được truy cập chỉ bởi khách hàng từ xa.

4.3 Clients lnterfaces for Stateful Session Bean

Bản thân một EJB không thể thực hiện bất kỳ chức năng nào cho đến khi nó được gọi bởi máy khách. Máy khách EJB là một đối tượng tương tác với EJB để bean thực hiện một số dịch vụ thay mặt cho khách hàng này tương tác ở dạng khách hàng gọi các hoạt động trên các giao diện beanfs Giao diện của một EJB xác định các phương thức có sẵn cho các máy khách để gọi.

Khách hàng không bao giờ có quyền truy cập vào EJBt thực tế EJB nằm trong vùng chứa EJB và chỉ vùng chứa có quyền truy cập vào bean Khách hàng chỉ có quyền truy cập vào đối tượng EJB mà chứa chữ ký của tất cả các phương thức mà máy khách có thể calL Đối tượng EJB hoạt động như một nhà máy và nhà phân phối các đối tượng EJB cho khách hàng.

Quyết định cung cấp truy cập cục bộ hoặc truy cập từ xa phụ thuộc vào các yếu tố sau:

+ Loại dịch vụ-Kể từ khi ứng dụng khách có thể truy cập các hạt phiên của các ứng dụng

tien hoặc thông qua giao diện cục bộ hoặc thông qua các giao diện từ xa, chúng có thể được gọi là máy khách cục bộ hoặc máy khách từ xa Dựa trên loại dịch vụ được cung cấp bởi apa plication một khách hàng thích hợp được phát triển.

+ Mối quan hệ giữa các thành phần - Đậu doanh nghiệp cũng nhận các dịch vụ từ các hạt đậu khác Nếu các hạt đậu doanh nghiệp được kết hợp chặt chẽ với nhau tức là chúng có các yếu tố phụ đối với nhau, đó là một lựa chọn thiết kế tốt để tạo ra chúng như một đơn vị logic Trong một kịch bản các hạt đậu được cung cấp quyền truy cập cục bộ Nếu các thành phần hạt đậu lỏng lẻo được ghép nối sau đó các hạt đậu có thể truy cập vào nhau từ xa

+ Vị trí của các thành phần trên mạng doanh nghiệp - Một bean có thể được truy cập cục bộ hoặc từ xa dựa trên sự phân bố của các thành phần ứng dụng trên các bước vào mạng giải thưởng Nếu các thành phần còn lại của ứng dụng phải truy cập vào đậu doanh nghiệp được định vị từ xa thì thành phần đậu sẽ được định vị từ xa đã truy cập

+ Hiệu suất damands - Dựa trên nhu cầu hiệu suất của ứng dụng, nhà phát triển phải quyết định cách định vị và truy cập các thành phần bean của ứng dụng Các thành phần ứng dụng được đặt ở xa bị giảm hiệu suất do sự chậm trễ do truyền tải dữ liệu trên mạng. Nhà phát triển nên xem xét những yếu tố này trong khi quyết định loại hình tiếp cận các hạt doanh nghiệp

Dựa trên sự lựa chọn quyền truy cập vào bean, các phương thức truy cập bean có tiền tố là @Local và chú thích @Remote.

4.3.1 Local Client

Các máy khách cục bộ và EJB luôn nằm trong cùng một JVMt. và hạt đậu doanh nghiệp có mặt trong cùng một JVMt.

Một máy khách cục bộ có thể là một thành phần Web hoặc bean doanh nghiệp khác của ứng dụng.

Các máy khách cục bộ có thể truy cập các session bean thông qua nointerface hoặc thông qua local interface View View nointerface bao gồm tất cả các phương thức công khai của lớp session bean và giao diện cục bộ bao gồm các phương thức được khai báo như một phần của giao diện cục bộ Nếu giao diện nghiệp vụ của session bean là không được chú thích rõ ràng bằng chú thích @Local, nó được coi là giao diện cục bộ.

4.3.2 Remote Client

Một máy khách từ xa tới một EJB không cần phải được đặt trong cùng một JVM để truy cập các phương thức của bean Nó có thể nằm trong một JVM khác trên một máy vật lý khác Máy khách từ xa không quan tâm đến vị trí thực của máy mà nó truy cập.

Máy khách từ xa cen là một doanh nghiệp khác đang cư trú tại cùng một vị trí hoặc khác hoặc nó cũng có thể là một trang web epplicetion một applet hoặc một ứng dụng bảng điều khiển Java. Máy khách từ xa cen thậm chí là một chương trình không phải Java, chẳng hạn như ứng dụng CORBA được viết bằng C ++.

Ứng dụng khách từ xa không thể truy cập doanh nghiệp thông qua chế độ xem không giao diện Nó phải triển khai giao diện doanh nghiệp được chú thích bằng @Remo te annotation Một doanh nghiệp được khách hàng từ xa cho phép truy cập thông qua giao diện từ xa Các phương thức vòng đời kết thúc kinh doanh của doanh nghiệp được xác định trong điều khiển từ xa giao diện.

Code Snippet 3 thể hiện đoạn mã khách hàng từ xa truy cập vào ứng dụng cổng thông tin mua sắm.

Code Snippet 3:

4.3.3 Accessing JNDI Lookups

Máy khách có thể truy cập giao diện cục bộ hoặc từ xa của en doanh nghiệp bean thông qua các đối tượng EJB hoặc thông qua các dịch vụ tra cứu như JNDL JNDI là một dịch vụ đặt tên và thư mục được sử dụng để đăng ký các hạt doanh nghiệp cho lệnh gọi từ xa.

Để thực hiện tra cứu đối tượng EJB bằng JNDI, dịch vụ các thành phần sau cần được thiết lập như sau:

 

+ Các tham số khởi tạo JNDI e Các tham số khởi tạo JNDI bao gồm trình điều khiển JNDI được sử dụng để gọi bean doanh nghiệp đã đăng ký từ thư mục đặt tên Các trình điều khiển JNDI từ vùng chứa đến vùng chứa được sử dụng để meneging thể hiện bean Vì vậy, để truy cập dịch vụ JNDI, khách hàng phải cung cấp hướng dẫn sử dụng tài sản để truy cập

nhập trình điều khiển JNDI cụ thể cho vùng chứa trong chương trình máy khách Cách mã hóa cứng trình điều khiển JNDI phá hủy tính khả chuyển của mã Do đó, API JNDI cung cấp một ngữ cảnh ban đầu mặc định được sử dụng bởi trình trung tâm để đặt các thuộc tính JNDI cụ thể cho trung tâm. Các thuộc tính này được đặt cho môi trường khách trước bean được truy cập.

+ lnitialContext Class Một lớp văn bản InitialCon được sử dụng để tạo điểm nhập vào hệ thống neming được sử dụng trong epplicetion Các đối tượng của ứng dụng được liên kết với các tên JNDI để tham chiếu và được sử dụng trong epplicetion JNDI hoặc tạo tất cả các đối tượng của epplicetion thành một hệ thống cấp bậc và cá thể InitialContext được sử dụng để tạo gốc của cấu trúc hierer. javax t đặt tên cho i Lớp InitzialContzextz thực hiện giao diện Context.

Đoạn mã 4 trình bày cách sử dụng đối tượng InitialContext.

Code Snippet 4:

Đoạn mã cho thấy việc sử dụng đối tượng InitialContext, lấy lại tham chiếu của giao diện ProductzCatzaloBeanRemote.

+ Cấu hình JNDI

Thao tác tra cứu trong mã nguồn JNDI được thực hiện thông qua phương pháp tra cứu trong Đoạn mã 4, thao tác tra cứu được thực hiện để truy cập giao diện từ xa của Nhóm sản phẩm Bảng tên trong mã thực hiện tra cứu trên bảng tên chung.

Phương thức tra cứu sử dụng bộ mô tả triển khai để nhận được liên kết đối tượng và neme JNDI.

Đoạn mã 5 hiển thị mô tả triển khai mẫu e với các liên kết neme JNDI được xác định.

Code Snippet 5:

Bộ mô tả triển khai là một tệp XML không tinh vi được sử dụng để định cấu hình ứng dụng trong Đoạn mã 5, ProductCatalogEean được liên kết với JNDI neme 'pro'.

4.3.4 Web Clients

Máy khách web là các thành phần Web khác nhau của ứng dụng có thể truy cập hạt đậu doanh nghiệp thông qua giao diện từ xa hoặc giao diện cục bộ dựa trên các giao diện được xác định bởi hạt đậu doanh nghiệp.

Các máy khách dịch vụ Web gọi các phương thức kinh doanh của đậu Stateless S ession Một máy khách Web có thể truy cập tất cả các phương thức công khai của đậu doanh nghiệp.

4.4 Tiêm các tài nguyên trong doanh nghiệp Beans

 Việc chèn tài nguyên cho phép các nhà phát triển đưa các tài nguyên như cơ sở dữ liệu, trình kết nối, v.v. vào các thành phần được quản lý bởi vùng chứa như thành phần Web và thành phần bean. Các tài nguyên phải được xác định trong không gian tên JNDI để nó có thể được đưa vào thành phần. Javax.annotation.Resource được sử dụng để khai báo một tham chiếu đến một tài nguyên. Chú thích được thêm vào mã dưới dạng @Resource. Việc tiêm tài nguyên có thể là tiêm dựa trên lớp, tiêm dựa trên trường / phương thức.

Chú thích tài nguyên có năm thành phần cụ thể là tên, loại, xác thựcType,

shareable, mappedName và mô tả. Mô tả của các phần tử như sau:

-        trường tên có tên JNDI của tài nguyên đang được truy cập.

-        type ngụ ý loại tài nguyên.

-        Mô tả mô tả tài nguyên.

-        mappedName ngụ ý bất kỳ tên cụ thể nào của hệ thống mà tài nguyên phải có

được lập bản đồ.

-        shareable ngụ ý liệu tài nguyên có thể được chia sẻ với các thành phần khác hay không.

Để sử dụng chèn dựa trên trường, khai báo trường phải được đặt trước chú thích Tài nguyên.

Đối với phương thức chèn dựa trên phương thức, phương thức setter có thể được khai báo trước chú thích @Resource. Phương thức setter phải tuân theo quy ước đặt tên bean; tên phương thức phải bắt đầu bằng 'set'.

Việc chèn tài nguyên dựa trên lớp có thể được thực hiện bằng cách cung cấp chú thích @Resource với các giá trị tên và kiểu thích hợp.

4.5 Xử lý ngoại lệ trong phiên Beans

Ngoại lệ trong Java đề cập đến các điều kiện bất thường phát sinh trong quá trình thực thi ứng dụng. Java cung cấp các cơ chế xử lý ngoại lệ để làm cho ứng dụng trở nên mạnh mẽ. Ngoại lệ là một sự kiện, xảy ra trong quá trình thực thi chương trình làm gián đoạn luồng hướng dẫn bình thường của chương trình.

Một số trường hợp ngoại lệ này là do lỗi người dùng, một số do lỗi lập trình và các trường hợp khác do tài nguyên vật lý bị lỗi theo một cách nào đó.

Xử lý ngoại lệ được thực hiện thông qua các cơ chế như khối try-catch và câu lệnh ném trong mã Java.

Trong trường hợp khối try — catch, mã có khả năng tạo ra một ngoại lệ được bao gồm trong khối try và khối catch bao gồm mã được thực thi để xử lý ngoại lệ xảy ra trong khối try.

Trong một khối mã nhất định nếu có xác suất xảy ra ngoại lệ thì nó có thể được đề cập rõ ràng với câu lệnh ném. Khối catch chịu trách nhiệm xử lý ngoại lệ.

4.5.1 Các loại ngoại lệ

Có ba loại ngoại lệ:

-        Checked exceptions - Ngoại lệ đã kiểm tra là một ngoại lệ thường là lỗi của người dùng hoặc sự cố mà người lập trình không thể lường trước được - các điều kiện không hợp lệ trong các khu vực nằm ngoài sự kiểm soát ngay lập tức của chương trình (đầu vào của người dùng không hợp lệ, sự cố cơ sở dữ liệu, sự cố mạng và tệp vắng mặt).

-         Unchecked / Runtime exceptions - Các ngoại lệ không được kiểm tra xảy ra do lỗi trong logic lập trình, chúng không thể được phát hiện tại thời điểm biên dịch, do đó được gọi là ngoại lệ thời gian chạy.

-        Ngoại lệ thời gian chạy - Các ngoại lệ thời gian chạy xảy ra do logic được triển khai trong ứng dụng không chính xác. Chúng chỉ được phát hiện khi ứng dụng thực thi. Chúng không thể được phát hiện trong thời gian biên dịch ứng dụng.

4.5.2 Ngoại lệ Java EE

-         Theo đặc tả của EJB, một ứng dụng doanh nghiệp có thể có hai loại ngoại lệ - Ngoại lệ ứng dụng và Ngoại lệ hệ thống.

-        Các ngoại lệ của ứng dụng phát sinh do các điều kiện nhất định trong logic nghiệp vụ của ứng dụng.

-        Hệ thống ngoại lệ phát sinh do lỗi trong cơ sở hạ tầng ứng dụng hoặc lỗi kết nối cơ sở dữ liệu.

-        Các ngoại lệ ứng dụng trong trường hợp ứng dụng doanh nghiệp là - CreateException, FinderException và RemoveException.

-        Các ngoại lệ hệ thống thường xảy ra là RemoteException, NamingExceptions, SQLException, v.v.

-        Một EJBException được ném ra khi một ngoại lệ Ứng dụng hoặc ngoại lệ Hệ thống xảy ra.

CreateException : Được nâng lên khi việc khởi tạo một đối tượng hoặc bean không thành công.

FinderException: Nâng lên khi ứng dụng không thể tìm thấy đối tượng.

RemoveException: Nâng lên khi ứng dụng không thể loại bỏ một phiên bản bean không thể bị xóa khỏi vùng chứa.

RemoteException: Nâng lên khi có sự cố mạng và máy khách không thể truy cập vào một obiect từ xa.

NamingException: Được nâng lên khi tên jndi không thể được phân giải cho đối tượng.

SQLException: Tăng lên khi bean không thể nhận được phản hồi từ ứng dụng cơ sở dữ liệu.

lEJBException: Nó có thể được nâng lên khi bean không thể phản hồi các ứng dụng khách một cách thích hợp.

4.6 Exception Handling in Enterprise Applications

Trong các ứng dụng doanh nghiệp, việc xử lý ngoại lệ có thể được thực hiện bởi vùng chứa hoặc thông qua enterprise Beans. Cả ngoại lệ ứng dụng và ngoại lệ hệ thống đều có thể được xử lý bằng cách thùng chứa hoặc một bean.

4.6.1 Handling Exceptions Through a Container (Xử lý các ngoại lệ thông qua một vùng chứa)

Các ngoại lệ ứng dụng có thể được đưa ra bởi các phương thức bean doanh nghiệp được gọi bởi khách hàng hoặc các enterprise beans. Khi một ngoại lệ được ném, giao dịch trong đó ngoại lệ được ném không cần phải được cuộn lại. Thay vào đó, ngoại lệ được ném được chuyển vào bean người gọi hoặc máy khách. Các ứng dụng doanh nghiệp không khôi phục các hành động đã thực hiện. Ngoại lệ được ném ra được trả về quay lại người gọi và sau đó, vùng chứa tiếp tục thực thi mã xử lý ngoại lệ.

Bất cứ khi nào một vùng chứa gặp phải các ngoại lệ của hệ thống, thì nó sẽ thực hiện các hoạt động sau:

-        Đầu tiên vùng chứa ghi lại ngoại lệ hệ thống.

-        Sau đó, nó sẽ phân bổ tất cả các tài nguyên được phân bổ và thực hiện tất cả các hoạt động dọn dẹp trên cá thể bean.

-        Xóa cá thể bean khỏi bộ nhớ đã gây ra ngoại lệ hệ thống.

-        Phương thức gọi được thông báo về ngoại lệ hệ thống bằng cách ném một ngoại lệ như javax.ejb.EJBException, javax.EJBJ'IoSuchEZJBI-Ixception, và như thế.

4.6.2 Handling exceptions though beans

Các ngoại lệ có thể được xử lý bằng cách viết mã rõ ràng để xử lý ngoại lệ. Nếu các ngoại lệ được xử lý thông qua các lớp bean sau đó bean cố gắng khôi phục từ ứng dụng. Nếu ứng dụng có thể được khôi phục thì mã khôi phục sẽ được gọi. Nếu ngoại lệ thì không có thể phục hồi sau đó giao dịch được khôi phục.

Code Snippet 6:

Các ngoại lệ thời gian chạy có thể là ngoại lệ ứng dụng và ngoại lệ hệ thống. Bean có thể xử lý các ngoại lệ của ứng dụng bằng cách chuyển hướng đến mã xử lý ngoại lệ trong bean. Đó là một lựa chọn thiết kế tốt để xử lý các ngoại lệ khác với các ngoại lệ ứng dụng thông qua vùng chứa. Bất cứ khi nào một ngoại lệ ứng dụng được ném ra, bean sẽ xử lý chúng theo những cách sau:

-        Nếu mã xử lý ngoại lệ cho ngoại lệ ứng dụng được xác định thì mã xử lý ngoại lệ sẽ được thực thi.

-        Nếu ngoại lệ của ứng dụng không thể khôi phục được, thì lớp bean sẽ ném một ngoại lệ và thoát.

-        Nếu ngoại lệ gây ra mất tính toàn vẹn của dữ liệu thì giao dịch sẽ được khôi phục.Các ngoại lệ hệ thống như EJBException và RuntimeException không được xử lý thông qua các phương thức bean. Chúng thường được xử lý thông qua thùng chứa.

 4.7 Exception Logging

Ứng dụng ghi nhật ký các ngoại lệ để nhà phát triển phân tích thêm và khắc phục nguyên nhân của ngoại lệ. Các ngoại lệ có thể được ghi ở nhiều cấp - Ghi nhật ký cấp thành phần, ghi nhật ký cấp trung bình và ghi nhật ký cấp cao nhất.

 

Ghi nhật ký cấp thành phần của các ngoại lệ đề cập đến ghi nhật ký ngoại lệ tại mỗi thành phần của ứng dụng. Bất cứ khi nào, một thành phần ném một ngoại lệ, nó cũng tạo một mục nhập vào nhật ký ngoại lệ. Cơ chế ghi nhật ký ngoại lệ này yêu cầu mã ghi nhật ký được viết cho từng thành phần. Trong trường hợp ghi nhật ký ngoại lệ cấp trung bình, nhật ký ngoại lệ được duy trì ở một vị trí chung cho các thành phần khác nhau, nơi có đủ thông tin về tất cả các thành phần, chẳng hạn như một vùng chứa. Ghi nhật ký cấp trung gian không có thông tin về toàn bộ ứng dụng mà là một tập hợp con của các thành phần ứng dụng.

 

Nhật ký ngoại lệ cũng có thể được duy trì ở cấp cao nhất, điều này đề cập đến nhật ký ngoại lệ của ứng dụng. Ghi nhật ký cấp cao nhất của các ngoại lệ có thông tin về tất cả các ngoại lệ được đưa vào ứng dụng. Các bản ghi ngoại lệ như vậy rất hữu ích để đánh giá hiệu suất của toàn bộ ứng dụng.

 

Code Snippet 7 thể hiện việc ghi ngoại lệ trong các ứng dụng doanh nghiệp.

Code Snippet 7: