TÌM HIỂU về CORBA trong java

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.. I/ CORBA: Khả năng tương tác interoperability của c

TÌM HIỂU VỀ CORBA CHƯƠ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:

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:

+ 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 để 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

Client Client Object Implementation IDL Stub IDL Skeleton Request Object Request Broker

I/ CORBA và OMA:

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:

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.

Á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

Skeleton code Biên dịch và link Biên dịch và link

Obje Clien

Skel

Stu b

ORB

Hình 2.2 Vai trò của chuẩn hóa ánh xạ ngôn ngữ OMG.

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

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

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.