1 00:00:00,000 --> 00:00:03,458 [MUSIC PLAYING] 2 00:00:03,458 --> 00:00:42,070 3 00:00:42,070 --> 00:00:45,100 Mike, your title is full of buzzwords-- objects 4 00:00:45,100 --> 00:00:48,225 interfaces system software structure. 5 00:00:48,225 --> 00:00:49,600 What are we going to learn today? 6 00:00:49,600 --> 00:00:51,400 And what do these buzzwords mean? 7 00:00:51,400 --> 00:00:53,840 Well, there's three things I'd like to cover today. 8 00:00:53,840 --> 00:00:58,330 The first is issues relating to objects in the system software, 9 00:00:58,330 --> 00:01:01,000 as opposed to just in object-oriented programming 10 00:01:01,000 --> 00:01:02,260 languages. 11 00:01:02,260 --> 00:01:05,680 The second is the Object Management Group's CORBA, 12 00:01:05,680 --> 00:01:08,680 Common Object Request Broker Architecture, 13 00:01:08,680 --> 00:01:12,760 and how it attempts to solve some of these problems 14 00:01:12,760 --> 00:01:15,010 in system software for objects. 15 00:01:15,010 --> 00:01:17,590 The third is how the CORBA architecture 16 00:01:17,590 --> 00:01:20,920 is used to allow objects systems that already 17 00:01:20,920 --> 00:01:23,110 exist to be connected together. 18 00:01:23,110 --> 00:01:25,978 Now, I understand that in object speak 19 00:01:25,978 --> 00:01:27,520 there are a lot of buzzwords that are 20 00:01:27,520 --> 00:01:30,970 used in fairly ambiguous ways. 21 00:01:30,970 --> 00:01:34,360 I have some fairly specific meanings to these terms. 22 00:01:34,360 --> 00:01:36,550 And I'd like to describe them. 23 00:01:36,550 --> 00:01:41,320 To me an object is a combination of computation and state 24 00:01:41,320 --> 00:01:43,960 that are considered to be a unit. 25 00:01:43,960 --> 00:01:47,380 An object has its own integrity in that you can't just 26 00:01:47,380 --> 00:01:50,950 go in and manipulate part of it or associate the computation 27 00:01:50,950 --> 00:01:52,420 with some other state. 28 00:01:52,420 --> 00:01:54,100 The only way to manipulate an object 29 00:01:54,100 --> 00:01:58,090 is by asking it, by sending requests to it, 30 00:01:58,090 --> 00:02:01,990 and letting it perform the actual operations. 31 00:02:01,990 --> 00:02:03,550 Objects are self-describing. 32 00:02:03,550 --> 00:02:04,930 So when you walk up to an object, 33 00:02:04,930 --> 00:02:06,460 you can find out what it is. 34 00:02:06,460 --> 00:02:09,639 You don't necessarily have to know what an object is ahead 35 00:02:09,639 --> 00:02:12,390 of time in order to use it. 36 00:02:12,390 --> 00:02:15,700 An interface describes the shape of the object. 37 00:02:15,700 --> 00:02:19,000 It includes things like what the operations are, 38 00:02:19,000 --> 00:02:21,670 how to go about making requests on the object. 39 00:02:21,670 --> 00:02:24,640 But what's important is that it doesn't include anything 40 00:02:24,640 --> 00:02:26,983 about the actual implementation of the object. 41 00:02:26,983 --> 00:02:28,900 It doesn't say anything about either the state 42 00:02:28,900 --> 00:02:30,490 or the computation. 43 00:02:30,490 --> 00:02:34,720 In a sense, the interface is the contracts between the object 44 00:02:34,720 --> 00:02:37,480 and the clients of that object. 45 00:02:37,480 --> 00:02:41,110 And interfaces are also used to categorize objects. 46 00:02:41,110 --> 00:02:43,570 Objects that share parts of their interfaces 47 00:02:43,570 --> 00:02:47,290 are generally considered similar and interchangeable. 48 00:02:47,290 --> 00:02:51,100 Now, by system I mean a broader context 49 00:02:51,100 --> 00:02:53,920 than you would normally have in a particular programming 50 00:02:53,920 --> 00:02:54,700 language. 51 00:02:54,700 --> 00:02:57,820 In a system, we're talking about a collection of components that 52 00:02:57,820 --> 00:03:01,778 have a number of properties. 53 00:03:01,778 --> 00:03:03,320 For example, they may be distributed. 54 00:03:03,320 --> 00:03:05,920 They may be physically in different places 55 00:03:05,920 --> 00:03:09,190 and have to find some way to communicate together. 56 00:03:09,190 --> 00:03:11,290 Generally, a system is unbounded in the sense 57 00:03:11,290 --> 00:03:14,230 that dynamically another part of the system 58 00:03:14,230 --> 00:03:17,800 can show up that you didn't know existed before. 59 00:03:17,800 --> 00:03:22,390 In general, systems are connected to people 60 00:03:22,390 --> 00:03:24,050 that you don't necessarily trust. 61 00:03:24,050 --> 00:03:28,360 So the various components have to be mutually suspicious. 62 00:03:28,360 --> 00:03:31,120 They have to check to see if the person who's making a request 63 00:03:31,120 --> 00:03:33,910 is in fact intended to be able to make a request. 64 00:03:33,910 --> 00:03:36,560 The various components in a system are autonomous. 65 00:03:36,560 --> 00:03:39,490 They start, stop, fail, recover independently, 66 00:03:39,490 --> 00:03:41,290 as opposed to as a unit. 67 00:03:41,290 --> 00:03:44,380 And what is probably the most subtle property of systems 68 00:03:44,380 --> 00:03:48,430 but affects almost everything you do is that they evolve. 69 00:03:48,430 --> 00:03:51,850 And there's no way to sort of with one flip of the switch 70 00:03:51,850 --> 00:03:54,670 change the way a system behaves. 71 00:03:54,670 --> 00:03:57,100 It's necessary to have simultaneously 72 00:03:57,100 --> 00:03:59,140 some older parts of the system in some newer 73 00:03:59,140 --> 00:04:01,210 parts of the system. 74 00:04:01,210 --> 00:04:03,670 Now, by software structure I'm talking 75 00:04:03,670 --> 00:04:07,570 about how the software is organized at the macro level. 76 00:04:07,570 --> 00:04:11,170 I'm not as interested in this context in what happens 77 00:04:11,170 --> 00:04:12,908 inside a particular component. 78 00:04:12,908 --> 00:04:14,950 But I'm much more interested in the relationships 79 00:04:14,950 --> 00:04:19,120 between components and how those components communicate 80 00:04:19,120 --> 00:04:21,010 with each other and what sort of mechanisms 81 00:04:21,010 --> 00:04:24,620 it takes to actually support components. 82 00:04:24,620 --> 00:04:26,823 Now, the Object Management Group is a group 83 00:04:26,823 --> 00:04:28,240 of people from different companies 84 00:04:28,240 --> 00:04:30,010 that are all working on object systems. 85 00:04:30,010 --> 00:04:32,830 And it turns out they're all working on different object 86 00:04:32,830 --> 00:04:36,460 systems that are in some ways incompatible as people discover 87 00:04:36,460 --> 00:04:41,570 new things and new ideas in object-oriented programming. 88 00:04:41,570 --> 00:04:44,080 What the Object Management Group is trying to do 89 00:04:44,080 --> 00:04:47,470 is to figure out how to make those systems more compatible. 90 00:04:47,470 --> 00:04:49,100 And that happens in a couple of ways. 91 00:04:49,100 --> 00:04:51,790 One way is to figure out how to evolve them, 92 00:04:51,790 --> 00:04:53,518 so they are more similar. 93 00:04:53,518 --> 00:04:55,310 The other is to figure out how to make them 94 00:04:55,310 --> 00:04:56,852 so that even though they're different 95 00:04:56,852 --> 00:04:58,675 they'll be able to play together. 96 00:04:58,675 --> 00:05:01,300 In some sense, it's interesting how the Object Management Group 97 00:05:01,300 --> 00:05:03,130 works at two different levels. 98 00:05:03,130 --> 00:05:04,930 At the same time that they're working 99 00:05:04,930 --> 00:05:07,330 on the common concepts for the software 100 00:05:07,330 --> 00:05:09,850 to be able to have this object system to be able to talk 101 00:05:09,850 --> 00:05:13,030 to this object system, they're also evolving inside 102 00:05:13,030 --> 00:05:15,402 of terminology and way of describing things 103 00:05:15,402 --> 00:05:17,860 so that we can have this person who's working on objects be 104 00:05:17,860 --> 00:05:20,710 able to communicate adequately with this other person who's 105 00:05:20,710 --> 00:05:22,190 working on objects. 106 00:05:22,190 --> 00:05:25,600 Now, the Common Object Request Broker Architecture 107 00:05:25,600 --> 00:05:30,280 is their basic object mechanism. 108 00:05:30,280 --> 00:05:33,940 And it has the philosophy instead of the usual, 109 00:05:33,940 --> 00:05:36,310 well, my object system is better than your object system 110 00:05:36,310 --> 00:05:39,970 in these 12 ways, is well actually your object system 111 00:05:39,970 --> 00:05:44,130 and my object system can play together. 112 00:05:44,130 --> 00:05:46,883 So it turns out that partially by design and partially 113 00:05:46,883 --> 00:05:48,300 because of the problem it's trying 114 00:05:48,300 --> 00:05:51,730 to solve in plugging together object systems, 115 00:05:51,730 --> 00:05:54,840 it turns out that CORBA contains a number of the solutions 116 00:05:54,840 --> 00:05:57,850 to the problem of system software and objects. 117 00:05:57,850 --> 00:06:00,660 Well, I do understand about object technology as used 118 00:06:00,660 --> 00:06:03,708 in programming languages like C++ and Smalltalk. 119 00:06:03,708 --> 00:06:05,250 But what's different about how you're 120 00:06:05,250 --> 00:06:07,097 going to use objects for system software? 121 00:06:07,097 --> 00:06:09,180 Some of the notions in object-oriented programming 122 00:06:09,180 --> 00:06:11,250 languages are of particular relevance 123 00:06:11,250 --> 00:06:13,560 to the system software environment. 124 00:06:13,560 --> 00:06:16,530 The combination of the computation unit 125 00:06:16,530 --> 00:06:21,000 in a piece of state is something that happens in systems all 126 00:06:21,000 --> 00:06:22,960 the time, the notion of a process 127 00:06:22,960 --> 00:06:24,480 in a traditional operating system. 128 00:06:24,480 --> 00:06:25,980 The fact that there are well-defined 129 00:06:25,980 --> 00:06:28,920 interfaces that you do information hiding. 130 00:06:28,920 --> 00:06:31,440 That there can be multiple implementations 131 00:06:31,440 --> 00:06:36,600 of the same service, that you can do extensions, 132 00:06:36,600 --> 00:06:39,078 that you can have relationships between different types 133 00:06:39,078 --> 00:06:40,620 of objects, these are all things that 134 00:06:40,620 --> 00:06:42,995 are extremely important in a system software environment. 135 00:06:42,995 --> 00:06:46,260 And they are provided by object-oriented technology 136 00:06:46,260 --> 00:06:50,187 in traditional object-oriented programming languages. 137 00:06:50,187 --> 00:06:52,020 On the other hand, there are some techniques 138 00:06:52,020 --> 00:06:53,850 that are used in a programming language 139 00:06:53,850 --> 00:06:56,850 context that really don't work very well in a system 140 00:06:56,850 --> 00:06:57,360 environment. 141 00:06:57,360 --> 00:07:00,450 For example, implementation inheritance, the ability 142 00:07:00,450 --> 00:07:03,090 to reuse parts of other implementations, 143 00:07:03,090 --> 00:07:07,260 turns out not to be a good idea in the system software 144 00:07:07,260 --> 00:07:11,070 environment, because it creates a dependency between two 145 00:07:11,070 --> 00:07:14,280 different pieces of software that is not well defined, 146 00:07:14,280 --> 00:07:16,613 that is hard to evolve forward. 147 00:07:16,613 --> 00:07:18,030 So that's a concept that would not 148 00:07:18,030 --> 00:07:20,310 be appropriate in a system software environment that's 149 00:07:20,310 --> 00:07:22,780 OK in a programming language environment. 150 00:07:22,780 --> 00:07:26,820 It's also the case that types in object systems 151 00:07:26,820 --> 00:07:30,030 generally need to be considered relative to who's 152 00:07:30,030 --> 00:07:31,500 telling you what the type is. 153 00:07:31,500 --> 00:07:35,170 If you trust the other component that you're interacting with, 154 00:07:35,170 --> 00:07:37,830 then you can trust the types that are provided to. 155 00:07:37,830 --> 00:07:40,530 But if that component might be a high school student breaking 156 00:07:40,530 --> 00:07:42,360 into your system, you can't exactly 157 00:07:42,360 --> 00:07:44,190 trust the fact, when it says that this 158 00:07:44,190 --> 00:07:48,360 is their driver's license and this is their ID card. 159 00:07:48,360 --> 00:07:50,520 It might have been forged. 160 00:07:50,520 --> 00:07:52,620 Also, type checking in a system environment 161 00:07:52,620 --> 00:07:55,090 is done locally rather than globally. 162 00:07:55,090 --> 00:07:59,100 So the type checking is done within one program when it goes 163 00:07:59,100 --> 00:08:01,320 to interact with the system. 164 00:08:01,320 --> 00:08:03,870 But it can't be done sort of from one program 165 00:08:03,870 --> 00:08:05,380 to another program. 166 00:08:05,380 --> 00:08:07,900 The system can't provide all of those guarantees, 167 00:08:07,900 --> 00:08:09,600 because one program could be working 168 00:08:09,600 --> 00:08:11,400 in one language with one type system, 169 00:08:11,400 --> 00:08:13,170 the other program could be working in another language 170 00:08:13,170 --> 00:08:14,280 in another type system. 171 00:08:14,280 --> 00:08:19,360 There really isn't a way to make all of that be consistent. 172 00:08:19,360 --> 00:08:22,230 Now, if we look at how systems software has evolved, 173 00:08:22,230 --> 00:08:25,260 we can see that there are some changes in structure that 174 00:08:25,260 --> 00:08:30,210 lead us towards object-oriented solutions to system software 175 00:08:30,210 --> 00:08:30,750 problems. 176 00:08:30,750 --> 00:08:33,390 In the early mainframe computers, the system 177 00:08:33,390 --> 00:08:35,130 itself has lots of functionality, 178 00:08:35,130 --> 00:08:38,490 but it tends to be fixed and not easy to extend. 179 00:08:38,490 --> 00:08:43,470 And programs generally go to the system to get their work done. 180 00:08:43,470 --> 00:08:45,510 Well, when PCs came along, it turned out 181 00:08:45,510 --> 00:08:47,910 that the system had very little functionality in it. 182 00:08:47,910 --> 00:08:50,100 When people wanted to do particular things, 183 00:08:50,100 --> 00:08:51,840 they would go out and they would buy an application. 184 00:08:51,840 --> 00:08:54,423 And the application would have almost all of the functionality 185 00:08:54,423 --> 00:08:55,690 that the user wanted in it. 186 00:08:55,690 --> 00:08:57,513 And it was really a classic example, 187 00:08:57,513 --> 00:08:58,680 if you get what you pay for. 188 00:08:58,680 --> 00:09:00,810 If you bought this application, you'd have that functionality. 189 00:09:00,810 --> 00:09:02,370 If you didn't, you wouldn't. 190 00:09:02,370 --> 00:09:05,040 In a modern distributed system, there's 191 00:09:05,040 --> 00:09:06,840 more of an open ended set of functions 192 00:09:06,840 --> 00:09:08,850 that are available because you're connected 193 00:09:08,850 --> 00:09:12,120 to a network of machines that can be potentially unbounded 194 00:09:12,120 --> 00:09:15,090 and you could access a service somewhere out 195 00:09:15,090 --> 00:09:16,777 there in the network. 196 00:09:16,777 --> 00:09:18,360 In general, there's little distinction 197 00:09:18,360 --> 00:09:20,730 in this environment between what's in the system 198 00:09:20,730 --> 00:09:24,210 and what's an extension or what a particular user adds. 199 00:09:24,210 --> 00:09:28,530 And access to services is sort of independent of where it is. 200 00:09:28,530 --> 00:09:31,540 The environment is used as a whole. 201 00:09:31,540 --> 00:09:33,060 So in this environment, it's sort of 202 00:09:33,060 --> 00:09:35,790 natural to focus on software organized 203 00:09:35,790 --> 00:09:38,550 as a set of components that we want 204 00:09:38,550 --> 00:09:41,172 to be able to extend and replace these components, 205 00:09:41,172 --> 00:09:43,380 that we want to be able to wander around the network, 206 00:09:43,380 --> 00:09:45,490 discover components, and be able to use them. 207 00:09:45,490 --> 00:09:46,990 And when I look at all these things, 208 00:09:46,990 --> 00:09:48,270 it sounds like objects to me. 209 00:09:48,270 --> 00:09:50,040 Well, I can see that objects would 210 00:09:50,040 --> 00:09:51,390 be good for system software. 211 00:09:51,390 --> 00:09:54,330 But what would you really want to use them for? 212 00:09:54,330 --> 00:09:55,980 Well, in a word everything. 213 00:09:55,980 --> 00:09:59,980 If I had to use two words, I'd probably say almost everything. 214 00:09:59,980 --> 00:10:01,980 One of the things that objects allow us to do 215 00:10:01,980 --> 00:10:06,660 is to unify things, both across different functionalities 216 00:10:06,660 --> 00:10:10,740 and across different levels in different granularities 217 00:10:10,740 --> 00:10:13,240 in the software environment. 218 00:10:13,240 --> 00:10:17,910 So in a system context, being able to unify things 219 00:10:17,910 --> 00:10:20,800 across different functionalities is extremely important. 220 00:10:20,800 --> 00:10:23,400 A system environment is like a service industry. 221 00:10:23,400 --> 00:10:26,410 Its main purpose in life is to provide access to things. 222 00:10:26,410 --> 00:10:28,440 And it's really much more convenient 223 00:10:28,440 --> 00:10:30,930 if I can use the same mechanism to get access 224 00:10:30,930 --> 00:10:32,522 to a wide variety of services. 225 00:10:32,522 --> 00:10:34,230 I don't want to have to use the telephone 226 00:10:34,230 --> 00:10:36,808 to get to some things and the mail to get to other things. 227 00:10:36,808 --> 00:10:38,850 I'd like to be able to get to all of the services 228 00:10:38,850 --> 00:10:41,672 that I want in the same way. 229 00:10:41,672 --> 00:10:44,970 So objects are general enough to be able to do this. 230 00:10:44,970 --> 00:10:47,960 For example, we can use objects for OS concepts, operating 231 00:10:47,960 --> 00:10:50,510 systems concepts, like files, users, mailboxes. 232 00:10:50,510 --> 00:10:53,570 We can use them for application concepts, like paragraph, 233 00:10:53,570 --> 00:10:55,040 cells, and bitmaps. 234 00:10:55,040 --> 00:10:57,560 We can use them for communication pipes 235 00:10:57,560 --> 00:10:59,960 and sockets and hotlinks that will give me 236 00:10:59,960 --> 00:11:01,940 updated views of data. 237 00:11:01,940 --> 00:11:06,620 Various services like printing or network mail or naming. 238 00:11:06,620 --> 00:11:10,340 And all of these things can be done as objects. 239 00:11:10,340 --> 00:11:13,880 And it gives us a uniform way of describing 240 00:11:13,880 --> 00:11:16,940 these services, because of the fact that we've unified them 241 00:11:16,940 --> 00:11:18,510 in this way. 242 00:11:18,510 --> 00:11:20,360 Now, objects are also flexible enough 243 00:11:20,360 --> 00:11:22,190 to cover different levels of services, 244 00:11:22,190 --> 00:11:25,370 for example, from things as lightweight as toolkits, 245 00:11:25,370 --> 00:11:27,230 a button object in a Windows system 246 00:11:27,230 --> 00:11:29,457 where a synchronization variable can be an object, 247 00:11:29,457 --> 00:11:31,040 things you would normally think of you 248 00:11:31,040 --> 00:11:35,360 do a system call for like a page or an access right, 249 00:11:35,360 --> 00:11:38,630 being able to access services that you would traditionally 250 00:11:38,630 --> 00:11:42,200 do by way of an IPC or an RPC and authentication 251 00:11:42,200 --> 00:11:44,940 service or a database server. 252 00:11:44,940 --> 00:11:47,240 And, in fact, even things as large as whole programs 253 00:11:47,240 --> 00:11:49,940 or multiple programs, a multimedia document that 254 00:11:49,940 --> 00:11:53,780 might consist of a number of different parts 255 00:11:53,780 --> 00:11:57,830 could all be viewed as objects. 256 00:11:57,830 --> 00:12:00,710 By being able to span these multiple levels, 257 00:12:00,710 --> 00:12:04,220 we provide the same mechanism that we can use, 258 00:12:04,220 --> 00:12:07,700 the same way to access things independent of whether it's 259 00:12:07,700 --> 00:12:10,210 a small thing or a large thing. 260 00:12:10,210 --> 00:12:11,960 Well, you've probably heard the old saying 261 00:12:11,960 --> 00:12:13,770 that to a person who has only a hammer, 262 00:12:13,770 --> 00:12:15,510 everything looks like a nail. 263 00:12:15,510 --> 00:12:17,840 And in a certain sense, objects can make this possible. 264 00:12:17,840 --> 00:12:21,020 And applying object technology to the system environment 265 00:12:21,020 --> 00:12:23,790 is in some sense trying to make everything look like a nail 266 00:12:23,790 --> 00:12:26,510 and then make sure that everybody gets a hammer. 267 00:12:26,510 --> 00:12:29,270 However, one of the things that we must be careful about 268 00:12:29,270 --> 00:12:32,750 is trying to use a single solution to solve 269 00:12:32,750 --> 00:12:35,750 too wide range of a problem. 270 00:12:35,750 --> 00:12:37,730 You may notice that I have large hands. 271 00:12:37,730 --> 00:12:40,910 And one of the problems that I have is one size 272 00:12:40,910 --> 00:12:44,000 fits all gloves because they basically just don't fit. 273 00:12:44,000 --> 00:12:46,010 The CORBA architecture has a variety 274 00:12:46,010 --> 00:12:48,092 of places where different choices can be made, 275 00:12:48,092 --> 00:12:49,550 different implementation techniques 276 00:12:49,550 --> 00:12:52,730 can be used, according to the granularity, frequency, access, 277 00:12:52,730 --> 00:12:54,260 and other properties of the objects. 278 00:12:54,260 --> 00:12:57,200 So we get to be able to use the same framework, 279 00:12:57,200 --> 00:13:00,140 the same architecture, the same mode of description 280 00:13:00,140 --> 00:13:01,130 for objects. 281 00:13:01,130 --> 00:13:04,370 But we have different abilities to implement them. 282 00:13:04,370 --> 00:13:07,730 So that we can actually take advantage of the things 283 00:13:07,730 --> 00:13:09,770 that we know about different kinds of objects. 284 00:13:09,770 --> 00:13:12,270 [MUSIC PLAYING] 285 00:13:12,270 --> 00:13:17,270 286 00:13:17,270 --> 00:13:19,460 OK, so you told me that everything in a system 287 00:13:19,460 --> 00:13:21,120 can considered be an object. 288 00:13:21,120 --> 00:13:22,820 And now, you're talking about the CORBA. 289 00:13:22,820 --> 00:13:24,410 Just what is the CORBA? 290 00:13:24,410 --> 00:13:28,130 Well, I should take a minute and first tell you 291 00:13:28,130 --> 00:13:30,470 the question that CORBA was designed to answer, 292 00:13:30,470 --> 00:13:34,190 because OMG did a request for technology for a thing 293 00:13:34,190 --> 00:13:37,490 that they called ORB, the Object Request Broker, which 294 00:13:37,490 --> 00:13:43,670 is the basic mechanism to allow communication between objects. 295 00:13:43,670 --> 00:13:48,740 And the process that we went through to submit CORBA 296 00:13:48,740 --> 00:13:51,230 and to get a number of companies to work together 297 00:13:51,230 --> 00:13:56,180 in defining CORBA as the answer to that question 298 00:13:56,180 --> 00:13:59,300 caused us to pull together a lot of different ideas 299 00:13:59,300 --> 00:14:00,560 in this common solution. 300 00:14:00,560 --> 00:14:03,240 And it really helped make it so that CORBA 301 00:14:03,240 --> 00:14:08,030 spans a wide range of solutions than it might have if we'd just 302 00:14:08,030 --> 00:14:09,860 taken any individual object system 303 00:14:09,860 --> 00:14:13,220 and called that the object request broker. 304 00:14:13,220 --> 00:14:17,900 So the approach was to define whatever things we could 305 00:14:17,900 --> 00:14:20,890 that were in common across the various object systems 306 00:14:20,890 --> 00:14:23,970 that we knew about or that we were working with, 307 00:14:23,970 --> 00:14:26,690 so that we could envision portable applications that 308 00:14:26,690 --> 00:14:29,270 could work the same in these different environments 309 00:14:29,270 --> 00:14:31,380 by relying on these common things, 310 00:14:31,380 --> 00:14:34,340 and also so that we could have the basis for communication 311 00:14:34,340 --> 00:14:37,020 between the different object systems. 312 00:14:37,020 --> 00:14:39,320 We also then tried to define an architecture that 313 00:14:39,320 --> 00:14:42,350 could embrace multiple systems, either 314 00:14:42,350 --> 00:14:45,680 by having them adapt and support the CORBA 315 00:14:45,680 --> 00:14:49,580 architecture without having to rewrite them from scratch 316 00:14:49,580 --> 00:14:52,820 and also to allow future evolution, optimization, 317 00:14:52,820 --> 00:14:56,370 and extension of systems as we learned more about them. 318 00:14:56,370 --> 00:14:59,450 So CORBA is essentially an architecture designed 319 00:14:59,450 --> 00:15:01,700 to unify multiple ORBs. 320 00:15:01,700 --> 00:15:04,580 It's not just a single implementation 321 00:15:04,580 --> 00:15:06,110 of an object request broker. 322 00:15:06,110 --> 00:15:10,100 And it's designed to allow a portability of applications 323 00:15:10,100 --> 00:15:11,690 across these different object systems 324 00:15:11,690 --> 00:15:14,070 and interoperability between them. 325 00:15:14,070 --> 00:15:17,210 So I understand that CORBA is the architecture for the ORBs 326 00:15:17,210 --> 00:15:20,760 and the ORBs are what allow us to have objects. 327 00:15:20,760 --> 00:15:23,150 So let's be more specific about what an object is. 328 00:15:23,150 --> 00:15:26,480 Can you tell me in concrete terms just what is an object? 329 00:15:26,480 --> 00:15:28,070 Well, yes or no. 330 00:15:28,070 --> 00:15:31,400 In CORBA, the concrete definition of an object 331 00:15:31,400 --> 00:15:34,130 is that it's an abstraction. 332 00:15:34,130 --> 00:15:37,460 Fortunately, it turns out that there is a concrete thing 333 00:15:37,460 --> 00:15:39,440 that you can put your finger on or your program 334 00:15:39,440 --> 00:15:40,790 can put its finger on. 335 00:15:40,790 --> 00:15:43,340 And that's what we call an object reference. 336 00:15:43,340 --> 00:15:45,800 The client of an object accesses it 337 00:15:45,800 --> 00:15:47,390 by using an object reference. 338 00:15:47,390 --> 00:15:49,220 And that is something that you can 339 00:15:49,220 --> 00:15:56,100 have and pass around and use to refer to the objects. 340 00:15:56,100 --> 00:15:58,590 The only way to experience the real object, 341 00:15:58,590 --> 00:16:01,580 however, is to do operations using the object reference. 342 00:16:01,580 --> 00:16:03,620 It's sort of like the philosophical question 343 00:16:03,620 --> 00:16:05,660 about the tree in the Northwoods and if it falls 344 00:16:05,660 --> 00:16:06,620 does it make a sound. 345 00:16:06,620 --> 00:16:09,325 And in the CORBA environment, it only 346 00:16:09,325 --> 00:16:11,450 makes a sound if you have an object reference to it 347 00:16:11,450 --> 00:16:14,020 and you call the listen operation 348 00:16:14,020 --> 00:16:17,180 to determine that it's actually made a sound. 349 00:16:17,180 --> 00:16:20,582 Otherwise, you can't tell what's actually there. 350 00:16:20,582 --> 00:16:22,040 Now, as I mentioned, you can store, 351 00:16:22,040 --> 00:16:24,320 pass around object references. 352 00:16:24,320 --> 00:16:26,960 And the world is sort of connected together 353 00:16:26,960 --> 00:16:29,580 by these object references. 354 00:16:29,580 --> 00:16:32,720 Many clients can have the equivalent, a reference 355 00:16:32,720 --> 00:16:34,100 to a particular object. 356 00:16:34,100 --> 00:16:36,590 And there can actually be multiple references 357 00:16:36,590 --> 00:16:37,590 to the same object. 358 00:16:37,590 --> 00:16:39,260 For example, if the object is a file, 359 00:16:39,260 --> 00:16:42,990 some object references might support the write operation. 360 00:16:42,990 --> 00:16:44,510 Other object references would not 361 00:16:44,510 --> 00:16:46,700 support the write operation. 362 00:16:46,700 --> 00:16:50,000 So you can actually have multiple object references 363 00:16:50,000 --> 00:16:51,770 for the same object. 364 00:16:51,770 --> 00:16:53,750 In general, you don't know anything 365 00:16:53,750 --> 00:16:56,910 about how the object is actually implemented or where it is. 366 00:16:56,910 --> 00:16:58,160 You have the object reference. 367 00:16:58,160 --> 00:16:59,840 You do an operation on it. 368 00:16:59,840 --> 00:17:00,860 You get the answer back. 369 00:17:00,860 --> 00:17:06,329 That's the extent that you can know about the object itself. 370 00:17:06,329 --> 00:17:10,160 Now, the operation is a transfer of control and data. 371 00:17:10,160 --> 00:17:13,160 So a client initiates the call. 372 00:17:13,160 --> 00:17:15,500 The object reference determines exactly where 373 00:17:15,500 --> 00:17:17,630 the call is going to go. 374 00:17:17,630 --> 00:17:20,690 The operation that is specified determines 375 00:17:20,690 --> 00:17:22,910 what code is actually going to be executed. 376 00:17:22,910 --> 00:17:26,060 The parameters get transmitted to the destination 377 00:17:26,060 --> 00:17:28,130 where the object is actually implemented. 378 00:17:28,130 --> 00:17:30,020 Control is transferred there. 379 00:17:30,020 --> 00:17:31,760 The implementation then runs, does 380 00:17:31,760 --> 00:17:34,580 whatever the operation requested, 381 00:17:34,580 --> 00:17:35,790 produces some results. 382 00:17:35,790 --> 00:17:38,778 And then those results are transmitted back to the client. 383 00:17:38,778 --> 00:17:40,320 Control transfers back to the client. 384 00:17:40,320 --> 00:17:42,030 And then the client continues. 385 00:17:42,030 --> 00:17:44,360 So the client effectively sees this 386 00:17:44,360 --> 00:17:47,000 as a procedure call that it makes. 387 00:17:47,000 --> 00:17:49,070 And the implementation sees it as a procedure 388 00:17:49,070 --> 00:17:51,440 called that seems to come out of nowhere 389 00:17:51,440 --> 00:17:53,460 into the implementation. 390 00:17:53,460 --> 00:17:56,090 So from now on, when I say object, what I really mean 391 00:17:56,090 --> 00:18:00,350 is the abstract entity that specified by an object 392 00:18:00,350 --> 00:18:02,870 reference, because that's in practice what 393 00:18:02,870 --> 00:18:05,180 it means in the CORBA context. 394 00:18:05,180 --> 00:18:07,130 OK, so I understand I don't have an object. 395 00:18:07,130 --> 00:18:08,760 I have an object reference. 396 00:18:08,760 --> 00:18:10,550 So I have this object reference and now I 397 00:18:10,550 --> 00:18:12,360 want to perform some operation. 398 00:18:12,360 --> 00:18:13,350 How do I do that? 399 00:18:13,350 --> 00:18:15,090 And what does the ORB do for me? 400 00:18:15,090 --> 00:18:17,010 Well, the ORB does a number of things 401 00:18:17,010 --> 00:18:22,410 to make it easy and convenient for you to do operations 402 00:18:22,410 --> 00:18:23,340 on objects. 403 00:18:23,340 --> 00:18:26,350 And I'll mention some of them in a little bit. 404 00:18:26,350 --> 00:18:28,110 Basically, the assumption is that you're 405 00:18:28,110 --> 00:18:30,610 writing a programming in your favorite programming language. 406 00:18:30,610 --> 00:18:33,540 And for the sake of discussion, let's assume that C++. 407 00:18:33,540 --> 00:18:36,570 You have some representation in your programming language 408 00:18:36,570 --> 00:18:38,650 of the object reference. 409 00:18:38,650 --> 00:18:42,210 And let's suppose that that's a surrogate object that you might 410 00:18:42,210 --> 00:18:47,790 have in C++ that looks like a normal C++ object. 411 00:18:47,790 --> 00:18:50,760 You then want to be able to call some code that 412 00:18:50,760 --> 00:18:53,607 will do this work for you, because for your purposes, 413 00:18:53,607 --> 00:18:55,440 you'd like it to look like a procedure call. 414 00:18:55,440 --> 00:18:58,470 And in the C++ context, that's liable to be a method 415 00:18:58,470 --> 00:19:00,300 on the surrogate object. 416 00:19:00,300 --> 00:19:02,460 Now, that method we call a stub. 417 00:19:02,460 --> 00:19:05,640 And it's going to do the work of figuring out 418 00:19:05,640 --> 00:19:09,150 what other stuff it needs to do to actually cause the operation 419 00:19:09,150 --> 00:19:12,310 to be transmitted to the implementation. 420 00:19:12,310 --> 00:19:15,210 So the stub and the ORB cooperate 421 00:19:15,210 --> 00:19:18,480 to actually cause the parameters to be transmitted 422 00:19:18,480 --> 00:19:21,630 and the implementation to be located. 423 00:19:21,630 --> 00:19:23,430 On the implementation side, there 424 00:19:23,430 --> 00:19:25,020 is a thing called a skeleton, which 425 00:19:25,020 --> 00:19:28,410 is analogous to the stub, which tries to then call 426 00:19:28,410 --> 00:19:30,570 an appropriate method. 427 00:19:30,570 --> 00:19:34,140 That's the implementation of that particular operation. 428 00:19:34,140 --> 00:19:36,060 When that method returns, the skeleton 429 00:19:36,060 --> 00:19:40,380 then takes the return values, passes them back using the ORB. 430 00:19:40,380 --> 00:19:42,840 And then the stub on the client side 431 00:19:42,840 --> 00:19:45,330 returns, passing those things back to the programming 432 00:19:45,330 --> 00:19:47,640 language environment that the caller had, 433 00:19:47,640 --> 00:19:51,198 presumably in a way that's convenient for that programmer. 434 00:19:51,198 --> 00:19:53,490 So the goal is for the client to think that it's simply 435 00:19:53,490 --> 00:19:56,160 calling a local routine and the implementation 436 00:19:56,160 --> 00:19:57,990 to appear to be called locally. 437 00:19:57,990 --> 00:20:02,070 And the ORB plus the stubs plus the skeleton sort 438 00:20:02,070 --> 00:20:03,840 of cooperate to provide the glue to make 439 00:20:03,840 --> 00:20:06,610 these two pieces fit together. 440 00:20:06,610 --> 00:20:09,480 Note that the interfaces to the stubs of the skeletons 441 00:20:09,480 --> 00:20:10,980 are, in fact, language specific. 442 00:20:10,980 --> 00:20:13,110 We call it this a language mapping. 443 00:20:13,110 --> 00:20:15,870 And it can be customized for a particular programming 444 00:20:15,870 --> 00:20:16,370 language. 445 00:20:16,370 --> 00:20:18,630 So if your programming language has objects, 446 00:20:18,630 --> 00:20:21,330 you're liable to have a language mapping that makes 447 00:20:21,330 --> 00:20:22,560 it look more like objects. 448 00:20:22,560 --> 00:20:25,050 If you're programming in FORTRAN or something like that, 449 00:20:25,050 --> 00:20:27,360 well, you'll have to use your imagination 450 00:20:27,360 --> 00:20:30,270 to see where the objects are in this program. 451 00:20:30,270 --> 00:20:33,480 CORBA currently defines a standard mapping for C. 452 00:20:33,480 --> 00:20:37,650 And they're currently working on C++ and some other mappings. 453 00:20:37,650 --> 00:20:40,050 Now, note that the client and the implementation mapping 454 00:20:40,050 --> 00:20:41,230 can be completely different. 455 00:20:41,230 --> 00:20:43,710 And the ORB has to solve the problem of having a COBOL 456 00:20:43,710 --> 00:20:47,440 program call an implementation that's written in Smalltalk, 457 00:20:47,440 --> 00:20:49,860 and it does solve that problem. 458 00:20:49,860 --> 00:20:51,330 An important feature of the stubs 459 00:20:51,330 --> 00:20:54,840 is that while the interface to the client 460 00:20:54,840 --> 00:20:57,770 and to the implementation is the same, 461 00:20:57,770 --> 00:21:02,100 the interface between the stub or the skeleton and the ORB 462 00:21:02,100 --> 00:21:04,840 is specific to the ORB implementation. 463 00:21:04,840 --> 00:21:07,260 This is really important because the ORBs may be 464 00:21:07,260 --> 00:21:08,790 implemented quite differently. 465 00:21:08,790 --> 00:21:12,600 And the right thing to do to map a particular programming 466 00:21:12,600 --> 00:21:14,670 language into a particular ORB may be 467 00:21:14,670 --> 00:21:16,690 different in different cases. 468 00:21:16,690 --> 00:21:19,530 So the stubs and the skeletons take 469 00:21:19,530 --> 00:21:23,760 care of this problem of mapping the language environment 470 00:21:23,760 --> 00:21:26,010 into the particular ORB. 471 00:21:26,010 --> 00:21:27,870 Neither the clients nor the implementation 472 00:21:27,870 --> 00:21:30,180 have to be concerned with generating the stubs 473 00:21:30,180 --> 00:21:31,590 or the skeletons however. 474 00:21:31,590 --> 00:21:32,860 So that sounds pretty easy. 475 00:21:32,860 --> 00:21:35,580 All I have to do to do an operation on object references 476 00:21:35,580 --> 00:21:37,500 make a function call. 477 00:21:37,500 --> 00:21:38,970 Is that really all there is to it? 478 00:21:38,970 --> 00:21:42,862 Well, for the users, that's pretty close. 479 00:21:42,862 --> 00:21:44,320 Unfortunately, for ORB implementors 480 00:21:44,320 --> 00:21:46,560 there's more to it. 481 00:21:46,560 --> 00:21:49,155 Note that I didn't say anything about where the client 482 00:21:49,155 --> 00:21:50,530 and where the implementation are. 483 00:21:50,530 --> 00:21:52,590 The ORB has to keep track of this. 484 00:21:52,590 --> 00:21:54,720 As the object reference gets passed around, 485 00:21:54,720 --> 00:21:56,880 it's got to be able to get back to wherever 486 00:21:56,880 --> 00:21:58,720 the implementation happens to be, 487 00:21:58,720 --> 00:22:00,750 whether you're crossing machine boundaries. 488 00:22:00,750 --> 00:22:02,220 If you're going onto a machine with the different 489 00:22:02,220 --> 00:22:03,660 architecture, it's going to have to figure out 490 00:22:03,660 --> 00:22:06,077 how to translate the parameters into the data formats that 491 00:22:06,077 --> 00:22:07,963 are appropriate for that architecture. 492 00:22:07,963 --> 00:22:09,880 There may be differences in operating systems, 493 00:22:09,880 --> 00:22:12,690 et cetera, that have to be overcome. 494 00:22:12,690 --> 00:22:16,170 In fact, the ORB manages the object references persistently. 495 00:22:16,170 --> 00:22:18,870 So you could have an object reference, 496 00:22:18,870 --> 00:22:20,545 save it, come back tomorrow. 497 00:22:20,545 --> 00:22:22,170 That object reference is still supposed 498 00:22:22,170 --> 00:22:25,420 to work unless that object has been destroyed. 499 00:22:25,420 --> 00:22:27,330 So you can store object references 500 00:22:27,330 --> 00:22:29,490 in the middle of files and documents or whatever. 501 00:22:29,490 --> 00:22:32,280 The ORB also keeps track of the type of object references 502 00:22:32,280 --> 00:22:34,930 because you want to know what kind of an object 503 00:22:34,930 --> 00:22:37,140 this object reference refers to. 504 00:22:37,140 --> 00:22:39,450 Besides invocation, the ORB also provides 505 00:22:39,450 --> 00:22:42,630 functions like creation and deletion of objects. 506 00:22:42,630 --> 00:22:47,010 And when you do an operation, if the implementation, 507 00:22:47,010 --> 00:22:49,200 because you got bored and didn't use 508 00:22:49,200 --> 00:22:52,230 the object for a couple of weeks, 509 00:22:52,230 --> 00:22:54,510 isn't active at the moment, the ORB 510 00:22:54,510 --> 00:22:57,390 will actually start up the implementation in order 511 00:22:57,390 --> 00:23:00,810 to get it running before it delivers the request. 512 00:23:00,810 --> 00:23:02,730 There's also an interface definition language 513 00:23:02,730 --> 00:23:05,490 for specifying the interfaces defining 514 00:23:05,490 --> 00:23:07,133 what the operations are. 515 00:23:07,133 --> 00:23:08,550 That interface definition language 516 00:23:08,550 --> 00:23:12,000 is used to produce the stubs and the skeletons. 517 00:23:12,000 --> 00:23:13,830 And that information is also stored 518 00:23:13,830 --> 00:23:15,630 in an interface repository. 519 00:23:15,630 --> 00:23:17,600 So we can find out what interfaces 520 00:23:17,600 --> 00:23:21,380 are supported by a particular object at runtime. 521 00:23:21,380 --> 00:23:24,290 The ORB supports the notion of object adapters. 522 00:23:24,290 --> 00:23:27,900 So there can be different styles of implementations as well. 523 00:23:27,900 --> 00:23:30,140 So the ORB provides a number of functions 524 00:23:30,140 --> 00:23:34,280 that make it easy for the client in the implementation. 525 00:23:34,280 --> 00:23:37,580 But this means that the orb is responsible with the stubs 526 00:23:37,580 --> 00:23:40,130 in the skeleton in the interface repository for keeping 527 00:23:40,130 --> 00:23:43,620 track of this information for the convenience of the client 528 00:23:43,620 --> 00:23:44,620 and the implementations. 529 00:23:44,620 --> 00:23:47,560 [MUSIC PLAYING] 530 00:23:47,560 --> 00:23:51,480 531 00:23:51,480 --> 00:23:53,880 So you mentioned interface definition language. 532 00:23:53,880 --> 00:23:56,790 Does this mean that I have to learn another new programming 533 00:23:56,790 --> 00:23:58,500 language to use the system? 534 00:23:58,500 --> 00:24:01,950 Well, it is necessary to learn another language. 535 00:24:01,950 --> 00:24:03,870 But you actually don't program in it. 536 00:24:03,870 --> 00:24:06,330 The Interface Definition Language, or IDL, 537 00:24:06,330 --> 00:24:09,960 some people say IDL, is used for defining the operations 538 00:24:09,960 --> 00:24:11,490 on objects. 539 00:24:11,490 --> 00:24:13,740 I'm actually fond of the name we used for the research 540 00:24:13,740 --> 00:24:15,810 prototype of this language, which was contract, 541 00:24:15,810 --> 00:24:19,710 because the interface definition language is trying to express 542 00:24:19,710 --> 00:24:22,590 the agreements between the clients 543 00:24:22,590 --> 00:24:24,870 and the implementation of the objects. 544 00:24:24,870 --> 00:24:27,090 It defines the things that most object systems 545 00:24:27,090 --> 00:24:30,870 have, like operations, what they do, signatures, 546 00:24:30,870 --> 00:24:33,810 how you actually request them, exceptions, 547 00:24:33,810 --> 00:24:36,780 what might go wrong when you try to do a particular operation. 548 00:24:36,780 --> 00:24:39,900 It groups operations together in interfaces 549 00:24:39,900 --> 00:24:42,090 and allows there to be relationships 550 00:24:42,090 --> 00:24:43,890 between interfaces. 551 00:24:43,890 --> 00:24:45,390 There's interface inheritance, which 552 00:24:45,390 --> 00:24:46,890 expresses sort of what operations 553 00:24:46,890 --> 00:24:49,937 are in common between two different interfaces. 554 00:24:49,937 --> 00:24:52,020 On the other hand, there are some important things 555 00:24:52,020 --> 00:24:54,630 that interface definition language doesn't say. 556 00:24:54,630 --> 00:24:58,050 For example, it doesn't name any instances of objects. 557 00:24:58,050 --> 00:24:59,960 You have to get those yourself. 558 00:24:59,960 --> 00:25:02,970 It doesn't say anything about how the object is implemented, 559 00:25:02,970 --> 00:25:04,920 where it is. 560 00:25:04,920 --> 00:25:07,290 And also, it's important to note that there's 561 00:25:07,290 --> 00:25:10,110 no correspondence between an interface 562 00:25:10,110 --> 00:25:12,990 and any particular implementation. 563 00:25:12,990 --> 00:25:16,320 There can be a large number of different, completely unrelated 564 00:25:16,320 --> 00:25:17,920 implementations of the same interface. 565 00:25:17,920 --> 00:25:19,920 And there may be some interfaces for which there 566 00:25:19,920 --> 00:25:21,930 are no actual implementations. 567 00:25:21,930 --> 00:25:26,490 So whether your implementation of an object is written in C 568 00:25:26,490 --> 00:25:29,290 and it's inside your program, or whether it's written in FORTRAN 569 00:25:29,290 --> 00:25:32,010 and it's on Mars, it could be the same interface 570 00:25:32,010 --> 00:25:34,870 and you wouldn't notice any difference. 571 00:25:34,870 --> 00:25:37,050 Now, as far as programming, there 572 00:25:37,050 --> 00:25:38,970 are no executable statements in IDL. 573 00:25:38,970 --> 00:25:41,760 So in that sense, it's not a new programming language. 574 00:25:41,760 --> 00:25:44,070 You write programs in your own language. 575 00:25:44,070 --> 00:25:46,260 And what you have to understand is the mapping 576 00:25:46,260 --> 00:25:50,760 that IDL has to the language that you want to program in. 577 00:25:50,760 --> 00:25:56,160 Now, IDL has C or C++ style syntax, 578 00:25:56,160 --> 00:25:58,480 for which we sort of apologize. 579 00:25:58,480 --> 00:26:01,500 It at least has a syntax that's familiar 580 00:26:01,500 --> 00:26:03,570 and data types that are familiar. 581 00:26:03,570 --> 00:26:06,930 It continues to have all the same problems that C and C++ do 582 00:26:06,930 --> 00:26:07,720 in that space. 583 00:26:07,720 --> 00:26:12,400 But we decided we'd rather not make new mistakes in that area. 584 00:26:12,400 --> 00:26:14,100 Now, it turns out that inheritance 585 00:26:14,100 --> 00:26:16,630 is crucial for systems. 586 00:26:16,630 --> 00:26:18,810 And so I want to say a little bit about that 587 00:26:18,810 --> 00:26:22,860 and how inheritance is used in IDL. 588 00:26:22,860 --> 00:26:24,510 It's often the case in systems where 589 00:26:24,510 --> 00:26:26,970 you want to deal with objects without knowing 590 00:26:26,970 --> 00:26:28,122 their exact type. 591 00:26:28,122 --> 00:26:30,330 For example, if you have something that's a document, 592 00:26:30,330 --> 00:26:32,430 and a spreadsheet is a kind of document, 593 00:26:32,430 --> 00:26:34,380 and a printer can print a document, 594 00:26:34,380 --> 00:26:37,440 then that means a printer can print a spreadsheet. 595 00:26:37,440 --> 00:26:42,720 With IDL we're able to express those relationships precisely. 596 00:26:42,720 --> 00:26:44,490 When you use interface inheritance 597 00:26:44,490 --> 00:26:48,120 you're asserting that the spreadsheet object, in fact, 598 00:26:48,120 --> 00:26:52,350 can be used and supports all the operations that a document has. 599 00:26:52,350 --> 00:26:56,040 Since all that anybody can know about an object is 600 00:26:56,040 --> 00:26:57,750 what's expressed in the interface, 601 00:26:57,750 --> 00:27:00,030 if they see an object that has a document interface 602 00:27:00,030 --> 00:27:01,710 and that's what they use, they don't 603 00:27:01,710 --> 00:27:05,370 care what else might be true about that particular kind 604 00:27:05,370 --> 00:27:06,090 of document. 605 00:27:06,090 --> 00:27:08,100 Well, I understand about interfaces. 606 00:27:08,100 --> 00:27:11,940 I write C++ class definitions and put them in header files. 607 00:27:11,940 --> 00:27:13,620 Why are you putting so much emphasis 608 00:27:13,620 --> 00:27:15,430 on interface in this system? 609 00:27:15,430 --> 00:27:18,900 Well, in system software we use these interface techniques 610 00:27:18,900 --> 00:27:19,920 over and over again. 611 00:27:19,920 --> 00:27:23,310 There's generic services, as I mentioned, like printer. 612 00:27:23,310 --> 00:27:25,800 If you look at a system today, like Unix, 613 00:27:25,800 --> 00:27:28,230 the only way you can really tell that a file and a pipe 614 00:27:28,230 --> 00:27:31,260 and a socket are really something in common-- well, 615 00:27:31,260 --> 00:27:33,090 you can look at the code. 616 00:27:33,090 --> 00:27:35,350 Or you can read the man pages and say, boy, they 617 00:27:35,350 --> 00:27:37,140 seem to say a lot of the same things 618 00:27:37,140 --> 00:27:39,888 about these different concepts. 619 00:27:39,888 --> 00:27:41,430 This happens all the time and systems 620 00:27:41,430 --> 00:27:43,055 that we build different implementations 621 00:27:43,055 --> 00:27:45,037 of the same kinds of things. 622 00:27:45,037 --> 00:27:46,620 We want to have them related together, 623 00:27:46,620 --> 00:27:51,540 and the interface scheme allows us to express that directly. 624 00:27:51,540 --> 00:27:53,310 It's also the case that we want to allow 625 00:27:53,310 --> 00:27:55,630 alternate implementations of the same interfaces. 626 00:27:55,630 --> 00:27:58,410 So if, for example, there's a mouse trap interface, 627 00:27:58,410 --> 00:28:00,480 you can look at that interface and say, hey, I 628 00:28:00,480 --> 00:28:02,010 can build a better mouse trap. 629 00:28:02,010 --> 00:28:05,730 You can do that, and when you provide that service, when 630 00:28:05,730 --> 00:28:07,950 you provide that mouse trap, what you know 631 00:28:07,950 --> 00:28:11,160 is that all of the other parts of the system that expect 632 00:28:11,160 --> 00:28:14,010 to use mouse traps will work with your mouse trap, 633 00:28:14,010 --> 00:28:16,260 because the only thing they could possibly know 634 00:28:16,260 --> 00:28:17,200 is the interface. 635 00:28:17,200 --> 00:28:19,530 And if you've successfully implemented that interface, 636 00:28:19,530 --> 00:28:22,260 those parts of the system, more or less, 637 00:28:22,260 --> 00:28:25,380 have to work with your flavor of mouse trap. 638 00:28:25,380 --> 00:28:27,900 It's also the case that systems evolve. 639 00:28:27,900 --> 00:28:30,150 And we often will be in a situation 640 00:28:30,150 --> 00:28:33,990 where we want either newer versions of the same interface 641 00:28:33,990 --> 00:28:35,880 or extended interfaces. 642 00:28:35,880 --> 00:28:39,150 We want to make it so that clients of the old interface 643 00:28:39,150 --> 00:28:42,720 can use the new objects without worrying about the extensions. 644 00:28:42,720 --> 00:28:44,220 At the same time, we want to make it 645 00:28:44,220 --> 00:28:46,410 so that clients of the newer interfaces 646 00:28:46,410 --> 00:28:49,170 can, in fact, use the new features. 647 00:28:49,170 --> 00:28:51,600 Extensions are another thing that are common in systems. 648 00:28:51,600 --> 00:28:54,630 These are things where you want to add value added 649 00:28:54,630 --> 00:28:56,920 versions of existing facilities, for example, 650 00:28:56,920 --> 00:28:59,430 if you want to have a compressed version of files 651 00:28:59,430 --> 00:29:02,670 so that they would take less space on the disk. 652 00:29:02,670 --> 00:29:07,290 So new objects that are this new extended service 653 00:29:07,290 --> 00:29:11,313 will work with other services because they're still files. 654 00:29:11,313 --> 00:29:12,855 But you may decide, well, jeez that I 655 00:29:12,855 --> 00:29:17,160 don't want to spend all my time compressing and uncompressing 656 00:29:17,160 --> 00:29:19,050 this file, so I'm going to do an operation 657 00:29:19,050 --> 00:29:21,790 on this compressed file that says, 658 00:29:21,790 --> 00:29:25,260 well, don't compress it because I want it to run faster 659 00:29:25,260 --> 00:29:26,020 or whatever. 660 00:29:26,020 --> 00:29:28,530 So you want to access the extended functionality 661 00:29:28,530 --> 00:29:32,460 and be able to have additional control on that service. 662 00:29:32,460 --> 00:29:34,650 And the important thing is that all of these things 663 00:29:34,650 --> 00:29:35,970 end up being first class. 664 00:29:35,970 --> 00:29:37,887 Because they're all described in the same way, 665 00:29:37,887 --> 00:29:40,260 because they're all accessed the same way, whether it's 666 00:29:40,260 --> 00:29:44,160 a built-in system function, whether it's an installation 667 00:29:44,160 --> 00:29:46,890 specific function, whether it's something 668 00:29:46,890 --> 00:29:48,660 that an individual user has, whether it's 669 00:29:48,660 --> 00:29:51,210 permanent or temporary or conditional used 670 00:29:51,210 --> 00:29:55,250 in certain circumstances, they're all done the same way. 671 00:29:55,250 --> 00:29:59,150 Another key aspect about how IDL does inheritance 672 00:29:59,150 --> 00:30:00,980 is that it uses multiple inheritance. 673 00:30:00,980 --> 00:30:04,310 And, in fact, we encourage the use of multiple inheritance 674 00:30:04,310 --> 00:30:05,545 for interfaces. 675 00:30:05,545 --> 00:30:06,920 With single inheritance, you have 676 00:30:06,920 --> 00:30:09,710 to decide where to put the various interfaces 677 00:30:09,710 --> 00:30:11,780 in the interface tree. 678 00:30:11,780 --> 00:30:13,910 If you put things too close to the root, 679 00:30:13,910 --> 00:30:16,400 you end up having things that are not necessarily 680 00:30:16,400 --> 00:30:18,620 making sense for all of the objects that are 681 00:30:18,620 --> 00:30:21,200 below them in the type tree. 682 00:30:21,200 --> 00:30:23,450 On the other hand, if you spread these interfaces out 683 00:30:23,450 --> 00:30:25,520 at multiple places in the type tree, 684 00:30:25,520 --> 00:30:28,160 you no longer have the type relationship between those two 685 00:30:28,160 --> 00:30:30,530 different sub-trees. 686 00:30:30,530 --> 00:30:33,560 For example, if you consider the traditional sort of I/O stream 687 00:30:33,560 --> 00:30:36,980 and file kind of relationship, where would you add replication 688 00:30:36,980 --> 00:30:38,420 to this picture? 689 00:30:38,420 --> 00:30:41,270 Should you add it below I/O stream? 690 00:30:41,270 --> 00:30:42,830 Should you added above I/O stream 691 00:30:42,830 --> 00:30:45,230 so that file can inherit i also? 692 00:30:45,230 --> 00:30:48,980 Do you add it below I/O stream and below file, in which case 693 00:30:48,980 --> 00:30:54,350 a replicated I/O stream isn't the same type 694 00:30:54,350 --> 00:30:58,010 as a replicated file? 695 00:30:58,010 --> 00:31:01,250 I actually have a sort of a hobby of class hierarchy 696 00:31:01,250 --> 00:31:01,858 archaeology. 697 00:31:01,858 --> 00:31:03,275 It's sort of like heirarcheaology. 698 00:31:03,275 --> 00:31:07,050 I don't know if that's a new word. 699 00:31:07,050 --> 00:31:09,590 Basically, when people are defining single inheritance 700 00:31:09,590 --> 00:31:11,480 hierarchies, there's some point in time 701 00:31:11,480 --> 00:31:14,250 after which it's difficult to change the hierarchy. 702 00:31:14,250 --> 00:31:16,250 And that's because while you ship some products, 703 00:31:16,250 --> 00:31:18,590 there are a lot of people that are depending upon it. 704 00:31:18,590 --> 00:31:20,758 And so you can't add new things to the base classes. 705 00:31:20,758 --> 00:31:22,550 And it's always interesting to look and see 706 00:31:22,550 --> 00:31:24,380 what things got into the base classes 707 00:31:24,380 --> 00:31:28,790 because it was easy to do and what things didn't get in later 708 00:31:28,790 --> 00:31:31,520 when it was too hard to do. 709 00:31:31,520 --> 00:31:33,890 With multiple inheritance a new interface 710 00:31:33,890 --> 00:31:36,530 becomes a new root node in the interface graph. 711 00:31:36,530 --> 00:31:39,300 And it can be inherited wherever it's appropriate. 712 00:31:39,300 --> 00:31:41,660 So you can use objects that support the new interface 713 00:31:41,660 --> 00:31:45,380 independent of what other interfaces they might have 714 00:31:45,380 --> 00:31:49,200 or where they are in the previous parts of the type 715 00:31:49,200 --> 00:31:50,110 graph. 716 00:31:50,110 --> 00:31:52,580 In the example of replicated file, 717 00:31:52,580 --> 00:31:56,030 a replicated file can be replicated I/O stream. 718 00:31:56,030 --> 00:31:58,400 And you can use replicated things independent 719 00:31:58,400 --> 00:32:03,370 of what other things they think might happen to be. 720 00:32:03,370 --> 00:32:06,610 Now, although these sort of type and interface and inheritance 721 00:32:06,610 --> 00:32:08,830 issues are important for programming languages, 722 00:32:08,830 --> 00:32:12,070 they are really paramount in software systems, 723 00:32:12,070 --> 00:32:14,860 because although it may be possible to recompile 724 00:32:14,860 --> 00:32:18,970 a whole program, it's not really practical to ever recompile 725 00:32:18,970 --> 00:32:21,340 a whole system in all of the software that 726 00:32:21,340 --> 00:32:23,420 will depend upon the system class hierarchy. 727 00:32:23,420 --> 00:32:27,550 So there are so many different suppliers of software, 728 00:32:27,550 --> 00:32:30,700 you have to be able to use software without knowing more 729 00:32:30,700 --> 00:32:31,580 than is necessary. 730 00:32:31,580 --> 00:32:34,300 You have to allow other people to have a stable base 731 00:32:34,300 --> 00:32:36,160 to depend upon. 732 00:32:36,160 --> 00:32:38,650 And that means that you have to spend 733 00:32:38,650 --> 00:32:41,290 a lot more time making sure you get the interfaces right. 734 00:32:41,290 --> 00:32:44,920 But, as you pointed out earlier, distributed system 735 00:32:44,920 --> 00:32:47,890 is very dynamic and would seem to require a dynamically typed 736 00:32:47,890 --> 00:32:48,887 object system. 737 00:32:48,887 --> 00:32:51,220 But what you're describing seems to be statically typed? 738 00:32:51,220 --> 00:32:52,180 Isn't that a problem? 739 00:32:52,180 --> 00:32:55,600 Well, the system is definitely statically typed. 740 00:32:55,600 --> 00:32:58,790 And there are sort of two reasons for that. 741 00:32:58,790 --> 00:33:01,000 The second is that, in fact, we managed 742 00:33:01,000 --> 00:33:03,580 to get a fair amount of dynamic behavior in spite of the fact 743 00:33:03,580 --> 00:33:05,050 that our types are static. 744 00:33:05,050 --> 00:33:06,880 But the first reason that I want to say 745 00:33:06,880 --> 00:33:10,630 is that static is actually better for our problems. 746 00:33:10,630 --> 00:33:13,330 We want to have type systems that actually document 747 00:33:13,330 --> 00:33:15,640 and guarantee the contract analogy, 748 00:33:15,640 --> 00:33:17,810 what the objects are going to be able to do. 749 00:33:17,810 --> 00:33:21,040 And so we don't want to have the opportunity for someone 750 00:33:21,040 --> 00:33:23,740 to change things without having that reflected somehow 751 00:33:23,740 --> 00:33:25,750 in the type system. 752 00:33:25,750 --> 00:33:27,190 A lot of time, software components 753 00:33:27,190 --> 00:33:29,680 are going to first be introduced to each other 754 00:33:29,680 --> 00:33:31,120 at the customer site. 755 00:33:31,120 --> 00:33:32,688 And the customer is going to want 756 00:33:32,688 --> 00:33:35,230 to know who to blame if these two things don't work together. 757 00:33:35,230 --> 00:33:37,355 And the type system is a way that says, well, look, 758 00:33:37,355 --> 00:33:38,930 here's how it's supposed to work. 759 00:33:38,930 --> 00:33:41,365 So that guy is misbehaving, or this guy is misbehaving, 760 00:33:41,365 --> 00:33:45,190 so you know which customer service number to call. 761 00:33:45,190 --> 00:33:47,050 We can still have a lot of generality 762 00:33:47,050 --> 00:33:48,820 with inherited interfaces because there 763 00:33:48,820 --> 00:33:52,870 can be lots of differences among implementations. 764 00:33:52,870 --> 00:33:55,240 And, of course, we do have the opportunity 765 00:33:55,240 --> 00:33:58,510 to do checking in compiled languages 766 00:33:58,510 --> 00:33:59,760 by having static type. 767 00:33:59,760 --> 00:34:01,720 So before you ship your product, you 768 00:34:01,720 --> 00:34:03,970 can know that it's going to do the right things 769 00:34:03,970 --> 00:34:07,250 relative to the system defined interfaces. 770 00:34:07,250 --> 00:34:09,250 And if there are bugs to be found, 771 00:34:09,250 --> 00:34:11,679 they're probably going to be in someone else's software. 772 00:34:11,679 --> 00:34:16,418 But it turns out that we also provide with IDL and in the ORB 773 00:34:16,418 --> 00:34:18,460 a number of features that are normally associated 774 00:34:18,460 --> 00:34:20,710 with dynamic type systems. 775 00:34:20,710 --> 00:34:24,037 For example, new interfaces and implementations 776 00:34:24,037 --> 00:34:26,620 can be added without disrupting the type system as I mentioned 777 00:34:26,620 --> 00:34:28,900 with multiple inheritance. 778 00:34:28,900 --> 00:34:32,199 It's possible to discover at run time an object 779 00:34:32,199 --> 00:34:35,260 and find out what its type is and then 780 00:34:35,260 --> 00:34:37,550 figure out how to actually use it 781 00:34:37,550 --> 00:34:40,159 using the interface repository. 782 00:34:40,159 --> 00:34:41,860 And you can delay the determination 783 00:34:41,860 --> 00:34:45,320 of the exact type of an object for a long period of time. 784 00:34:45,320 --> 00:34:47,770 So you can use objects without actually caring 785 00:34:47,770 --> 00:34:49,179 what their exact type is. 786 00:34:49,179 --> 00:34:53,320 There's two ways of dealing with types dynamically. 787 00:34:53,320 --> 00:34:56,170 The first is to use the get interface operation 788 00:34:56,170 --> 00:35:00,577 to get the interface repository information. 789 00:35:00,577 --> 00:35:02,410 That's not always what you want because it's 790 00:35:02,410 --> 00:35:05,920 going to give you a very specific answer to the question 791 00:35:05,920 --> 00:35:07,690 of what type are you. 792 00:35:07,690 --> 00:35:10,018 If what you need is a file and what 793 00:35:10,018 --> 00:35:12,310 you get from the interface repository is something that 794 00:35:12,310 --> 00:35:14,557 says that it's a vacuum cleaner, you 795 00:35:14,557 --> 00:35:16,390 may have to run around in the type hierarchy 796 00:35:16,390 --> 00:35:18,670 to figure out, OK, where in vacuum cleaner 797 00:35:18,670 --> 00:35:22,840 do I find the file interface? 798 00:35:22,840 --> 00:35:25,312 But it does have all the information that you need. 799 00:35:25,312 --> 00:35:27,520 So if you stumble across this new object and you say, 800 00:35:27,520 --> 00:35:28,623 oh, it's vacuum cleaner. 801 00:35:28,623 --> 00:35:30,040 You can go and find out what sorts 802 00:35:30,040 --> 00:35:32,260 of things, what sorts of operations, that object 803 00:35:32,260 --> 00:35:33,640 might actually support. 804 00:35:33,640 --> 00:35:35,230 A more common way to deal with types 805 00:35:35,230 --> 00:35:38,083 dynamically is an operation that we call narrow, 806 00:35:38,083 --> 00:35:40,000 which is a variation on the normal programming 807 00:35:40,000 --> 00:35:42,700 language narrow, because of the fact that you can do it 808 00:35:42,700 --> 00:35:46,660 across multiple parts of the tree with multiple inheritance. 809 00:35:46,660 --> 00:35:48,670 And that is that you ask if the object has 810 00:35:48,670 --> 00:35:50,020 a particular interface. 811 00:35:50,020 --> 00:35:52,700 And then it gives you that particular interface view. 812 00:35:52,700 --> 00:35:54,970 So if you have this thing, and it turns out 813 00:35:54,970 --> 00:35:58,370 to be a vacuum cleaner, and you're asking if it's a file, 814 00:35:58,370 --> 00:36:01,060 I can point you to the part of it that looks like a file 815 00:36:01,060 --> 00:36:02,860 and not have to bother you with the fact 816 00:36:02,860 --> 00:36:04,360 that it really is a vacuum cleaner. 817 00:36:04,360 --> 00:36:06,370 If you were interested in using file operations, 818 00:36:06,370 --> 00:36:08,860 you're then able to use them, ignoring 819 00:36:08,860 --> 00:36:11,386 the rest of the details of what the object is. 820 00:36:11,386 --> 00:36:13,970 [MUSIC PLAYING] 821 00:36:13,970 --> 00:36:18,110 822 00:36:18,110 --> 00:36:20,900 OK, well, we talked about how I can use an object that's 823 00:36:20,900 --> 00:36:22,052 out there in the system. 824 00:36:22,052 --> 00:36:23,510 But now it comes to the point where 825 00:36:23,510 --> 00:36:25,380 I want to start defining my own objects. 826 00:36:25,380 --> 00:36:27,950 How do I go about implementing an object? 827 00:36:27,950 --> 00:36:31,130 Well, an implementation is pretty much 828 00:36:31,130 --> 00:36:34,800 guaranteed to be more complicated than a client. 829 00:36:34,800 --> 00:36:36,500 We spend a lot of time trying to make 830 00:36:36,500 --> 00:36:39,263 it easy for the customers in some sense of objects. 831 00:36:39,263 --> 00:36:40,680 But the implementation, of course, 832 00:36:40,680 --> 00:36:42,170 has to do the real work. 833 00:36:42,170 --> 00:36:44,870 It has to deal with creating and deleting and preserving 834 00:36:44,870 --> 00:36:47,700 the state and all those sorts of things. 835 00:36:47,700 --> 00:36:49,670 But the core of an implementation of objects 836 00:36:49,670 --> 00:36:52,130 is very similar to what an implementation of objects 837 00:36:52,130 --> 00:36:54,500 would be in a typical object-oriented programming 838 00:36:54,500 --> 00:36:55,970 language. 839 00:36:55,970 --> 00:36:57,770 Basically, the ORB and the skeleton 840 00:36:57,770 --> 00:37:00,650 are set up to make it so that you simply 841 00:37:00,650 --> 00:37:05,120 plug in the methods that do the operations into the ORB. 842 00:37:05,120 --> 00:37:07,080 However, because we're dealing with a system, 843 00:37:07,080 --> 00:37:09,030 there are two extra concerns. 844 00:37:09,030 --> 00:37:10,370 The first is security. 845 00:37:10,370 --> 00:37:13,340 This is this high school student out there 846 00:37:13,340 --> 00:37:15,120 that's trying to break into your system. 847 00:37:15,120 --> 00:37:18,510 And you've got to decide who's allowed to do which operations. 848 00:37:18,510 --> 00:37:21,350 And there's also the issue of asynchrony, 849 00:37:21,350 --> 00:37:25,250 because you can have several requests made at the same time. 850 00:37:25,250 --> 00:37:26,750 Both of these issues can be dealt 851 00:37:26,750 --> 00:37:29,330 with in either a simple or complex way depending 852 00:37:29,330 --> 00:37:30,070 upon the object. 853 00:37:30,070 --> 00:37:31,610 For example, if it's a really simple object, 854 00:37:31,610 --> 00:37:33,110 I can just acquire a lock and then 855 00:37:33,110 --> 00:37:36,770 release it at the beginning and end of each method, 856 00:37:36,770 --> 00:37:39,650 and that will pretty much solve the problem. 857 00:37:39,650 --> 00:37:41,730 For more interesting objects, I may, in fact, 858 00:37:41,730 --> 00:37:44,090 want to release the locks partway 859 00:37:44,090 --> 00:37:46,550 through an operation to allow other operations to start 860 00:37:46,550 --> 00:37:48,830 or make progress. 861 00:37:48,830 --> 00:37:51,788 Similarly, with the security issue, 862 00:37:51,788 --> 00:37:54,080 I could simply delegate it to an authentication service 863 00:37:54,080 --> 00:37:55,220 and say, protect me. 864 00:37:55,220 --> 00:37:58,730 Or I may choose to have more fine grained control, 865 00:37:58,730 --> 00:38:01,100 and I'm going to look at your ID and say, well, this 866 00:38:01,100 --> 00:38:02,480 is a good thing for you to be able to do? 867 00:38:02,480 --> 00:38:04,313 And then I'm going to go look at my database 868 00:38:04,313 --> 00:38:06,120 and make my own decisions. 869 00:38:06,120 --> 00:38:08,720 So you have a range of possibilities. 870 00:38:08,720 --> 00:38:12,200 And there is a good opportunity for using some standard system 871 00:38:12,200 --> 00:38:14,830 facilities to make life easier. 872 00:38:14,830 --> 00:38:17,890 Probably the major difference between a programming language 873 00:38:17,890 --> 00:38:20,930 object implementation and a CORBA object implementation, 874 00:38:20,930 --> 00:38:22,870 however, is activation. 875 00:38:22,870 --> 00:38:26,450 Because objects are persistent, they can last a long time, 876 00:38:26,450 --> 00:38:28,750 you, as an implementation, may get bored or tired 877 00:38:28,750 --> 00:38:32,390 or your system may crash, and then some time later, a request 878 00:38:32,390 --> 00:38:32,890 comes in. 879 00:38:32,890 --> 00:38:35,740 Well, the ORB provides the means for you 880 00:38:35,740 --> 00:38:38,230 to get started, get your state set up 881 00:38:38,230 --> 00:38:41,890 again, before it actually delivers that request to you. 882 00:38:41,890 --> 00:38:44,210 This involves a number of up calls from the ORB 883 00:38:44,210 --> 00:38:45,910 and some down calls back to the ORB 884 00:38:45,910 --> 00:38:49,520 to register your implementation and say 885 00:38:49,520 --> 00:38:51,130 that you're ready to go. 886 00:38:51,130 --> 00:38:53,375 This is another place where the architecture provides 887 00:38:53,375 --> 00:38:55,000 a number of hooks so that you can do it 888 00:38:55,000 --> 00:38:58,360 in some very gentle and complicated ways 889 00:38:58,360 --> 00:38:59,600 if you need to. 890 00:38:59,600 --> 00:39:02,290 But it's also a place where if you're using standard storage 891 00:39:02,290 --> 00:39:05,290 facilities or if you're doing something pretty traditional, 892 00:39:05,290 --> 00:39:08,410 you can probably find the right routine to just plug 893 00:39:08,410 --> 00:39:12,040 into your implementation and let somebody else do 894 00:39:12,040 --> 00:39:13,540 the actual work. 895 00:39:13,540 --> 00:39:15,340 Well, you've described a wide range 896 00:39:15,340 --> 00:39:19,000 of choices I could make when I do an object implementation. 897 00:39:19,000 --> 00:39:21,880 But what do I have available to me to make those choices? 898 00:39:21,880 --> 00:39:23,530 What kind of choices do I have? 899 00:39:23,530 --> 00:39:25,090 Different objects implementations 900 00:39:25,090 --> 00:39:28,750 can be quite different and have some real differences in what 901 00:39:28,750 --> 00:39:31,660 they expect from the ORB. 902 00:39:31,660 --> 00:39:35,650 And to avoid having to have one size fits all 903 00:39:35,650 --> 00:39:39,910 object implementations, we've invented a concept 904 00:39:39,910 --> 00:39:41,830 that we call the object adapter. 905 00:39:41,830 --> 00:39:44,920 And this really is an important architectural feature 906 00:39:44,920 --> 00:39:47,860 of the CORBA system, because it's 907 00:39:47,860 --> 00:39:49,930 the thing that allows us to have sort 908 00:39:49,930 --> 00:39:54,790 of multiple sizes of interfaces to the ORB. 909 00:39:54,790 --> 00:39:57,730 So an object adapter defines the interface to the ORB, 910 00:39:57,730 --> 00:39:59,890 including operations for creating and deleting 911 00:39:59,890 --> 00:40:00,970 and moving objects. 912 00:40:00,970 --> 00:40:04,135 And it also pins down the exact structure of the skeletons. 913 00:40:04,135 --> 00:40:06,010 All the skeletons for all the object adapters 914 00:40:06,010 --> 00:40:07,790 are probably going to be pretty similar, 915 00:40:07,790 --> 00:40:10,090 but there may be some important differences in exactly 916 00:40:10,090 --> 00:40:11,350 how the request is delivered. 917 00:40:11,350 --> 00:40:13,960 The basic object adapter is the only one 918 00:40:13,960 --> 00:40:16,570 that the Object Management Group has yet approved. 919 00:40:16,570 --> 00:40:20,050 But we're investigating a couple of others already. 920 00:40:20,050 --> 00:40:22,540 We probably don't want a large number of objects adapters, 921 00:40:22,540 --> 00:40:24,370 because in order to make portable object 922 00:40:24,370 --> 00:40:26,770 implementations, all of the ORBs have 923 00:40:26,770 --> 00:40:30,100 to support all of the possible object adapters. 924 00:40:30,100 --> 00:40:32,830 So in general, you only want to have an object adapter 925 00:40:32,830 --> 00:40:35,830 if there's really a radically different set of requirements 926 00:40:35,830 --> 00:40:39,790 from the ORB for a particular object implementation. 927 00:40:39,790 --> 00:40:42,580 OK, so you've mentioned the one object adapter, 928 00:40:42,580 --> 00:40:44,080 the basic object adapter. 929 00:40:44,080 --> 00:40:45,790 What kind of object implementations 930 00:40:45,790 --> 00:40:48,430 would I use that object adapter for? 931 00:40:48,430 --> 00:40:50,530 Well, the basic object adapter is 932 00:40:50,530 --> 00:40:53,270 aimed at what I might call server style implementations. 933 00:40:53,270 --> 00:40:55,968 It's sort of in the middle of the range of granularity. 934 00:40:55,968 --> 00:40:58,510 We're not talking about nuclear aircraft carriers as objects, 935 00:40:58,510 --> 00:41:01,690 but we're also not talking about subatomic particles as objects. 936 00:41:01,690 --> 00:41:04,240 It's things like documents or spreadsheet cells 937 00:41:04,240 --> 00:41:07,360 or users or system concepts like that. 938 00:41:07,360 --> 00:41:09,700 The assumption is that the implementation of the object 939 00:41:09,700 --> 00:41:11,650 can be protected from the client, 940 00:41:11,650 --> 00:41:13,930 that it can have this general activation 941 00:41:13,930 --> 00:41:17,530 mechanism of being started up independent of other objects. 942 00:41:17,530 --> 00:41:21,070 The ORB actually will remember about 1k bytes of state 943 00:41:21,070 --> 00:41:23,540 for each object if you want. 944 00:41:23,540 --> 00:41:26,380 And it assumes that there is external visibility 945 00:41:26,380 --> 00:41:29,470 of those objects, that they are going to be passed around. 946 00:41:29,470 --> 00:41:32,860 And so it also has a security model that 947 00:41:32,860 --> 00:41:35,650 assumes access control lists. 948 00:41:35,650 --> 00:41:38,680 The performance expectations for this kind of object 949 00:41:38,680 --> 00:41:41,020 is probably on the order of a few dozen invocations 950 00:41:41,020 --> 00:41:41,560 per second. 951 00:41:41,560 --> 00:41:43,602 You probably aren't going to get up to a million. 952 00:41:43,602 --> 00:41:45,820 But you can probably do something in that range. 953 00:41:45,820 --> 00:41:49,450 It shouldn't take an hour and a half to do an invocation. 954 00:41:49,450 --> 00:41:52,510 It has actually a rich set of activation mechanisms, 955 00:41:52,510 --> 00:41:55,480 because there will be different kinds of implementations 956 00:41:55,480 --> 00:41:57,490 for objects. 957 00:41:57,490 --> 00:42:00,010 A typical one is that a server might have 958 00:42:00,010 --> 00:42:01,760 many objects implemented in it. 959 00:42:01,760 --> 00:42:05,380 So when you start it up for the first object that you use, 960 00:42:05,380 --> 00:42:08,270 it says, oh, by the way, I implement all these other ones. 961 00:42:08,270 --> 00:42:10,960 So you don't have to do the extra work of activating 962 00:42:10,960 --> 00:42:13,360 those objects separately. 963 00:42:13,360 --> 00:42:16,330 On the other extreme is an object 964 00:42:16,330 --> 00:42:19,130 where each operation will start up a different program. 965 00:42:19,130 --> 00:42:21,730 This would tend to be for a larger size 966 00:42:21,730 --> 00:42:23,710 object, where you would have a program 967 00:42:23,710 --> 00:42:26,920 to print or edit the object. 968 00:42:26,920 --> 00:42:28,630 We expect the basic object adapter 969 00:42:28,630 --> 00:42:32,450 to be able to be used for most common application in system 970 00:42:32,450 --> 00:42:32,950 objects. 971 00:42:32,950 --> 00:42:35,830 And that's why it was the first one that we designed. 972 00:42:35,830 --> 00:42:39,700 Well, in fact, it seems to cover a very wide range of objects. 973 00:42:39,700 --> 00:42:42,700 Can you give an example of another kind of object adaptor 974 00:42:42,700 --> 00:42:44,030 that would be quite different? 975 00:42:44,030 --> 00:42:48,810 Well, the next one that we're likely to try to standardize 976 00:42:48,810 --> 00:42:51,880 is the one that we call the library object adapter. 977 00:42:51,880 --> 00:42:55,360 And this is for objects that I might call toolkit style 978 00:42:55,360 --> 00:42:58,000 implementations, things that you would normally expect 979 00:42:58,000 --> 00:43:01,090 to be in an object library. 980 00:43:01,090 --> 00:43:03,730 The objects are fine grained and very lightweight, 981 00:43:03,730 --> 00:43:07,270 things like buttons in a Windows system toolkit or simple data 982 00:43:07,270 --> 00:43:08,553 structures. 983 00:43:08,553 --> 00:43:09,970 The difference in these objects is 984 00:43:09,970 --> 00:43:11,740 that they're expected to co-reside 985 00:43:11,740 --> 00:43:13,570 with the client, which means that you have 986 00:43:13,570 --> 00:43:15,740 to be very for writing the environmental impact 987 00:43:15,740 --> 00:43:17,810 statement of the object because it 988 00:43:17,810 --> 00:43:22,763 could have impact on the client that's trying to use it. 989 00:43:22,763 --> 00:43:24,680 But it also has a simpler notion of activation 990 00:43:24,680 --> 00:43:26,888 because it's assumed to be activated with the client. 991 00:43:26,888 --> 00:43:29,450 So you don't have to do a lot of separate work. 992 00:43:29,450 --> 00:43:30,780 There's no ORB state. 993 00:43:30,780 --> 00:43:32,750 We're trying to keep these things lightweight. 994 00:43:32,750 --> 00:43:34,880 And the assumption is that these aren't 995 00:43:34,880 --> 00:43:37,070 going to be externally visible, although there 996 00:43:37,070 --> 00:43:39,777 are ways to make them visible if you pass them out. 997 00:43:39,777 --> 00:43:40,610 There's no security. 998 00:43:40,610 --> 00:43:42,770 If you're going to live with the client, 999 00:43:42,770 --> 00:43:45,370 it presumably can do to you whatever it wants. 1000 00:43:45,370 --> 00:43:48,470 And the main reason for supporting this different style 1001 00:43:48,470 --> 00:43:52,160 of object is that we expect to have much stronger performance 1002 00:43:52,160 --> 00:43:53,990 requirements to be able to do thousands 1003 00:43:53,990 --> 00:43:56,715 of invocations per second. 1004 00:43:56,715 --> 00:43:59,090 And we can probably do this because there isn't security. 1005 00:43:59,090 --> 00:44:00,257 There isn't the extra state. 1006 00:44:00,257 --> 00:44:02,222 And they have limited visibility. 1007 00:44:02,222 --> 00:44:03,680 But these do sound quite different. 1008 00:44:03,680 --> 00:44:07,160 Won't that mean that when I use a BOA object or a LOA object, 1009 00:44:07,160 --> 00:44:10,640 I'll have to do different things to use those different objects? 1010 00:44:10,640 --> 00:44:12,650 Well, no, the whole goal here is to make it 1011 00:44:12,650 --> 00:44:14,750 so that clients use the objects the same way 1012 00:44:14,750 --> 00:44:18,380 and aren't aware of the choice of object adapter. 1013 00:44:18,380 --> 00:44:21,428 This is why we want to make it so that if a client has 1014 00:44:21,428 --> 00:44:23,720 an object that happens to be implemented by the library 1015 00:44:23,720 --> 00:44:25,970 object adapter and it passes it, say, 1016 00:44:25,970 --> 00:44:28,820 on a call using an object that's implemented by the basic object 1017 00:44:28,820 --> 00:44:31,070 adapter that's going out to Mars, that we 1018 00:44:31,070 --> 00:44:32,330 will do the right thing. 1019 00:44:32,330 --> 00:44:35,480 We'll make that library adapter object 1020 00:44:35,480 --> 00:44:38,090 be available through a basic object adapter 1021 00:44:38,090 --> 00:44:40,970 so that it can be accessed externally. 1022 00:44:40,970 --> 00:44:43,520 On the other hand, we do win because for objects 1023 00:44:43,520 --> 00:44:46,640 that tend to be local and tend to be accessed locally, 1024 00:44:46,640 --> 00:44:50,303 we get the performance advantage, 1025 00:44:50,303 --> 00:44:52,220 although we do have to worry a little bit more 1026 00:44:52,220 --> 00:44:54,380 about the environmental impact statement. 1027 00:44:54,380 --> 00:44:56,030 But we still do have the generality. 1028 00:44:56,030 --> 00:44:58,130 So if it's an occasional thing that we 1029 00:44:58,130 --> 00:45:00,060 pass one of these objects to Mars, 1030 00:45:00,060 --> 00:45:03,165 we figure out how to make that work. 1031 00:45:03,165 --> 00:45:04,790 But you can see from these two examples 1032 00:45:04,790 --> 00:45:07,460 how important it is to have an object adapter. 1033 00:45:07,460 --> 00:45:12,253 These are quite different sets of requirements. 1034 00:45:12,253 --> 00:45:14,420 Unfortunately, if we would have burdened all objects 1035 00:45:14,420 --> 00:45:16,940 with having security, for example, 1036 00:45:16,940 --> 00:45:21,090 that would make the fine-grained objects much more heavy weight. 1037 00:45:21,090 --> 00:45:23,090 On the other hand, if we constrained all objects 1038 00:45:23,090 --> 00:45:26,930 to not have any state and to not do activation, 1039 00:45:26,930 --> 00:45:28,430 that would make it hard to construct 1040 00:45:28,430 --> 00:45:31,010 the range of server style objects 1041 00:45:31,010 --> 00:45:32,480 that we'd like to be able to do. 1042 00:45:32,480 --> 00:45:34,760 OK, so I'm implementing an object. 1043 00:45:34,760 --> 00:45:37,642 And you've told me about interface inheritance. 1044 00:45:37,642 --> 00:45:39,350 But you still haven't told me how I might 1045 00:45:39,350 --> 00:45:41,870 use implementation inheritance? 1046 00:45:41,870 --> 00:45:45,620 Well, that's because no one uses implementation inheritance. 1047 00:45:45,620 --> 00:45:49,160 Basically, I'm sort of opposed to implementation inheritance, 1048 00:45:49,160 --> 00:45:51,650 although there's probably some amendment 1049 00:45:51,650 --> 00:45:54,570 to the constitution that says I have to let you do it. 1050 00:45:54,570 --> 00:45:57,560 The problem is that when I do implementation inheritance, 1051 00:45:57,560 --> 00:46:00,830 I create dependencies between the part 1052 00:46:00,830 --> 00:46:03,153 that I inherit in the new part that I write that is not 1053 00:46:03,153 --> 00:46:04,070 written down anywhere. 1054 00:46:04,070 --> 00:46:06,020 The guy who wrote the original implementation 1055 00:46:06,020 --> 00:46:08,330 doesn't know what parts I depend on 1056 00:46:08,330 --> 00:46:10,820 and what parts are safe for change. 1057 00:46:10,820 --> 00:46:16,700 And I'm not sure what parts might be changed tomorrow. 1058 00:46:16,700 --> 00:46:18,800 But it turns out that the CORBA doesn't say much 1059 00:46:18,800 --> 00:46:22,040 about implementation inheritance either way. 1060 00:46:22,040 --> 00:46:24,800 The requirement is that when you register an implementation 1061 00:46:24,800 --> 00:46:27,350 for object, you have to provide an implementation for all 1062 00:46:27,350 --> 00:46:28,418 of the operations. 1063 00:46:28,418 --> 00:46:30,710 Where those methods come from and whether those methods 1064 00:46:30,710 --> 00:46:34,110 are shared with other object implementations, we don't know. 1065 00:46:34,110 --> 00:46:36,260 And in some sense, we don't care. 1066 00:46:36,260 --> 00:46:38,420 If you have a programming language that 1067 00:46:38,420 --> 00:46:40,670 supports implementation inheritance 1068 00:46:40,670 --> 00:46:43,130 and you want to build a collection of implementations 1069 00:46:43,130 --> 00:46:46,370 that reuse parts of the code, that's OK 1070 00:46:46,370 --> 00:46:48,140 as far as CORBA is concerned. 1071 00:46:48,140 --> 00:46:51,170 But it's important not to assume that because you 1072 00:46:51,170 --> 00:46:53,750 used implementation inheritance in your implementation 1073 00:46:53,750 --> 00:46:55,310 that that's going to have any effect 1074 00:46:55,310 --> 00:46:57,140 on other implementations, because there's 1075 00:46:57,140 --> 00:46:59,660 no way to force other implementations to reuse 1076 00:46:59,660 --> 00:47:01,410 any parts of your code. 1077 00:47:01,410 --> 00:47:04,910 It's always possible for them to write it all from scratch. 1078 00:47:04,910 --> 00:47:06,800 But what I might suggest as an alternative 1079 00:47:06,800 --> 00:47:08,810 to implementation inheritance is what 1080 00:47:08,810 --> 00:47:10,640 is usually called delegation. 1081 00:47:10,640 --> 00:47:13,670 And it's effectively using another object 1082 00:47:13,670 --> 00:47:15,860 for some of the methods, performing operations 1083 00:47:15,860 --> 00:47:19,130 on that other object to get those methods. 1084 00:47:19,130 --> 00:47:22,040 It's safe because you're using that other object abstractly. 1085 00:47:22,040 --> 00:47:24,470 You're just invoking operations the same way anybody else 1086 00:47:24,470 --> 00:47:25,490 might be able to. 1087 00:47:25,490 --> 00:47:28,670 And the fact that you're doing your operations by invoking 1088 00:47:28,670 --> 00:47:31,880 its operations, that's fine. 1089 00:47:31,880 --> 00:47:34,410 So my standard phrase in this area 1090 00:47:34,410 --> 00:47:38,480 is that I want objects to use, not to be reused. 1091 00:47:38,480 --> 00:47:41,260 Reuse implies that I'm going to do something partial 1092 00:47:41,260 --> 00:47:42,260 with the implementation. 1093 00:47:42,260 --> 00:47:43,670 It requires me to understand something 1094 00:47:43,670 --> 00:47:44,880 about the implementation. 1095 00:47:44,880 --> 00:47:46,400 And it adds this dependence. 1096 00:47:46,400 --> 00:47:49,010 Use implies that I'm going to have a coherent abstraction. 1097 00:47:49,010 --> 00:47:50,510 I'm just going to use the interface, 1098 00:47:50,510 --> 00:47:52,907 and I get the clean separation that I want. 1099 00:47:52,907 --> 00:47:55,292 [MUSIC PLAYING] 1100 00:47:55,292 --> 00:47:59,110 1101 00:47:59,110 --> 00:48:02,770 Well, we've talked about how I could use the objects out there 1102 00:48:02,770 --> 00:48:03,340 in the world. 1103 00:48:03,340 --> 00:48:06,010 And you've told me how I can implement some of those objects 1104 00:48:06,010 --> 00:48:07,030 out there. 1105 00:48:07,030 --> 00:48:09,740 But what about this ORB that makes all this happen? 1106 00:48:09,740 --> 00:48:12,430 Can you tell me about what's going on inside the ORB? 1107 00:48:12,430 --> 00:48:14,800 Well, sure, now, remember CORBA was 1108 00:48:14,800 --> 00:48:16,270 designed to allow the integration 1109 00:48:16,270 --> 00:48:17,810 of different systems. 1110 00:48:17,810 --> 00:48:21,280 So it's hard for me to tell you what any one of them will do. 1111 00:48:21,280 --> 00:48:25,240 But we do have some experience with the style of system. 1112 00:48:25,240 --> 00:48:26,950 And we do know that there is sort 1113 00:48:26,950 --> 00:48:30,210 of a range of possibilities. 1114 00:48:30,210 --> 00:48:32,710 Remember, we want to be able to adapt some existing systems, 1115 00:48:32,710 --> 00:48:34,730 but we probably will build some from scratch. 1116 00:48:34,730 --> 00:48:35,800 And it might be interesting to think 1117 00:48:35,800 --> 00:48:37,842 about what some of those ones that would be built 1118 00:48:37,842 --> 00:48:39,310 from scratch might look like. 1119 00:48:39,310 --> 00:48:42,340 Currently most ORBs are designed to be systems that 1120 00:48:42,340 --> 00:48:45,160 are approximately RPC style. 1121 00:48:45,160 --> 00:48:48,220 The object references used to locate the server. 1122 00:48:48,220 --> 00:48:52,240 You use the RPC mechanism to actually pass the request. 1123 00:48:52,240 --> 00:48:54,873 It has the advantage that RPC systems already exist. 1124 00:48:54,873 --> 00:48:56,290 You have the advantage of building 1125 00:48:56,290 --> 00:48:59,260 on widespread technology that works in a distributed 1126 00:48:59,260 --> 00:49:00,610 environment. 1127 00:49:00,610 --> 00:49:03,730 And it's good to have that to fall back on. 1128 00:49:03,730 --> 00:49:06,880 If you build an ORB that is better in some way 1129 00:49:06,880 --> 00:49:10,090 but more limited, that's going to make it hard 1130 00:49:10,090 --> 00:49:12,250 for you to get access to all the things out there. 1131 00:49:12,250 --> 00:49:14,410 And having another ORB that you can fall back on 1132 00:49:14,410 --> 00:49:17,500 to get access to that wider set of services 1133 00:49:17,500 --> 00:49:19,960 is always a good idea. 1134 00:49:19,960 --> 00:49:22,990 The ideal ORB is probably something 1135 00:49:22,990 --> 00:49:25,360 like an object microkernel. 1136 00:49:25,360 --> 00:49:26,740 You can make it be efficient. 1137 00:49:26,740 --> 00:49:28,690 You can make it be secure. 1138 00:49:28,690 --> 00:49:31,660 You can forward a request up to networking software 1139 00:49:31,660 --> 00:49:33,790 when you have the cross machine boundaries. 1140 00:49:33,790 --> 00:49:40,450 And here in some labs, we have a research prototype on Spark 1141 00:49:40,450 --> 00:49:43,300 that can do a cross address space call in about 100 cycles. 1142 00:49:43,300 --> 00:49:46,810 So we can see that we can get fairly reasonable performance 1143 00:49:46,810 --> 00:49:49,780 if we design the microkernel to be object oriented 1144 00:49:49,780 --> 00:49:51,042 from the start. 1145 00:49:51,042 --> 00:49:53,500 In addition, there are a number of other optimizations that 1146 00:49:53,500 --> 00:49:56,860 are possible, for example, being able to pass parameters 1147 00:49:56,860 --> 00:49:58,900 and shared memory and having memory 1148 00:49:58,900 --> 00:50:02,860 shared between the client and the implementation. 1149 00:50:02,860 --> 00:50:04,960 Object systems have sort of gotten a bad rap 1150 00:50:04,960 --> 00:50:06,730 for being slow. 1151 00:50:06,730 --> 00:50:10,990 And we've spent a lot of time in our research 1152 00:50:10,990 --> 00:50:14,668 and also in doing the CORBA architecture to make sure 1153 00:50:14,668 --> 00:50:16,460 that there is room there for optimizations, 1154 00:50:16,460 --> 00:50:19,090 that we can get the performance that we 1155 00:50:19,090 --> 00:50:23,800 need to make these things be used all the time every day. 1156 00:50:23,800 --> 00:50:25,750 And it's important to understand that as we 1157 00:50:25,750 --> 00:50:27,730 do these kinds of optimizations, as we change 1158 00:50:27,730 --> 00:50:31,390 from RPC to microkernel to shared memory ORB 1159 00:50:31,390 --> 00:50:33,610 implementation, the client and the implementation 1160 00:50:33,610 --> 00:50:34,460 stay the same. 1161 00:50:34,460 --> 00:50:38,620 So what the client sees, what the implementation sees, 1162 00:50:38,620 --> 00:50:41,200 what the code they write is is the same. 1163 00:50:41,200 --> 00:50:45,490 And we're replacing the ORB and the communication mechanisms 1164 00:50:45,490 --> 00:50:49,030 between in a transparent way. 1165 00:50:49,030 --> 00:50:51,940 Now, it turns out the clients can use different ORBs 1166 00:50:51,940 --> 00:50:54,410 simultaneously. 1167 00:50:54,410 --> 00:50:56,620 And this is basically an application 1168 00:50:56,620 --> 00:51:00,790 of object-oriented design to the way you access the stubs. 1169 00:51:00,790 --> 00:51:02,985 And by making the particular stubs be associated 1170 00:51:02,985 --> 00:51:05,110 with the particular piece of data that's the object 1171 00:51:05,110 --> 00:51:08,110 reference, we can make it so that you 1172 00:51:08,110 --> 00:51:11,170 can get to the right stub for that object reference 1173 00:51:11,170 --> 00:51:12,940 right away and then be doing code 1174 00:51:12,940 --> 00:51:16,520 that is appropriate for that particular implementation. 1175 00:51:16,520 --> 00:51:18,670 So you can see that we provided a number of places 1176 00:51:18,670 --> 00:51:22,720 in the architecture where we can get leverage on performance-- 1177 00:51:22,720 --> 00:51:26,080 in the ORB itself, by using stubs and skeletons to allow 1178 00:51:26,080 --> 00:51:30,190 us to have the ORB implemented as efficiently as possible 1179 00:51:30,190 --> 00:51:32,950 and bringing that right up to the programming language level, 1180 00:51:32,950 --> 00:51:35,080 in the structure of the implementations, 1181 00:51:35,080 --> 00:51:38,170 in the interfaces provided by the object adaptor 1182 00:51:38,170 --> 00:51:40,360 to make them allow us to have the best 1183 00:51:40,360 --> 00:51:45,130 possible implementations, and in the support for multiple ORBs 1184 00:51:45,130 --> 00:51:47,583 so that you could have ORBs that are optimized 1185 00:51:47,583 --> 00:51:49,000 for different situations and could 1186 00:51:49,000 --> 00:51:50,480 have different characteristics. 1187 00:51:50,480 --> 00:51:52,480 Well, you talked about all these different ORBs. 1188 00:51:52,480 --> 00:51:55,050 It would seem important that these ORBs talk to each other. 1189 00:51:55,050 --> 00:51:58,972 So what does OMG and the CORBA say about interoperability? 1190 00:51:58,972 --> 00:52:00,430 Well, the first thing to understand 1191 00:52:00,430 --> 00:52:03,100 is that useful interoperability has to be brought up 1192 00:52:03,100 --> 00:52:04,263 to the application level. 1193 00:52:04,263 --> 00:52:05,680 What really matters is can my word 1194 00:52:05,680 --> 00:52:07,480 processor use your spreadsheet? 1195 00:52:07,480 --> 00:52:08,980 And there's a lot of agreements that 1196 00:52:08,980 --> 00:52:11,380 have to happen there-- data formats, protocols, 1197 00:52:11,380 --> 00:52:15,220 how we rendezvous, update policies, and stuff like that. 1198 00:52:15,220 --> 00:52:18,130 CORBA addresses it at the lowest level to get us going. 1199 00:52:18,130 --> 00:52:19,900 And sometimes it's like the telegraph. 1200 00:52:19,900 --> 00:52:22,100 We've agreed on Morse code. 1201 00:52:22,100 --> 00:52:24,160 So we have the basic communication mechanism 1202 00:52:24,160 --> 00:52:26,710 that we can use and everybody knows 1203 00:52:26,710 --> 00:52:28,570 how to transmit Morse code back and forth, 1204 00:52:28,570 --> 00:52:31,692 whether they're doing it over radio waves or over wires. 1205 00:52:31,692 --> 00:52:33,400 But unfortunately, we haven't yet agreed, 1206 00:52:33,400 --> 00:52:35,483 are we speaking French or are we speaking English? 1207 00:52:35,483 --> 00:52:38,590 And OMG is working on some of these higher level 1208 00:52:38,590 --> 00:52:41,860 agreements that are going to make interoperability up 1209 00:52:41,860 --> 00:52:44,630 to the application level actually be possible. 1210 00:52:44,630 --> 00:52:47,530 However, we have focused on making it possible for ORBs 1211 00:52:47,530 --> 00:52:50,410 to connect together, because we agree that the things being 1212 00:52:50,410 --> 00:52:55,120 communicated are object in locations and parameters 1213 00:52:55,120 --> 00:52:57,790 that are defined in the interface definition language. 1214 00:52:57,790 --> 00:53:00,610 We can plug them together using something 1215 00:53:00,610 --> 00:53:03,010 very analogous to a telegraph repeater, which 1216 00:53:03,010 --> 00:53:05,170 has sort of a clicker connected to another key that 1217 00:53:05,170 --> 00:53:09,170 allows you to transmit from one medium to another. 1218 00:53:09,170 --> 00:53:12,950 We can have the same concept in ORBs, which we call a gateway. 1219 00:53:12,950 --> 00:53:16,960 A gateway knows how to understand request from the two 1220 00:53:16,960 --> 00:53:18,730 ORBs that it's connecting together 1221 00:53:18,730 --> 00:53:21,745 and translates the data formats and passes the information. 1222 00:53:21,745 --> 00:53:23,740 It takes a request from one side and turns it 1223 00:53:23,740 --> 00:53:25,990 into a request on the other side. 1224 00:53:25,990 --> 00:53:27,520 One of the subtle parts about this 1225 00:53:27,520 --> 00:53:30,550 is that when I pass an object reference from one ORB 1226 00:53:30,550 --> 00:53:32,560 to another, what I want to do is replace it 1227 00:53:32,560 --> 00:53:34,990 with an object reference that points back to the gateway. 1228 00:53:34,990 --> 00:53:38,073 So that when I'm over in this ORB and I make a request, 1229 00:53:38,073 --> 00:53:39,490 I get back to the gateway and then 1230 00:53:39,490 --> 00:53:44,620 it knows how to pass that request onto the object 1231 00:53:44,620 --> 00:53:46,450 in the other ORB. 1232 00:53:46,450 --> 00:53:49,307 So with CORBA, a program can use objects 1233 00:53:49,307 --> 00:53:50,890 that are implemented in different ORBs 1234 00:53:50,890 --> 00:53:55,000 either because the environment that that program is running in 1235 00:53:55,000 --> 00:53:59,230 has access to multiple ORBs or because it's accessing objects 1236 00:53:59,230 --> 00:54:03,490 that have been passed to it from another ORB through a gateway. 1237 00:54:03,490 --> 00:54:06,460 And as I mentioned earlier, the CORBA 1238 00:54:06,460 --> 00:54:10,030 is trying to integrate different object systems. 1239 00:54:10,030 --> 00:54:12,280 It turns out now we can look back and see that there's 1240 00:54:12,280 --> 00:54:14,738 actually three different ways that I could take an existing 1241 00:54:14,738 --> 00:54:17,920 object system and figure out how to get a connect into the CORBA 1242 00:54:17,920 --> 00:54:18,790 architecture. 1243 00:54:18,790 --> 00:54:20,740 One is I can make the object system appear 1244 00:54:20,740 --> 00:54:22,570 as a normal object implementation 1245 00:54:22,570 --> 00:54:24,760 and have its objects registered with the ORB 1246 00:54:24,760 --> 00:54:26,230 and exported through it. 1247 00:54:26,230 --> 00:54:29,470 A second way is to use a special object adapter, which 1248 00:54:29,470 --> 00:54:32,890 would allow any differences between the type system 1249 00:54:32,890 --> 00:54:37,390 and the method of operation of the new object system 1250 00:54:37,390 --> 00:54:40,343 to be able to be translated into the ORB. 1251 00:54:40,343 --> 00:54:42,760 And the third way is that I can think of the object system 1252 00:54:42,760 --> 00:54:44,890 as an ORB in itself and then simply build 1253 00:54:44,890 --> 00:54:47,950 a gateway between that object system and the ORB. 1254 00:54:47,950 --> 00:54:50,620 Whichever way works best is going 1255 00:54:50,620 --> 00:54:52,930 to depend upon what the object system is, 1256 00:54:52,930 --> 00:54:55,180 what its characteristics are, and how much freedom you 1257 00:54:55,180 --> 00:54:57,030 have to go back and change it. 1258 00:54:57,030 --> 00:55:00,820 I see we have an object system for system software. 1259 00:55:00,820 --> 00:55:02,960 But where does the CORBA go from here? 1260 00:55:02,960 --> 00:55:05,417 Well, currently there is about a half a dozen-- 1261 00:55:05,417 --> 00:55:07,000 there may be more since they don't all 1262 00:55:07,000 --> 00:55:09,190 have to register with me-- 1263 00:55:09,190 --> 00:55:11,360 implementations in progress in different companies. 1264 00:55:11,360 --> 00:55:12,610 Some of them are from scratch. 1265 00:55:12,610 --> 00:55:15,565 Some of them are adapting existing object systems. 1266 00:55:15,565 --> 00:55:17,440 There's currently widespread support for this 1267 00:55:17,440 --> 00:55:20,980 because it does meet the needs of object systems. 1268 00:55:20,980 --> 00:55:23,750 It allows objects systems to work together. 1269 00:55:23,750 --> 00:55:25,780 And it's the first object architecture 1270 00:55:25,780 --> 00:55:27,880 that seriously addresses openness 1271 00:55:27,880 --> 00:55:30,880 and the evolution of software in the presence 1272 00:55:30,880 --> 00:55:32,930 of strong interfaces. 1273 00:55:32,930 --> 00:55:35,830 So the OMG is working to refine CORBA, 1274 00:55:35,830 --> 00:55:39,280 to add some more language bindings and things like that. 1275 00:55:39,280 --> 00:55:42,130 And it's also using CORBA and IDL 1276 00:55:42,130 --> 00:55:45,070 as the basis for defining the further services that they're 1277 00:55:45,070 --> 00:55:46,838 trying to standardize on. 1278 00:55:46,838 --> 00:55:49,228 [MUSIC PLAYING] 1279 00:55:49,228 --> 00:55:52,100 1280 00:55:52,100 --> 00:55:54,610 So to try to summarize, we've sort of 1281 00:55:54,610 --> 00:55:59,350 talked about the challenges of system software for object 1282 00:55:59,350 --> 00:56:03,280 technology and talked about how important interfaces 1283 00:56:03,280 --> 00:56:06,130 are for this definitional property, 1284 00:56:06,130 --> 00:56:10,810 providing this taxonomy to the services and components, 1285 00:56:10,810 --> 00:56:15,190 and focusing on the issues of multiple, evolving, and open 1286 00:56:15,190 --> 00:56:17,170 implementations. 1287 00:56:17,170 --> 00:56:19,030 We've developed language bindings 1288 00:56:19,030 --> 00:56:20,740 to try to make this stuff as convenient 1289 00:56:20,740 --> 00:56:25,150 as possible for both the clients and the implementations. 1290 00:56:25,150 --> 00:56:27,040 And the architecture supports a variety 1291 00:56:27,040 --> 00:56:30,610 of different implementations in objects themselves, in the ORB 1292 00:56:30,610 --> 00:56:33,730 itself, and provides lots of opportunities 1293 00:56:33,730 --> 00:56:35,860 for optimization and extension. 1294 00:56:35,860 --> 00:56:40,450 And it does accomplish one of the major goals of OMG 1295 00:56:40,450 --> 00:56:42,700 in asking for the ORB in the first place, which 1296 00:56:42,700 --> 00:56:45,610 is it provides a variety of choices for how object 1297 00:56:45,610 --> 00:56:47,247 systems connect together. 1298 00:56:47,247 --> 00:56:51,479 [MUSIC PLAYING] 1299 00:56:51,479 --> 00:57:57,000