bộ. Sự thúc đẩy này cũng dẫn đến các mô hình thông báo mà chúng ta đã thảo luận ở chương 2.

Mô hình lời gọi đối tượng:

Mặc định, khi một client gọi một đối tượng, nó gửi một yêu cầu tới đối tượng chủ tương ứng và khoá cho tới khi nhận được câu trả lời. Trong trường hợp thành công, các ngữ nghĩa này tương ứng chính xác tới lời gọi phương thức đơn thuần khi người gọi và người được gọi cùng cư trú trong một không gian địa chỉ.

Tuy nhiên, vấn đề là ở chỗ nếu có điều gì phức tạp hơn xảy ra trong trường hợp không thành công thì sẽ giải quyết thế nào. Trong trường hợp lời gọi đồng bộ, như được mô tả, một client cuối cùng sẽ nhận được một biệt lệ chỉ rõ rằng lời gọi đã không hoàn tất. CORBA chỉ rõ rằng trong trường hợp này, lời gọi sẽ theo ngữ nghĩa báo không thành công là at - most - once, ngụ ý rằng phương thức được gọi có thể được gọi một lần nữa hay không gọi lần nào cả. Lưu ý rằng, đó còn tuỳ vào sự thi hành để cung cấp các ngữ nghĩa này.

Lời gọi đồng bộ vì thế mà hữu ích khi client chờ câu trả lời. Nếu một câu trả lời tương ứng được trả về, CORBA bảo đảm rằng phương thức đã được gọi một cách chính xác. Tuy nhiên, trong các trường hợp không xác định nơi nào cần câu trả lời, thì cách tốt hơn và đơn giản cho client là gọi phương thức và tiếp tục sự thi hành của nó càng sớm khi có thể. Kiểu gọi này tương tự như truyền không đồng bộ của RPCs mà chúng ta đã thảo luận ở chương 2.

Trong CORBA, dạng lời gọi không đồng bộ được gọi là yêu cầu một chiều. Một phương thức có thể được chỉ rõ là một chiều chỉ khi nó được định rõ là không có kết quả trả về. Tuy nhiên, không giống như dịch vụ phát không đồng bộ bảo đảm trong RPCs, yêu cầu một chiều trong CORBA chỉ cung cấp một dịch vụ phát best - effort . Nói cách khác, không có đảm bảo nào được đưa ra cho người gọi rằng các lời gọi yêu cầu được phát tới máy chủ của các đối tượng.

Ngoài các yêu cầu một chiều, CORBA cũng hỗ trợ yêu cầu đồng bộ trì hoãn. Đó là một sự kết hợp giữa yêu cầu một chiều và sự cho phép máy chủ gửi đồng bộ kết quả trở lại tới client. Ngay sau khi client gửi yêu cầu của nó tới server, nó tiếp tục mà không cần chờ bất kỳ câu trả lời nào từ phía server. Nói cách khác, client có thể không bao giờ biết chắc rằng yêu cầu của nó có thật sự được phát tới server hay không.

Đây là 3 mô hình lời gọi khác nhau được tóm tắt trong bảng 9-4:

Loại yêu cầu Ngữ nghĩa báo không thành công Mô tả ngắn

Đồng bộ At - most - once Người gọi khóa cho tới khi một câu trả lời được trả về hay một biệt lệ được bật lên.

Một chiều Phát best - effort Người gọi tiếp tục ngay lập tức mà không cần chờ bất cứ câu trả lời nào từ phía server.

Đồng bộ trì hoãn At - most - once người gọi tiếp tục ngay lập tức và có thể sau đó khoá cho tới khi câu trả lời được phát.

Các dịch vụ sự kiện và khai báo:

Mặc dù mô hình lời gọi được cung cấp bởi CORBA thì thường sẽ bao gồm hầu hết các yêu cầu truyền thông trong một hệ phân tán hướng đối tượng, nhưng vẫn cảm thấy rằng chỉ có các lời gọi phương thức là vẫn không đủ. Cụ thể hơn, cần cung cấp một dịch vụ có thể báo hiệu các sự cố của một sự kiện một cách đơn giản. Các client chịu trách nhiệm để các sự kiện đó có thể đưa ra hành động thích hợp.

Dịch vụ sự kiện đựơc tạo ra là vì mục đích trên. Mô hình cơ bản cho các sự kiện trong CORBA là hoàn toàn đơn giản. Mỗi sự kiện kết hợp với một mục dữ liệu đơn, thông thường được đại diện bởi một đối tượng tham chiếu, nếu không thì là một giá trị ứng dụng cụ thể. Sự kiện được tạo ra bởi một supplier (cung cấp) và được thu nhận bởi một consumer (khách hàng). Các sự kiện được phát ra xuyên qua kênh sự kiện, kênh này được đặc logic giữa các supplier và các consumer, như hình 9-5:

Hình 9-5:Tổ chức logic của các Supplier và các consumer của các sự kiện, theo mô hình push - style.

Hình 9-5 là mô hình đẩy. Trong mô hình này, bất cứ khi nào một sự kiện xuất hiện, Supplier sẽ tạo ra sự kiện và đẩy nó xuyên qua kênh sự kiện và sau đó đẩy tới các consumer. Mô hình đẩy gần như là hoạt động không đồng bộ mà hầu hết mọi người kết hợp với các sự kiện. Thực tế, các consumer chờ truyền tải sự kiện một cách thụ động và mong đợi được ngắt theo một hoặc nhiều cách khi một sự kiện xảy ra.

Một mô hình khác, cũng được hỗ trợ bởi CORBA là mô hình kéo được mô tả trong hình 9-6. Trong mô hình này, các consumer thăm dò kênh sự kiện để kiểm tra có một sự kiện nào xảy ra hay chưa. Kênh sự kiện lại quay trở lại thăm dò các supplier.

Hình 9-6: Mô hình push - style cho sự phát các sự kiện trong CORBA

Mặc dù dịch vụ sự kiện cung cấp một cách đơn giản và dễ hiểu cho việc truyền tải sự kiện, nhưng lại có một hạn chế khá nghiêm trọng. Để truyền tải sự kiện, cần thiết các supplier và các consumer phải được nối kết với kênh sự kiện. Điều này cũng có nghĩa là khi một consumer kết nối với một kênh sự kiện sau khi có sự xuất hiện của sự kiện thì sự kiện đó sẽ bị mất. Nói cách khác, dịch vụ sự kiện của CORBA không hỗ trợ sự lưu trữ lâu dài cho các sự kiện.

Điều nghiêm trọng hơn là các consumer không có các phương tiện để lọc các sự kiện; Mỗi một sự kiện, về nguyên tắc, đều đi qua mọi consumer. Nếu có nhiều loại sự kiện khác nhau cần phải được phân biệt, thì cần thiết phải thiết lập một kênh sự kiện riêng cho mỗi loại. Tính năng lọc đã được thêm vào như là mọt sự mở rộng gọi là dịch vụ khai báo. Thêm vào đó, dịch vụ này cung cấp các tiện ích để ngăn chặn việc truyền tải sự kiện khi không có một consumer nào đón nhận một sự kiện định rõ.

Cuối cùng, truyền tải sự kiện vẫn là không tin cậy. Các trạng thái kỹ thuật của CORBA không đảm bảo rằng sự phát các sự kiện sẽ tốt đẹp. Chúng ta sẽ thảo luận ở chương 12, các ứng dụng tồn tại được là do việc truyền tải sự kiện tin cậy, điều này rất quan trọng. Các ứng dụng sẽ không sử dụng dịch vụ sự kiện của CORBA nhưng sẽ phải sử dụng đến các phương tiện truyền thông khác.

Thông báo:

Tất cả việc truyền thông của CORBA được diễn ra một cách trong suốt. Điều này có nghĩa rằng một thông báo được lưu trữ chỉ trong hệ thống truyền thông miễn là cả người gửi và người nhận nó đều đang chạy. Như chúng ta đã thảo luận ở chương 2, có nhiều ứng dụng yêu cầu truyền lưu trữ lâu dài để một thông báo được lưu trữ cho tới khi nó được phát đi. Với việc truyền lưu trữ lâu dài, không lo ngại rằng người gửi hay nhận nó có đang chạy hay không sau khi thông báo đã được gửi đi. Trong tất cả các trường hợp, nó sẽ được lưu trữ đến khi nào cần thiết.

Mô hình phổ biến trong truyền lưu trữ lâu dài là mô hình hàng đợi thông báo. CORBA hỗ trợ mô hình này như là một sự bổ sung cho mô hình thông báo. Cái gì đã tạo nên sự khác biệt giữa mô hình thông báo của CORBA với các hệ thống khác? Đó là mục đích hướng đối tượng vốn có của nó cho việc truyền thông. Cụ thể, người thiết kế của dịch vụ thông báo cần giữ lại mô hình mà tất cả việc truyền thông được đặt trong một đối tượng gọi. Trong trương hợp dịch vụ thông báo, việc thiết kế này ràng buộc kết quả ở 2 dạng bổ sung của phương thức gọi không đồng bộ.

Trong mô hình cuộc gọi trở lại (callback), một client cung cấp cho một đối tượng thực thi một giao diện hàm chứa phương thức callback. Các phương thức này có thể được gọi bởi hệ thống truyền thông cơ bản để chuyển giao kết quả của lời gọi không đồng bộ. Một vấn đề quan trọng trong việc thiết kế là phương thức gọi không đồng bộ không làm ảnh hưởng tới sự thi hành của đối tượng đầu tiên. Nói cách khác, đó là sự đáp trả của client để làm thay đổi lời gọi đồng bộ ban đầu thành lời gọi không đồng bộ; server được đưa đến một lơig gọi yêu cầu thông thường (đồng bộs).

Kkởi dựng lời gọi không đồng bộ được thực hiện qua 2 bước. Đầu tiên, giao diện ban đầu mà giao diện này được thi hành bởi đối tượng được sẽ được thay thế bởi 2 giao diện mới mà 2 giao diện này được thi hành chỉ bởi phần mềm client - side. Một giao diện thì hàm chứa các kỹ thuật của các phương thức mà một client có thể gọi. Không có phương thức nào trong đó trả về một giá trị hay có tham số xuất. Giao diện thứ 2 là giao diện callback. Cho mỗi thao tác trong giao diện gốc, nó hàm chứa một phương thức sẽ được gọi bởi ORB của client để chuyển giao kết quả của phương thức kết hợp như đã được gọi bởi client.

Ví dụ: Một đối tượng thực thi một giao diện đơn giản chỉ với một phương thức: int add(in int i, in int j, out int k);

Thừa nhận rằng phương thức này (chúng ta đã mô tả trong CORBA IDL) có 2 biến không âm kiểu interger i và j và trả về giá trị k = i+j. Phương thức sẽ trả về giá trị -1 nếu thao tác không thành công. Biến đổi phương thức gọi gốc (đồng bộ) thành một phương thức không đồng bộ với callback được hoàn tất bởi việc tạo ra đầu tiên cặp phương thức sau (vì mục đích của chúng ta, chúng ta chọn các tên phù hợp và thuận tiện thay vì theo các luật nghiêm khắc đã định rõ trong OMG, 2001b):

void sendcb_add(in int i, in int j); // được gọi bởi client

void replycb_add(in int ret_val, in int k); // được gọi bởi OMG của client

Trong thực tế, tất cả các tham số xuất từ phương thức gốc được di chuyển từ phương thức được gọi bởi client và trở thành tham số vào của các thao tác callback. Tương tự như vậy, nếu phương thức gốc định rõ một giá trị trả về thì giá trị này được chuyển thành tham số vào của thao tác callback.

Bước thứ 2 đơn giản là dịch các giao diện đã được tạo ra. Một điều hiển nhiên rằng client được cung cấp một mẩu, mẩu này cho phép nó gọi không đồng bộ phương thức sendcb_add. Tuy nhiên, client sẽ cần cung cấp một sự thi hành cho giao diện callback, trong ví dụ này hàm chứa phương thức replycb_add. Lưu ý rằng, những sự thay đổi này không làm ảnh hưởng đến sự thi hành server - side của đối tượng. sử dụng ví dụ này, mô hình callback được tóm tắt như hình 9-7:

Như một sự chọn lựa cho các callback, CORBA cung cấp một mô hình thăm dò. Trong mô hình này, client được cung cấp một tập hợp các thao tác để thăm dò ORB của nó cho các kết quả vào. Cũng như mô hình callback, client có trách nhiệm chuyển các phương thức gọi đồng bộ gốc thành không đồng bộ. Một lần nữa, hầu hết công việc điều có thể được thực hiện một cách tự động bằng cách phát các phương thức định rõ thích hợp từ giao diện gốc được thi hành bởi đối tượng.

Trở lại ví dụ trên, phương thức add sẽ dẫn đến 2 phương thức định rõ được tạo ra như sau:

void sendpoll_add(in int i, in int j); // được gọi bởi client

void replypoll_add(out int ret_val, out int k); // cũng được gọi bởi client

Sự khác nhau quan trọng với mô hình callback là phương thức replypoll_add sẽ phải được thi hành bởi ORB của client. Sự thi hành này có thể được tự động hoá tạo ra bởi một trình biên dịch IDL. Mô hình thăm dò được tóm tắt trong hình 9-8. Một lần nữa, lưu ý rằng sự thi hành gốc của đối tượng lúc nó xuất hiện tại mặt của server không được thay đổi.

Trong khi mô tả các mô hình, chúng ta đã bỏ qua phần các thông báo gửi giữa một client và một server, bao gồm câu trả lời cho lời gọi không đồng bộ, được lưu trữ bởi hệ thống cơ bản trong trường hợp client hay server vẫn chưa chạy. Thật may mắn thay, hầu hết các vấn đề liên quan như truyền lưu trữ lâu dài không ảnh hưởng đến mô hình lời gọi không đồng bộ. Việc cần thiết là cài đặt bộ các server thông báo cho phép các thông báo (là các lời gọi yêu cầu hay đáp trả) được lưu trữ tạm thời cho đến khi có thể phát chúng đi. Sự việc này được đề xuất trong (ORB, 2001b), tương tự như hệ thống hàng đợi thông báo của IBM, cái này chúng ta đã thảo luận ở phần 2.4.4 và sẽ không được nhắc lại ở đây.

Tính liên thao tác:

Các phiên bản cũ của CORBA mở ra nhiều vấn đề về sự thi hành trong thực tế. Kết quả là hệ thống CORBA từ các nhà sản xuất khác nhau lại có cách riêng để khả năng hoá việc truyền thông giữa các client và các đối tượng chủ. Cụ thể, nếu chỉ một client và một đối tượng chủ đang sử dụng ORB giống nhau thì client có thể gọi một trong các đối tượng chủ.

Sự thiếu hụt của tính liên thao tác đã được giải quyết bởi sự ra đời của giao thức chuẩn inter - ORB, trong sự kết hợp với một cách như nhau cho các đối tượng tham chiếu. Trở lại hình 9-2, điều đó có nghĩa là việc truyền thông giữa client và server trung thành với một giao thức chuẩn, trong CORBA là giao thức General Inter - ORB (GIOP).

GIOP thật sự là một khung làm việc cho một giao thức; Thừa nhận rằng một sự thi hành thực sự được chạy trên đỉnh của một giao thức tầng giao vận. Giao thức tầng giao vận này là đáng tin cậy, kết nối hướng đối tượng và cung cấp khái niệm về luồng byte, cùng với một vài các đặc trưng khác. Và không ngạc nhiên khi TCP có thể đáp ứng tất cả các yêu cầu trên, nhưng các giao thức tầng giao vận khác cũng có thể làm điều đó. Sự thi hành của GIOP chạy trên đỉnh của TCP được gọi là giao thức Internet inter - ORB hay đơn giản là IIOP.

GIOP (và IIOP hay bất kỳ sự thi hành khác của GIOP) có thể nhận dạng được 8 loại thông báo khác nhau, như hình 9-9. Hai loại thông báo quan trọng nhất là Yêu cầu và đáp trả, chúng là một phần của sự thi hành thực sự của một phương thức gọi xa.

Một thông báo Yêu cầu chứa một lời gọi yêu cầu được kiểm soát chặt chẽ, bao gồm một đối tượng tham chiếu, tên của phương thức được gọi và tất cả các tham số vào cần thiết. Đối tượng tham chiếu và tên phương thức nằm trong phần header. Mỗi một thông báo Yêu cầu cũng có định danh yêu cầu của chính nó và cái này sau đó sẽ được sử dụng để so trùng với câu trả lời tương ứng.

Một thông báo đáp trả chứa các giá trị trả về được kiểm soát và các tham số xuất kết hợp với phương thức được gọi trước. Không cần phải định danh đối tượng hay phương thức một cách rõ ràng; Chỉ đơn giản là trả về một định danh yêu cầu giống như trong thông báo yêu cầu tương ứng là đủ.

Loại thông báo Nguồn gọi Mô tả

Yêu cầu Client chứa một lời gọi yêu cầu

Đáp trả Server chứa câu trả lời cho lời gọi

Yêu cầu định vị Client chứa một yêu cầu tại một vị trí xác định của một đối tượng

Đáp trả định vị Server Chứa thông tin vị trí về một đối tượng

Huỷ yêu cầu Client bảo client không cần đợi câu trả lời nữa

Đóng kết nối cả hai kết nối bị đóng

thông báo lỗi cả hai chứa thông tin về lỗi

Phân mảnh cả hai một phần của một mảnh lớn

Như những gì mà chúng ta sẽ thảo luận ở phần sau, một client có thể yêu cầu một kho thi hành để cung cấp chi tiết về nơi một đối tượng được chỉ ra có thể được lấy. Một yêu cầu được gửi bằng một thông báo Yêu cầu định vị (LocateRequest). Kho thi hành sẽ trả lời bằng thông báo Đáp trả định vị (LocateReply) thường dùng để định danh server hiện tại của đối tượng mà lời gọi yêu cầu có thể được gửi đến server này.

Thông báo Huỷ yêu cầu có thể được gửi bởi client tới một server khi client muốn huỷ một yêu cầu đã gửi trước đó hay thông báo LocateRequest. Việc huỷ một yêu cầu có nghĩa là client không cần phải đợi câu trả lời từ phía server. Có nhiều nguyên nhân khác nhau để một client muốn huỷ câu trả lời cho một yêu cầu, nhưng nguyên nhân thường thấy nhất là do timeout trong chương trình của client. Lưu ý việc huỷ một yêu cầu không có nghĩa rằng yêu cầu tương ứng sẽ được thực hiện. Nó tuỳ thuộc vào chương trình của client để đối phó với các tình huống.

Trong GIOP, một client luôn luôn cài đặt một kết nối tới server. Các server chỉ chấp nhận hay không chấp nhận các yêu cầu kết nối, nhưng không tự cài đặt kết nối tới một client. Tuy nhiên, cả client và server đều được cho quyền để đóng kết nối, vì thế chúng có thể gửi một thông báo CloseConnection tới các bộ phận truyền thông khác.

Nếu có thất bại, bộ phận khác được báo tin là nhờ thông báo báo lỗi MessageError. Một thông báo như thế chứa phần header của thông báo GIOP chỉ ra nguyên nhân gây lỗi. (điều này tương tự như thông báo của ICMP trong giao thức Internet được sử dụng để trả về thông tin lỗi khi có gì sai. Trong trường hợp đó, phần header của gói IP chỉ ra một lỗi được gửi như là một gói dữ liệu trong thông báo ICMP).

Cuối cùng, GIOP cũng cho phép các thông báo yêu cầu và đáp trả khác được phân mảnh. Theo cách này, các lời gọi yêu cầu có quá nhiều dữ liệu được truyền đi giữa một client và một server có thể dễ dàng được hỗ trợ. Các phân mảnh được gửi là các thông báo phân mảnh đặc biệt có chứa các định danh thông tin về thông báo gốc và cho phép tập hợp lại các thông báo đó tại phía nhận.ss

9.1.3. processes (sử lý )quá trình.

CORBA phân biệt 2 kiểu xử lý :khách và chủ. 1mục đích thiết là quan trọng của CORBA là tạo ra những máy khách càng đơn giản càng tốt.

Clients (máy khách )

Như trước đây đã đề cập phần mềm client- sicle của CORBA là giữ 1 mứcnhỏ nhất chỉ rỏ IPL của đối tượnglà bản coppy đơn giản trong sự ủy nhiệm thu nhập lời yêu cầu.Ví dụ IIOP REQUEST MESSAGES và sự ứng không thu nhập với reply messages trong kết quả mà có thể nó chuyển dao trở lại kéo theo máy chủ

Sự uỷ nhiệm corba không có nghĩa phụ như là kết nối ứng dụng cũa máy khách tới bên dưới orb thay vì đặc điểm của sự uỷ nhiệm một đối tượng đặc biệt 1 máy khách có năng lực kéo theo đối tượng qua dii

Kết quả của phương pháp này đó là nếu 1 đối tượng yêu cầu sự thi hành client- sicle đặc biệt của chính dao diện đó nó sẽ có chỉ dẫn sự phát triển sử dụng bản copy idl như là đặc điểm của phần mềm hoặc cung cấp chính sự uỷ nhiệm của máy khách ví dụ một sự thi hành đối tượng có thể đi cùng với việc thiết đặt sự uỷ nhiệm mà sự thi hành 1 kế hoạch đối tượng đặc biệt client- sicle caching tất nhiên phương pháp sau là tổng số ra khỏi đường dây với đối tượng corba của tính dễ chuyển dời và phân tan dao dịch 1 phương pháp # là quyên vấn đề đối tượng đặc biệt và dựa vào client- sicle orb cái mà cung cấp sự hỗ trợ cần thiết cái gì là cần thiết để 1 cơ cấu sử dụng sự uỷ nhiệm như là đặc điểm bởi bản copy idl trong sự phối hợp với client- sicle orb hiện tại nhưng tuy nhiên có thể thích nghi với phần mềm client- sicle khi cần thiết giải đáp của corba là vấn đề sử dụng thanh chắn (intercepton) như là chính tên đề ghi. 1 thanh chắn là 1 máy móc (cơ cấu ) số việc yêu cầu có thể chắn trong chung từ máy khách tới máy chủ và thích nghi gần như hoàn toàn trước khi cho thuê nó tiếp tục về bản chất 1 thanh chắn là được thay đổi 1 lời yêu cầu từ máy khách tới máy chủ.1 thanh chắn trong CORBA có thể ở vị trí tại 1 trong 2 cấp độ logic # nhau trong hình 9.10 1 mức g/c thanh chắn là nơi logic giữ sự ủy nhiệm máy khách và ORB trước khi lời y/c được gửi qua ORB nó là lần đầu chuyển qua thanh chắn cái mà có thể thay đổi lời yêu cầu trong server sơ de, mức độ y/c thanh chắn là vị trí giữa ORB và thích nghi

Sự tương quan là vị trí giữa 1ORB và dưới mạng máy tính một massage-level inter ceptos không biết gì về thông điệp mà nó gửi , chỉ có thông điệp GIOP tuỳ ý sử dụng đó như là ước muốn thay đổi 1 ví dụ thông thường của massage-level inter ceptos là 1vỡ ra từng mảnh sự thực thi tại cạnh gửi

Thanh chắn giống như là 1 orb đó là ... nó là 1 orb trách nhiệm của theo 1 thanh chắn những máy khách và máy chủ gẩn như cùng lúc thấy thanh chắn trừ thời gian kết nối từ máy khách tới máy chủ Chú ý là orb có thể tạo sử dụng các kiểu thanh chắn trong cùng 1 thời gian

Sự thích nghi của đối tượng đi động trong chương 3 chúng ta đã thảo luận 1 cách chi tiết về sự chú ý của sự thích nghi của đối tượng cái mà 1 máy móc (cơ cấu ) là sự thực thi 1 chính sách hành động đặc biệt cho của nhóm đối tượng ví dụ 1 sự thích nghi có thể là sự thích nghi 1 thuật toán yêu cầu sử dụng separate thred cho mỗi yêu cầu nơi mà 1 cái # chỉ sử dụng 1 thred đơn cho tất cả các đối tượng mà nó quản lý.

Nói chung 1 sự thích nghi của đối tượng có nhiều hơn 1 lời gọi phương pháp trong 1 đối tượng như là 1 để nghị đặt tên của chính nó 1 đối tượng thích nghi là sự chịu chách nhiệm cho việc phát triển bao gồm cả hình ảnh của cái gọi là 1 đối tượng là sự