CHƯƠNG 3.

Đang xem: Corba là gì

Bạn Đang Xem: Giới Thiệu Về Corba Là Gì – Corba/Common Object Request Broker Architecture – Cúng Đầy Tháng – Trang Tin Tức Online Tổng Hợp

Mô hình thành phần CORBA

Khái niệm cơ bản về công nghệ phần mềm hướng thành phần Giới thiệu Có rất nhiều khái niệm cơ bản thường gặp về công nghệ phần mềm hướng thành phần (CBSE) <8vàgt;. Các khái niệm khác nhau có thể gây ra các nhầm lẫn vì CBSE là một khái niệm mới mẻ. Nhiều khái niệm vẫn chưa hoàn toàn giảng giải hoặc thử nghiệm trong thực tế, và như một kệ quả, các khái niệm của chúng vẫn còn rất mơ hồ.

CBSE cơ bản dựa vào khái niệm của thành phần. Các từ ngữ khác ví như giao diện, hợp đồng, framework, và khuôn mẫu có liên quan chặt chẽ đến việc phát triển thành phần phần mềm.

Một thành phần là một đơn vị có thể sử dụng lại của việc triển khai và kết cấu nên phần mềm. Một điểm chung ở đây là thành phần có quan hệ chặt chẽ với đối tượng người sử dụng, vì thế, nó là một phần mở rộng của việc phát triển công nghệ hướng đối tượng người sử dụng. Tuy nhiên, có nhiều nhân tố như rõ ràng, khái niệm về kết cấu và triển khai, thậm chí còn cả quá trình phát triển, cũng phải phân biệt rõ thành phần và đối tượng người sử dụng.Một giao diện quy định cụ thể những điểm truy cập đến thành phần một, và do đó giúp khách hàng hiểu được chức năng và cách sử dụng của thành phần một. Giao diện rõ ràng là tách ra từ việc thực hiện các thành phần một. Thực hiện đúng quy định, giao diện một quy định cụ thể các tính chất chức năng của thành phần một. Một mô tả hoàn toàn chức năng của thành phần là không đủ.

Một giao diện quy định cụ thể những điểm truy cập đến một thành phần, và do đó giúp khách hàng hiểu dược chức năng và cách sử dụng của thành phần đó. Giao diện được tách hẳn ra từ việc thực hiện các thành phần. Theo như khái niệm, một giao diện quy định cụ thể các tính chất, chức năng của một thành phần. Do đó, một mô tả về chức năng của một thành phần là không đủ.

Các đặc tả thành phần có thể thực hiện được thông qua một hợp đồng, trong đó tập trung vào việc đặc tả các nhập cuộc mà thành phần tương tác với môi trường xung quanh của nó. Mặc dù các component có thể có những kích cỡ khác nhau và các thành phần lớn được chú trọng hơn hết. Một tập hợp các thành phần đóng một vai trò cụ thể sẽ tiến hành chú trọng hơn là một thành phần đơn lẻ. Điều này dẫn đến khái niệm framework. Một framework mô tả một đơn vị lớn của thiết kế và xác định quan hệ trong một nhóm nhất định của khá nhiều yếu tố. Các yếu tố này còn có thể là những thành phần.

Khuôn mẫu xác định các giải pháp cho những vấn đề ở tại mức độ trừu tượng cao và các phương pháp sử dụng lại chúng. Khuôn mẫu thường bắt những đơn vị thiết kế nhỏ khi được so sánh với framework, bởi vì framework gồm có các khuôn mẫu thiết kế khác nhau.

Thành phần Thành phần là trung tâm của CBSE và cần phải khái niệm xác thực về thành phần để hiểu được cơ sở của CBSE. Tất cả chúng ta có thể tìm được vài khái niệm của thành phần trong nhiều tài liệu, phần lớn trong số chúng không có khái niệm trực quan về thành phần. Ví dụ trong công nghệ Component Object Model (COM) của Microsoft, một thành phần được khái niệm là: một phòng ban soạn nên phần mềm, cung cấp nên một dịch vụ. Mọi người đều đồng ý rằngthành phần là một phòng ban của phần mềm và nó rõ ràng là cung cấp một dịch vụ nhưng khái niệm này còn quá rộng. Ví dụ như biên dịch các thư viện (các file có đuôi .o và .dll) cũng tồn tại thể được khái niệm Theo phong cách này.

Một đặc điểm quan trong nhất của thành phần là sự việc tách biệt giao diện của nó trong sự thực thi. Sự tách biệt này khác với những gì tất cả chúng ta có thể tìm thấy ở nhiều tiếng nói lập trình khác hoặc trong tiếng nói lập trình hướng đối tượng người sử dụng mà việc khái niệm lớp được tách biệtvới những lớp thực thi. Trong CBSE, các thành phần được yêu cầu phối hợp lại trong phần mềm. Các thành phần phối hợp và triển khai phải tồn tại độc lập và không cần thiết phải biên dịch lại hoặc phải liên kết lại với phần mềm khi mà thêm mới hoặc chỉnh sửa các thành phần khác. Một đặc điểm quan trọng nữa của thành phần là khả năng thể hiện chức năng thông qua giao diện của nó. Ý nghĩa của nó là cấp thiết cho việc hoàn thiện các đặc tả của thành phần gồm có các giao diện chức năng, đặc tính phi chức năng (hiệu suất, tài nguyên,…), ca sử dụng, kiểm thử…

Đối tượng người sử dụng và thành phần Đối tượng người sử dụng và thành phần thường được nghĩ đến là đồng nghĩa hoặc tương tự nhau. Tác giả Szyperski và Pfister <8vàgt; đã xem thành phần như thể tập hợp các đối tượng người sử dụng, mà các đối tượng người sử dụng này hợp tác chặt chẽ với nhau. Ranh giới giữa một thành phần với những thành phần hoặc đối tượng người sử dụng khác được chỉ rõ và sự tương tác của thành phần được thực thi qua các giao diện của thành phần trong lúc các tính chất bên trong các thành phần (ví dụ như các đối tượng người sử dụng của nó) được ẩn đi. Đối tượng người sử dụng trong một thành phầnđơn lẻ có thể truy cập đến việc thực thi của thành phần khác. Tuy nhiên, sự truy cập đến việc thực thi của một đối tượng người sử dụng từ phía ngoài thành phần cần phải được ngăn chặn.

Thay vì chứa các lớp hoặc đối tượng người sử dụng, một component có thể chứa các thủ tục cổ điển, các biến global (static), và do đó không những có thể thực hiện bằng phương pháp tiếp cận hướng đối tượng người sử dụng mà còn tồn tại thể tiếp cận theo phía chức hoặc cách tiếp cận tiếng nói assembly. Tương tự như quan hệ thừa kế giữa các đối tượng người sử dụng, một component có thể có một quan hệ với những thành phần khác. Một lớp cha của một lớp không cấp thiết phải ở trong component chứa lớp đó. Nếu một lớp trong component có lớp cha trong một component khác, quan hệ thừa kế giữa các lớp xuất ngày nay ranh giới giữa các component.

D.Souza and Wills <8vàgt; thảo luận về sự việc khác biệt và giống nhau của đối tượng người sử dụng và thành phần. Một thắc mắc quan trọng nêu lên là có khi nào một lớp trở thành một thành phần hay là không. Nếu một lớp được đóng gói cùng với những khái niệm về giao giện rõ ràng mà nó yêu cầu và thực hiện, thì lớp này sẽ tiến hành gọi là một thành phần. Giao diện lập trình ứng dụng (API) là một đặc tả các tính chất của mô đun mà client phụ thuộc vào. API của thành phần có sẵn ở dạng một hay nhiều cấu trúc giao diện (ví dụ: java interfaces hoặc abstract virtual classes trong C++). Cũng tương tự như vậy với lớp, component có thể liên kết với những lớp khác. Nếu các lớp này tự chúng có đầy đủ các khái niệm API, tập hợp kết của của khá nhiều lớp được thiết kế kết cấu thành một component.

Có 3 sự khác biệt quan trọng nhất ở chỗ này giữa component và đối tượng người sử dụng:

Component thường sử dụng việc lưu trữ liên tục trong những lúc đối tượng người sử dụng lưu trữ ở từng nơi từng vùng. Component có một bộ các cơ chế liên thông với nhau rộng hơn so với đối tượng người sử dụng, trong này thường sử dụng cơ chế gửi tin nhắn. Component thường là những đơn vị có tính chất to ra hơn các đối tượng người sử dụng và có hành động phức tạp hơn ở những giao diện của chúng. Giao diện Một giao diện của component có thể được khái niệm dưới dạng đặc tả của những điểm truy cập của nó. Các máy người truy cập các dịch vụ cung cấp bởi thành phần sử dụng những điểm truy cập đó. Nếu thành phần có nhiều điểm truy cập, mỗi điểm sẽ tương ứng với với những dịch vụ khác nhau được cung cấp bởi component, sau đó component dự kiến sẽ sở hữu nhiều giao diện.

Điều lưu ý quan trọng là một giao diện không cung cấp một sự thực thi của bất kỳ hoạt động nào của nó. Thay vào đó, nó chỉ thuần tuý là tên gọi của tập hợp các hành động và cung cấp các mô vả và giao thức những hoạt động của nó. Đặc điểm này làm cho nó có thể thay thế một phần thực hiện mà không phải thay đổi giao diện, và cách làm này cải thiện được hiệu năng khối hệ thống mà không phải xây dựng lại khối hệ thống; và thêm một giao diện (và những sự thực thi) mà không phải thay đổi những sự thực thi đã có và trong cách này cải thiện được khả năng tương thích của component.

Khách hàng tùy chỉnh các component bởi các phương tiện giao diện vì giao diện chỉ nhìn thấy được một phần. Lý tưởng nhất, trong giao diện, ngữ nghĩa của mỗi hành động phải được xác định vởi tị nạnh đây là điều quan trọng cho tất cả sự thi hành của giao diện và máy khách sử dụng giao diện. Trong phần lớn các mô hình component ngày nay, giao diện định chỉ khái niệm một cú pháp (ví dụ: kiểu nguồn vào đầu ra) và đưa ra rất ít thông tin về các component.

Giao diện được khái niệm trong công nghệ component có thể diễn đạt các functional properties. Function properties gồm có một phần signature mà hành động được cung cấp bởi một component đã được miêu tả, và một phần trạng thái mà trạng thái của component được xác định.

Tất cả chúng ta có thể phân biệt hai loại giao diện. Các component có thể xuất và nhập các giao diện cho và từ môi trường xung quanh mà có thể gồm có các component khác. Một giao diện xuất ra ngoài miêu tả dịch vụ cung cấp bởi component ra môi trường xung quanh, trong những lúc một giao diện nhập vào xác định một dịch vụ yêu cầu bởi component từ môi trường xung quanh. Các phương pháp tiếp cận chung của khá nhiều giao diện là cú pháp truyền thống. Tuy nhiên, việc thực hiện các vấn đề văn cảnh liên quan đến văn cảnh phụ thuộc (tức là đặc tả của môi trường xung quanh triển khai và môi trường xung quanh chạy) và sự tương tác đã cho thấy sự cấp thiết của một hợp đồng rõ ràng xác định các hành vi của một component. Hợp đồng Hồ hết các kỹ thuật dùng để làm mô tả giao diện như IDL chỉ có quan tâm đến phần chữ ký, trong đó hành động được cung cấp bởi một thành phần được miêu tả và do đó không xử lý các hành vi chung của khá nhiều thành phần. Một đặc tả xác thực của khá nhiều hành vi của một thành phần có thể thực hiện một hợp đồng. Meyer đã đề cập, một hợp đồng list cácràng buộc chung mà thành phần sẽ duy trì gọi là tính định hình. Mỗi hành vi trong thành phần, hợp đồng đưa ra list các nhập cuộc mà phải gắn với bên thực hiện (tiền nhập cuộc) và các kết quả thành phần cần phải trả lại (hậu nhập cuộc). Tiền nhập cuộc, hậu nhập cuộc và tính định hình hợp thành đặc tả những hành vi của thành phần. Mở rộng hơn việc đặc tả cách hành vi của thành phần đơn lẻ, hợp đồng có thể được dùng để làm quy định các tương tác giữa một nhóm các thành phần. Tuy nhiên, chúng được sử dụng một cách khác nhau. Một hợp đồng quy định tương tác giữa các thành phần có những nhập cuộc sau: Có một tập những thành phần tham gia. Vai trò của mỗi thành phần thông qua các nghĩa vụ của hợp đồng, ví dụ như loại nghĩa vụ yên cầu các thành phần tương trợ các biến nhất định và giao diện, và nghĩa vụ hệ quả yên cầu các thành phần thực hiện một chuỗi lệnh của hành động, gồm có việc gửi tin nhắn đến những thành phần khác. Tính biết biến được duy trì bởi các thành phần. Đặc tả các phương thức thuyết minh cho một hợp đồng. Lưu ý rằng các thành phần không chỉ cung cấp các dịch vụ cho những thành phần khác mà còn yên cầu chúng từ các thành phần khác. Nó đúng cho tất cả yêu cầu chức năng và yêu cầu phi chức năng. Đo đó, các nghĩa vụ hợp đồng có sự khác biệt đáng kể so với tiền nhập cuộc, hậu nhập cuộc của khá nhiều phương thức được cung cấp bởi một thành phần.

Tất cả hành vi của thành phần có thể khá phức tạp bởi vì nó tham gia trong nhiều hợp đồng. Hơn nữa, hợp đồng chỉ rõ nhập cuộc mà trong đó tương tác giữa các thành phần trong pháp lý của tiền nhập cuộc và hậu nhập cuộc về hoạt động. Tiền nhập cuộc chỉ rõ các đặc điểm môi trường xung quanh phải đáp ứng để hoạt động của hợp đồng có thể đáp ứng hậu điềukiện. Đơn giản tiền nhập cuộc/hậu nhập cuộc về hoạt động thiết lập sự đúng đắn cục bộ, trong những lúc để hoàn thiện sự đúng đắn tổng thể, sự chấm hết là cấp thiết. Bởi vì hợp đồng được thiết kế để thay mặt cho những tin nhắn, qua giao thức giữa các thành phần, chúng là bắt buộc trong tự nhiên và do đó khó diễn tả trong một hình thức khai báo

Cũng lưu ý rằng hợp đồng và giao diện là những khái niệm khác nhau. Giao diện là tập hợp những hoạt động chỉ rõ các dịch vụ được cung cấp bởi thành phần, hợp đồng chỉ rõ các hành vi phía ngoài của thành phần hoặc là tương tác giữa các thành phần khác nhau. Khuôn mẫu Kiến trúc sư Christopher Alexander <8vàgt; đã lần trước tiên giới thiệu khái niệm về khuôn mẫu vào trong thời điểm cuối năm 1970. Trong khái niệm này, khuôn mẫu khái niệm giải pháp tuần hoàn cho những vấn đề tuần hoàn. Khuôn mẫu bắt những giải pháp không rõ ràng, không chỉ là những nguyên tắc và chiến lược trừu tượng, một cách gián tiếp, với tính chất khác biệt với nhiều kỹ thuật xử lý vấn đề khác (như thể mẫu hoặc phương thức thiết kế phần mềm) mà giải pháp bắt nguồn từ nguyên tắc. Các giải pháp cần được chứng minh để xử lý vấn đề chứ không phải là lý thuyết hoặc suy đoán. Khuôn mẫu mô tả quan hệ giữa cấu trúc khối hệ thống và cơ chế và không những là các mô đun độc lập. Cuối cùng, yếu tố con người là một phần của khuôn mẫu. Một khuôn mẫu thiết kế có thể được dùng để làm miêu tả trong thiết kế và tài liệu của một thành phần. Một thành phần, như một thực thể tái sử dụng, có thể được xem như một sự thi hành một số khuôn mẫu thiết kế. Các khuôn mẫu thiết kế có thể được sử dụng để mô tả mức độ thấp rõ ràng sự thi hành của hành vi và cấu trúc của những thành phần, hoặc là quan hệ giữa các thành phần trong toàn cảnh của một tiếng nói lập trình cụ thể.

Khuôn mẫu đã được ứng dụng cho những thiết kế của nhiều khối hệ thống hướng đối tượng người sử dụng, và được xem như là tái sử dụng những kiến trúc nhỏ góp phần vào trong 1 kiến trúc tổng thể.

Quan hệ giữa các thành phần và khuôn mẫu thiết kế có thể được xem như sau. Khuôn mẫu thiết kế được sử dụng rộng rãi trong quá trình thiết kế khối hệ thống dựa thành phần, trong đó các đơn vị tái sử dụng phải được xác định. Việc sử dụng các khuôn mẫu thiết kế làm cho nó dễ dàng hơn cho tất cả chúng ta xác nhận những phần tái sử dụng hoặc tìm chúng trong các thành phần từ trước hoặc phát triển chúng như thể các đơn vị tái sử dụng. Khuôn mẫu thiết kế có thể được sử dụng để mô tả hành vi của khá nhiều phòng ban bên trong thành phần và do này được sử dụng để phát triển thành phần. Hơn nữa, khuôn mẫu thiết kế không những được sử dụng để mô tả kết cấu thành phần khi thiết kế một hợp đồng hoặc framework mà các liên kết các thành phần riêng biệt. Frameworks Nghĩa của CBSE khi xây dựng một phần mềm là: “đặt các phần lại với nhau”. Trong số đó một môi trường xung quanh là điều cấp thiết để các phần đó có thể ghép lại với nhau. Framework là một phương tiện cung cấp một môi trường xung quanh như vậy.

Framework có liên quan chặt chẽ đến khuôn mẫu. Chúng xác định một nhóm những bên tham gia và các quan hệ giữa chúng mà có thể tái sử dụng trong bất kỳ trạng thái nào. Szyperski <8vàgt; thấy rằng: so với khuôn mẫu, việc mô tả đơn vị của thiết kế và chuyên biệt hơn khuôn mẫu. Một tiêu biểu và thường được sử dụng là mô hình Model-View-Controller (MVC) trong đó xác định một thiết lập mà Model được trình bày bởi View, và Controller quản lý các thao tác của người dùng. Framework cũng là các đơn vị kiến trúc phù hợp để san sẻ và tái sử dụng.

Xem thêm: Giải Mã Giấc Mơ Thấy Tiền 500 Nghìn, Điềm Báo Tốt Hay Xấu

Framework cung cấp một giải pháp mạnh mẽ trong toàn cảnh các thành phần tham gia có thể nối ghép một cách hiệu quả. Framework sử dụng ở đây là framework hướng đối tượng người sử dụng và có hơi khác so với framework thành phần. Framework hướng đối tượng người sử dụng trừu tượng hơn. Chúng là một phần của thiết kế và triển khai cho những ứng dụng trong một miền cụ thể. Framework có trách nhiệm xử lý các tương tác phức tạp và các thành phần chỉ có thực hiện đầy đủ vai trò của chúng trong framework. Frameworks và thành phần Theo như các khái niệm framework trước đó, một framework được xem như thể một bảng mạch (framework thành phần) mà trong đó các vị trí trống đang chờ chèn các thành phần. Framework được thuyết minh bằng phương pháp lấp đầy những chỗ trống. Yêu cầu được chỉ ra để đã cho thấy những gì mà thành phần cần làm cho phù phù hợp với các chức năng như những gì đã được quy định ở bảng mạch. Trong khái niệm về framework chuẩn, tất cả chúng ta thấy rằng hành vi của framework có thể được đặc tả trong các điểu khoản của tiền nhập cuộc và hậu điền kiện của framework, tính định hình và sự thuyết minh cũng như thể các thành phần được tham gia và mỗi quan hệ tĩnh giữa chúng. Hai vấn đề nữa là chuẩn hóa kết nối giữa các thành phần và xác định cụ thể hơn giao diện các hành phần cần phải có để các framework xung quanh.

Các chỗ trống có thể được lập đầy bằng các thành phần hoặc các framework khác. Các giao diện và các quan hệ giữa các thành phần được miêu tả. Các rõ ràng trong đặc tả vẫn còn được che dấu trong thành phần và cần tiếp thục như vậy. Các framework thành phần cần phải được lấp đầy bởi các thành phần và được thuyết minh Theo phong cách này. Như framework được thuyết minh bởi thành phần, chính nó sẽ trở thành một thành phần mới để sử dụng trong các framework mới.

Khái niệm CORBA Giới thiệu Các tiếng nói lập trình đều phải có những điểm chung là các lời gọi hàm, thủ tục, thông số truyền, trị trả về… Trong những lúc đó các đối tượng người sử dụng trong tiếng nói lập trình hướng đối tượng người sử dụng thiết kế bằng tiếng nói nào thì chỉ có mã lệnh tương ứng của tiếng nói đó mới truy xuất được chúng. Vậy làm thế nào các đối tượng người sử dụng được thiết kế bằng các tiếng nói lập trình khác nhau có thể triệu gọi và sử dụng lẫn nhau? Những điểm chung của khá nhiều tiếng nói lập trình được tập hợp lại trong tiếng nói đặc tả. Và CORBA là một tiếng nói đặc tả.

CORBA là từ viết tắt của Common Object Request Broker Architecture và tạm dịch là kiến trúc môi giới gọi các đối tượng người sử dụng phân tán.

Xem Thêm : Trà xanh là gì? Tuesday là gì? Điều gì khiến chị em lo sợ hơn

CORBA còn được gọi là tiếng nói đặc tả giao tiếp (IDL – Interface Description Language) Tiếng nói đặc tả giao tiếp IDL IDL <10vàgt; được sử dụng để mô tả các giao diện giữa các đối tượng người sử dụng CORBA. Tiếng nói IDL là trung lập so với tiếng nói thực hiện, nói cách khác, giao diện IDL có thể được thực hiện trong bất kỳ tiếng nói nào ví dụ như Java, C, C + +, và một số tiếng nói khác.

Ta lấy một ví dụ về đặc tả đối tượng người sử dụng Calculator bằng tiếng nói IDL của CORBA:

Tạo file sentayho.com.vn interface Calculator {long addNumber ( in long x, in long y );

};

Để chuyển file đặc tả này sang các tiếng nói lập trình khác tất cả chúng ta có thể dùng như sau: idl2cpp sentayho.com.vn // chuyển sang C++idlj sentayho.com.vn // chuyển sang java Kết quả là tất cả chúng ta đã sở hữu được tập tin sentayho.com.vn như sau: publicinterface CalculatorOperations{int addNumber(int x, int y);

} //interface CalculatorOperations

Ánh xạ từ IDL sang java:

Bảng 3: Bảng ánh xạ từ IDL sang java

IDL

Java module package interface interface string sentayho.com.vn long int long long long float float double double exception class operation Method

CORBA IDL: module { interface MathLibrary {long add( in long x, in long y ); string About( in string version );}}; Java : package Math;publicinterface MathLibrary { int add (int x, int y); String About(String version);}

Tiếng nói đặc tả trong mô hình CORBA gần giống với tiếng nói C.

CORBA đưa ra từ khóa in cho những biến truyền vào theo trị và từ khóa out để lấy trị trả về. Mô hình thành phần CORBA Mô hình thành phần CORBA (CCM) là đặc tả thành phần gần đây nhất và được hoàn thiện từ đặc tả OMG (Object Management Group). Nó được thiết kế dựa trên cơ sở tích lũy kinh nghiệm sử dụng dịch vụ CORBA, JavaBeans, và EJB <12vàgt;

Giống như nhiều mô hình thành phần khác, CCM tập trung vào các nhà phát triển ứng dụng bằng phương pháp ghép các mô-đun có sẵn, mà còn rõ ràng với việc thiết kế thành phần, lắp ráp và triển khai. Mục tiêu chính đằng sao đặc tả CCM là cung cấp giải pháp cho việc phức tạp của CORBA và những dịch vụ của nó. Trọng tâm của CCM là “một mô hình thành phần phía sever cho việc xây dựng và phát triển ứng dụng CORBA”

Một trong những lợi ích của CCM là sự việc nỗ lực “thống nhất” các mặt được gồm có trong kĩ nghệ phần mềm. Kết quả là một ứng dụng phần mềm được mô tả trong các hình thức khác nhau theo 2 chiều: chiều thời kì (vòng đời, từ thiết kế nhiệm triển khai) và chiều trừu tượng (từ khái niệm trừu tượng đến thi hành). Nhìn chung, điều này đã làm cho những đặc tả khá phức tạp.

Với CCM, một thành phần là “một đơn vị mã phần mềm độc lập gồm có tài liệu và sự logic của nó, cùng với khái niệm về kết nối được xác định rõ ràng hoặc giao diện xúc tiếp về liên lạc. Nó được thiết kế để sở hữu thể sử dụng tái diễn trong phát triển ứng dụng, có thể có hoặc không có những tùy biến”

Giao diện và sự nối ghép Cái nhìn từ phía ngoài của một thành phần là một phần mở rộng của tiếng nói CORBA IDL truyền thống. Một giao diện thành phần được tạo bởi các cổng được chia thành từng phần một <12vàgt;

Hình 1: Giao diện thành phần CORBA và các cổng

Thành phần được xem như như thể một hộp đen. Giao diện chỉ là những điểm truy cập đến thành phần và đặc tả của thành phần trở thành đặc tả của giao diện thành phần.

Thành phần tương trợ nhiều tính năng phía ngoài mà khách hàng và các thành phần khác của môi trường xung quanh ứng dụng có thể tương tác với thành phần. Các đặc tính phía ngoài này được gọi là các cổng. Mô hình thành phần tương trợ 4 loại cổng đây chính là:

Facets: được đặt tên cho giao diện được cung cấp bởi thành phần cho những tương tác của bên khách hàng. Receptacles: được đặt tên cho điểm kết nối miêu tả khả năng của thành phần sử dụng sự tham khảo được tương trợ bởi một vài tác nhân phía ngoài. Sự kiện sources: được đặt tên cho điểm kết nối mà phát ra các sự kiện của một kiểu lý thuyết tới một hoặc nhiều sự kiện người dùng quan tâm hoặc tới một kênh sự kiện. Sự kiện sinks: được đặt tên cho điểm kết nối vào mà sự kiện của một kiểu lý thuyết có thể được đẩy vào. CCM xem những cổng như thể các biến được đặt tên và đặt kiểu, do đó các facets khác nhau của cùng một thành phần có thể có những kiểu giống nhau. Các thành phần được đặt kiểu và có thể thừa kế từ các thành phần khác. Đặc tả CCM bằng tiếng nói IDL Thành phần Thành phần được sử dụng với từ khóa component.

Giao diện tương đương được tương trợ bởi các thành phần có thể thừa kế từ một số giao diện người dùng tự khái niệm. Quan hệ này được thể hiện bằng phương pháp sử dụng từ khóa supports.

Ví dụ:interface Clock {Time getTime ();void ResetTime (in Time t);

};component Car supports Clock {};

Facets Facets tương ứng với giao diện được cung cấp bởi một thành phần. Facets được sử dụng với từ khóa provides.component XXX {provides ;

};Ví dụ:

module motors {interface Engine{};interface Panel {};component Car supports Clock{provides Engine _engine;provides Panel_panel;

};};

Receptacles Tương ứng với giao diện được yêu cầu bởi thành phần chức năng trong một môi trường xung quanh nhất định.

Xem Thêm : Giới thiệu chung về kỳ thi trung học phổ thông quốc gia

Receptacle được sử dụng với từ khóa uses

Receptacle đơn Có thể kết nối đến một đối tượng người sử dụng,component XXX {uses ;

};Ví dụ:

interface Customer {};component Trương mục {uses Customer owner;

};

Nhiều receptacle Có thể kết nối với nhiều đối tượng người sử dụng.component XXX {usesmultiple ;

};Ví dụ:

component Trương mục {usesmultiple Customer owner;

};

Sự kiện Sources Từ khóa publishes được sử dụng để khái niệm sự kiện sources. Từ khóa này đồng ý chấp thuận kết nối 1 – ncomponent XXX {publishes ;

};Ví dụ:

module stockbroker {eventtype AlertSignal{public string reason;

};component Broker {

publishes AlertSignal alert_source;

};};

Từ khóa emits đồng ý chấp thuận kết nối 1- 1component XXX {emits ;

};Ví dụ:

module stockbrocker {eventtype StockLimit {public long stock_value;

};component Broker {

emits StockLimit limitAlert;

};};

Sự kiện Sinks Sự kiện sink được sử dụng với từ khóa consumes.

Xem thêm: Gạo St25 Giá Bao Nhiêu Tiền Một Kg? Gạo Ngon Nhất Thế Giới St25 Giá Bao Nhiêu 1Kg

component XXX {consumes ;

};Ví dụ:

module stockbrocker {eventtype AlertSignal {public string reason;

};component Trader {

consumes AlertSignal alert_sink;

};};

Tham gia kết nối Để các thành phần trong CCM có thể kết nối được với nhau nếu các cổng của chúng thỏa mãn một số nhập cuộc chính sau: Facet có thể chỉ kết nối với receptacles (cổng provideschỉ kết nối với cổng uses) Sự kiện source chỉ có thể kết nối với sự kiện sinks (nói cách khác: cổng publishes và cổng emitschỉ có thể kết nối với cổng consumes). Mỗi cổng provides(facet) có thể kết nối với nhiều cổng uses(receptacles), mỗi cổng publishes có thể kết nối với nhiều cổng consumesnhưng không thể trái lại. Mỗi cổng emitschỉ có thể kết nối với một cổng consumes. Với mỗi một cặp cổng đã được kết nối, kiểu của cổng cung cấp (facets, sự kiện sources) là kiểu con của một trong những cổng yêu cầu (receptacles, sự kiện sinks) CHƯƠNG 4.