Giới Thiệu Về Corba Là Gì – Corba/Common Object Request Broker Architecture – Cúng Đầy Tháng

Bài viết Giới Thiệu Về Corba Là Gì – Corba/Common Object Request Broker Architecture – Cúng Đầy Tháng thuộc chủ đề về Giải Đáp Câu Hỏi đang được rất nhiều bạn lưu tâm đúng không nào !! Hôm nay, Hãy cùng sotaythongthai.vn tìm hiểu Giới Thiệu Về Corba Là Gì – Corba/Common Object Request Broker Architecture – Cúng Đầy Tháng trong bài viết hôm nay nha !
Các bạn đang xem bài viết : “Giới Thiệu Về Corba Là Gì – Corba/Common Object Request Broker Architecture – Cúng Đầy Tháng”


CHƯƠNG 3.

Đang xem: Corba là gì

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) <8>. Các định nghĩa khác nhau khả năng gây ra 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ải thích hoặc thử nghiệm trong thực tế, và như một kệ quả, các định nghĩa của chúng vẫn còn rất mơ hồ.

Bạn đang xem: corba la gi

CBSE cơ bản dựa vào khái niệm của thành phần. Các từ ngữ khác 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ị khả năng dùng lại của việc triển khai và cấu tạo nên phần mềm. Một điểm chung ở đây là thành phần có mối quan hệ tình dục chặt chẽ với đối tượ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. mặc khác, có nhiều nhân tố như chi tiết, khái niệm về cấu tạo và triển khai, thậm chí cả quy trình phát triển, cũng phải phân biệt rõ thành phần và đối tượng.Một giao diện quy định chi tiết các điểm truy cập đến thành phần một, và vì thế giúp khách hàng hiểu được chức năng và cách 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 chi tiết các thuộc tính 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 chi tiết các điểm truy cập đến một thành phần, và vì thế giúp khách hàng hiểu dược chức năng và cách 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ư định nghĩa, một giao diện quy định chi tiết các thuộc tính, chức năng của một thành phần. vì thế, 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 khả năng 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 điều kiện mà thành phần tương tác với môi trường của nó. Mặc dù các component khả năng có các kích cỡ khác nhau và các thành phần lớn được chú trọng hơn cả. Một tập hợp các thành phần đóng một vai trò chi tiết sẽ được chú trọng hơn là một thành phần đơn lẻ. Điều này kéo theo 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 mối quan hệ tình dục trong một nhóm nhất định của các yếu tố. Các yếu tố này khả năng là những thành phần.

Khuôn mẫu xác định các giải pháp cho các vấn đề ở mức độ trừu tượng cao và các cách 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 bao gồm 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 định nghĩa chính xác về thành phần để hiểu được cơ sở của CBSE. Chúng ta khả năng tìm được vài định nghĩa của thành phần trong nhiều tài liệu, phần lớn trong số chúng không có định nghĩa 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 định nghĩa là: một bộ phận biên 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 bộ phận của phần mềm và nó rõ ràng là cung cấp một dịch vụ nhưng định nghĩa 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 khả năng được định nghĩa theo cách này.

Một đặc điểm quan trong nhất của thành phần là sự 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ì chúng ta khả năng tìm thấy ở nhiều ngôn ngữ lập trình khác hoặc trong ngôn ngữ lập trình hướng đối tượng mà việc định nghĩa lớp được tách biệtvới những lớp thực thi. Trong CBSE, các thành phần được bắt buộc kết hợp lại trong phần mềm. Các thành phần kết hợp và triển khai phải tồn tại độc lập và không cần phải biên dịch lại hoặc phải kết nối 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à rất cần thiết cho việc hoàn thiện các đặc tả của thành phần bao gồm 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 dùng, kiểm thử…

Đối tượng và thành phần Đối tượ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 <8> đã xem thành phần như là tập hợp các đối tượng, mà các đối tượ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 các thành phần hoặc đối tượ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 khi các tính chất bên trong các thành phần (ví dụ như các đối tượng của nó) được ẩn đi. Đối tượng trong một thành phầnđơn lẻ khả năng truy cập đến việc thực thi của thành phần khác. mặc khác, sự truy cập đến việc thực thi của một đối tượng từ bên 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, một component khả năng chứa các giấy tờ cổ điển, các biến global (static), và vì thế không những khả năng thực hiện bằng cách tiếp cận hướng đối tượng mà còn khả năng tiếp cận theo hướng chức hoặc cách tiếp cận ngôn ngữ assembly. Tương tự như quan hệ tình dục thừa kế giữa các đối tượng, một component khả năng có một mối quan hệ tình dục với các thành phần khác. Một lớp cha của một lớp không rất cần 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ệ tình dục thừa kế giữa các lớp xuất hiện nay ranh giới giữa các component.

D.Souza and Wills <8> thảo luận về sự khác biệt và giống nhau của đối tượng và thành phần. Một câu hỏi quan trọng đặt ra là có khi nào một lớp trở thành một thành phần hay không. Nếu một lớp được đóng gói cùng với các định nghĩa về giao giện rõ ràng mà nó bắt buộc và thực hiện, thì lớp này sẽ được 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 thuộc tính 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ư thế với lớp, component khả năng kết nối với các lớp khác. Nếu các lớp này tự chúng có đầy đủ các định nghĩa API, tập hợp kết của của các lớp được thiết kế cấu tạo thành một component.

Có 3 sự khác biệt quan trọng nhất dưới đây giữa component và đối tượng:

Component thường dùng việc lưu trữ liên tục trong khi đối tượ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, trong đó thường dùng cơ chế gửi tin. Component thường là những đơn vị có tính chất lớn hơn các đối tượ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 khả năng được định nghĩa dưới dạng đặc tả của các điểm truy cập của nó. Các máy khách truy cập các dịch vụ cung cấp bởi thành phần dùng các đ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 các dịch vụ khác nhau được cung cấp bởi component, sau đó component dự kiến sẽ có nhiều giao diện.

Điều chú ý 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ỳ vận hành nào của nó. Thay vào đó, nó chỉ đơn thuần là tên của tập hợp các hành động và cung cấp các mô vả và giao thức các vận hành của nó. Đặc điểm này làm cho nó khả năng thay thế một phần thực hiện mà không phải thay đổi ngay giao diện, và cách làm này nâng cao hơn được hiệu năng hệ thống mà không phải xây dựng lạ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 ngay những sự thực thi đã có và trong cách này nâng cao hơ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 bì đây là điều quan trọng cho cả sự thi hành của giao diện và máy khách dùng giao diện. Trong phần lớn các mô hình component hiện nay, giao diện định chỉ định nghĩa một cú pháp (ví dụ: kiểu đầu vào đầu ra) và đưa ra rất ít thông tin về các component.

Giao diện được định nghĩa trong công nghệ component khả năng diễn đạt các functional properties. Function properties bao gồm 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.

Chúng ta khả năng phân biệt hai loại giao diện. Các component khả năng xuất và nhập các giao diện cho và từ môi trường mà khả năng bao gồm 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, trong khi một giao diện nhập vào xác định một dịch vụ bắt buộc bởi component từ môi trường. Các phương pháp tiếp cận chung của các giao diện là cú pháp truyền thống. mặc khác, việc thực hiện các vấn đề ngữ cảnh liên quan đến ngữ cảnh phụ thuộc (tức là đặc tả của môi trường triển khai và môi trường chạy) và sự tương tác cho biết sự rất cần 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ầu hết các kỹ thuật dùng để mô tả giao diện như IDL chỉ có lưu 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à vì thế không giải quyết các hành vi chung của các thành phần. Một đặc tả chính xác của các hành vi của một thành phần khả năng thực hiện một hợp đồng. Meyer đã đề cập, một hợp đồng danh sách cácràng buộc chung mà thành phần sẽ duy trì gọi là tính bất biến. Mỗi hành vi trong thành phần, hợp đồng đưa ra danh sách các điều kiện mà cần phải gắn với bên thực hiện (tiền điều kiện) và các kết quả thành phần cần phải trả lại (hậu điều kiện). Tiền điều kiện, hậu điều kiện và tính bất biến 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 khả năng được dùng để quy định các tương tác giữa một nhóm các thành phần. mặc khác, chúng được 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 điều kiện 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ụ đòi hỏi các thành phần hỗ trợ các biến nhất định và giao diện, và nghĩa vụ hệ quả đòi hỏi các thành phần thực hiện một chuỗi lệnh của hành động, bao gồm việc gửi tin đến các 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. Chú ý rằng các thành phần không những cung cấp các dịch vụ cho các thành phần khác mà còn đòi hỏi chúng từ các thành phần khác. Nó đúng cho cả bắt buộc chức năng và bắt buộc phi chức năng. Đo đó, các nghĩa vụ hợp đồng có sự khác biệt một cách đáng kể so với tiền điều kiện, hậu điều kiện của các 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 khả năng 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õ điều kiện mà trong đó tương tác giữa các thành phần trong điều khoản của tiền điều kiện và hậu điều kiện về vận hành. Tiền điều kiện chỉ rõ các đặc điểm môi trường phải đáp ứng để vận hành của hợp đồng khả năng đáp ứng hậu điềukiện. đơn giản tiền điều kiện/hậu điều kiện về vận hành thiết lập sự đúng đắn cục bộ, trong khi để hoàn thiện sự đúng đắn tổng thể, sự chấm dứt là rất cần thiết. Bởi vì hợp đồng được thiết kế để đại diện cho các tin nhắn, qua giao thức giữa các thành phần, chúng là bắt buộc trong một cách tự nhiên và vì thế khó diễn tả trong một cách 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 các vận hành 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 bên 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 <8> đã lần đầu tiên giới thiệu khái niệm về khuôn mẫu vào cuối năm 1970. Trong khái niệm này, khuôn mẫu định nghĩa giải pháp tuần hoàn cho các 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 những 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 giải quyết vấn đề khác (như là 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 để giải quyết vấn đề chứ không phải là lý thuyết hoặc suy đoán. Khuôn mẫu mô tả mối quan hệ tình dục giữa cấu trúc 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ế khả năng được dùng để 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 dùng, khả năng được xem như một sự thi hành một vài khuôn mẫu thiết kế. Các khuôn mẫu thiết kế khả năng được dùng để mô tả mức độ thấp chi tiết 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à mối quan hệ tình dục giữa các thành phần trong bối cảnh của một ngôn ngữ lập trình chi tiết.

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

Mối quan hệ tình dục giữa các thành phần và khuôn mẫu thiết kế khả năng được xem như sau. Khuôn mẫu thiết kế được dùng rộng rãi trong quy trình thiết kế hệ thống dựa thành phần, trong đó các đơn vị tái dùng phải được xác định. Việc dùng các khuôn mẫu thiết kế làm cho nó đơn giản hơn cho chúng ta công nhận những phần tái 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ư là các đơn vị tái dùng. Khuôn mẫu thiết kế khả năng được dùng để mô tả hành vi của các bộ phận bên trong thành phần và vì thế được 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 dùng để mô tả cấu tạo thành phần khi thiết kế một hợp đồng hoặc framework mà các kết nối 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 đó một môi trường là điều rất cần thiết để các phần đó khả năng ghép lại với nhau. Framework là một phương tiện cung cấp một môi trường 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 mối quan hệ tình dục giữa chúng mà khả năng tái dùng trong bất kỳ trạng thái nào. Szyperski <8> 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 điển hình và thường được 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 để chia sẻ và tái 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 bối cảnh các thành phần tham gia khả năng nối ghép một cách kết quả. Framework dùng ở đây là framework hướng đối tượng và có hơi khác so với framework thành phần. Framework hướng đối tượng trừu tượng hơn. Chúng là một phần của thiết kế và triển khai cho các ứng dụng trong một miền chi tiết. 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ần thực hiện đầy đủ vai trò của chúng trong framework. Frameworks và thành phần Theo như các định nghĩa framework trước đó, một framework được xem như là 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 cách lấp đầy những chỗ trống. bắt buộc được chỉ ra để cho biết những gì mà thành phần cần làm cho 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, chúng ta thấy rằng hành vi của framework khả năng được đặc tả trong các điểu khoản của tiền điều kiện và hậu điền kiện của framework, tính bất biến và sự thuyết minh cũng như là các thành phần được tham gia và mỗi quan hệ tình dục 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 chi tiết hơn giao diện các hành phần cần phải có để các framework bao quanh.

Các chỗ trống khả năng đượ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 mối quan hệ tình dục giữa các thành phần được miêu tả. Các chi tiết trong đặc tả vẫn còn được che dấu trong thành phần và cần tiếp thục như thế. 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 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 để dùng trong các framework mới.

Khái niệm CORBA Giới thiệu Các ngôn ngữ lập trình đều có các điểm chung là các lời gọi hàm, giấy tờ, tham số truyền, trị trả về… trong lúc đó các đối tượng trong ngôn ngữ lập trình hướng đối tượng thiết kế bằng ngôn ngữ nào thì chỉ có mã lệnh tương ứng của ngôn ngữ đó mới truy xuất được chúng. Vậy làm sao các đối tượng được thiết kế bằng các ngôn ngữ lập trình khác nhau khả năng triệu gọi và dùng lẫn nhau? Các điểm chung của các ngôn ngữ lập trình được tập hợp lại trong ngôn ngữ đặc tả. Và CORBA là một ngôn ngữ đặ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 phân tán.

Xem thêm: Tổng hợp prosure là gì | Sen Tây Hồ

CORBA còn được gọi là ngôn ngữ đặc tả giao tiếp (IDL – Interface Description Language) Ngôn ngữ đặc tả giao tiếp IDL IDL <10> được dùng để mô tả các giao diện giữa các đối tượng CORBA. Ngôn ngữ IDL là trung lập đối với ngôn ngữ thực hiện, nói cách khác, giao diện IDL khả năng được thực hiện trong bất kỳ ngôn ngữ nào chẳng hạn như Java, C, C + +, và một vài ngôn ngữ khác.

Ta lấy một ví dụ về đặc tả đối tượng Calculator bằng ngôn ngữ 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 ngôn ngữ lập trình khác chúng ta khả năng dùng như sau: idl2cpp sentayho.com.vn // chuyển sang C++idlj sentayho.com.vn // chuyển sang java Kết quả là chúng ta có được tập tin sentayho.com.vn như sau: publicinterface CalculatorOperationsint 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);

Ngôn ngữ đặc tả trong mô hình CORBA gần giống với ngôn ngữ C.

CORBA đưa ra từ khóa in cho các 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 dùng dịch vụ CORBA, JavaBeans, và EJB <12>

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 cách 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 đích chính đằng sao đặc tả CCM là cung cấp giải pháp cho sự 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 máy chủ cho việc xây dựng và phát triển ứng dụng CORBA”

một trong số những lợi ích của CCM là sự cố gắng “hợp nhất” các mặt được bao gồm 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 cách thức khác nhau theo 2 chiều: chiều thời gian (vòng đời, từ thiết kế đến 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 các đặ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 bao gồm dữ liệu và sự logic của nó, cùng với định nghĩa về kết nối được xác định rõ ràng hoặc giao diện tiếp xúc về liên lạc. Nó được thiết kế để khả năng dùng lặp lại trong phát triển ứng dụng, khả năng có hoặc không có các tùy biến”

Giao diện và sự nối ghép Cái nhìn từ bên ngoài của một thành phần là một phần mở rộng của ngôn ngữ 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 <12>

*
Giới Thiệu Về Corba Là Gì – Corba/Common Object Request Broker Architecture 2

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

Thành phần được coi như là một hộp đen. Giao diện chỉ là các đ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 hỗ trợ nhiều tính năng bên ngoài mà khách hàng và các thành phần khác của môi trường ứng dụng khả năng tương tác với thành phần. Các đặc tính bên ngoài đó được gọi là các cổng. Mô hình thành phần hỗ trợ 4 loại cổng chính là:

Facets: được đặt tên cho giao diện được cung cấp bởi thành phần cho các 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 dùng sự tham khảo được hỗ trợ bởi một vài tác nhân bên ngoài. Event 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 lưu tâm hoặc tới một kênh sự kiện. Event 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 khả năng được đẩy vào. CCM xem các cổng như là các biến được đặt tên và đặt kiểu, vì thế các facets khác nhau của cùng một thành phần khả năng có các kiểu giống nhau. Các thành phần được đặt kiểu và khả năng kế thừa từ các thành phần khác. Đặc tả CCM bằng ngôn ngữ IDL Thành phần Thành phần được dùng với từ khóa component.

Giao diện cũng như được hỗ trợ bởi các thành phần khả năng kế thừa từ một vài giao diện người dùng tự định nghĩa. Mối quan hệ tình dục này được thể hiện bằng cách 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 dùng với từ khóa provides.component XXX provides ;

;Ví dụ:

module motors interface Engine;interface Panel ;component Car supports Clockprovides Engine _engine;provides Panel_panel;

;;

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

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

Tham khảo thêm: Out Of là gì và cấu trúc cụm từ Out Of trong câu Tiếng Anh

Receptacle đơn khả năng kết nối đến một đối tượng,component XXX uses ;

;Ví dụ:

interface Customer ;component Account uses Customer owner;

;

Nhiều receptacle khả năng kết nối với nhiều đối tượng.component XXX usesmultiple ;

;Ví dụ:

component Account usesmultiple Customer owner;

;

Event Sources Từ khóa publishes được dùng để định nghĩa event sources. Từ khóa này chấp nhận kết nối 1 – ncomponent XXX publishes ;

;Ví dụ:

module stockbroker eventtype AlertSignalpublic string reason;

;component Broker

publishes AlertSignal alert_source;

;;

Từ khóa emits chấp nhận kết nối 1- 1component XXX emits ;

;Ví dụ:

module stockbrocker eventtype StockLimit public long stock_value;

;component Broker

emits StockLimit limitAlert;

;;

Event Sinks Event sink được 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;

;;

Điều kiện kết nối Để các thành phần trong CCM khả năng kết nối được với nhau nếu các cổng của chúng thỏa mãn một vài điều kiện chính sau: Facet khả năng chỉ kết nối với receptacles (cổng provideschỉ kết nối với cổng uses) Event source chỉ khả năng kết nối với event sinks (nói cách khác: cổng publishes và cổng emitschỉ khả năng kết nối với cổng consumes). Mỗi cổng provides(facet) khả năng kết nối với nhiều cổng uses(receptacles), mỗi cổng publishes khả năng kết nối với nhiều cổng consumesnhưng không thể ngược lại. Mỗi cổng emitschỉ khả năng 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, event sources) là kiểu con của một trong số những cổng bắt buộc (receptacles, event sinks) CHƯƠNG 4.

Xem thêm: Lá Diêu Bông là gì? Sự thật về “Lá Diêu Bông” | Việt Nam 24h

Bạn thấy bài viết thế nào?

Các câu hỏi về Giới Thiệu Về Corba Là Gì – Corba/Common Object Request Broker Architecture – Cúng Đầy Tháng

Team Sổ Tay Thông Thái mà chi tiết là Mỹ Chi đã biên soạn bài viết dựa trên tư liệu sẵn có và kiến thức từ Internet. Dĩ nhiên tụi mình biết có nhiều câu hỏi và nội dung chưa thỏa mãn được bắt buộc của các bạn.

Thế nhưng với tinh thần tiếp thu và nâng cao hơn, Mình luôn đón nhận tất cả các ý kiến khen chê từ các bạn & Quý đọc giả cho bài viêt Giới Thiệu Về Corba Là Gì – Corba/Common Object Request Broker Architecture – Cúng Đầy Tháng

Nếu có bắt kỳ câu hỏi thắc mắt nào vê Giới Thiệu Về Corba Là Gì – Corba/Common Object Request Broker Architecture – Cúng Đầy Tháng hãy cho chúng mình biết nha, mõi thắt mắt hay góp ý của các bạn sẽ giúp mình nâng cao hơn hơn trong các bài sau nha <3 Chốt lại nhen <3 Bài viết Giới Thiệu Về Corba Là Gì - Corba/Common Object Request Broker Architecture - Cúng Đầy Tháng ! được mình và team xem xét cũng như tổng hợp từ nhiều nguồn. Nếu thấy bài viết Giới Thiệu Về Corba Là Gì - Corba/Common Object Request Broker Architecture - Cúng Đầy Tháng Cực hay ! Hay thì hãy ủng hộ team Like hoặc share. Nếu thấy bài viết Giới Thiệu Về Corba Là Gì - Corba/Common Object Request Broker Architecture - Cúng Đầy Tháng rât hay ! chưa hay, hoặc cần bổ sung. Bạn góp ý giúp mình nha!!

Các Hình Ảnh Về Giới Thiệu Về Corba Là Gì – Corba/Common Object Request Broker Architecture – Cúng Đầy Tháng

Giới Thiệu Về Corba Là Gì - Corba/Common Object Request Broker Architecture - Cúng Đầy Tháng

Các từ khóa tìm kiếm cho bài viết #Giới #Thiệu #Về #Corba #Là #Gì #CorbaCommon #Object #Request #Broker #Architecture #Cúng #Đầy #Tháng

Tham khảo báo cáo về Giới Thiệu Về Corba Là Gì – Corba/Common Object Request Broker Architecture – Cúng Đầy Tháng tại WikiPedia

Bạn khả năng tìm thêm thông tin về Giới Thiệu Về Corba Là Gì – Corba/Common Object Request Broker Architecture – Cúng Đầy Tháng từ web Wikipedia.◄

Tham Gia Cộng Đồng Tại

💝 Nguồn Tin tại: https://sotaythongthai.vn/

💝 Xem Thêm Giải Đáp Thắc Mắt tại : https://mangraovat.edu.vn/hoi-dap/

Related Posts

About The Author