View Full Version : bonusapp va web_server/app_server
hello,
tôi cài lại win2000 server và lên được thư mục public_html tuy nhiên lại xảy ra chuyện.Tôi đã bắt đầu bài học đầu tiên của bài viết Developing Enterprise Applications Using the J2EE(TM) Platform ..tại http://developer.java.sun.com/developer/onlineTraining/J2EE/Intro2/j2ee.html
khi tôi gõ vào lệnh j2ee -verbose thì quá trình khởi động j2ee không thành công,tuy nhiên nếu khởi động tương tự trên win2000 professional thì lại được.
thứ đến,tôi dùng j2sdkee1.3 và jdk1.3 để compile và deploy ứng dụng.Và tôi đã deploy thành công ứng dụng bonusapp ,tuy nhiên khi tôi kích nút submit ,kết quả không phải là một file html đã được trình duyệt dịch mà giống như là một file văn bản bao gồm các thẻ và nội dung sẽ được hiển thị,đây là điều tôi muốn hỏi các bạn.
còn chuyện nữa là ,người ta nói rằng iplanet là một web server và weblogic là một application server;vậy thì ,sự khác nhau giữa web server và application server là gì.:question:
thank in advance.
1.Bạn xem lại các PATH của ứng dụng.
2.Vì file nó sinh ra là file html
3.Câu này khó trả lời ,nói chung Web Server là một ứng dụng cho phép ta thiết lập một Server ,còn ột Web Application thường là một phụ trợ của WebServer dùng thiết lập các ứng dụng chuyên nghiệp trên WebServer.
oxcafebabe
23-09-2002, 19:11
WEB Sever (WS) dùng để "serve" http requests - GET, SET, POST... Đơn giản thế thôi.
Muốn biết "Application Server" (AS) là gì thì trước tiên ta phải liệt kê ra những thành phần cấu trúc (architectural component) tồi thiểu của những client/server (c/s) applications:
0. Business Logic
1. Security.
2. Database
3. Session management
4. Presentation (User Interface)
5. Version Control
6. System resources Management (Memory, Thread,...)
Trừ Business Logic ra, những thành phần khác có nhiều nét tương tự và có thể được tái dụng nguyên bản (hoặc thay đổi rất ít). Application Server (chính nó là một application) là môi trường cung cấp những đòi hỏi từ 1-6 của c/s applications. Vì vậy, khi biên trình cho application server, bạn chỉ cần chú tâm vào business logic trong một khuôn khổ (application framework) sẵn định.
Nếu phần presentation generation của AS được thiết kế đúng mức thì user interface của AS có thể là web browsers, awp browsers, swing, hay bất cứ công nghệ nào. Tuy nhiên user interface thông dụng nhất vẫn là web browser, vì vậy phần lớn các AS đều có "built-in" hoặc chạy song song với một cái WS, và applications chạy trên AS còn có tên là Web Application.
Ồ bạn Oxcafebabe giỏi quá ,Box này đang thiếu một Mod nừa ,bạn có thể công tác với mình làm Mod của Box Java không !
1.Bạn xem lại các PATH của ứng dụng.
2.Vì file nó sinh ra là file html
thanks,
1.tuy nhiên tôi nghĩ rằng path hay classpath không có vấn đề bởi vì tôi còn compile được trên nền win2000 server rồi.
2.file html khi hiển thì bởi trình duyệt thì phải không còn nhìn thấy các thẻ của nó chứ,đằng này lại gồm hỗn hợp giữa nội dung và kết quả.lol
Tuy nhiên user interface thông dụng nhất vẫn là web browser, vì vậy phần lớn các AS đều có "built-in" hoặc chạy song song với một cái WS, và applications chạy trên AS còn có tên là Web Application.
thanks,
bài viết của bạn rất hay.Đúng là trong j2sdkee1.3 thì quá trình khởi động của nó có thông báo rằng nó dùng cả tomcat4.0 làm Web server (khi có tomcat thì không cần phải cài thêm một web server nào nữa),có lẽ j2sdkee1.3 là một app server hoặc một ứng dụng chứa đựng cả một web server và một AS:question: .Người ta để các tệp War(web archive) tại web server và các đối tượng ejb ở app server.
iPlanet là 1 web server và weblogic là 1 app server,vì thế tôi phải triển khai war file trên iPlanet và ejbs trên weblogic.
bạn có nói là "Business logic" là một dạng yêu cầu mà AS đáp ứng được.Vậy thì theo bạn ,"Business logic" được hiểu theo nghĩa nào và được hiểu như thế nào:question: . Trong ejb họ cũng đề cập đến khái niệm này ví dụ như "business method" (Business methods đại diện cho các phần công việc mà một bean thực hiện)hay "business processes"(hoặc agents) mà thực hiện một dịch vụ chẳng hạn như làm một việc đặt chỗ ở một khách sạn.
note:bạn nào có biết từ scalable(scalability) dịch ra tiếng việt là gì không.
oxcafebabe
24-09-2002, 07:27
Bạn hiểu lầm rồi, tôi đâu có nói là AS đáp ứng được phần Business Logic - đây là phần "tâm huyết" của ứng trình mà. Tuy nhiên nếu bạn gói gém phần tâm huyết này vào trong cái application framework như ejb thì bạn có thể tận dụng tất cả những "services on offer" - session, persistence, security...management.
Có thể nói ejb là framework trong business modelling trong AS, mà trong AS còn có nhiều frameworks khác, - jsp engine cho nội dung động, Struts cho presentation, JDO (một tiêu chuẩn/công nghệ khá mới) cho persistence, JMS cho thông tin giữa các distributed apps....
Hà, dịch scalable/scalibity sang tiếng Việt thì tôi chiụ thua, nhưng cố thử giải thích xem sao ;-).
Scalibity đến từ cấu trúc (architecture), nó cho phép ứng trình thích nghi với thay đổi và tận dụng triệt để tài nguyên của host platform. Theo đúng nghiã thì scalability có 2 chiều - up và down, nhưng thông thường lại được sử dụng để ám chỉ (một cách sai lầm) về chiều "up" mà thôi.
Ngoài ra, scalibity còn có chiều dọc và ngang (vertical/horizontal scalability). Chiều dọc dùng trong phạm vi của một "host machine" - có nghiã là mức đo lường của tài nguyên (CPU, RAM, HDD...) vs. hiệu năng của ứng trình. Ðể đạt được vertical scalability thì khá dễ . Thường thì "thread based programs are more (vertical) scalable than process based one". Lý do cũng đơn giản - program threads được hệ điều hành phân phối trên mọi CPU , máy càng nhiều CPU thì năng xuất càng cao và ngược lại. Còn mỗi process thì nhiều nhất thì "chiếm ngự" lấy một CPU nên nếu một ứng trình mà có 10 processes thì chỉ có thể "up-scale" tới CPU là cùng.
Ðây là lý thuyết còn về thực hành hơi phũ phàng tí xiú. Vì program threads phải chung dụng tài nguyên - network connections, database connections, files, objects... thành ra đến một lúc nào đó chúng phải dừng (idle) để ...chờ phiên. Vả lại, multi-thread programming cũng không phải là đơn giản, nếu không khéo thì ứng trình lại chậm hơn single-thread.
"Nói" nhiều quá nên khàn tiếng rồi ;-). Nếu các bạn muốn "nghe " thêm thì tôi sẽ bàn thêm về horizontal scalability ở post tới.
To quangvu :
Tôi bận lắm nên chỉ "cỡi ngưạ xem hoa thôi", nếu có câu hỏi lý thú sẽ dừng lại mà nói bậy vài câu ;-).
Bạn hiểu lầm rồi, tôi đâu có nói là AS đáp ứng được phần Business Logic - đây là phần "tâm huyết" của ứng trình mà. Tuy nhiên nếu bạn gói gém phần tâm huyết này vào trong cái application framework như ejb thì bạn có thể tận dụng tất cả những "services on offer" - session, persistence, security...management.
Có thể nói ejb là framework trong business modelling trong AS, mà trong AS còn có nhiều frameworks khác, - jsp engine cho nội dung động, Struts cho presentation, JDO (một tiêu chuẩn/công nghệ khá mới) cho persistence, JMS cho thông tin giữa các distributed apps....
chỗ này khó hiểu quá:o
tôi sẽ đưa bản dịch về "business logic" từ http://java.sun.com/blueprints/guidelines/designing_enterprise_applications/ejb_tier/business_logic/index.html để bạn nhận xét nhé.
5.1 Business Logic
Business logic, theo nghĩa rộng,là tập các hướng dẫn để quản lý một chức năng kinh doanh cụ thể. Chiểu theo cách tiếp cận huớng đối tượng khiến nhà phát triển phân tích một chức năng kinh doanh vào trong tập của các thành phần hoặc các phần tử được gọi là business objects. Cũng như các đối tượng khác ,các business objects này sẽ có cả hai characteristics (trạng thái hoặc dữ liệu) và hành vi.Ví dụ,một đối tượng employee sẽ có dữ liệu chẳng hạn một name, address, social security number, ... Nó sẽ có các phượng thức cho việc gán nó tới một phòng ban mới hoặc thay đổi lương của nó theo một tỷ lệ phần trăm nhất định. Để quản lý vấn đề kinh doanh này chúng ta phải có khả năng đại diện các đối tượng này có chức năng hoặc tương tác để cung cấp các chức năng mong muốn như thế nào. Các quy định kinh doanh cụ thể mà giúp chúng ta nhận dạng cấu trúc hoặc hành vi của các đối tượng business objects, cùng với các điều kiện trước và sau mà phải đựơc đáp ứng khi một đối tượng bộc lộ hành vi của nó tới các đối tượng khác trong hệ thống, được hiểu như business logic.
Thảo luận sau đây thể hiện làm thế nào để định nghĩa cấu trúc và hành vi của một đối tượng business object từ những yêu cầu được nhấn mạnh bởi các vấn đề kinh doanh mà nó thuộc về .Ví dụ như , ứng dụng mẫu chứa đựng một nhóm các business objects: một đối tượng catalog để thể hiện các pets có sẵn,một đối tượng shopping cart để tạm thời nắm giữ sự lựa chọn các pets của khách hàng,một đối tượng account để giữ thông tin về các khách hàng,và một đối tượng order (đặt hàng) để theo dõi “placed orders”(các đơn đặt hàng đã đặt).Chúng ta cân nhắc các yêu cầu đối với đối tượng account:
1. Mỗi client phải có một account duy nhất.
2. Mỗi account nên contact thông tin cho một khách hàng ví dụ như name, street address, và email address.
3. Các Clients phải có thể tạo các accounts mới.
4. Các Clients phải có khả năng cập nhật thông tin tiếp cận cho account của họ .
5. Các Clients phải có khả năng thu nhận thông tin cho account của họ.
6. Các Clients có thể thu nhận và cập nhật chỉ những thông tin account của họ.
7. Thông tin tài khoản phải được bảo trì trong kho lưu trữ file.
8. Đa khách hàng phải có khả năng truy cập thông tin tài khoản của họ cùng một thời điểm.
9. Đa khách hàng không thể cập nhật cùng lúc cùng một tài khoản.
Các yêu cầu đầu tiên đặc tả các thuộc tính cấu trúc của đối tượng tài khoản (account object).Các quy định sau đây , đối tượng account nên có một trường(field) để giữ đinh danh tài khoản và các trường khác sẽ nắm giữ address, phone, và các thông tin tiếp xúc khác.
Hành vi của đối tượng account được miêu tả trong yêu cầu 3,4 và 5.Ví dụ ,các tài khoản nên có các hành vi để tạo một account mới ,cập nhật thong tin tiếp xúc ,và để lấy thông tin tài khoản.
4 yêu cầu cuỗi cùng đặc tả các điều kiện chung mà phải được đáp ứng khi nhận ra hành vi của đối tượng account Ví dụ,khi một khách hàng cập nhật một tài khoản ,khách hàng nên có thẩm quyền để truy cập vào tài khoản cụ thể đó, thông tin tài khoản được cập nhật nên được ghi vào kho lưu trữ file và việc truy cập đồng thời tới thông tin tài khoản do nhiều khách hàng nên bị cấm.
Các định nghĩa yêu cầu và phân tích tương tự nên được thực hiện cho các đối tượng khác. Ví dụ, một đối tượng đặt hàng sẽ có một tập các điều kiện chung về hành vi của nó sự tương quan đáng kể tới hành vi của một đối tượng. Đó là ,một khách hàng cần được có thẩm quyền trước khi cập nhật hoặc đọc trạng thái của một đối tượng đặt hàng( order), các chi tiết đặt hàng cần được ghi tới một kho lưu trữ dữ liệu ..
Nếu bạn kiểm tra các đối tượng business objects trong các ứng dụng tương tự ,bạn sẽ thấy rằng thậm chí cấu trúc và hành vi thực sự của một đối tượng được ràng buộc chặt chẽ tới vấn đề kinh doanh nó đang giải quyết ,nhiều dịch vụ mà các business objects này cung cấp những khuôn mẫu cụ thể sau mà tương đối phổ dụng trong tự nhiên.
5.1.1 Common Requirements of Business Objects
Phần này miêu tả các yêu cầu chung của các đối tượng business objects.
5.1.1.1 Maintain State
một business object hay cần bảo trì trạng thái được đại diện trong các biến instance giữ các lời gọi phương thức.Trạng thái có thể là "đàm thoại" hoặc persistent(bền vững-lưu vào file).
Cân nhắc một đối tượng shopping cart . Trạng thái của đối tượng shopping cart đại diện các khoản mục(item) và số lượng của các khoản mục được mua bởi khách hàng. Cart(giỏ hàng) đầu tiên là trống và thu lại một trạng thái có ý nghĩa khi người dùng thêm một mục vào giỏ hàng. Khi một người dùng thêm một khoản mục khác nữa vào cart,giỏ hàng nên có cả hai mục trong đó .Tương tự ,khi một người dùng xoá một mục từ giỏ hàng ,giỏ hàng nên phản ánh sự thay đổi trạng thái trong đó. Khi một người dùng thoát khỏi ứng dụng , đối tượng cart cần đựơc khởi tạo lại .Khi đối tượng thu lơị,bảo trì và mất trạng thái của nó bởi do kết cục tương tác lặp lại với cùng một client, chúng ta nói đối tượng bảo toàn trạng thái hội thoại”.
Để hiểu trạng thái bền vững ,cân nhắc một đối tượng account .Khi một người dùng tạo một account , thông tin account cần được lưu trữ lâu dài để mà khi người dung thoát khỏi ứng dụng và tái đăng nhập vào ứng dụng ,thông tin account có thể được trình bày lại tới người dùng đó.Trạng thái của một đối tượng account cần được bảo trì trong một kho lưu trữ bền vững ví dụ như cơ sở dữ liệu.Điển hình,các đối tượng business objects mà hoạt động trên sự bảo trì trạng thái bền vững trưng bày dữ liệu trung lập theo phiên.
5.1.1.2 Operate on Shared Data
Đặc tính chung khác của các đối tượng business objects là chúng thường hoạt động trên sự chia sẻ dữ liệu.Trong trường hợp này ,các đo lường phải được lấy để cung cấp sự diều khiển đồng thời và các mức độ thích hợp của việc cách ly dữ liệu được chia sẻ.Một ví dụ như một viễn cảnh sẽ là nhiều người dùng cập nhật cùng một thông tin tài khoản. Nếu 2 người dung cố câp nhật cùng một tài khoản tại cùng một thời điểm , đối tượng business object nên cung cấp một cơ chế để giữ dữ liệu trong một trạng thái “consistent” khác.
5.1.1.3 Participate in Transactions
Một giao dịch có thể được miêu tả như một tập các phần việc mà cần được hoàn thành như một unit. Nếu một trong các phần việc lỗi(bể, đổ bể),tất cả các phần việc trong unit sẽ được “rolled back”.Nếu tất cả chúng thành công,giao dịch(giao tác) đựơc coi là đã được cam kết.
Các đối tượng Business objects thường hay cần tham gia các giao dịch. Ví dụ,nơi đặt hàng cần phải được giao tác bởi do tập hợp các phần việc đựoc yêu cầu để hoàn thành một đặt hang --giảm các khoản mục được mua trong “bản kiểm kê khoản mục”, lưu giữ các chi tiết đặt hàng,và gửi cam kết đặt hàng tới người dùng. Để giao dịch được hoàn thành,tất cả các phần việc này phải thành công.Nếu bất kỳ một trong cái này bị lỗi,việc làm hoàn thành bởi các phần việc khác cần được làm lại.
Trong nhiều hoạt động kinh doanh,các giao dịch có “span” hơn một nguồn dữ liệu từ xa. Các giao dịch này--được gọi là các giao dịch phân tán—yêu cầu các giao thức đặc biệt để đảm bảo toàn vẹn dữ liệu. Trong ứng dụng mẫu,nơi đặt hàng là một giao dịch phân tán bởi vì bảng “inventory” và bảng đặt hàng cư trú trong các nguồn dữ liệu khác nhau
5.1.1.4 Service a Large Number of Clients
Một đối tượng business nên có khả năng cung cấp dịch vụ của nó tới một số lượng lớn các clients tại cùng một thời điểm. Điều này chuyển vào trong một yêu cầu cho các thuật toán quản trị mà đưa mỗi client một sự nhấn mạnh rằng một đối tượng “chuyên môn về business object” là sẵn có để phục vụ yêu cầu của nó. Không có một cơ chế như thế,hệ thống sẽ thậm chí chạy ra ngoài các tài nguyên và sẽ không thể phục vụ bất kỳ khách nào hơn nữa .
5.1.1.5 Provide Remote Access to Data
Một client nên có thể truy cập từ xa các dịch vụ được đề xuất bởi một đối tượng business object. Điều này nghĩa là đối tượng business object nên có một vài kiểu hạ tầng cơ sở để hỗ trợ các khách hàng tham gia dịch vụ qua mạng. Điều này lần lượt ngụ ý rằng,một đối tượng business object nên là một phần của một môi trường tính toán phân tán mà chăm sóc các sự kiện trong hệ thống phân tán chẳng hạn vùng và sự trong suốt lỗi.
5.1.1.6 Control Access
các dịch vụ được đề xuất bởi các đối tượng business objects thường yêu cầu cùng kiểu hợp lệ client authentication và cơ chế thẩm quyền để cho phép chỉ một tập hợp khách hang truy cập các dịch vụ được bảo vệ.Ví dụ.một đối tượng account business cần hợp lệ “authenticity “ của khách hang trước khi cho phép nó cập nhật thông tin tài khoản của nó. Trong nhiều kịch bản doanh nghiệp,các mức độ khác nhau của điều khiển truy cập là được cần. ví dụ, các nhân viên(employees ) được phép xem chỉ các đối tượng lương của họ ,trong khi một "người quản trị lương“ có thể xem cũng như sửa đổi tất cả các đối tượng lương.
5.1.1.7 Reusable
Một yêu cầu chung của các đối tượng business objects là chúng được tái sử dụng bởi các thành phần khác nhau của cùng một ứng dụng và/hoặc bởi các ứng dụng khác nhau.Ví dụ,một ứng dụng được dung bởi phòng trả lương để theo dõi lương của các nhân viên có thể có 2 đối tượng business objects: employee và salary. Đối tượng salary business object có thể sử dụng các dịch vụ của một đối tượng employee business object để lấy múc độ cấp bậc(grade) của một nhân viên.Một ứng dụng ,mà theo dõi tiền cấp phát lương nhân viên(employee vacation allowances) có thể muốn dùng đối tượng employee object này để lấy tên của nhân viên trong số các nhân viên. Để cho các business objects có thể được dùng bởi các thành phần ứng dụng “inter- and intra-“ ,chúng cần được phát triển trong một cách chuẩn mực và chạy trong môi trường mà tuân theo bởi các chuẩn mực này.Nếu các chuẩn mực này đựơc chấp nhận và thực hiện rộng rãi bởi cộng đồng vendor ,một ứng dụng có thể được lắp ráp từ các thành phần “off-the-shelf “ từ các vendors khác nhau.Ngoài việc phát triển các ứng dụng nhanh,cách tiếp cận này giúp cho các nhà phát triển tránh “vendor lock-in”.
Tltk:
http://developer.java.sun.com/developer/onlineTraining/J2EE/Intro/
http://developer.java.sun.com/developer/onlineTraining/J2EE/Intro2/j2ee.html
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications/apmTOC.html
http://developer.java.sun.com/developer/onlineTraining/EJBIntro/EJBIntro.html
Enterprise Beans as Distributed Objects
Các giao diện remote và home là các kiểu giao diện từ xa Java RMI Remote interfaces. Giao diện java.rmi.Remote đuợc dùng bởi các đối tượng phân tán để đại diện cho bean trong một không gian địa chỉ khác (process hoặc machine). Một enterprise bean là một đối tượng phân tán. Điều này nghĩa là lớp bean được khởi tạo và sống trong một container nhưng có thể được truy cập bởi các các ứng dụng mà sống trong các không gian địa chỉ khác.
Để làm một đối tượng trường hợp(object instance) trong một không gian địa chỉ có sẵn trong cái khác yêu cầu yêu cầu một “ little trick involving network sockets”. để làm “ trick work”,bao gói(chứa) trường hợp trong một đối tượng đặc biệt được gọi là một “skeleton” mà có một kết nối mạng tới một đối tượng đặc biệt khác được gọi là một “stub”. stub thực thi giao diện remote vì thế nó trông như một business object. Nhưng stub không chứa đựng business logic; nó nắm giữ một kết nối “network socket” tới “skeleton”. Mọi lúc một hành vi business method được gọi lên giao diện từ xa của stub ,stub gửi một thông điệp mạng tới “skeleton” nói lên phương thức nào được gọi. Khi “skeleton” nhận một thông điệp mạng từ “stub”, nó nhận dạng hành vi được gọi lên và các đối số,và rồi gọi lên phương thức tương ứng trên các trường hợp thực sự. Trường hợp(instance) thực hiện hành vi business method và trả về kết quả tới “skeleton”,mà gửi nó tới “stub”.Biểu đồ sáu minh hoạ điều này:
file:///C:\Documents and Settings\users02\Desktop\clip_image001.gif
“stub” trả về kết quả tới ứng dụng mà đã gọi lên hành vi giao diện từ xa của nó.Từ “ perspective of the application using the stub”, nó trông như “stub” làm công việc tại địa phương.Thực chất,”stub” chỉ là một đối tượng mạng câm (dumb network object) mà gửi các yêu cầu chéo qua mạng tới skeleton, mà lần lượt gọi lên hành vi lên thể hiện sự. Trường hợp không làm tất cả các công việc , “stub” và “skeleton” chỉ truyền các đối số và định danh phương thức đi và trở lại chéo qua mạng
Trong EJB, “skeleton” cho các giao diện remote và home interfaces được thực thi bởi container,không phải bởi lớp bean Điều này đảm bảo rằng mọi hành vi được gọi lên trên các kiểu tham chiếu này bởi một trình ứng dụng là được xử lý đầu tiên bởi container và rồi uỷ quyền tới đối tượng bean. container phải chặn các yêu cầu kia tới bean để mà nó có thể áp dụng sự bền vững (entity beans), transactions, và truy cập điều khiển tự động.
Các giao thức đối tượng phân tán định nghĩa khuôn dạng của các thông điệp mạng được gửi giữa các không gian địa chỉ. Các giao thức đối tượng phân tán có một sự phức tạp nhất định, nhưng may thay bạn không nhìn thấy bất cứ điều gì của nó bởi vì nó được xủa lý tự động. Hầu hết các EJB servers hỗ trợ cả Java Remote Method Protocol (JRMP) hoặc CORBA's Internet Inter-ORB Protocol (IIOP). Lập trình viên về bean và lập trình ứng dụng chỉ nhìn thấy lớp và giao diện từ xa của nó, các chi tiết của truyền thông mạng bị che hết.
Đối với EJB API, lập trình viên không quan tâm có hay không EJB server dùng JRMP hay IIOP-- API là giống nhau. đặc tả EJB yêu cầu rằng bạn dùng một phiên bản đặc biệt Java RMI API, khi làm việc với một bean từ xa. Java RMI là một API cho việc truy cập các đối tượng phân tán và “ is somewhat protocol agnostic”—trong cùng cách mà JDBC là “database agnostic”.vì thế,một EJB server có thể hỗ trợ JRMP hoặc IIOP, nhưng bean và nhà phát triển ứng dụng luôn luôn sử dụng cùng Java RMI API. Để EJB server có lựa chọn sự hỗ trợ IIOP, một phiên bản đặc biệt của Java RMI, được goi là Java RMI-IIOP đã được phát triển. Java RMI-IIOP dùng IIOP như giao thức và Java RMI API. EJB servers không phải dùng IIOP, nhưng chúng phải “respect “ các hạn chế của Java RMI-IIOP,vì thế EJB 1.1 dùng “ specialized Java RMI-IIOP conventions” và các kiểu, nhưng giao thức nằm dưới có thể là bất kỳ cái gì
oxcafebabe
27-09-2002, 08:48
Trước hết thì tôi muốn nhấn mạnh là chữ business logic hiện nay được dùng để ám chỉ luôn application logic, nghiã là nó không chỉ nằm trong lãnh vực kinh doanh.
Trong phần định nghĩa của business logic rất chính xác về việc tách rời business object model ra khỏi business rules.
Tuy nhiên người viết không (chưa) đề cập tới lý do - design and implementation stability.
Phần liệt kê nhu cầu chung thì những phần về bảo đảm ACID (Atomic Concurrent, Independent Durable), scalability, distribution, security - vì có tính đại cương hơn nên có thể được hổ trợ trực tiếp bởi một application framework.
Còn các phần state và reusability (có thể nhập chung làm một) thì quá cụ thể trong một lãnh vực chuyên môn (vd. online trading, payroll,...) nên chỉ có thể được hỗ trợ trên add-on packages, cartridges chuyên môn.
Thật tình mà nói "database agnostic" là hứa hẹn ảo của jdbc, java.sql.Clob, java.sql.Blob là hai dẫn chứng cụ thể. Chiều hướng về persistent đang nhắm về JDO (java data object) để giải quyết phần này.
Còn về phần đối tuợng phân tán (distributed object) thì rmiop và iiop thông thường thì không thể bảo đảm được tính chất high availablity và load-balancing - hai tính chất cần thiết để đạt tới horizontal scalability. JMS (java messaging system) và MOM (message object model) có thể khắc phục được sự thiếu sót này.
Bài dịch công phu quá, lẽ ra phải được trả lời thích đáng hơn. Tôi đang bận quá nên chỉ qua loa vài hàng, xin thông cảm. Nếu được thì bạn post câu hỏi cụ thể hơn, tôi sẽ cố gắng trả lời sau.
Powered by vBulletin® Version 4.2.0 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.