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