Tìm hiểu về corba

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 code Skeleton code Biên dịch và link Biên dịch và link Object Client Skeleton Stub 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 đ