Đang tải... (xem toàn văn)
Tìm hiểu về CORBA
https://www.facebook.com/pages/Tài-liệu-hay-và-rẻ/600827713314928?ref=hl 1 1 TÌM HIỂU VỀ CORBACHƯƠNG 1: TỔNG QUAN VỀ CORBA CORBA , viết tắt từ Common Object Request Broker Architecture, được xây dựng nhằm phát triển hệ thống hướng đối tượng rộng rãi. CORBA cho phép các ứng dụng giao tiếp nhau mà không cần biết vị trí và ai đã tạo ra. ORB là phần trung gian tạo khả năng cho các mối liên hệ giữa client/server thông qua những object. Bằng cách sử dụng ORB, client có thể gọi một phương pháp trên object server một cách thông suốt mà object đó có thể ở trên cùng một máy hay trên mạng máy tính. ORB chịu trách nhiệm tìm kiếm object mà có thể hiện thực các yêu cầu, truyền thông số, gọi phương pháp của nó và trả về kết quả. Client không cần phải biết vị trí của object, ngôn ngữ hiện thực, hệ điều hành hay bất kỳ khía cạnh hệ thống nào khác mà chúng không phải là thành phần của giao diện object. ORB, cũng với cách như thế, cung cấp khả năng nội tương tác giữa các ứng dụng trên các máy tính khác nhau trong viễn cảnh của môi trường phân bố và nhiều hệ thống. Trong lãnh vực client/server cụ thể, những nhà phát triển dùng cách thiết kế và chuẩn riêng của mình để tạo ra một protocol dùng chung giữa các thiết bị. Với một ORB, protocol được định nghĩa với những giao diện ứng dụng thông qua việc đặc tả không phụ thuộc ngôn ngữ hiện thực đơn, IDL. ORB cho phép phát triển hoàn thiện những cơ cấu đã được xây dựng sẵn. Đơn giản dựa vào nền tảng CORBA , những nhà phát triển lập mô hình cấu trúc thừa kế sử dụng cùng một loại IDL mà họ dùng để tạo ra object mới, sau đó viết đoạn mã nhằm dịch giữa bus chuẩn và giao diện có sẵn. I/ CORBA: Khả năng tương tác (interoperability) của các object: 2 2 Trong CORBA, một object cung cấp các dịch vụ mà các dịch vụ đó được biểu diễn trong một "contract"giữa object và phần còn lại của hệ thống. Bảng "contract" đó nhằm: + Cho các client khả hiệu của dịch vụ mà object cung cấp biết bằng cách nào xây dựng thông điệp để gọi các dịch vụ. + Để cấu trúc giao tiếp biết dạng format tất cà các thông điệp mà object nhận và gởi. Mỗi object cần 1 handle duy nhất mà client có thể qua đó tìm ra thông điệp truyền cho nó. Chúng ta không gọi nó là một địa chỉ-những object giữ cùng một handle khi di chuyển sang vị trí khác. Ta xét handle như loại địa chỉ định hướng trước tự động. Như vậy, môi trường mạng tính toán của chúng ta là: - Mỗi nút là một object có interface được định nghĩa tốt và được định danh bởi một handle duy nhất. Thông điệp truyền tải giữa object nhận và đích; object đích được định danh bởi handle của nó và dạng thông điệp được định nghĩa trong interface mà interface này được biết đến hệ thống. II/ OMA: (Object Management Architecture) CORBA chỉ liên kết các object nhưng không liên kết các ứng dụng. Muốn thế, OMG cung cấp điều đó trong OMA _ phải dựa trên CORBA. Những object ứng dụng mặc dù không được chuẩn hóa bởi OMG nhưng sẽ truy xuất các dịch vụ và công cụ của CORBA thông qua những interface chuẩn nhằm cung cấp những lợi điểm cho người cung cấp và người sử dụng cuối cùng mà không cần quan tâm đến những platform phía dưới. Dựa trên kiến trúc CORBA, OMA đặc tả một tập những hàm và interface chuẩn cho từng cơ cấu. Việc hiện thực interface và các chức năng của các nhà cung cấp khác nhau ứng dụng lên mạng lưới của khách hàng nhằm cho phép phát triển thêm những tính năng từ những module mua được (hoặc phát triển thêm cho chính mình). CORBAservices cung cấp chức năng cơ bản mà hầu như object nào cũng cần: dịch vụ chu kỳ sống (lifecycle) của object (như copy và xóa), dịch vụ đặt tên và thư mục và những cái cơ bản khác . Tại vị trí mà CORBAservices cung cấp những dịch vụ cho object thì cũng chính là nơi CORBAfacilities cung cấp những dịch vụ cho các ứng dụng. Kiến trúc CORBAfacilities gồm hai phần horizontal và vertical. Như vậy, OMA là kiến trúc gồm 4 phần: 3 3 + Cơ cấu nền tảng: ORB + những dịch vụ thêm được dùng bởi những nhà phát triển chủ yếu nhằm quản lý những object phân bố. + những dịch vụ được sử dụng chung cho những ứng dụng khác nhau và, + những ứng dụng phân bố của chính chúng. III/ Những lợi ích của CORBA: Cho những nhà phát triển: + CORBA là môi trường duy nhất cho phép chúng ta tận dụng tiện lợi những công cụ mà chúng ta mua được từ phần cứng đến những phần mềm phát triển. ( cần một kiến trúc để có thể thực thi trên tất cả các hệ thống mạng và platform phần cứng). + Mô hình hướng đối tượng : tạo điều kiện thuận lợi cho việc thực thi trên môi trường phân bố đối tượng + Cung cấp cho chúng một giao diện IDL và tầng mỏng của đoạn mã "wrapper"; và được thừa hưởng những ứng dụng kế thừa trong môi trường CORBA. + CORBA tạo năng suất cao nhất cho những nhà lập trình (CORBAservices và CORBfacilities). + Code được tái sử dụng bằng 2 cách: dùng những ứng dụng tái kiến thiết động hoặc mới; hoặc bổ sung thêm những thông tin trên những objects tồn tại sẵn . Cho những người sử dụng: một ứng dụng CORBA/OMA là một tập hợp động các cơ cấu hiện thực client và đối tượng, được lập cấu hình và kết nối trong thời gian thực thi 4 4 Client Client ObjectImplementation IDLStub IDL Skeleton RequestObject Request Broker để giải quyết những vấn đề. Nói chung là phải tổng hợp những thành phần ở các platform và OS khác nhau. IV/ OMG: (Object Managenent Group): Là sự kết hợp của nhiều công ty máy tính có liên quan. Để một cái chuẩn được sử dụng, chuẩn đó phải tồn tại như một hiện thực trải qua nhiều giai đoạn phát triển và nhu cầu chung => cơ sở hình thành OMG CHƯƠNG 2: T NG QUAN V K THU TỔ Ề Ỹ Ậ I/ CORBA và OMA: 5 5 Request truyền từ Client đến object implementation trong kiến trúc của CORBA: + CORBA đòi hỏi mọi giao diện của object được đặc tả trong OMG IDL. Client chỉ có thể lấy được giao diện của đối tượng mà không bao giờ thấy được chi tiết hiện thực nào. + Mọi yêu cầu của đối tượng CORBA được truyền tới ORB: dạng của yêu cầu là giống nhau dù object là local hay "remote". Chi tiết về sự phân bố lưu trong ORB nơi mà chúng được điều khiển từ phần mềm mà ta mua, chứ không phải từ phần mềm ta xây dựng. Đoạn mã ứng dụng tập trung vào vấn đề cần giải quyết OMA định nghĩa cấu trúc chung này (hình). CORBAservices cung cấp những dịch vụ mức hệ thống này mà hầu hết hệ thống hướng đối tượng đều cần; trong khi CORBAfacilities cho phép việc truy cập dựa trên chuẩn các dữ liệu chung và chức năng cần thiết. II/ CORBA object: Một object trên môi trường CORBA (3 phần quan trọng của object là : tính đóng kín, thừa kế và đa hình). III/ OMG IDL: Trong CORBA, một giao diện được định nghĩa trong OMG IDL. Việc định nghĩa giao diện nhằm đặc tả những tác vụ mà object chuẩn bị thực thi, các thông số nhập xuất mà các tác vụ đó đòi hỏi, và bất kỳ "exception" nào phát sinh trong quá trình xử lý. Đối với người sử dụng, interface (được viết trong OMG IDL) thực hiện lời hứa: Khi client gởi một thông điệp hoàn hảo tới interface, đáp ứng sẽ trả về. Còn đối với những nhà hiện thực đối tượng, interface tượng trưng cho nghĩa vụ: người đó phải hiện thực tất cả các tác vụ được đặc tả trong interface bằng một ngôn ngữ nào đó. 1/ Xây dựng object CORBA: Việc đầu tiên là phải tìm hiểu chính xác đối tượng đó sẽ làm gì và vì đây là CORBA object nên việc kế tiếp là định nghĩa interface của nó trong OMG IDL. 2/ Thực hiện việc lựa chọn: Sự chuẩn hoá cho phép những sự lựa chọn quan trọng ( như ngôn ngữ lập trình dùng để hiện thực, platform hoặc hệ điều hành mà nó thực thi, ORB kết nối, thực thi local hay remote, . ) được dời lại cho đến những phần sau của quá trình phát triển. Trong CORBA tất cả những gì mà các nhà phát triển client cần phải biết là sự định nghĩa IDL interface và tất cả những gì mà object sẽ làm. 3/ Chọn ngôn ngữ hiện thực: 6 6 Ta cần xét hai vấn đề: tính thích hợp và tính khả thi Ngôn ngữ lập trình thích hợp là ngôn ngữ đáp ứng được những gì ứng dụng của ta cần, chỉ sử dụng nguồn tài nguyên mà chúng ta sẵn có, và ta và đội ngũ lập trình hợp tác có thể học hoặc biết về nó. Về tính khả thi, chúng ta phải kiểm tra các ORB có khả thi với những platform phần cứng mà ta dự định thực thi trên nó Đối với mọi ngôn ngữ lập trình chính, ánh xạ ngôn ngữ theo chuẩn OMG đặc tả kiểu IDL, phương pháp gọi, và những kiến thiết khác chuyển vào trong các cuộc gọi hàm bằng ngôn ngữ lập trình. Như hình 2.2 mô tả, chính là cách IDL skeleton và object implementation làm việc với nhau. Vì việc ánh xạ ngôn ngữ là chuẩn của OMG, mọi trình biên dịch IDL của các nhà cung cấp đều tạo ra cùng một tập các cuộc gọi hàm từ file IDL được giao. Điều này đảm bảo rằng, dù chúng ta ORB của nhà cung cấp nào cho ngôn ngữ cụ thể, object implementation truy cập skeleton cùng một cú pháp. Nếu chúng ta thực hiện trên các ORB của nhiều nhà cung cấp, code chuyển từ ORB này sang ORB khác. 4/ Kết nối tới ORB: Hai khía cạnh của implementation skeleton trái ngược nhau: Việc kết nối tới client , được quản lý bởi OMG IDL, được chuẩn hoá; còn kết nối ORB trên khía cạnh khác thì thuộc về người chủ; điều này giúp cho nhà cung cấp đáp ứng những nhu cầu của khách hàng. Vì giao diện của ORB_skeleton thuộc về người chủ nên ORB và trình dịch IDL phải cùng một xuất xứ. Chúng ta phải sử dụng trình dịch IDL với ORB kèm theo: skeleton từ nhà cung cấp A sẽ không tương thích với ORB từ nhà cung cấp B. 7 Ánh x ngôn ng OMG đ c xâyạ ữ ượ d ng trong ự trình biên d ch IDLị Nhà l p trình ậ tham kh o ánh x ả ạ ngôn ng OMG ữ IDL IDL Compiler c đ nhố ị ch n ngôn ng l pọ ữ ậ trình Object Impl code Skeleton code 7 Tóm lại về mục đích của việc hiện thực đối tượng: chúng ta bắt đầu với việc định nghĩa giao diện IDL hữu dụng với bất kỳ ngôn ngữ lập trình và ORB nào. Chúng ta có thể dùng trình dịch IDL được kèm theo với ORB để tạo ra skeleton mà có thể kết nối với ORB đã chọn sau khi nhập vào IDL file. Tính năng có thể tích hợp (được đảm bảo bởi ánh xạ ngôn ngữ chuẩn) cho phép chúng ta biên dịch bằng trình dịch IDL của nhà cung cấp khác và tạo ra skeleton bằng cùng các cuộc gọi hàm, nhưng stub thì kết nối với ORB của nhà cung cấp mới. IV/ ORB: Định nghĩa về ORB đã được xét qua. Hiện tại, ta cần xét đến những khía cạnh khác: Trong cấu trúc, người ta không đòi hỏi ORB phải hiện thực như những thành phần đơn mà nó được định nghĩa như những interfaces trực thuộc nó. Bất kỳ sự hiện thực ORB nào cũng cung cấp những giao diện thích hợp chấp nhận được. Interface được tổ chức trong 3 loại sau: + Các tác vụ là như nhau đối với tất cả sự hiện thực ORB. + Các tác vụ ứng với những kiểu cụ thể của object . + Các tác vụ tương ứng với những phong cách hiện thực object cụ thể. Những ORB khác nhau chọn cách hiện thực khác nhau. Khi hai ORB làm việc chung với nhau, những ORB đó phải phân biệt những tham chiếu object (OR) của chúng. 8 Biên dịch và linkBiên dịch và link ObjectClient Skele ton Stub ORB Hình 2.2 Vai trò c a chu n hóa ánh x ngôn ng OMG.ủ ẩ ạ ữ 8 Nhân (Core) ORB là một phần của ORB cung cấp sự hiện diện cơ bản của những object và sự truyền thông của các requests. CORBA được thiết kế nhằm hỗ trợ những cơ cấu object khác nhau và CORBA cũng cấu thành ORB với những thành phần phía trên "ORB Core" (nó cung cấp những interfaces nhằm có thể che đi những sự khác nhau giữa những ORB Cores). 1/ Nền tảng cho khả năng tương tác qua lại: Mục tiêu của chúng ta là sử dụng một "web" của ORB-ORB để tạo khả năng tương tác qua lại giữa tất cả đối tượng CORBA trên mạng. Hai vấn đề nảy sinh: - Location: đánh địa chỉ cho invocation đến object implimentation như thế nào. => giải quyết: object reference. - Translation: invocation mà chúng ta gởi đi được dịch sang dạng format khác như thế nào và đáp ứng trả về ra sao.=> giải quyết: IDL. 2/ Object reference: Một OR là thông tin cần thiết để đặc tả object trong ORB. Hai ORB implementation có thể chọn cách thể hiện cho OR khác nhau. Sự thể hiện của OR được chỉ khả thi (valid) trong thời gian sống của client. Mỗi object CORBA trong hệ thống đều có object reference (OR) của riêng nó mà không quan tâm đến thời gian sống của object; được gán bởi ORB của nó lúc tạo ra object và vần còn valid cho đến khi object bị xóa đi một cách tường minh. Client lưu giữ những OR bằng nhiều cách khác nhau, và giao tiếp với chúng bằng yêu cầu phụ thuộc vào ánh xạ ngôn ngữ đang dùng. Sự giao tiếp này tạo khả năng cho ORB gọi trực tiếp đến object đích được đặc tả. Client có thể lưu trữ những tham chiếu của một object trong một file hay một database. Sau đó, khi client lấy tham chiếu ra, OMA đòi hỏi cuộc gọi phải được thực thi một cách hoàn hảo ngay cả khi object đích đã bị xóa trong thời gian quá độ (nhưng không đúng khi object bị xóa một cách tường minh). Điều này có nghĩa là OR không đơn giản chỉ là địa chỉ network hay bộ nhớ của object. Những tiêu chuẩn OMG cho phép mỗi nhà cung cấp ORB hiện thực cách dịch OR sang object đích thực sự được xem là tốt nhất đối với hệ thống và nền tảng của khách hàng. Điều bắt buộc là ORB nào cũng phải hiểu được mọi OR ở mọi lúc. Và bất kỳ một ứng dụng dùng ORB nào đó trên network cũng có thể lấy các OR và truyền cho ORB của chính nó nhằm gọi object. Và vì thế, OR đóng vai trò rất quan trọng trong việc cho phép user sử dụng tài nguyên trong hệ thống phân bố trải rộng. 9 9 Vì chúng ta đang đứng ở vị trí là người sử dụng ORB thay vì là người tạo ra ORB, khái niệm của OR cho phép chúng ta định hướng trước: ta có thể truyền OR đến ORB, và ORB truyền phép gọi đến object đích. Và nếu như chúng ta đang truyền hay đang nhận OR như một thông số thì ORB chỉ quan tâm đến những chi tiết không liên quan đến vị trí và quãng đường truyền tải của OR. 3/ IDL và ORB: ORB quan tâm đến những chi tiết như liên kết những nhóm platform với những dạng format khác nhau. ORB cần một công cụ để thực hiện: đó là OMG IDL. CORBA đòi hỏi phải lưu trữ về định nghĩa IDL của tất cả các object của nó trong IR (Interface Repository). Tập hợp những định nghĩa giao diện này là tài nguyên quan trọng trong hệ thống phân bố. IDL còn phải hữu dụng đối với client, object implementation và các tiện ích khác. Thuận lợi của IR trong việc liên kết ORB: Biết được kiểu và thứ tự liên kết của các đố số trong thông điệp tạo khả năng liên lạc giữa các ORB nhằm chuyển đổi thứ tự byte và dạng format dữ liệu ở bất kỳ nơi nào cần thiết. Lợi ích chính của việc sử dụng IR là DII (Dynamic Invocation Interface). 4/ DII: (Dynamic Invocation Interface) Để gọi một tác vụ trên object, client phải gọi và, được liên kết tĩnh với stub tương ứng. Vì những nhà phát triển xác định những stub nào chứa trong client mà họ đã viết code của nó nên interface này (SII) không thể truy xuất những object vừa thêm vào hệ thống. Những người sử dụng cấp cao (phức tạp) muốn sử dụng object mới sau khi họ được cung cấp thêm bất kỳ ORB trên mạng mà không phải đợi hoặc cài đặt phần mới cho sofware của client trên desktop. DII cung cấp khả năng này và nó được "built in" cho mọi ORB tuân theo chuẩn CORBA. Tại thời điểm thực thi, DII cung cấp cho client: + Tìm thấy object mới. + Tìm thấy những interface của chúng (những object mới). + Lấy ra những định nghĩa về interfaces. + Tạo và phát ra phép gọi. + Nhận đáp ứng kết quả hoặc thông tin "exception". 10 10 . https://www.facebook.com/pages/Tài-liệu-hay-và-rẻ/600827713314928?ref=hl 1 1 TÌM HIỂU VỀ CORBACHƯƠNG 1: TỔNG QUAN VỀ CORBA CORBA , viết tắt từ Common Object Request Broker Architecture,. chuẩn CORBA : 1/ CORBA core: Tất cả những sản phẩm của CORBA phải tuân theo những đặc tả của CORBA core; gồm: - Mô hình đối tượng CORBA . - Kiến trúc CORBA.