I. Tìm hi u v ORB c a CORBAể ề ủ1. Ch ng trình môi gi i trung gian ORB( Object Request Broker)ươ ớ

a. Dich thu t:ậObject: Đ i t ngố ượRequest: H i, yêu c uỏ ầBroker: Ng i môi gi i trung gianườ ớ Object Request Broker: Trình môi gi i trung gian các yêu c u c aớ ầ ủ

đ i t ng.ố ượ

b. ORB là gì?ORB là m t d ch v phân tán th c thi yêu c u đ n các đ i t ng xa.ộ ị ụ ự ầ ế ố ượ ở

Nó đ nh v đ i t ng xa trên m ng, g i yêu c u đ n đ i t ng, ch k tị ị ố ượ ở ạ ử ầ ế ố ượ ờ ế qu và khi s n s ng thì g i các k t qu này tr l i cho client.ả ẵ ằ ử ế ả ở ạ

ORB th c thi v trí trong su t. Chính xác là c ch yêu c u gi ng nhauự ị ố ơ ế ầ ố đ c s d ng b i client và đ i t ng CORBA mà không quan tâm đ n vượ ử ụ ở ố ượ ế ị trí c a đ i t ng. Nó có th n m trong m t b x lí v i client, ho c b tủ ố ượ ể ằ ộ ộ ử ớ ặ ở ấ kì n i nào. ơ

ORB th c thi các ngôn ng l p trình đ c l p v i các yêu c u. Client đ aự ữ ậ ộ ậ ớ ầ ư ra m t yêu c u đ c vi t b i m t ngôn ng l p trình có th khác v iộ ầ ượ ế ở ộ ữ ậ ể ớ ngôn ng l p trình vi t trong đ i t ng CORBA. ORB th c hi n vi c d chữ ậ ế ố ượ ự ệ ệ ị c n thi t gi a các ngôn ng l p trình. Các liên k t ngôn ng đ c đ nhầ ế ữ ữ ậ ế ữ ượ ị nghĩa cho t t c các ngôn ng l p trình thông d ng.ấ ả ữ ậ ụ

Hình 3: Ki n trúc c b n c a h phân tán.ế ơ ả ủ ệ Hình 3 là c ch tri u g i l n nhau c a các đ i t ng vi tơ ế ệ ọ ẫ ủ ố ượ ế b ng C++, Delphi, Java thông qua ORB.ằ

c. ORB ho t đ ng nh th nàoạ ộ ư ế

C++CORBAObject O

RB Internet

JavaCORBAObject

DelphiCORBAObject

ORB

ORB

Nh ngôn ng đ c t IDL, các đ i t ng cho dù đ c cài đ t b ng b tờ ữ ặ ả ố ượ ượ ặ ằ ấ kì ngôn ng nào n u nh tuân th theo đ c t IDL đ u đ c xem là đ iữ ế ư ủ ặ ả ề ượ ố t ng CORBA. Tuy không cài đ t b n thân đ i t ng nh ng d a vào đ cượ ặ ả ố ượ ư ự ặ t IDL ORB sẽ bi t đ c tên ph ng th c c n g i, ki u đ i s truy n choả ế ượ ươ ứ ầ ọ ể ố ố ề ph ng th c, tr tr v c a ph ng th c g i. V i nh ng thông tin này,ươ ứ ị ả ề ủ ươ ứ ọ ớ ữ ORB có th tri u g i ph ng th c mà đ i t ng cài đ t (Hình 4). ORB làể ệ ọ ươ ứ ố ượ ặ hoàn toàn trong su t (transparent) v i l p trình viên (hay ng i s d ngố ớ ậ ườ ử ụ đ i t ng). B n g i đ i t ng c a Java trong C++ hay Delphi hoàn toànố ượ ạ ọ ố ượ ủ theo cách t nhiên nh b n g i đ i t ng đ c xây d ng t chính ngônự ư ạ ọ ố ượ ượ ự ừ ng g c.ữ ố

Hình 4 : Tri u g i đ i t ng trong CORBAệ ọ ố ượ Kh năng “trong su t” không ch gi i h n gi a các đ i t ng trên cùngả ố ỉ ớ ạ ữ ố ượ

m t máy mà còn đ c m r ng gi a các đ i t ng n m b t kỳ đâu trênộ ượ ở ộ ữ ố ượ ằ ở ấ th gi i thông qua k t n i m ng. Đ i t ng c a b n vi t b ng Java đ tế ớ ế ố ạ ố ượ ủ ạ ế ằ ặ trên m t máy t i Vi t Nam có th đ c g i b i m t đ i t ng Châu Mỹộ ạ ệ ể ượ ọ ở ộ ố ượ ở (“bên kia đ i d ng”) cài đ t b ng C++.ạ ươ ặ ằ

V i kh năng trên, CORBA qu là mang l i đi u kỳ di u cho th gi i l pớ ả ả ạ ề ệ ế ớ ậ trình. CORBA m c a đ các l p trình viên có th xích l i g n nhau h n,ở ử ể ậ ể ạ ầ ơ t o nên m t th th ng nh t c a mô hình l p trình h ng đ i t ng.ạ ộ ể ố ấ ủ ậ ướ ố ượ

C++CORBAObject

JavaCORBAObject

ORB IDL

ORB IDLInternet

Hình 5 : ORB giao ti p v i đ i t ng thông qua các thông tin đ c t IDL.ế ớ ố ượ ặ ả

2. C ch làm vi c c a CORBAơ ế ệ ủORB cũng dùng khái ni m l p trung gian _Stub và _Skel t ng t nhệ ớ ươ ự ư

cách làm vi c c a các đ i t ng RMI. Th t s _Stub và _Skel là hai l p trungệ ủ ố ượ ậ ự ớ gian đ c sinh ra t trình biên d ch d a vào đ c t IDL. B n không c nượ ừ ị ự ặ ả ạ ầ ph i vi t mã l nh cho l p _Stub và _Skel. Đây là công vi c c a các nhà cungả ế ệ ớ ệ ủ c p và thi t k ORB. Hình 6 là c th ho t đ ng c a trình môi gi i ORB liênấ ế ế ơ ế ạ ộ ủ ớ l c gi a trình khách và đ i t ng CORBA trên máy ch . Th ng thì vi c càiạ ữ ố ượ ủ ườ ệ đ t đ i t ng CORBA trên máy ch và tri u g i đ i t ng t trình kháchặ ố ượ ủ ệ ọ ố ượ ừ đ c th c hi n nh sau:ượ ự ệ ư

Ph n cài đ t đ i t ng CORBA trên máy chầ ặ ố ượ ủĐ c t đ i t ng X b ng ngôn ng IDL c a CORBAặ ả ố ượ ằ ữ ủChuy n đ c t X thành mô t c a m t ngôn ng c th (ch ng h nể ặ ả ả ủ ộ ữ ụ ể ẳ ạ

dùng trình biên d ch idlj.exe đ chuy n đ c t c a đ i t ng X sang ngônị ể ể ặ ả ủ ố ượ ng Java). D a vào đ c t IDL yêu c u trình biên d ch t o ra l p trung gianữ ự ặ ả ầ ị ạ ớ _Skel.

Cài đ t đ i t ng X b ng Java.ặ ố ượ ằ Ph n k t n i v i đ i t ng t máy khách ầ ế ố ớ ố ượ ừS d ng đ c t IDL c a đ i t ng X yêu c u trình biên d ch t o raử ụ ặ ả ủ ố ượ ầ ị ạ

l p trung gian _Stub. Tuỳ theo ngôn ng mu n vi t máy khách mà taớ ữ ố ế ở s d ng trình biên d ch thích h p. Ví d n u b n mu n vi t trình kháchử ụ ị ợ ụ ế ạ ố ế b ng ngôn ng C++ b n có th dùng trình biên d ch idl2cpp.exe đ t o raằ ữ ạ ể ị ể ạ l p _Stub dành cho ch ng trình C++ tri u g i đ i t ng CORBA.ớ ươ ệ ọ ố ượ

Khi trình khách tri u g i đ i t ng ch , th c t l i g i sẽ đ cệ ọ ố ượ ủ ự ế ờ ọ ượ chuy n qua l p _Stub trên máy khách, g i đ n trình môi gi i ORB. Trìnhể ớ ử ế ớ ORB trên máy khách sẽ k t n i v i trình ORB trên máy ch (theo giao th cế ố ớ ủ ứ IIOP). Trình ORB trên máy ch chuy n l i g i cho l p trung gian _Skel trênủ ể ờ ọ ớ máy ch . Cu i cùng thì đ i t ng CORBA trên máy ch sẽ th c thi ph ngủ ố ố ượ ủ ự ươ th c c a nó.ứ ủ

Hình 6. Giao ti p gi a m t Client và m t đ i t ng CORBA trên serverế ữ ộ ộ ố ượ

3. Quá trình phát tri n ng d ng s d ng CORBAể ứ ụ ử ụCài đ t các interface (các đ i t ng trên server) d a trên vi c k th aặ ố ượ ự ệ ế ừ

b khung (skeleton) sinh ra b i b d ch IDL.ộ ở ộ ịVi c phát tri n c a phía client b t đ u d a trên m t tham chi uệ ể ủ ắ ầ ự ộ ế

(reference) đ n đ i t ng. Vi c g i các method c a các đ i t ng t xaế ố ượ ệ ọ ủ ố ượ ừ cũng gi ng nh khi g i các ph ng th c c c b .ố ư ọ ươ ứ ụ ộ

Tuy nhiên cũng c n chú ý m t s đi m khi g i ph ng th c t xaầ ộ ố ể ọ ươ ứ ừ  :Th i gian g i ( tính theo ms, 1000 l n ch m h n khi g i c c b ).ờ ọ ầ ậ ơ ọ ụ ộVi c giao ti p gi a client và server sẽ ph i tính đ n các exception ( Cácệ ế ữ ả ế

exception này ph i đ c phía client ch p nh n và x lý).ả ượ ấ ậ ử

Hình 7 : Quá trình phát tri n ng d ng Corba.ể ứ ụ

II. CORBA Servies1. D ch v qu n lý tên COS NAMING c a CORBAị ụ ả ủ

1.1 Tìm hi u v JNDIể ềKhi b n mu n s d ng m t đ i t ng nào đó trong cu c s ng, đ uạ ố ử ụ ộ ố ượ ộ ố ầ

tiên b n c n ph i bi t là n i mà v t đó đang đ c c t gi (hay đ t đ ).ạ ầ ả ế ơ ậ ượ ấ ữ ặ ể Làm th nào đ tìm ra đ i t ng? Làm th nào đ l u l i đ i t ng sauế ể ố ượ ế ể ư ạ ố ượ khi s d ng?… M i đ i t ng trong th gi i th c đ u đ c mang m t tênử ụ ỗ ố ượ ế ớ ự ề ượ ộ g i nh t đ nh. Ít ra hai v t th khác nhau cũng có th phân bi t v i nhauọ ấ ị ậ ể ể ệ ớ qua tên g i (các v t th trùng nhau v tính ch t cũng có th phân bi t quaọ ậ ể ề ấ ể ệ m t đ c tr ng khác bi t nào đó mà trong môi tr ng c s d li u ra v nộ ặ ư ệ ườ ơ ở ữ ệ ẫ quen g i là khóa). M t khác, c n ph i có m t h th ng l u tr nh ng tênọ ặ ầ ả ộ ệ ố ư ữ ữ g i này theo cách nào đó đ khi c n b n có th d a theo tên đ tìm ra đ iọ ể ầ ạ ể ự ể ố t ng th t d dàng.ượ ậ ễ

Khái ni m trên chúng ta g p r t nhi u trong cu c s ng. Nh danhệ ặ ấ ề ộ ố ư b đi n tho i là m t h th ng l u tr tên d a vào s đi n tho i c aạ ệ ạ ộ ệ ố ư ữ ự ố ệ ạ ủ ng i dùng. B n đ là m t h th ng tên g n li n v i các thành ph ,ườ ả ồ ộ ệ ố ắ ề ớ ố đ ng xá. H th ng file là m t d ch v qu n lý tên c a th m c và t p tinườ ệ ố ộ ị ụ ả ủ ư ụ ậ

ORB

Skeleton

Server program

Client program

Java compiler

IDL

compiler

Stub

Object impl

Skeletons

Client prog

Stubs

IDL

defs

trên đĩa, DNS là d ch v g n li n đ a ch IP c a máy tính v i m t tên g iị ụ ắ ề ị ỉ ủ ớ ộ ợ nh nào đó.ớ

M t d ch v qu n lý tên đ u quy đ nh cách th c đ b n l u tr vàộ ị ụ ả ề ị ứ ể ạ ư ữ g n tên cho đ i t ng. Ví d trong danh b đi n tho i b n l u tên g n v iắ ố ượ ụ ạ ệ ạ ạ ư ắ ớ s đi n tho i theo th t ACB. Trên b n đ , tên các thành ph đ ng xáố ệ ạ ứ ự ả ồ ố ườ đ c phân theo qu n huy n. H th ng file th ng l u t p tin và th m cượ ậ ệ ệ ố ườ ư ậ ư ụ theo c u trúc hình cây. V i m i cách l u tr nh v y, d ch v qu n lý tênấ ớ ỗ ư ữ ư ậ ị ụ ả luôn cung c p cho b n cách th c tìm ki m và đ t tên cho đ i t ng c nấ ạ ứ ế ặ ố ượ ầ qu n lý m t cách nh t đ nh.ả ộ ấ ị

T ng quát hóa JAVA đ c t m t t p h p các hàm API dùng đ ph cổ ặ ả ộ ậ ợ ể ụ v cho vi c qu n lý và l u tr tên đ i t ng. Các hàm API này g i là JNDIụ ệ ả ư ữ ố ượ ọ (Java Naming Directory Interface). JNDI cung c p cách đ t tên, l u tr vàấ ặ ư ữ tìm ki m đ i t ng m t cách t ng quát nh t. V i JNDI b n có th g iế ố ượ ộ ổ ấ ớ ạ ể ọ cùng ph ng th c đ tìm ki m t p tin trên h th ng file, th m c, tên đ aươ ứ ể ế ậ ệ ố ư ụ ị ch qua m ng Internet, tên các đ i t ng RMI, CORBA,…JNDI ch đ a raỉ ạ ố ượ ỉ ư các đ c t d ng interface. Các d ch v nào mu n s d ng JNDI thì ph iặ ả ở ạ ị ụ ố ử ụ ả cài đ t giao ti p do Java quy đ nh.ặ ế ị

1.2 JNDI và d ch v COS Naming c a CORBA:ị ụ ủD a vào đ c t JNDI c a Java, Corba xây d ng m t c ch l u trự ặ ả ủ ự ộ ơ ế ư ữ

tên và tham chi u c a đ i t ng.ế ủ ố ượCorba phân ra khái ni m NamingContext và NamingComponentệ

t ng t nh khái ni m file và th m c mà ta v n quen thu c.ươ ự ư ệ ư ụ ẫ ộNamingContext là m t đ i t ng có kh năng d n tham chi u đ nộ ố ượ ả ẫ ế ế

NamingComponent hay NamingContext khác (NamingContext đóng vai trò nh m t th m c). NamingContext đ c đ t tên d a vàoư ộ ư ụ ượ ặ ự NamingComponent.

NamingComponent là m t thành ph n ch a tên (t ng t nhãnộ ầ ứ ươ ự ho c tên file) có kh năng ràng bu c tên v i m t đ i t ng b t kỳ nào đóặ ả ộ ớ ộ ố ượ ấ (đ i t ng này ph i là đ i t ng Corba).ố ượ ả ố ượ

NamingComponent và NamingContext quan h v i nhau theo c uệ ớ ấ trúc hình cây t ng t c u trúc cây th m c c a h th ng file trên đĩa.ươ ự ấ ư ụ ủ ệ ố Hình 10 là m t ví d v cách l u tr c a d ch v COS Naming trong Corba.ộ ụ ề ư ữ ủ ị ụ D ch v này chính là ch ng trình tnameserv.exe mà ta sẽ có d p tìm hi uị ụ ươ ị ể qua khi cài đ t ch ng trình.ặ ươ

Object ANameComponent

Toys

Stock

Market

Hình 8. Mô hình ràng bu c và l u tr đ i t ng c a d ch v COSộ ư ữ ố ượ ủ ị ụ Naming

Nh ta đã th y hình 10, Market là m t đ i t ng NamingContext.ư ấ ở ộ ố ượ Nó cho phép b n tìm ra 3 thành ph n tên: Stock, Shefl và Panel. B n thânạ ầ ả Stock, Shelf là hai NamingContext. Stock ch a 2 thành ph n mang tên Toysứ ầ và Fruit. Shelf ch a m t thành ph n mang tên Book. Đ i t ng Object Aứ ộ ầ ố ượ đ c ràng bu c v i tên Toys trong khi đ i t ng Object B, Object C đ cượ ộ ớ ố ượ ượ ràng bu c b i tên Fruit và Book.ộ ở

M t đ i t ng không ch đ c ràng bu c b i m t tên mà có thộ ố ượ ỉ ượ ộ ở ộ ể nhi u tên. Ví d c Panel và Book cùng ám ch đ n đ i t ng Object C.ề ụ ả ỉ ế ố ượ Đi u này t ng t h nh trong Windows, m t t p tin trên đĩa có th đ cề ươ ự ư ộ ậ ể ượ tham chi u đ n b ng nhi u shortcut hay trong Unix/Linux, m t t p tinế ế ằ ề ộ ậ v t lý có th đ c tham chi u b ng nhi u link khác nhau.ậ ể ượ ế ằ ề

Bây gi ta th hình dung COS Naming là m t cây th m c. N uờ ử ộ ư ụ ế đ ng t Market đ tham chi u đ n đ i t ng Object A ta ph i ch đ ngứ ừ ể ế ế ố ượ ả ỉ ườ d n nh sau: Market\Stock\Toys. Mu n tham chi u đ n Object C, ta chẫ ư ố ế ế ỉ đ ng d n Market\Panel ho c Market\Shelf\Book. Tuy nhiên n u ta đangườ ẫ ặ ế đ ng v trí Stock ta ch c n tham chi u đ n đ i t ng Objetc A theo cáchứ ở ị ỉ ầ ế ế ố ượ Stock\toys là đ . Đó chính là khái ni m ng c nh (context) mà ta sẽ g pủ ệ ữ ả ặ trong d ch v COS Naming c a CORBA. Đ i v i m t đ i t ng, tùy theoị ụ ủ ố ớ ộ ố ượ cntext khác nhau mà ta có th truy xu t theo tên c a đ i t ng khác nhau.ể ấ ủ ố ượ

2. D ch v s u t p (collection service)ị ụ ư ậ cung c p các ph ng ti n đ nhómấ ươ ệ ể

các đ i t ng vào danh sách, hàng đ i, stack, t p h p, ... Ph thu c vào tố ượ ợ ậ ợ ụ ộ ố

ch t t nhiên c a nhóm, mà có r t nhi u c ch truy xu t đ c đ a ra. Víấ ự ủ ấ ề ơ ế ấ ượ ư

d , danh sách có th đ c xem xét kĩ t ng ph n thông qua cái g i là m tụ ể ượ ừ ầ ọ ộ

l p đi l p l i. Cũng có s d dàng trong vi c ch n các đ i t ng b ng cáchặ ặ ạ ự ễ ệ ọ ố ượ ằ

đ c t m t giá tr khóa. V m t b n ch t, d ch v s u t p có v g n v iặ ả ộ ị ề ặ ả ấ ị ụ ư ậ ẻ ầ ớ

cái mà ta g i là các th vi n l p trong các ngôn ng l p trình h ng đ iọ ư ệ ớ ữ ậ ướ ố

t ng.ượ

3. D ch v truy v n (query service)ị ụ ấ cung c p ph ng ti n đ xây d ngấ ươ ệ ể ự

t p h p các đ i t ng mà có th đ c truy v n b ng cách s d ng m tậ ợ ố ượ ể ượ ấ ằ ử ụ ộ

ngôn ng truy v n có khai báo. M t truy v n có th tr v m t thamữ ấ ộ ấ ể ả ề ộ

chi u đ n m t đ i t ng ho c m t t p h p các đ i t ng. D ch v truyế ế ộ ố ượ ặ ộ ậ ợ ố ượ ị ụ

Toys

v n làm tăng lên v i d ch v t p h p b ng các truy v n nâng cao. Nó phânấ ớ ị ụ ậ ợ ằ ấ

bi t v i d ch v s u t p các cung c p sau này v các lo i s u t p khác.ệ ớ ị ụ ư ậ ở ấ ề ạ ư ậ

4. D ch v đi u khi n t ng tranh (concurrency control service)ị ụ ề ể ươ cung

c p các c ch khóa nâng cao mà các client truy xu t vào các đ i t ngấ ơ ế ấ ố ượ

đ c chia s . D ch v này có th đ c dùng đ cài đ t các giao tác đ cượ ẻ ị ụ ể ượ ể ặ ượ

cung c p b i m t d ch v tách bi t. ấ ở ộ ị ụ ệ D ch v giao tác (transactionị ụ

service) cho phép m t client đ nh nghĩa m t chu i các yêu c u ph ngộ ị ộ ỗ ầ ươ

th c thông qua nhi u đ i t ng trong cùng m t giao tác. D ch v này hứ ề ố ượ ộ ị ụ ỗ

tr c lo i giao tác ph ng và l ng nhau.ợ ả ạ ẳ ồ

Thông th ng, client yêu c u các ph ng th c trên các đ i t ng vàườ ầ ươ ứ ố ượ

ch câu tr l i v yêu c u đó. Đ h tr giao ti p không đ ng b , Corbaờ ả ờ ề ầ ể ỗ ợ ế ồ ộ

cung c p ấ d ch v s ki n (event service)ị ụ ự ệ cho phép các client và các đ iố

t ng có th b ng t d a trên s x y ra c a m t s ki n c th . Cácượ ể ị ắ ự ự ả ủ ộ ự ệ ụ ể

ph ng ti n nâng cao cho giao ti p không đ ng b đ c cung c p b iươ ệ ế ồ ộ ượ ấ ở

d ch v khai báo (notification service)ị ụ . Chúng ta sẽ mô t các d ch vả ị ụ

này m t cách chi ti t ph n sau.ộ ế ở ầ

S ngo i hi n (Externalization)ự ạ ệ liên quan đ n vi c đóng gói các đ iế ệ ố

t ng theo cách mà chúng ta có th đ c l u tr trên đĩa hay đ c l uượ ể ượ ư ữ ượ ư

tr qua m ng. Nó có th đ c so sánh v i tính năng ữ ạ ể ượ ớ serialization đ cượ

cung c p b i Java, cho phép đ i t ng đ c ghi vào m t lu ng d li uấ ở ố ượ ượ ộ ồ ữ ệ

(data stream) nh là m t chu i các bytes.ư ộ ỗ

5. D ch v vòng đ i (life cycle service)ị ụ ờ cung c p các ph ng ti n đ t o,ấ ươ ệ ể ạ

phá h y, sao chép và di chuy n đ i t ng. M t khái ni m khóa là ủ ể ố ượ ộ ệ đ iố

t ng s n xu t (factory object)ượ ả ấ , đó là m t đ i t ng đ c bi t đ cộ ố ượ ặ ệ ượ

dùng đ t o ra các đ i t ng khác. Th c t ch ra r ng ch có s t o ra cácể ạ ố ượ ự ế ỉ ằ ỉ ự ạ

đ i t ng m i c n đ c đi u khi n b i m t d ch v tách bi t. Tuy nhiênố ượ ớ ầ ượ ề ể ở ộ ị ụ ệ

vi c phá h y, sao chép và di chuy n đ i t ng th ng đ c đ nh nghĩaệ ủ ể ố ượ ườ ượ ị

m t cách thu n ti n b i chính các đ i t ng đó. Lý do là các thao tác nàyộ ậ ệ ở ố ượ

th ng nh h ng đ n tr ng thái c a đ i t ng thoeo m t cách đ c tườ ả ưở ế ạ ủ ố ượ ộ ặ ả

đ i t ng nào đó.ố ượ

D ch vị ụ Mô tả

Collection Các ph ng ti n cho vi c nhóm các đ iươ ệ ệ ố t ng vào danh sách, hàng đ i, t p h p, …ượ ợ ậ ợ

Query Các ph ng ti n cho vi c truy v n t pươ ệ ệ ấ ậ các đ i t ng theo cách có khai báoố ượ

Concurrency

Các ph ng ti n cho phép truy xu t đ ngươ ệ ấ ồ th i đ n các đ i t ng đ c chia sờ ế ố ượ ượ ẻ

Transaction

Các giao tác b ng ph ng và l ng nhauằ ẳ ồ trên các ph ng th c g i qua nhi u đ iươ ứ ọ ề ố t ngượ

Event Các ph ng ti n cho vi c giao ti p khôngươ ệ ệ ế đ ng b thông qua các s ki nồ ộ ự ệ

Notification

Các ph ng ti n nâng cao cho vi c giaoươ ệ ệ ti p không đ ng b d a trên s ki nế ồ ộ ự ự ệ

Externalization

Các ph ng ti n cho vi c đóng gói vàươ ệ ệ tách bóc các đ i t ngố ượ

Life cycle Các ph ng ti n cho vi c t o, xóa, saoươ ệ ệ ạ chép, và di chuy n các đ i t ngể ố ượ

Licensing Các ph ng ti n cho vi c g n license vàoươ ệ ệ ắ cho đ i t ngố ượ

Naming Các ph ng ti n cho vi c đ nh danh đ iươ ệ ệ ị ố t ng trên toàn h th ngượ ệ ố

Property Các ph ng ti n cho vi c đính kèm c pươ ệ ệ ặ (thu c tính, giá tr ) vào đ i t ngộ ị ố ượ

Trading Các ph ng ti n cho vi c xu t b n và tìmươ ệ ệ ấ ả ki m các d ch v mà m t đ i t ng ph iế ị ụ ộ ố ượ ả cung c pấ

Persistence

Các ph ng ti n cho vi c l u tr 1 cáchươ ệ ệ ư ữ b n v ng các đ i t ngề ữ ố ượ

Relationship

Các ph ng ti n cho vi c bi u di n m iươ ệ ệ ể ễ ố quan h gi a các đ i t ngệ ữ ố ượ

Security Các c ch cho các kênh an toàn, phânơ ế quy n, ki m đ nhề ể ị

Time Cung c p th i gian hi n t i bên trong cácấ ờ ệ ạ l l i đ c đ c tề ỗ ượ ặ ả

Hình 9. T ng quan các d ch v c a Corbaổ ị ụ ủ

6. D ch v license (licensing service)ị ụ cho phép nhà cung c p các đ i t ngấ ố ượ

g n m t license vào đ i t ng c a h và làm cho có hi u l c m t chínhắ ộ ố ượ ủ ọ ệ ự ộ

sách license c th . M t license bi u th các quy n mà m t client ph i cóụ ể ộ ể ị ề ộ ả

đ có th s d ng đ i t ng. Ví d , m t license đ c g n vào m t đ iể ể ử ụ ố ượ ụ ộ ượ ắ ộ ố

t ng có th làm cho có hi u l c r ng đ i t ng đó ch có th đ c dùngượ ể ệ ự ằ ố ượ ỉ ể ượ

b i m t ng i dùng t i m i th i đi m. License khác có th ch c ch nở ộ ườ ạ ọ ờ ể ể ắ ắ

r ng m t đ i t ng sẽ b vô hi u hóa sau m t kho ng th i gian quá h nằ ộ ố ượ ị ệ ộ ả ờ ạ

nào đó.

Corba cũng cung c p m t d ch v g i là ấ ộ ị ụ ọ d ch v đ nh danh (namingị ụ ị

service) cho phép m t đ i t ng có th đ c g n v i m t tên có th đ cộ ố ượ ể ượ ắ ớ ộ ể ọ

đ c và ánh x v i ID c a đ i t ng đó. Ph ng ti n c b n cho vi c môượ ạ ớ ủ ố ượ ươ ệ ơ ả ệ

t đ i t ng đ c cung c p b i ả ố ượ ượ ấ ở d ch v thu c tính (property service)ị ụ ộ .

D ch v này cho phép client k t h p c p (thu c tính, giá tr ) v i các đ iị ụ ế ợ ặ ộ ị ớ ố

t ng. L u ý r ng các thu c tính này không ph i là m t ph n c a tr ngượ ư ằ ộ ả ộ ầ ủ ạ

thái đ i t ng, nh ng thay vào đó chúng đ c dùng đ mô t đ i t ng.ố ượ ư ượ ể ả ố ượ

Nói cách khác, chúng cung c p thông tin v đ i t ng thay vì m t ph nấ ề ố ượ ộ ầ

c a đ i t ng. Liên quan đ n hai d ch v này là ủ ố ượ ế ị ụ d ch v th ng m iị ụ ươ ạ

(trading service) cho phép các đ i t ng thông báo nh ng gì mà chúngố ượ ữ

ph i cung c p (thông qua giao di n c a chúng), và cho phép các client tìmả ấ ệ ủ

ki m các d ch v b ng cách s d ng m t ngôn ng đ c bi t h tr mô tế ị ụ ằ ử ụ ộ ữ ặ ệ ỗ ợ ả

các ràng bu c.ộ

7. D ch v b n v ng (persistence service)ị ụ ề ữ cung c p các ph ng ti n choấ ươ ệ

vi c l u tr thông tin trên đĩa d i d ng các đ i t ng l u tr . M t v nệ ư ữ ướ ạ ố ượ ư ữ ộ ấ

đ quan tr ng đây là s trong su t b n v ng (persistence transprency)ề ọ ở ự ố ề ữ

đ c cung c p. M t client không c n ph i truy n d li u m t cách rõượ ấ ộ ầ ả ề ữ ệ ộ

ràng vào m t đ i t ng l u tr gi a m t đĩa và b nh chính s n có.ộ ố ượ ư ữ ữ ộ ổ ộ ớ ẵ

Không m t d ch v nào trong các d ch v trên cung c p các ph ngộ ị ụ ị ụ ấ ươ

ti n có liên quan m t cách rõ ràng đ n hai hay nhi u l p đ i t ng.ệ ộ ế ề ớ ố ượ

Nh ng ph ng ti n này đ c cung c p b i ữ ươ ệ ượ ấ ở d ch v m i quan hị ụ ố ệ

(relationship service), d ch v này h tr cho vi c t ch c các đ i t ngị ụ ỗ ợ ệ ổ ứ ố ượ

tùy thu c vào l c đ khái ni m nh đ c dùng trong c s d li u.ộ ượ ồ ệ ư ượ ơ ở ữ ệ

Tính b o m t đ c cung c p b i ả ậ ượ ấ ở d ch v b o m t (securityị ụ ả ậ

service). Vi c cài đ t d ch v này có th so sánh v i các h th ng b o m tệ ặ ị ụ ể ớ ệ ố ả ậ

Sesame và Kerberos. D ch v b o m t c a Corba cung c p các ph ngị ụ ả ậ ủ ấ ươ

ti n cho vi c xác nh n, c p quy n, ki m đ nh, giao ti p an toàn, s ch pệ ệ ậ ấ ề ể ị ế ự ấ

hành và v n đ qu n tr . Chúng ta sẽ quay tr l i v n đ này m t cách chiấ ề ả ị ở ạ ấ ề ộ

ti t ph n sau.ế ở ầ

Cu i cùng, Corba cung c p ố ấ d ch v th i gian (time service)ị ụ ờ cho phép

tr v th i gian hi n t i trong các vùng l i c th .ả ề ờ ệ ạ ỗ ụ ể

Nh gi i thích b i Pope (1998), các d ch v Corba đ c thi t k v iư ả ở ị ụ ượ ế ế ớ

mô hình đ i t ng c a Corba nh là c s c a chúng. Đi u này nghĩa làố ượ ủ ư ơ ở ủ ề

t t c các d ch v đ c đ c t b ng IDL và có m t s tách bi t gi a đ c tấ ả ị ụ ượ ặ ả ằ ộ ự ệ ữ ặ ả

giao di n và đ c t cài đ t đ c t o ra. M t nguyên lý thi t k quan tr ngệ ặ ả ặ ượ ạ ộ ế ế ọ

khác là các d ch v nên đ c t i thi u và đ n gi n hóa. Trong các ph nị ụ ượ ố ể ơ ả ầ

ti p theo chúng ta sẽ th o lu n chi ti t h n v m t s d ch v .ế ả ậ ế ơ ề ộ ố ị ụ

8. D ch v s ki n và d ch v khai báo (Event and Notification Services)ị ụ ự ệ ị ụ

M c dù các mô hình yêu c u đ c cung c p b i Corba th ng th aặ ầ ượ ấ ở ườ ỏ

mãn h u h t các yêu c u giao ti p trong m t h th ng phân tán h ngầ ế ầ ế ộ ệ ố ướ

đ i t ng, nh ng d ng nh ch có các yêu c u ph ng th c là không đ .ố ượ ư ườ ư ỉ ầ ươ ứ ủ

Trong các tr ng h p c th , c n thi t ph i cung c p m t d ch v có thườ ợ ụ ể ầ ế ả ấ ộ ị ụ ể

truy n tín hi u m t cách đ n gi n v s x y ra c a m t s ki n. Clientề ệ ộ ơ ả ề ự ả ủ ộ ự ệ

ch u trách nhi m r ng s ki n có th d n đ n các hành đ ng thích h p.ị ệ ằ ự ệ ể ẫ ế ộ ợ

K t qu là vi c đ nh nghĩa d ch v s ki n. Mô hình c b n c a các sế ả ệ ị ị ụ ự ệ ơ ả ủ ự

ki n trong Corba là khá đ n gi n. M i s ki n đ c kèm theo v i m tệ ơ ả ỗ ự ệ ượ ớ ộ

m c d li u, th ng đ c bi u di n b i m t tham chi u đ i t ng hayụ ữ ệ ườ ượ ể ễ ở ộ ế ố ượ

m t giá tr ng d ng c th . M t s ki n đ c sinh ra b i m t đ i t ngộ ị ứ ụ ụ ể ộ ự ệ ượ ở ộ ố ượ

cung c p (supplier) và đ c nh n b i m t đ i t ng tiêu dùngấ ượ ậ ở ộ ố ượ

(consumer). Các s ki n đ c truy n qua m t kênh s ki n (eventự ệ ượ ề ộ ự ệ

channel), mà v m t logic thì nó đ c đ t gi a supplier và consumerề ặ ượ ặ ở ữ

nh trong Hình 10.ư

Hình 10. T ch c các supplier và consumer c a các s ki n theo môổ ứ ủ ự ệ

hình ki u đ yể ẩ

Hình 10 mô t cái g i là mô hình đ y (push model). Trong mô hìnhả ọ ẩ

này, khi m t s ki n x y ra, supplier sinh ra s ki n và đ y nó thông quaộ ự ệ ả ự ệ ẩ

kênh s ki n, và chuy n s ki n đ n consumer. Mô hình đ y g n v iự ệ ể ự ệ ế ẩ ầ ớ

hành vi không đ ng b mà h u h t m i ng i t ng tác v i s ki n. Vồ ộ ầ ế ọ ườ ươ ớ ự ệ ề

m t hi u qu , consumer ph i ch đ i s lan truy n s ki n m t cách bặ ệ ả ả ờ ợ ự ề ự ệ ộ ị

đ ng, và mong đ i đó có th b ng t b ng cách này hay cách khác khi m tộ ợ ể ị ắ ằ ộ

s ki n x y ra.ự ệ ả

M t mô hình khác cũng đ c h tr b i Corba, là mô hình kéo (pullộ ượ ỗ ợ ở

model) nh trong Hình 11. Trong mô hình này consumer thăm dò kênh sư ự

ki n đ ki m tra khi nào thì m t s ki n sẽ x y ra. Kênh s ki n theo đóệ ể ể ộ ự ệ ả ự ệ

sẽ thăm dò đ n các supplier khác nhau.ế

Hình 11. Mô hình ki u đ y cho vi c truy n s ki n trong Corbaể ẩ ệ ề ự ệ

M c dù d ch v s ki n cung c p m t cách đ n gi n và tr c di n choặ ị ụ ự ệ ấ ộ ơ ả ự ệ

vi c lan truy n s ki n, nh ng nó có m t s các m t h n ch nghiêmệ ề ự ệ ư ộ ố ặ ạ ế

tr ng. Đ truy n s ki n, đi u ki n c n là các consumer và supplier ph iọ ể ề ự ệ ề ệ ầ ả

k t n i v i nhau thông qua kênh s ki n. Đi u này nghĩa là khi m tế ố ớ ự ệ ề ộ

consumer k t n i đ n kênh s ki n sau khi m t s ki n đã x y ra thì khiế ố ế ự ệ ộ ự ệ ả

đó s ki n đó sẽ b b qua. Nói cách khác d ch v s ki n c a Corba khôngự ệ ị ỏ ị ụ ự ệ ủ

h tr s b n v ng cho các s ki n.ỗ ợ ự ề ữ ự ệ

Nghiêm tr ng h n là các consumer có r t ít ph ng ti n đ l c các sọ ơ ấ ươ ệ ể ọ ự

ki n. M i s ki n v nguyên t c sẽ đ c chuy n cho t t c các consumer.ệ ỗ ự ệ ề ắ ượ ể ấ ả

N u các lo i s ki n khác nhau c n đ c phân bi t, thì khi đó c n thi tế ạ ự ệ ầ ượ ệ ầ ế

ph i cài đ t m t kênh s ki n tách bi t cho m i lo i s ki n. Kh năngả ặ ộ ự ệ ệ ỗ ạ ự ệ ả

l c đ c thêm vào trong m t ph n m r ng đ c g i là d ch v khai báo.ọ ượ ộ ầ ở ộ ượ ọ ị ụ

Thêm vào đó, d ch v này còn cung c p các ph ng ti n giúp tránh vi cị ụ ấ ươ ệ ệ

ph i truy n s ki n khi không có consumer nào quan tâm s ki n đó.ả ề ự ệ ự ệ

Cu i cùng vi c truy n s ki n v n là không đáng tin c y. Đ c t c aố ệ ề ự ệ ố ậ ặ ả ủ

Corba phát bi u r ng không có s đ m b o nào liên quan đ n vi c truy nể ằ ự ả ả ế ệ ề

các s ki n.ự ệ

Nh chúng ta sẽ th o lu n trong Ch ng 12, vi c các ng d ng có khư ả ậ ươ ệ ứ ụ ả

năng truy n s ki n m t cách đáng tin c y là r t quan tr ng. Nh ng ngề ự ệ ộ ậ ấ ọ ữ ứ

d ng nh v y không nên s d ng d ch v s ki n c a Corba mà nên dùngụ ư ậ ử ụ ị ụ ự ệ ủ

đ n các ph ng ti n khác v giao ti p.ế ươ ệ ề ế

9. Thông báo (Messaging)

M i giao ti p trong Corba đ c mô t t tr c t i gi là t m th iọ ế ượ ả ừ ướ ớ ờ ạ ờ

(transient). Nghĩa là m t thông đi p ch đ c l u tr bên d i h th ngộ ệ ỉ ượ ư ữ ướ ệ ố

giao ti p cho đ n khi c đ i t ng g i (sender) và đ i t ng nh nế ế ả ố ượ ử ố ượ ậ

(receiver) c a nó b t đ u làm vi c. Nh ta đã th o lu n Ch ng 2, cóủ ắ ầ ệ ư ả ậ ở ươ

nhi u ng d ng đòi h i ki u giao ti p b n v ng vì v y m t thông báo sẽề ứ ụ ỏ ể ế ề ữ ậ ộ

đ c l u tr cho đ n khi nó có th đ c truy n đi. V i ki u giao ti p b nượ ư ữ ế ể ượ ề ớ ể ế ề

v ng, sẽ không có v n đ gì khi đ i t ng g i (sender) ho c đ i t ngữ ấ ề ố ượ ử ặ ố ượ

nh n (receiver) th c thi sau khi thông đi p đã đ c g i đi; trong m iậ ự ệ ượ ở ọ

tr ng h p, thông báo sẽ đ c l u tr đ lâu n u c n.ườ ợ ượ ư ữ ủ ế ầ

M t mô hình giao ti p ki u b n v ng n i ti ng là mô hình thông báoộ ế ể ề ữ ổ ế

ki u hàng đ i (message – queuing model). Corba h tr mô hình này nhể ợ ỗ ợ ư

là m t d ch v ph tr i g i là d ch v thông báo. Đi u làm cho vi c thôngộ ị ụ ụ ộ ọ ị ụ ề ệ

báo trong Corba khác v i các h th ng khác là cách ti p c n vi c giao ti pớ ệ ố ế ậ ệ ế

theo ki u th a k d a trên đ i t ng c a nó. C th , ng i thi t k d chể ừ ế ự ố ươ ủ ụ ể ườ ế ế ị

v thông báo c n thi t ph i gi l i mô hình sao cho m i giao ti p sẽ x yụ ầ ế ả ữ ạ ọ ế ả

ra b i vi c yêu c u m t đ i t ng. V i tr ng h p c a thông báo, ki uở ệ ầ ộ ố ượ ớ ườ ợ ủ ể

thi t k này ràng bu c k t qu vào trong hai hình th c c a vi c yêu c uế ế ộ ế ả ứ ủ ệ ầ

ph ng th c không đ ng b .ươ ứ ồ ộ

Trong mô hình g i l i (callback), client cung c p đ i t ng đ c càiọ ạ ấ ố ượ ượ

đ t giao di n ch a đ ng các ph ng th c callback. Các ph ng th c nàyặ ệ ứ ự ươ ứ ươ ứ

có th đ c g i b i h th ng giao ti p bên d i đ chuy n k t qu choể ượ ọ ở ệ ố ế ướ ể ể ế ả

m t yêu c u không đ ng b . M t v n đ quan tr ng khi thi t k là nh ngộ ầ ồ ộ ộ ấ ề ọ ế ế ữ

yêu c u ph ng th c không đ ng b không nh h ng cài đ t g c c aầ ươ ứ ồ ộ ả ưở ặ ố ủ

đ i t ng. Nói cách khác, đó là nhi m v c a client trong vi c chuy n đ iố ượ ệ ụ ủ ệ ể ổ

m t yêu c u đ ng b g c thành m t yêu c u không đ ng b , server đ cộ ầ ồ ộ ố ộ ầ ồ ộ ượ

b n v ng m t yêu c u đ ng b bình th ng.ề ữ ộ ầ ồ ộ ườ

Vi c xây d ng m t yêu c u không đ ng b đ c th c hi n trong haiệ ự ộ ầ ồ ộ ượ ự ệ

b c. Đ u tiên, giao di n g c đ c cài đ t b i đ i t ng đ c thay thướ ầ ệ ố ượ ặ ở ố ượ ượ ế

b i hai giao di n m i mà chúng ch đ c cài đ t b i ph n m m phíaở ệ ớ ỉ ượ ặ ở ầ ề

client. M t giao di n ch a đ ng đ c t c a các ph ng th c mà client cóộ ệ ứ ự ặ ả ủ ươ ứ

th g i. Các ph ng th c này không tr v giá tr cũng không có b t cể ọ ươ ứ ả ề ị ấ ứ

tham s đ u ra nào. Giao di n còn l i g i là giao di n g i l i (callback).ố ầ ệ ạ ọ ệ ọ ạ

V i m i thao tác trong giao di n g c, nó bao g m m t ph ng th c sẽớ ỗ ệ ố ồ ộ ươ ứ

đ c tri u g i b i trình ORB c a client và chuy n k t qu c a ph ngượ ệ ọ ở ủ ể ế ả ủ ươ

th c k t h p đ c g i b i client.ứ ế ợ ượ ọ ở

Ví d , xét m t đ i t ng đ c cài đ t giao di n v i ch m t ph ngụ ộ ố ượ ượ ặ ệ ớ ỉ ộ ươ

th c:ứ

int add(in int i, in int j, out int k);

Gi s r ng ph ng th c này (đ c chúng ta cài đ t b ng Corba IDL)ả ử ằ ươ ứ ượ ặ ằ

nh n hai giá tr không âm ki u integer là i và j và tr v i+j qua tham sậ ị ể ả ề ố

đ u ra k. Thao tác này sẽ tr v giá tr -1 n u nó không th c hi n thànhầ ả ề ị ế ự ệ

công. Vi c chuy n đ i yêu c u ph ng th c đ ng b g c thành m t yêuệ ể ổ ầ ươ ứ ồ ộ ố ộ

c u không đ ng b v i các g i l i đ t đ c b i vi c sinh ra tr c tiên bầ ồ ộ ớ ọ ạ ạ ượ ở ệ ướ ộ

đ c t ph ng th c (v i m c đích c a chúng ta, ta ch n các tên thu nặ ả ươ ứ ớ ụ ủ ọ ậ

ti n thay vì ph i tuân theo các qui t c nghiêm ng t đ c đ c t trongệ ả ắ ặ ượ ặ ả

OMG, 2001b):

Void sendcb_add(in int i ,in int j); // đ c g i b i client ượ ọ ở

Void reply_add(in int ret_val ,in int k); // đ c g i b i ORB c a client ượ ọ ở ủ

V m t hi u qu , t t c tham s đ u ra t đ c t ph ng th c g cề ặ ệ ả ấ ả ố ầ ừ ặ ả ươ ứ ố

đ c lo i b kh i ph ng th c đ c g i b i client, và đ c tr v nh làượ ạ ỏ ỏ ươ ứ ượ ọ ở ượ ả ề ư

các tham s đ u vào c a các thao tác g i l i. T ng t nh th n uố ầ ủ ọ ạ ươ ự ư ế ế

ph ng th c g c đ c t m t giá tr tr v thì giá tr đó đ c chuy nươ ứ ố ặ ả ộ ị ả ề ị ượ ể

thành m t tham s đ u vào cho thao tác callback.ộ ố ầ

B c k ti p bao g m vi c biên d ch đ sinh ra các giao di n. K t quướ ế ế ồ ệ ị ể ệ ế ả

là client đ c cung c p m t m u (stub) cho phép nó yêu c u m t cáchượ ấ ộ ẩ ầ ộ

không đ ng b đ n sendcb_add. Tuy nhiên client sẽ c n ph i cung c pồ ộ ế ầ ả ấ

m t cài đ t cho giao di n callback; trong ví d c a chúng ta là ph ngộ ặ ệ ụ ủ ươ

th c replycb_add. L u ý r ng nh ng thay đ i này không nh h ng đ nứ ư ằ ữ ổ ả ưở ế

vi c cài đ t đ i t ng phía server. S d ng ví d này, mô hình g i l iệ ặ ố ượ ở ử ụ ụ ọ ạ

(callback) đ c tóm l i hình 12ượ ạ ở

Hình 12. Mô hình g i l i (callback)ọ ạ

Nh là m t thay th cho vi c callback, Corba cung c p m t mô hìnhư ộ ế ệ ấ ộ

g i là ki m soát vòng (polling). Trong mô hình này, client đ c cung c pọ ể ượ ấ

m t b các thao tác đ thăm dò ý ki n (poll) trình ORB c a nó cho các k tộ ộ ể ế ủ ế

qu đ n. Nh trong mô hình callback, client ch u trách nhi m trong vi cả ế ư ị ệ ệ

chuy n đ i các yêu c u ph ng th c đ ng b g c thành d ng không đ ngể ổ ầ ươ ứ ồ ộ ố ạ ồ

b . M t l n n a, h u h t công vi c có th đ c th c hi n b ng cáchộ ộ ầ ữ ầ ế ệ ể ượ ự ệ ằ

chuy n đ i m t cách t đ ng các đ c t ph ng th c thích h p t giaoể ổ ộ ự ộ ặ ả ươ ứ ợ ừ

di n g c đ c cài đ t b i đ i t ng.ệ ố ượ ặ ở ố ượ

Quay tr l i ví d c a chúng ta, ph ng th c add sẽ đ c chuy nở ạ ụ ủ ươ ứ ượ ể

thành hai đ c t ph ng th c đ c sinh ra nh sau:ặ ả ươ ứ ượ ư

Void sendpoll_add(in int i ,in int j); // đ c g i b i client ượ ọ ở

Void replypoll_add(out int ret_val ,out int k); // cũng đ c g i b iượ ọ ở

client

S khác bi t l n nh t so v i mô hình callback là ph ng th cự ệ ớ ấ ớ ươ ứ

replypoll_add sẽ ph i đ c cài đ t b i trình ORB c a client. S cài đ t nàyả ượ ặ ở ủ ự ặ

có th đ c sinh ra m t cách t đ ng b i trình biên d ch IDL. Mô hình vi cể ượ ộ ự ộ ở ị ệ

b phi u (polling) đ c tóm t t trong hình 8. M t l n n a, l u ý r ng càiỏ ế ượ ắ ộ ầ ữ ư ằ

đ t g c c a đ i t ng nh đã xu t hi n phía server không c n ph iặ ố ủ ố ượ ư ấ ệ ở ầ ả

thay đ i.ổ

Hình 13. Mô hình ki m soát vòng (polling)ể

Cái còn thi u trong các mô hình đã đ c mô t là vi c các thông báoế ượ ả ệ

đ c g i gi a client và server bao g m h i đáp cho m t yêu c u khôngượ ử ữ ồ ỏ ộ ầ

đ ng b ; đ c l u tr h th ng bên d i trong tr ng h p client ho cồ ộ ượ ư ữ ở ệ ố ướ ườ ợ ặ

server ch a kh i ch y. May m n thay, h u h t các v n đ liên quan đ nư ở ạ ắ ầ ế ấ ề ế

giao ti p b n v ng nh v y không làm nh h ng đ n mô hình yêu c uế ề ữ ư ậ ả ưở ế ầ

d ng không đ ng b đã th o lu n tr c đó. Đi u c n thi t là cài đ t m tạ ồ ộ ả ậ ướ ề ầ ế ặ ộ

t p các server message đ có th cho phép các messages đ c l u tr t mậ ể ể ượ ư ữ ạ

th i cho đ n khi chúng đ c truy n đi. H ng gi i quy t đ c đ xu tờ ế ượ ề ướ ả ế ượ ề ấ

trong (OMG, 2001b) là t ng t v i h th ng message hàng đ i c a IBMươ ự ớ ệ ố ợ ủ

mà chúng ta đã th o lu n 2.4.4.ả ậ ở

10.Kh năng t ng k t (Interoperability)ả ươ ế

Các phiên b n tr c c a Corba b qua m t s v n đ cho vi c cài đ tả ướ ủ ỏ ộ ố ấ ề ệ ặ

th t s . K t qu là h th ng Corba c a m i nhà s n xu t s h u riêng choậ ự ế ả ệ ố ủ ỗ ả ấ ở ữ

mình m t cách th c hi n vi c giao ti p gi a client và server. C th là chộ ự ệ ệ ế ữ ụ ể ỉ

khi client và server cùng dùng m t trình ORB thì khi đó client m i có thộ ớ ể

yêu c u đ i t ng t server.ầ ố ượ ừ

Vi c thi u h t kh năng t ng k t (Interoperability) đã đ c gi iệ ế ụ ả ươ ế ượ ả

quy t b ng vi c gi i thi u m t giao th c inter-ORB chu n; trong vi c tế ằ ệ ớ ệ ộ ứ ẩ ệ ổ

h p m t cách hình th c vi c tham chi u các đ i t ng. Tr l i hình 2, taợ ộ ứ ệ ế ố ượ ở ạ

th y giao ti p này ch ra có m t giao th c chu n gi a client và server màấ ế ỉ ộ ứ ẩ ữ

trong Corba đ c g i là giao th c General Inter-ORB Protocol (GIOP).ượ ọ ứ

GIOP th c s là m t khung cho m t giao th c, nó gi s r ng m t sự ự ộ ộ ứ ả ử ằ ộ ự

cài đ t th c t đ c th c hi n trên m t giao th c v n chuy n đã t n t i.ặ ự ế ượ ự ệ ộ ứ ậ ể ồ ạ

Giao th c v n chuy n đó ph i đáng tin c y h ng k t n i (connection-ứ ậ ể ả ậ ướ ế ố

oriented) và cung c p khái ni m c a dòng byte (byte stream), cùng v iấ ệ ủ ớ

m t s các tính năng khác. Không ng c nhiên khi mà TCP th a mãn các yêuộ ố ạ ỏ

c u này, nh ng m t s giao th c v n chuy n khác cũng th a mãn đi uầ ư ộ ố ứ ậ ể ỏ ề

này.

Vi c cài đ t GIOP ch y trên TCP đ c g i là Internet Inter_ORBệ ặ ạ ượ ọ

Protocol hay đ n gi n là IIOP.ơ ả

GIOP (và IIOP hay b t c cài đ t nào c a GIOP), nh n bi t đ c ki uấ ứ ặ ủ ậ ế ượ ể

thông báo khác nhau, ch ra trong Hình 14. Hai ki u thông báo quan tr ngỉ ể ọ

nh t là Request và Reply, là các hình th c tham gia chính vào trong cài đ tấ ứ ặ

th c t c a m t yêu c u ph ng th c t xa.ự ế ủ ộ ầ ươ ứ ừ

M t message request bao g m toàn b , m t yêu c u đã đ c đóng gói,ộ ồ ộ ộ ầ ượ

bao g m m t tham chi u đ i t ng, tên c a ph ng th c đ c yêu c u,ồ ộ ế ố ượ ủ ươ ứ ượ ầ

và t t c các tham s đ u vào c n thi t. Tham chi u đ i t ng và tênấ ả ố ầ ầ ế ế ố ượ

ph ng th c là các thành ph n c a tiêu đ (header). M i message requestươ ứ ầ ủ ề ỗ

còn có m t ID yêu c u c a nó, đ c dùng đ đ i chi u sau này khi câu trộ ầ ủ ượ ể ố ế ả

l i t ng ng đ c tr v .ờ ươ ứ ượ ả ề

M t message reply bao g m giá tr tr v đã đ c đóng gói và cácộ ồ ị ả ề ượ

tham s đ u ra k t h p v i ph ng th c đ c yêu c u tr c đó. Khôngố ầ ế ợ ớ ươ ứ ượ ầ ướ

c n ph i nh n bi t m t cách rõ ràng đ i t ng hay ph ng th c; đ nầ ả ậ ế ộ ố ượ ươ ứ ơ

gi n là tr v cùng ID yêu c u nh đã dùng t ng ng trong messageả ả ề ầ ư ươ ứ

request là đ :ủ

Ki uể message

Niơ

g iử

Mô tả

Request

Client

Ch a đ ng yêu c uứ ự ầ

Reply Server

Ch a đ ng h i đáp choứ ự ồ m t yêu c uộ ầ

Locate request

Client

Ch a đ ng v đ i t ngứ ự ề ố ượ m t v trí chính xácở ộ ị

Locate reply

Server

Ch a đ ng thông tin vứ ự ị trí c a m t đ i t ngủ ộ ố ượ

Cancel request

Client

Ch ra client không c nỉ ầ câu tr l i n aả ờ ữ

Close connection

Both

Ch ra k t n i sẽ b đóngỉ ế ố ị

Message error

Both

Ch a đ ng thông tin vứ ự ề l iỗ

Fragment

Both

Ph n c a m t messageầ ủ ộ l n h nớ ơ

Hình 14. Các ki u message c a GIOPể ủ

Nh chúng ta th o lu n sau đây, m t client có th yêu c u m t kho càiư ả ậ ộ ể ầ ộ

đ t cung c p các chi ti t v n i mà m t đ i t ng c th có th đ c tìmặ ấ ế ề ơ ộ ố ượ ụ ể ể ượ

th y. ấ M t yêu c u nh v y đ c g i b i Message Locate Request . Kho càiộ ầ ư ậ ượ ử ở

đ t sẽ tr l i b ng m t Message Locate Reply, th ng đ nh n bi t đ cặ ả ờ ằ ộ ườ ể ậ ế ượ

server hi n t i c a đ i t ng mà yêu c u đó có th đ c g i.ệ ạ ủ ố ượ ầ ể ượ ử

Message Cancel Request có th đ c g i b i m t client đ n server khiể ượ ử ở ộ ế

client mu n h y m t message request ho c locate request đã g i tr cố ủ ộ ặ ử ướ

đó. H y b m t yêu c u nghĩa là client không còn s n sàng đón nh n câuủ ỏ ộ ầ ẵ ậ

tr l i t server n a. Có nhi u lý do khác nhau cho vi c m t client mu nả ờ ừ ữ ề ệ ộ ố

h y b câu tr l i cho m t yêu c u, nh ng thu ng là do Time Out t o ngủ ỏ ả ờ ộ ầ ư ờ ạ ứ

d ng c a client. Th t quan tr ng khi ph i l u ý r ng h y b m t yêu c uụ ủ ậ ọ ả ư ằ ủ ỏ ộ ầ

sẽ không đ a đ n r ng yêu c u k t h p sẽ không b k t thúc. Tráchư ế ằ ầ ế ợ ị ế

nhi m c a ng d ng client là ph iđ i phó trong tình hu ng này.ệ ủ ứ ụ ả ố ố

Trong giao th c GIOP, client luôn luôn thi t l p m t k t n i đ n m tứ ế ậ ộ ế ố ế ộ

server. Server đ c mong đ i sẽ ch p nh n ho c t ch i các yêu c u k tượ ợ ấ ậ ặ ừ ố ầ ế

n i đ n, nh ng sẽ không t nó thi t l p các k t n i đ n client. Tuy nhiên,ố ế ư ự ế ậ ế ố ế

c client và server đ u có qu n đ đóng k t n i b ng vi c chúng có thả ề ề ể ế ố ằ ệ ể

g i message CloseCconnection đ n đ i tác k t n i.ử ế ố ế ố

N u l i x y ra, đ i tác sẽ nh c nh b ng cách g i m t message cóế ỗ ả ố ắ ở ằ ử ộ

ki u Message Error. M t message nh v y bao g m tiêu đ (header) c aể ộ ư ậ ồ ề ủ

message sinh ra l i. Cách ti p c n này t ng t nh message ICMP trongỗ ế ậ ươ ự ư

giao th c Internet th ng đ c dùng đ tr v thông tin l i khi có đi u gìứ ườ ượ ể ả ề ỗ ề

sai sót. Trong tr ng h p này tiêu đ (header) c a gói ID sinh ra l i đ cườ ợ ề ủ ỗ ượ

g i đi nh là d li u trong message ICMP.ử ư ữ ệ

Cu i cùng, GIOP cũng cho phép các message request và reply có thố ể

đ c phân m nh. B ng cách này, các yêu c u có nhi u d li u đ cượ ả ằ ầ ề ữ ệ ượ

chuy n gi a client và server có th đ c h tr m t cách d dàng. Cácể ữ ể ượ ỗ ợ ộ ễ

m nh đ c g i b ng message Frament b ng cách nh n bi t message g cả ượ ử ằ ằ ậ ế ố

và cho phép ghép l i message đó phía receiver.ạ ở

11.Đ ng b hóa (Synchronization)ồ ộ

Hai d ch v quan tr ng nh t cho phép t o s đ ng b trong Corba làị ụ ọ ấ ạ ự ồ ộ

d ch v qu n lý đ ng th i và d ch v giao tác. Hai d ch v này k t h p đị ụ ả ồ ờ ị ụ ị ụ ế ợ ể

cài đ t các giao tác phân tán và l ng vào nhau b ng cách s d ng khoá haiặ ồ ằ ử ụ

pha (two- phase).

Mô hình bên d i các giao tác trong Corba là nh sau: M t giao tácướ ư ộ

đ c kh i t o b i m t client và bao g m m t chu i các yêu c u đ iượ ở ạ ở ộ ồ ộ ỗ ầ ố

t ng. Khi m t đ i t ng đ c yêu c u l n đ u tiên, nó t đ ng trượ ộ ố ượ ượ ầ ầ ầ ự ộ ở

thành m t ph n c a giao tác. H qu là, server đ i t ng đ c nh c r ngộ ầ ủ ệ ả ố ượ ượ ắ ằ

bây gi nó đã tham gia vào giao tác. Thông tin đ c chuy n m t cách hoànờ ượ ể ộ

toàn đ n server khi vi c yêu c u đ i t ng x y ra.ế ệ ầ ố ượ ả

Có hai lo i đ i t ng có th là m t ph n c a giao tác. Đ i t ng cóạ ố ượ ể ộ ầ ủ ố ượ

th ph c h i (recoverable object) là m t đ i t ng mà đ c th c thi b iể ụ ồ ộ ố ượ ượ ự ở

m t đ i t ng server có kh năng tham vào giao th c chuy n hai pha. Cộ ố ượ ả ứ ể ụ

th server c a đ i t ng nh v y có th h tr vi c h y b m t giao tácể ủ ố ượ ư ậ ể ỗ ợ ệ ủ ỏ ộ

b ng vi c rolling back m i thay đ i đ c t o ra nh là k t qu c a vi cằ ệ ọ ổ ượ ạ ư ế ả ủ ệ

yêu c u m t trong các đ i t ng có th ph c h i c a nó. Tuy nhiên, cũngầ ộ ố ượ ể ụ ồ ủ

có th yêu c u các đ i t ng là m t ph n c a giao tác mà không th đ cể ầ ố ượ ộ ầ ủ ể ượ

rolled back tr l i tr ng thái tr c khi giao tác b t đ u. C th các đ iở ạ ạ ướ ắ ầ ụ ể ố

t ng có th giao tác (transactional objects) này đ c th c thi b i serverượ ể ượ ự ở

không tham gia vào giao th c chuy n (commit) hai pha c a giao tác. Cácứ ể ủ

đ i t ng transactional th c là các đ i t ng ch đ c.ố ượ ự ố ượ ỉ ọ

Vì v y, rõ ràng r ng các giao tác Corba t ng t nh các giao tác phânậ ằ ươ ự ư

tán và các giao th c c a chúng mà ta đã th o lu n ch ng 5 và ch ngứ ủ ả ậ ở ươ ươ

7.

T ng t d ch v khóa đ c cung c p b i d ch v qu n lý đ ng th iươ ự ị ụ ượ ấ ở ị ụ ả ồ ờ

là th r t đ c mong đ i. Trong th c t , d ch v này đ c cài đ t b ngứ ấ ượ ợ ự ế ị ụ ượ ặ ằ

cách s d ng m t trình qu n lý khóa trung tâm; nó không s d ng kỹử ụ ộ ả ử ụ

thu t khóa phân tán. D ch v này phân bi t vi c khóa đ c và khóa ghi vàậ ị ụ ệ ệ ọ

có kh năng h tr các ki u khóa cho các đ chi ti t khác nhau nhả ỗ ợ ể ộ ế ư

th ng đ c yêu c u trong c s d li u. Ví du, phân bi t vi c khóa toànườ ượ ầ ơ ở ữ ệ ệ ệ

b b ng v i vi c khóa ch m t b n ghi. Xem (Gay và Reuter, 1993; ho cộ ả ớ ệ ỉ ộ ả ặ

Garcia-Moding, 2000) đ bi t thêm thông tin v khóa granular.ể ế ề

B o m t (Security)ả ậ

Tính b o m t c a Corba có m t l ch s lâu dài. Trong phiên b n đ uả ậ ủ ộ ị ử ả ầ

tiên c a các đ c t Corba th t khó ti p c n ch đ này b i m t lý do đ nủ ặ ả ậ ế ậ ủ ề ở ộ ơ

gi n là các c g ng đ đ c t tính b o m t đ u b th t b i. Trong Corbaả ố ắ ể ặ ả ả ậ ề ị ấ ạ

2.4, d ch v b o m t chi m h n 400 trang đ đ c t và t o nên s rõ ràngị ụ ả ậ ế ơ ể ặ ả ạ ự

v cách mà tính b o m t đ c đ a vào trong các h th ng Corba. ề ả ậ ượ ư ệ ố

Bây gi chúng ta hãy xem xét kỹ h n v tính b o m t c a Corba.ờ ơ ề ả ậ ủ

T ng quan v nh ng v n đ này có th đ c tìm th y trong (Blakley,ổ ề ữ ấ ề ể ượ ấ

2000), đ c vi t b i m t trong các tác gi đã đ c t tính b o m t choượ ế ở ộ ả ặ ả ả ậ

Corba.

M t v n đ đ c t quan tr ng cho tính b o m t trong Corba là nh ngộ ấ ề ặ ả ọ ả ậ ữ

d ch v này nên cung c p m t t p các c ch thích h p mà có th đ cị ụ ấ ộ ậ ơ ế ợ ể ượ

dùng đ cài đ t cho nhi u chính sách b o m t khác nhau. Đi u làm ph cể ặ ề ả ậ ề ứ

t p v n đ là nh ng d ch v này sẽ đ c cung c p t i các đi m khác nhauạ ấ ề ữ ị ụ ượ ấ ạ ể

v m t không gian và th i gian. Ví d n u m t client mu n yêu c u đ iề ặ ờ ụ ế ộ ố ầ ố

t ng m t cách an toàn, thì chúng ta c n quy t đ nh khi nào c ch anượ ộ ầ ế ị ơ ế

toàn đ c dùng (ch ng h n t i th i đi m binding, hay yêu c u, hay cượ ẳ ạ ạ ờ ể ầ ả

hai) và n i mà các c ch này nên đ c dùng (ch ng h n t i m c ngơ ơ ế ượ ẳ ạ ạ ứ ứ

d ng, bên trong ORB, hay trong quá trình truy n message).ụ ề

Trái tim c a s b o m t trong Corba đ c hình thành b i s h trủ ự ả ậ ượ ở ự ỗ ợ

các yêu c u đ i t ng an toàn. Ý t ng bên d i là các đ i t ng m c ngầ ố ượ ưở ướ ố ượ ứ ứ

d ng nên không bi t các d ch v b o m t đ c dùng. Tuy nhiên, n u m tụ ế ị ụ ả ậ ượ ế ộ

client đ c dùng có nh ng yêu c u v b o m t c th , client nên đ cượ ữ ầ ề ả ậ ụ ể ượ

cho phép đ c t các yêu c u đó. Vì v y chúng có th nh n đ c tài kho nặ ả ầ ậ ể ậ ượ ả

khi m t đ i t ng đ c yêu c u. Tr ng h p t ng t x y ra cho m t đ iộ ố ượ ượ ầ ườ ợ ươ ự ả ộ ố

t ng khi nó đ c yêu c u. Cách ti p c n này d n đ n cách t ch c t ngượ ượ ầ ế ậ ẫ ế ổ ứ ổ

th nh trong hình 19.ể ư

Hình 15. T ch c chung cho 1 yêu c u đ i t ng an toàn trong Corbaổ ứ ầ ố ượ

Khi m t client liên k t v i m t đ i t ng đ yêu c u đ i t ng trìnhộ ế ớ ộ ố ượ ể ầ ố ượ

ORB c a client sẽ xác đ nh các d ch v b o m t nào là c n thi t t i phíaủ ị ị ụ ả ậ ầ ế ạ

client đ h tr các yêu c u an toàn.ể ỗ ợ ầ

Vi c ch n l a các d ch v đ c xác đ nh b i các chính sách b o m tệ ọ ự ị ụ ượ ị ở ả ậ

kèm theo mi n qu n tr c a n i mà client đang th c thi, nh ng cũng b iề ả ị ủ ơ ự ư ở

các chính sách c th c a client đó.ụ ể ủ

Các chính sách b o m t đ c đ c t b ng các đ i t ng chính sáchả ậ ượ ặ ả ằ ố ượ

(policy objects) kèm theo client. Trong th c t , domain mà client đangự ế

th c thi trong đó sẽ t o s n các chính sách b o m t ORB v a client đóự ạ ẵ ả ậ ủ

b ng m t t p c th các đ i t ng chính sách. Các chính sách m c đ nhằ ộ ậ ụ ể ố ượ ặ ị

đ c kèm theo m t cách t đ ng v i client. M t ví d v đ i t ng chínhượ ộ ự ộ ớ ộ ụ ề ố ượ

sách là nó đ c t ki u c a vi c b o v message đ c yêu c u, và các đ iặ ả ể ủ ệ ả ệ ượ ầ ố

t ng có m t danh sách các thành ph n đáng tin. Nh ng ví d khác và chiượ ộ ầ ữ ụ

ti t có th tìm th y trong (Blakley, 2000).ế ể ấ

M t c u trúc t ng t đ c cho phía server. M t l n n a domainộ ấ ươ ự ượ ở ộ ầ ữ

qu n lý n i mà đ i t ng đ c yêu c u đang th c thi sẽ yêu c u m t t pả ơ ố ượ ượ ầ ự ầ ộ ậ

c th các chính sách b o m t đ c dùng. T ng t nh v y, đ i t ngụ ể ả ậ ượ ươ ự ư ậ ố ượ

đ c yêu c u sẽ có t p các đ i t ng chính sách kèm theo c a riêng nóượ ầ ậ ố ượ ủ

n i mà các thông tin v đ i t ng c th đ c l u tr . Có nhi u cách ti pơ ề ố ượ ụ ể ượ ư ữ ề ế

c n có th đ c đ a ra đ cài đ t tính b o m t trong Corba. C th đậ ể ượ ư ể ặ ả ậ ụ ể ể

t o cho các ORB càng t ng quát càng t t thì nên đ c t các d ch v b oạ ổ ố ặ ả ị ụ ả

m t b i các giao di n chu n cho phép n s cài đ t c a các d ch v đó.ậ ở ệ ẩ ẩ ự ặ ủ ị ụ

Nh ng d ch v có th đ c đ c t theo cách này đ c g i là có th thayữ ị ụ ể ượ ặ ả ượ ọ ể

th trong Corba.ế

Các d ch v b o m t replaceable đ c cài đ t b ng vi c t h p v i haiị ụ ả ậ ượ ặ ằ ệ ổ ợ ớ

interceptor khác nhau, nh trong Hình 20. Interceptor ki m soát truy xu tư ể ấ

là interceptor m c yêu c u cho phép ki m tra quy n truy xu t đi kèm v iứ ầ ể ề ấ ớ

yêu c u. Ngoài ra, còn có m t interceptor m c message g i là interceptorầ ộ ứ ọ

yêu c u secure quan tâm đ n vi c cài đ t b o v cho message. Nói cáchầ ế ệ ặ ả ệ

khác, interceptor có th mã hóa (encrypt) các yêu c u và h i đáp cho m cể ầ ồ ụ

đích toàn v n (intergrity) và tin c n (confidentiality).ẹ ẩ

Hình 16. Vai trò c a các interceptor b o m t trong Corbaủ ả ậ

Interceptor yêu c u an toàn đóng m t vai trò c t y u, b i nhi m vầ ộ ố ế ở ệ ụ

c a nó là cài đ t m t ng c nh (context) b o m t cho client mà sẽ có phépủ ặ ộ ữ ả ả ậ

t ng đ ng yêu c u secure c a đ i t ng đích. Context b o m t nàyươ ươ ầ ủ ố ượ ả ậ

đ c bi u di n b i m t đ i t ng context b o m t, bao g m t t c thôngượ ể ễ ở ộ ố ượ ả ậ ồ ấ ả

tin và ph ng th c c n thi t cho vi c yêu c u đ i t ng đích m t cách anươ ứ ầ ế ệ ầ ố ượ ộ

toàn. Ví d nó mô t c ch nào sẽ đ c dùng, cung c p các ph ng th cụ ả ơ ế ượ ấ ươ ứ

đ mã hóa và gi i mã các message, l u tr các tham chi u đ y nhi m,…ể ả ư ữ ế ể ủ ệ

Server đ i t ng cũng sẽ ph i t o cho nó đ i t ng context b o m t.ố ượ ả ạ ố ượ ả ậ

Interceptor c a client vì th tr c ph i g i m t message đ n server đ iủ ế ướ ả ử ộ ế ố

t ng ch a đ ng nh ng thông tin c n thi t đ xác nh n client và làm choượ ứ ự ữ ầ ế ể ậ

server t o ra m t context b o m t cho các yêu c u sau đó. L u ý r ng,ạ ộ ả ậ ầ ư ằ

interceptor yêu c u an toàn server đ i t ng sẽ ki m tra nh ng đ iầ ở ố ượ ể ữ ố

t ng chính sách thao đ i t ng c th đ xem lúc nào và cách gì đ cácượ ố ượ ụ ể ể ể

yêu c u v b o m t có th g p nhau. Câu tr l i cho client có th bao g mầ ề ả ậ ể ặ ả ờ ể ồ

các thông tin ph tr i nh m cho phép client có th xác nh n v i server.ụ ộ ằ ể ậ ớ

Sau vi c trao đ i message ban đ u này, client sẽ đ c liên k t v i đ iệ ổ ầ ượ ế ớ ố

t ng đích, và c hai sẽ thi t l p cái g i là liên k t b o m t (securityượ ả ế ậ ọ ế ả ậ

association). T đó các yêu c u secure có th di n ra b i các interceptorừ ầ ể ễ ở

yêu c u secure b o v các message yêu c u và h i đáp theo chính sáchầ ả ệ ầ ồ

đ c đ ng ý gi a client và server đ i t ng. M t vai trò c t y u trongượ ồ ữ ố ượ ộ ố ế

vi c cài đ t m t security association là c a đ i t ng tách bi t, m t giaoệ ặ ộ ủ ố ượ ệ ộ

di n đ c chu n hóa, g i là đ i t ng h m. Đ i t ng h m (vault object)ệ ượ ẩ ọ ố ượ ầ ố ượ ầ

đ c g i b i các interceptor yêu c u secure đ t o ra m t đ i t ngượ ọ ở ầ ể ạ ộ ố ượ

context b o m t. Interceptor tr c h t đ c các thông tin chính sách tả ậ ướ ế ọ ừ

nh ng đ i t ng chính sách kèm theo c a client và chuy n nh ng thôngữ ố ượ ủ ể ữ

tin này đ n vault object. M t cách rõ ràng, vault object ph i đ c cài đ tế ộ ả ượ ặ

nh m t ph n c a ORB theo cách ch ng tr m c p (tamper- proof) vàư ộ ầ ủ ố ộ ắ

thu c v c s tính toán tin c y c a b t c h th ng Corba nào.ộ ề ơ ở ậ ủ ấ ứ ệ ố