Introduction to Java Distributed Objects-Using RMI and CORBA
Introduction to Java Distributed Objects - Using RMI and CORBA
Welcome to the Course Description: Architecture (CORBA) Prerequisites: To get the most out of this course.you need to be an experienced Java programmer Objectives: When you have completed the course.you should be able to: .Contrast RMI and CORBA both at the conceptual and technical levels .Write simple RMI and CORBA programs using the Java Development Kit (JDK) version 1.2 Welcome to the Java distributed objects course!Before we start.let's cover a few details.First of all,what should your background be?To get the most out the course,you already be a pretty good Java programmer.We will not cover any Java syntax.In particular,you should be comfortable with the notions of classes,interfaces,applications and applets.You don't need any background in distributed objects,however. When you finish the course,you should have a pretty good idea about how distributed objects work in Java.You should also be able to code simple programs using either RMI or CORBA. Now on to our agenda!
Welcome to the Course Description: This course introduces how to program distributed objects using Java Remote Method Invocation (RMI) and using the Common Object Request Broker Architecture (CORBA) Prerequisites: To get the most out of this course, you need to be an experienced Java programmer Objectives: When you have completed the course, you should be able to: Contrast RMI and CORBA both at the conceptual and technical levels Write simple RMI and CORBA programs using the Java Development Kit (JDK) version 1.2 Welcome to the Java distributed objects course! Before we start, let's cover a few details. First of all, what should your background be? To get the most out the course, you already be a pretty good Java programmer. We will not cover any Java syntax. In particular, you should be comfortable with the notions of classes, interfaces, applications and applets. You don't need any background in distributed objects, however. When you finish the course, you should have a pretty good idea about how distributed objects work in Java. You should also be able to code simple programs using either RMI or CORBA. Now on to our agenda!
Agenda using technol to solve a distributed office environment problem Coding with Java RMI--a complete introduction Coding with CORBA using the JDK 1.2 Object Request Broker Here's what we will cover in this course:We'll start by using an analogy to introduce the notion of distributed processing-we'll look at a fictitious company with growing pains and how they used technology to make their distributed office environment work.Then we'll take these notions and use Java RMI and CORBA to solve a similar programming problem,that is,how to access objects that reside on different computers. While doing so,you will see actual coding samples that use RMI and CORBA.We will place special emphasis on the deployment of these coding samples,since it turns out that deployment is the often the hardest part of using these technologies. But let's get started by looking at the Twisted Transistor company,which needs to grow while remaining efficient
Agenda An analogy - using technology to solve a distributed office environment problem An introduction to distributed object technologies Coding with Java RMI -- a complete introduction Coding with CORBA using the JDK 1.2 Object Request Broker Here's what we will cover in this course: We'll start by using an analogy to introduce the notion of distributed processing - we'll look at a fictitious company with growing pains and how they used technology to make their distributed office environment work. Then we'll take these notions and use Java RMI and CORBA to solve a similar programming problem, that is, how to access objects that reside on different computers. While doing so, you will see actual coding samples that use RMI and CORBA. We will place special emphasis on the deployment of these coding samples, since it turns out that deployment is the often the hardest part of using these technologies. But let's get started by looking at the Twisted Transistor company, which needs to grow while remaining efficient
Twisted Transistors,Inc.:the Beginning Once upon a time.Jill and Bill started a new company named Twisted Transistor,Inc.to manufacture LCD panels for laptop computers.At the beginning,with only a few people in the company,and only one building,life was easy.When they needed to meet,they just walked over to someone's office and hashed things out.All of their work was done at one location,and communication was simple
Twisted Transistors, Inc. : the Beginning Once upon a time, Jill and Bill started a new company named Twisted Transistor, Inc. to manufacture LCD panels for laptop computers. At the beginning, with only a few people in the company, and only one building, life was easy. When they needed to meet, they just walked over to someone's office and hashed things out. All of their work was done at one location, and communication was simple
Twisted Transistors,Inc.:Growing Pains But then a funny thing happened:the company grew,and soon found that it needed more space.The problem was,office space was expensive in their town,so they rented a building in Silver City,10 miles away.This gave them more space to work and to manufacture product,but now things that were easy before became difficult. For example,running a meeting was a nightmare compared to before.How could they get all of the meeting participants together?First they tried shuttling employees from one building to another,but that wasted too much time in transit.Then they tried conference calling,but found that to be awkward and it was difficult to show technical diagrams and presentations to each other. What Twisted Transistors needed was a way to make it seem like employees were together,when in fact they were spread out geographically
Twisted Transistors, Inc.: Growing Pains But then a funny thing happened: the company grew, and soon found that it needed more space. The problem was, office space was expensive in their town, so they rented a building in Silver City, 10 miles away. This gave them more space to work and to manufacture product, but now things that were easy before became difficult. For example, running a meeting was a nightmare compared to before. How could they get all of the meeting participants together? First they tried shuttling employees from one building to another, but that wasted too much time in transit. Then they tried conference calling, but found that to be awkward and it was difficult to show technical diagrams and presentations to each other. What Twisted Transistors needed was a way to make it seem like employees were together, when in fact they were spread out geographically
Twisted Transistors,Inc.:Communication Nirvana! To solve their meeting problem,Twisted Transistors purchased a communication system that included a virtual whiteboard and video teleconferencing.With the new system,even though the employees were located in another city,they could interact almost as if they were physically together.That way,the company could take advantage of the lower overhead costs in Silver City,but still all work as a group. This solution required an infrastructure--the two buildings needed to be connected with a leased-line network system and required special setup instructions to start the whiteboard and teleconferencing. The system wasn't perfect,but it was the best available until Star-Trek-like transporters become available
Twisted Transistors, Inc.: Communication Nirvana! To solve their meeting problem, Twisted Transistors purchased a communication system that included a virtual whiteboard and video teleconferencing. With the new system, even though the employees were located in another city, they could interact almost as if they were physically together. That way, the company could take advantage of the lower overhead costs in Silver City, but still all work as a group. This solution required an infrastructure -- the two buildings needed to be connected with a leased-line network system and required special setup instructions to start the whiteboard and teleconferencing. The system wasn't perfect, but it was the best available until Star-Trek-like transporters become available
Introduction to Distributed Objects client computer object server computer remote object The big problem Twisted Transistor had was making people in a remote location easily accessible.We can have the same issue with applications that we write.Often, applications grow,just like Twisted Transistor did-the program might start out as a single-user program,but may expand to allow multiple people to access the program at the same time. And remember,Java is an object-oriented language,so our real problem is:how do we work it so that programs running one computer can call methods on objects that reside on another?If we can pull this off,then we can distribute the computing load across networks-instead of writing standalone,single user programs,we can write programs that fully utilize our network. Such programming is often referred to as client/server programming-the program issuing the method calls is the client,and the computer that supplies the remote object is the server. Twisted Transistor solved their meeting problem by allowing people in separate offices to interact naturally-our goal here is to find technology so that remote and local objects can interact naturally
Introduction to Distributed Objects remote object client computer object server computer The big problem Twisted Transistor had was making people in a remote location easily accessible. We can have the same issue with applications that we write. Often, applications grow, just like Twisted Transistor did - the program might start out as a single-user program, but may expand to allow multiple people to access the program at the same time. And remember, Java is an object-oriented language, so our real problem is: how do we work it so that programs running one computer can call methods on objects that reside on another? If we can pull this off, then we can distribute the computing load across networks - instead of writing standalone, single user programs, we can write programs that fully utilize our network. Such programming is often referred to as client/server programming - the program issuing the method calls is the client, and the computer that supplies the remote object is the server. Twisted Transistor solved their meeting problem by allowing people in separate offices to interact naturally - our goal here is to find technology so that remote and local objects can interact naturally
Why Java for Distributed Objects? Java is an easy-to-use,intuitive language that enforces O-O programming Java works on many platforms .The Java infrastructure can automatically download code to client computers Java tools are becoming mature and widespread .Potential downside:execution speed versus compiled languages like C++ If you've decided that distributed objects are a good thing,your next job is to choose a distributed object infrastructure and your programming language.We'll come back on the infrastructure part in just a moment,but now let's talk about the programming language. This tutorial covers distributed objects using the Java programming language.Why Java?Because Java is ideally suited to the task.Most distributed object programs run on a mixture of operating systems,for example Windows for the client and a UNIX variant such as IBM's AIX for the server.Since Java itself is platform neutral,it lets you develop,test and deploy across different platforms without having to change languages In addition,the tool market for Java is exploding.Vendors such as IBM are developing powerful application servers that serve up Java distributed objects using technologies like Enterprise Java Beans.While we will not cover EJBs here,their use of Java helps to validate our choice of Java for this tutorial. Finally,we would be remiss if we didn't at least mention that Java is not always the solution.During this program,we will discuss one infrastructure technology,CORBA, that lets you use compiled languages such as C++whenever performance is the ultimate criteria
Why Java for Distributed Objects? Java is an easy-to-use, intuitive language that enforces O-O programming Java works on many platforms The Java infrastructure can automatically download code to client computers Java tools are becoming mature and widespread Potential downside: execution speed versus compiled languages like C++ If you've decided that distributed objects are a good thing, your next job is to choose a distributed object infrastructure and your programming language. We'll come back on the infrastructure part in just a moment, but now let's talk about the programming language. This tutorial covers distributed objects using the Java programming language. Why Java? Because Java is ideally suited to the task. Most distributed object programs run on a mixture of operating systems, for example Windows for the client and a UNIX variant such as IBM's AIX for the server. Since Java itself is platform neutral, it lets you develop, test and deploy across different platforms without having to change languages. In addition, the tool market for Java is exploding. Vendors such as IBM are developing powerful application servers that serve up Java distributed objects using technologies like Enterprise Java Beans. While we will not cover EJBs here, their use of Java helps to validate our choice of Java for this tutorial. Finally, we would be remiss if we didn't at least mention that Java is not always the solution. During this program, we will discuss one infrastructure technology, CORBA, that lets you use compiled languages such as C++ whenever performance is the ultimate criteria
Distributed Object Infrastructures Java Remote Method Invocation(RMI Common Object Request Broker Architecture(CORBA) .Microsoft's Distributed Component Object Model(DCOM) Enterprise Java Beans (EJB) Here we show a list of some of the important infrastructure technologies for developing distributed objects.In this tutorial,we will concentrate on the first two and compare and contrast them. That's not to say that other technologies have no merit;just that we will not cover them here. Finally,many experts in the distributed object field believe that eventually,all of these technologies will interoperate,so that clients and servers of each type will be able to communicate with objects on servers of other types
Distributed Object Infrastructures Java Remote Method Invocation (RMI) Common Object Request Broker Architecture (CORBA) Microsoft's Distributed Component Object Model (DCOM) Enterprise Java Beans (EJB) Here we show a list of some of the important infrastructure technologies for developing distributed objects. In this tutorial, we will concentrate on the first two and compare and contrast them. That's not to say that other technologies have no merit; just that we will not cover them here. Finally, many experts in the distributed object field believe that eventually, all of these technologies will interoperate, so that clients and servers of each type will be able to communicate with objects on servers of other types
Introduction to RMI client Sample Client Code server MyRemoteobject o =... o.myMethod () remote obiect Note:All of the code in this course has been compiled and tested with JDK 1.2. Release Candidate 1.Please consult the documentation for the version of the JDK that you are using for details on changes for that version. We will start our discussion of distributed object technologies with Java's Remote Method Invocation,which was introduced in Java 1.1. RMI's purpose is to make objects in separate virtual machines look and act like local objects.The virtual machine that calls the remote object is sometimes referred to as a client.Similarly,we refer to the VM that contains the remote as a server. Obtaining a reference for a remote object is a bit different than for local objects,but once you have the reference,you call the remote object just as if it was local as shown in the code snippet.The RMI infrastucture will automatically intercept the request,find the remote object,and dispatch the request remotely. This location transparency even includes garbage collection.In other words, the client doesn't have to do anything special to release the remote object-- the RMI infrastructure and the remote VM handle the garbage collection for you
Introduction to RMI MyRemoteObject o = ...; o.myMethod (); Sample Client Code client server remote object Note: All of the code in this course has been compiled and tested with JDK 1.2, Release Candidate 1. Please consult the documentation for the version of the JDK that you are using for details on changes for that version. We will start our discussion of distributed object technologies with Java's Remote Method Invocation, which was introduced in Java 1.1. RMI's purpose is to make objects in separate virtual machines look and act like local objects. The virtual machine that calls the remote object is sometimes referred to as a client. Similarly, we refer to the VM that contains the remote as a server. Obtaining a reference for a remote object is a bit different than for local objects, but once you have the reference, you call the remote object just as if it was local as shown in the code snippet. The RMI infrastucture will automatically intercept the request, find the remote object, and dispatch the request remotely. This location transparency even includes garbage collection. In other words, the client doesn't have to do anything special to release the remote object -- the RMI infrastructure and the remote VM handle the garbage collection for you
