TÌM HIỂU về CORBA trong java

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:
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à linkBiê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.
+ Tạo và phát ra phép gọi.
+ Nhận đáp ứng kết quả hoặc thông tin "exception".
DII thật ra là một ORB interface được định nghĩa trong IDL mà nó bao gồm
những giải thuật tìm đường nhằm cho phép client và ORB xây dựng và gọi những
tác vụ của bất kỳ object nào khi chúng làn việc chung với nhau và đang sử dụng
những định nghĩa interfaces từ IR.
Bằng cách nào mà client có thể biết object hay interface nào mà client muốn
lấy từ IR? Ví dụ, tại thời điểm cài đặt, những object mới có thể tạo ra các ngõ nhập
vào file mà client biết được, liệt kê tên interface của chúng với những thông tin
phụ mà client có thể display trong một menu; điều này cung cấp cho user thông tin
cần thiết để chọn object và client với thông tin cần thiết để lấy định nghĩa interface
từ IR. Những phương cách chuẩn dùng để tìm thấy những object trong hệ thống
phải kể đến Naming và Trader services.
Những tiện lợi khi sử dụng DII:
+ Client không cần phải biết những interfaces của server trong thời gian
biên dịch; thật ra định nghĩa interface thậm chí không cần tồn tại tại thời điểm mà
client được biên dịch. Điều này tạo khả năng linh động hữu hiệu cho những ứng
dụng dùng DII.
+ DII cung cấp nhiều option để chứa những thông số trả về từ một tác vụ.
Ứng dụng client có thể trả về kết quả một cách bình thường, gọi tác vụ và dùng
ngữ cảnh one_way hay lưu vào kết quả. Những option này tạo tính linh động trong
những ứng dụng DII hơn là trong những phần thực hiện phép gọi static.
Những bất lợi khi sử dụng DII:

+ Những ứng dụng dùng DII thường phức tạp hơn những ứng dụng tương
ứng khi sử dụng client stub (tĩnh). Bởi vì một phép gọi tác vụ dùng DII phải truyền
từng đối số một trong một thời điểm, gọi tác vụ và nhận từng đối số trả về một =>
công việc tẻ nhạt và thường gây ra quá trình error_prone.
+Trong khi khả năng kiểm tra kiểu được xây dựng trong cơ cấu gọi hàm
tĩnh, thì đối với những pháp gọi tác vụ trong DII là không cần thiết.
+ Vì từng đối số một truyền từng thời điểm, nên chi phí thêm sẽ phát sinh.
+ Vì chi phí phát sinh thêm nên client của DII phãi thỏa hiệp với server
trong trường hợp client cần cấp một hay nhiều interface.
V/ Khả năng tương tác trên nền tảng CORBA:
1/ Truy xuất một object từ một ORB từ xa:
Client
Object
Stub
Skel
ORB 1
Client
Object
Stub
Skel
ORB 2
Hình 2.4 Interoperability dùng liên lạc giữa các ORB
Khả năng tương tác trong CORBA dựa trên mối liên lạc ORB-ORB.
Client truyền cuộc gọi thông thường dựa trên IDL đến ORB cục bộ. Nếu
cuộc gọi chứa OR của object implementation cục bộ, ORB tìm đường gởi nó đến
object đích; nếu không có thì ORB tìm đường cho phép gọi đến ORB từ xa. Sau đó,
ORB từ xa tìm đường cho phép gọi đến object đích.
ORB sẽ quản lý tất cả những chi tiết của cuộc gọi: giải quyết OR cho ORB từ
xa và object; chuyển đổi thứ tự byte và dạng format ở nơi cần thiết.
Mỗi ORB phải lưu trữ ít nhất là hai cơ sở dữ liệu hoặc hai hệ thống thư mục:

IR với tập các định nghĩa interface và implementation với những thông tin về
object implementation. Những chi tiết truyền thông phải được đồng bộ hóa như
những ORB protocol phải liên kết hoặc những gateways phải chuyển đổi giữa
chúng.
Những chi tiết về implementation phải được quan tâm bởi những nhà hiện
thực ORB. Quyết định về những protocol có liên quan sẽ ảnh hưởng đến những
nhà quản trị mạng
2/ Tổ hợp thành phần đối tượng đã mua:
Client và object implementation có thể:
+ Ở trên các ORB của nhà cung cấp khác.
+ Trên những platform khác nhau.
+ Trên hệ điều hành khác.
+ Trên hệ thống mạng khác.
+ Và được viết dưới dạng ngôn ngữ lập trình khác nhau.
Tất cả những gì nhà lập trình cần viết client để truy cập những object từ xa
là bản sao của IDL file của nó, mô tả những việc mà từng tác vụ phải thực hiện và
mô tả OR.
Tiến trình được mô tả trong hình. Khi chúng ta mua phần mềm, chúng ta
nhận được cả hai object implementation có thể thực thi và một file IDL từ nhà
cung cấp. Cài đặt object trên ORB trên server mode mà nó sẽ trực thuộc. Tiến trình
thực hiện sinh ra OR .
Khi ta viết client, di chuyển đến phần development platform và không nhất
thiết phải cùng platform hay ORB đang thực thi object implementation. Chúng ta
không cần quan tâm đến ngôn ngữ mà nhà cung cấp dùng để viết object mà chúng
ta mua. Chúng ta có thể viết client bằng bất cứ ngôn ngữ nào mà chúng ta muốn, vì
vậy hãy chọn trình dịch IDL hỗ trợ được môi trường phát triển chúng ta cần. Sử
dụng client stub truy xuất ORB từ trong đoạn mã client, từ Naming service và file
lưu trữ, chúng ta lấy ra OR và dùng nó để gọi những tác vụ của object mà chúng ta
mua bất cứ nơi nào mà nó trực thuộc.
Hình 2.5 : Phát triển một object trong môi trường phần mềm

Nạp và dịch
Desktop
Server
IDL
Object
Biên dịch link
Client code
- - - - -
- - - - -
Client
Object
ORB
ORB
từ người bán
Cài đặt
Skeleton code
Stub code
Stub
Skel
Được viết bởi người lập trình
Không
dùng
từ người bán
3/ Phân bố client và object:
Quá trình đứng ở khía cạnh client giống như đã được trình bày ở trên.
Quá trình hiện thực object được thực thi tuần tự trên platform phát triển
server, lưu trữ skeleton IDL và xây dựng đoạn mã để có thể thực thi với nó.
Khi hai thành phần đã hoàn thành và register vào ORB có liên quan thì
client có thể lấy OR từ naming service hay bất kỳ nơi nào mà nó lưu trữ; và gọi
những tác vụ trên object bằng cách truyền cuộc gọi tới ORB cục bộ của nó.

VI/ Kiến trúc quản lý đối tượng: (OMA)
Phải có một ngôn ngữ chung cho tất cả các ứng dụng hoặc là chúng ta không
thể nhận ra tất cả các phần mềm thành phần plug_and_play. Ngôn ngữ chung đó
chính là OMG's OMA. OMA định nghĩa môi trường mà nơi đó khả năng tương tác
thâm nhập lên từ mức hệ thống vào những thành phần ứng dụng.
- Cấu trúc của OMA:
Ta có thể phân chia hệ thống ra làm 4 tầng lớp, vị trí của mỗi thành phần
không tương ứng với sự kết nối của chúng (vì mọi thứ đều kết nối với ORB) và
cũng không tương ứng chính xác với cách định thời gian. Ở đây, vị trí tương ứng
với việc mỗi thành phần có tính cơ bản như thế nào; việc thiết kế tầng thấp hơn sẽ
ảnh hưởng đến việc thiết kế của tầng cao hơn mặc dù chúng ta không nhất thiết
phải hoàn thành tất cả những thành phần thuộc tầng cụ thể nào đó trước khi bắt đầu
làm việc với những thành phần của tầng cao hơn.


User Interface
Information Management
System Management
Task
Management
Healthcare
Financial
etc
Application Objects
CORBAfacilities
Vertical CORBAfacilities
Horizontal CORBAfacilities
Object Request Brokers
Lifecycle
Naming

Persistence
CORBAservices
etc…
Hình : OMG’s Object Management Architecture:
HÌNH :Tổng quan về CORBA và OMA:2.6

Phần cứng và phần mềm
hệ thống
CORBAservices: Các dịch vụ căn bản cho
ứng dụng hướng đối tượng
CORBA Core và Interoperability: Kiến trúc và liên
lạc
CORBAfacilities: Thao tác và lưu trữ dữ liệu cấp ứng
dụng
Application Object: Sự cạnh tranh và đổi mới ở cấp
ứng dụng
Users