Advanced Java 2 Platform HOW TO PROGRAM phần 9 ppt

1434 Jiro Chapter 25 printer. This connection could be performed via any popular management protocol (SNMP, WEBM, RMI, etc.). For this exercise: a) Define interface RemotePrinter which exposes the management operations of class Printer (Fig. 25.8). RemotePrinter must extend interface Remote. Create a stand-alone application, RemotePrinterImpl, that starts a Printer thread. Class RemotePrinterImpl must implement RemotePrinter interface. Remote- PrinterImpl must post an RMI stub reference of itself in the Jini lookup service of the Jiro domain. Class RemotePrinterImpl must delegate any remote method calls to its Printer instance. b) Modify PrinterManagementImpl (Fig. 25.5) to retrieve a RemotePrinter stub from the Jini lookup service of the local Jiro domain. PrinterManagement dynamic service must delegate all printer management operations to stub RemotePrinter. BIBLIOGRAPHY "Declaring a Class as a Dynamic Service." Jiro Web site. <www.jiro.com/education/rec- ipes/service/>. Deri, L. “Network Management for the 90s,” Paper, IBM Zurich Research Laboratory, University of Berne. <www.sce.carleton.ca/netmanage/NMfor90s/SimpleNM.html>. “Executive Overview.” Jiro Web site. <www.jiro.com/overview/>. “Frequently Asked Questions.” Jiro Web site. <www.jiro.com/faqs/>. “Jiro Document Center.” Jiro Web site. <jiro.com/documentcenter/>. “Jiro Recipes.” Jiro Web site. <jiro.com/education/recipes/>. “Jiro Technical Overview.” Jiro Web site. <www.jiro.com/overview/ tech_overview.html>. “Jiro Technology Discussion Forum.” Jiro Web site. <www.jiro.com/cgi-bin/Ulti- mate.cgi?action=intro>. Monday, P., and W. Connor. The Jiro Technology Programmer’s Guide And Federated Management Architecture. Boston, MA: Addison-Wesley, 2001. 26 Common Object Request Broker Architecture (CORBA): Part 1 Objectives • To introduce CORBA (Common Object Request Broker Architecture). • To introduce the Interface Definition Language (IDL). • To use CORBA to develop push-model and pull- model applications. • To understand distributed exceptions. • To implement the Deitel Messenger application using CORBA. • To compare CORBA to other technologies for building distributed systems. In the master there is a servant, in the servant a master. Marcus Tullius Cicero Excellence is to do a common thing in an uncommon way. Booker T. Washington The virtue in most request is conformity. Ralph Waldo Emerson It is often wonderful how putting down on paper a clear statement of a case helps one to see, not perhaps the way out, but the way in. A.C. Benson 1436 Common Object Request Broker Architecture (CORBA): Part 1 Chapter 26 26.1 Introduction * To appreciate what Java has brought to the software-development industry in the past few years, one must first appreciate the happenings just beneath the radar screens of most de- velopers prior to Java’s introduction—the gradual acceptance that legacy systems were not going away and that there existed a need to take advantage of these systems. In addition, the explosive growth of the Web has made it critical to develop systems that can be distrib- uted (networked) “out of the box” rather than building the same communications infra- structure repeatedly. Java offered several features that made these systems possible but did not offer higher-level classes, tools or abstractions for building large-grained distributed systems in generic and predictable fashions. Java lacked the ability to make invocations on Outline 26.1 Introduction 26.2 Step-by-Step 26.3 First Example: SystemClock 26.3.1 SystemClock.idl 26.3.2 SystemClockImpl.java 26.3.3 SystemClockClient.java 26.3.4 Running the Example 26.4 Technical/Architectural Overview 26.5 CORBA Basics 26.6 Example: AlarmClock 26.6.1 AlarmClock.idl 26.6.2 AlarmClockImpl.java 26.6.3 AlarmClockClient.java 26.7 Distributed Exceptions 26.8 Case Study: Chat 26.8.1 chat.idl 26.8.2 ChatServerImpl.java 26.8.3 DeitelMessenger.java 26.8.4 Running Chat 26.8.5 Issues 26.9 Comments and Comparisons 26.10 Internet and World Wide Web Resources Summary • Terminology • Self-Review Exercises • Answers to Self-Review Exercises • Exercises • Works Cited • Bibliography *. This chapter was co-authored by Carlos Valcarcel of EinTech, Inc. Chapter 26 Common Object Request Broker Architecture (CORBA): Part 1 1437 local objects that, in reality, were invocations on remote objects. This capability would have allowed Java to make standard method calls on objects that appeared local, but were in a different process space. The supporting infrastructure was not available to Java, so ven- dors in the distributed-object arena began porting their infrastructure products to support Java. The infrastructure that was the best fit with Java turned out to be CORBA. CORBA stands for the Common Object Request Broker Architecture. More accurately, CORBA stands for “glue.” It allows programs written in various languages, with varying implementations running in disparate locations, to communicate with each other as easily as if they were in the same process address space. Conceptually, in the same way objects cooperate to accomplish specific tasks, CORBA describes architecture made of cooper- ating services. Software Engineering Observation 26.1 CORBA does not enforce good systems-integration practice; it merely enables the integra- tion of disparate systems. 26.1 CORBA relies on object technology to accomplish this. Encapsulation, inheritance, polymorphism and dynamic binding hide implementation details, making CORBA’s work appear transparent. Transparency is a crucial goal of CORBA. This transparency enables developers and system integrators to define standard services that legacy systems provide and make these services available to other systems that want to use them. Within this trans- parent infrastructure, a myriad of services are available to other users that need the services. Three areas leveraged by clients using CORBA are invocation transparency, implementa- tion transparency and location transparency. Invocation transparency defines the viewpoint of a client sending a message to a server. The language used to implement a client specifies how a called object receives a message—how arguments are passed on the stack, how the proper method is called, and how return values are delivered. Once a server (an object that is responsible for delivering a collection of related services) is defined within a CORBA framework, a client can make method calls to this CORBA-enabled object similarly as a call to any other object imple- mented within the target language. This kind of behavior is more naturally understood by developers using an object-oriented language (e.g., Java, C++, and Smalltalk), but is equally valid for developers using a non-OO language (e.g., C, COBOL, or Lisp). CORBA supports a number of object-oriented and non-object-oriented languages (10 altogether)— C, C++, Java, COBOL, Ada, Lisp, Smalltalk, PL/1, Python and IDLscript. Implementation transparency is a encapsulation applied to distributed systems. A client knows three things about a method invocation—the method name, the method parameters (if any) and the method return type. The client is not concerned with how the underlying code processes parameters and ensures returning valid values—even with per- formance considerations, the client can notify the server as to any performance constraints prior to making any method invocations. A client invokes a method in the target (client’s) language, and the code invoked to satisfy the method call is executed in any language sup- ported by an OMG mapping. Location transparency allows a client to invoke CORBA-enabled code that might exe- cute elsewhere on the network. This builds on implementation transparency—the clients appear to make local calls, but in reality, they call code that executes in different languages outside of the process space where the client is located (e.g., a Java servlet running in New 1438 Common Object Request Broker Architecture (CORBA): Part 1 Chapter 26 York communicates with a COBOL legacy database running in Japan). All of this is pos- sible because of various object-technology concepts (encapsulation, inheritance, and poly- morphism) used in implementation-independent ways. The Object Management Group (OMG) is the consortium responsible for CORBA. Founded in April 1989, the OMG’s goals are far reaching and have the backing of approx- imately 800 members. Their main goal is to create a “component-based software market- place by hastening the introduction of standardized object software.” 1 A major step toward the creation of this object marketplace was the defining of the OMG’s Object Management Architecture (OMA). The Object Management Architecture (OMA) distinguishes CORBA from other dis- tributed system technologies. Objects in an object-oriented system cooperate to achieve solutions to domain problems. The OMA (as a reference architecture) defines a system con- sisting of cooperating services solving a domain problem. The granularity of the solution is larger, but the concept of objects (or components) working together toward a common goal remains the same. So, how do the goals of systems integration, transparency, and ease of use come together, using a reference architecture in a fashion that allows multilanguage, multiplat- form, and multilocation issues to be handled in a consistent and straightforward fashion? The answer is in these three acronyms—IDL, ORB and IIOP. For objects to appear to speak the same language, they must use a common mapping to their particular language. For code in languages such as COBOL, Java, C, and Python to communicate to one another, an intermediate language must bind them. This intermediate language should be simple to use, easy to learn and have minimal overhead. OMG IDL™, the OMG Interface Definition Language (commonly referred to as IDL), allows developers to describe the interface (or API) of the data type they wish to use remotely in a language-independent fashion. IDL is a pure description language—no implementation details are included in IDL files (unless someone deliberately inserts com- ments describing implementation assumptions). Using a C++-like syntax, developers describe only two things—the interface to an object and any data structures a method call to the object may take or return as values. An IDL compiler takes an IDL file (convention- ally ending with .idl) and generates the code needed for a client to call a CORBA-com- pliant object and for the CORBA-compliant object to receive and return values. When we speak of a CORBA-compliant “object” we make no assumptions about whether it is an object in the way Java describes a object or procedural COBOL code that implements the operations (methods) defined in an IDL file in a non-object oriented fashion. The code that implements the operations (i.e., handles client requests to a CORBA object) constitutes a servant. In a non-object-oriented language there is an individual servant for each operation. In an object-oriented language, one servant (object) may implement all of the operations. The client does not know about the implementation issues involved, so a servant can exist for the duration of a method call, for until the server within which the servant is running is shut down or for some duration in between (this, however, is controlled by an object adapter which mediates all access to servants. We discuss this in more detail in Section 26.4). An IDL compiler creates a number of language-dependent files for each IDL file com- piled. A project would need as many IDL compilers as there are target languages in the system to be developed. To develop a Java front-end to a legacy COBOL system, two IDL Chapter 26 Common Object Request Broker Architecture (CORBA): Part 1 1439 compilers are needed—one to generate the client-side Java code, and one to generate the server-side COBOL code. For example, a Java front end would need the following gener- ated client-side Java files to interact with a back-end system named StockTicker: StockTicker.java StockTickerOperations.java StockTickerHolder.java StockTickerHelper.java _StockTickerStub.java StockTicker.java contains the base definition of the remote server. The StockTickerOperations source file contains method definitions of the operations that the CORBA object supports. The _StockTickerStub class is responsible for client-side communication, while the StockerTickerHelper file defines a conve- nience class usable by the client for CORBA-related tasks. These files hide the invocation mechanism from a caller. StockTicker.java and StockTickerOperations.java define interfaces for use by implementation classes; _StockTickerStub.java defines actual CORBA invocation code to make the remote method call to a server. Files StockTickerHelper.java and Stock- TickerHolder.java are additional support files that we discuss later. The vendor who supplies the server component ships an IDL file that describes the API to their server object. Using the vendor-supplied IDL file and an IDL compiler, a developer would generate the needed client-side files to talk directly to this server-side object. If a GUI written in C for the StockTicker system were to attempt to send messages to server-side objects written in Java (CORBA-enabled Java objects) the following Java files would have been generated by an IDL compiler to allow the Java server object to receive messages from any callers: StockTicker.java StockTickerOperations.java _StockTickerImplBase.java The files StockTicker.java and StockTickerOperations.java are the same as above (interfaces for use by implementation classes), and _StockTickerImplBase.java represents the CORBA code used by the server to accept method calls and deliver values across the network. In addition to declaring Java interfaces for developer use, both client-side and server- side files defined above implement base classes as proxies—stand-ins for other objects. Proxies allow a client to believe it is sending a message to one object when the client is really sending the message to another object. CORBA defines two related proxies—a stub and a skeleton. A stub is the client-side proxy and a skeleton is the server-side proxy. Both proxies hide the use of the ORB from the client and the server. The Object Request Broker is the “ORB part” of CORBA. Interoperability is the ORB’s central purpose. All CORBA-enabled objects must use an ORB to make or receive method requests, but those same objects rarely see the ORB. In the examples that follow, note the similarity of the code for connecting various pieces. This code similarity is the OMG at work. The base connectivity CORBA API is the same regardless of the CORBA implementation. 1440 Common Object Request Broker Architecture (CORBA): Part 1 Chapter 26 Portability Tip 26.1 Unless you use vendor-specific value-added features under CORBA 3.0, the replacement of an existing ORB installation with an ORB vendor’s new product should not require the mod- ification of existing CORBA code. 26.1 When a client invokes an operation on a distributed object, the client’s ORB uses an object reference to complete the invocation request. For example, if the client was written in Java, it behaves as if the reference is to a local version of the object being invoked. The object reference used by the client (supporting the public API of the object defined in the IDL file) contain an opaque network reference (opaque because neither the client nor server infer implementation details with the information contained in the reference). A client invokes operations on a distributed object through an object reference, whereas an Interoperable Object Reference (IOR) refers specifically to an object reference whose structure is well- understood by ORBs using the OMG-supported protocols (such as IIOP, discussed momen- tarily). The object reference comes from an object adapter pointing to the remote object. The object reference contains three important pieces of information—the distributed object’s location (an address, but not a memory address), a reference to the adapter that created the object reference and an object ID for the servant. All CORBA-compliant ORBs understand what object references are (and, for true interoperability, they must understand IORs) and how to use them to connect clients to servants. The final piece needed for interoperability is the creation and parsing of the IOR into the “on-the-wire” protocol to send a request across the network. 2 However, knowledge of IORs is not enough to allow one vendor’s ORB to communicate predictably with another vendor’s ORB. To enable robust, predictable communication, the OMG specified the Internet Inter-ORB Protocol or IIOP. All vendors must support IIOP (Internet Inter-ORB Protocol) for their ORBs to be CORBA-compliant. Vendors can support their own protocol as well, but, at a minimum, they must also support IIOP. IIOP is the protocol for how ORBs communicate with each other. The average developer does not need to know anything about IIOP; a CORBA site adminis- trator maintains the appropriate ORB protocol at any particular location. ORBs that expect to communicate with each other must speak the same protocol. If the ORBs support different protocols, custom bridges must be developed to map the protocols to enable communications between nonstandard-protocol ORBs. As the standard ORB protocol, IIOP should be the default protocol for any ORB installation, although IIOP is not the only choice. IIOP is the implementation of another OMG standard—the General Inter-ORB Pro- tocol, or GIOP. GIOP defines the messages needed by ORBs to communicate with each other and the support for the underlying transport mechanism of the platform on which the ORB runs. TCP/IP is the preferred transport—there is also specification support for Novell IPX and OSI. Vendors are free to support other transport mechanisms. Java, with its built- in network support, and CORBA, with its “under-the-covers” transport to connect distrib- uted objects transparently, are complementary technologies. Every programming language that the OMG supports must have an IDL-to-target-lan- guage mapping. Shortly after Java’s introduction, a number of ORB vendors made their own mappings to satisfy the demand for distributed Java applications. The OMG adopted a Java mapping as a CORBA standard in July 1998. When the OMG ratified the official IDL-to-Java mapping, vendors upgraded their products to conform. Conformity to the IDL mappings is an important step to maintaining integrity in the CORBA world. The IDL-to- Java mapping defines how the standard IDL keywords and data types translate into Java Chapter 26 Common Object Request Broker Architecture (CORBA): Part 1 1441 constructs. Java 2 was the first official Sun release to support the OMG mappings directly. We discuss IDL-to-Java mappings shortly. 26.2 Step-by-Step The steps necessary to implement a distributed system using Java and CORBA are: 1. Perform analysis and design by modeling the problem domain, modeling the sys- tem domain and defining subsystems using the system domain. 2. Define the IDL by specifying the API of the subsystems to be distributed and spec- ifying any data structures that cross system boundaries. 3. Implement the servant, using files generated by the IDL compiler. 4. Implement a client, using the stub files generated by the IDL compiler. 5. Decide on a method to distribute the servant’s object reference (traditionally done using a Naming Service, but this is not required). 6. Start the servant implementation. 7. Run the client. Software Engineering Observation 26.2 Implementing a distributed system is a nontrivial task. Developers must follow standard soft- ware development practices when using CORBA as an enabling infrastructure to bind vari- ous legacy systems together. 26.2 Good Programming Practice 26.1 Several processes and methodologies for modeling problem domains exist. Make sure the model you choose maps to the problem being solved (otherwise, you might find yourself re- doing your project. 26.1 The OMG’s OMA remains the preferred reference architecture for directing architec- tural concerns. OMA defines architecture in the context of a collection of cooperating ser- vices. Consider the subsystems you declare as sharing responsibilities. There are more opportunities for process reuse if your system defines fundamental services that are usable by other development groups. Once subsystems have been defined, you want to decide which subsystems to con- figure as distributed services. If all of the subsystem designs assume distributed/sharable functionality, the migration of subsystems to CORBA becomes much easier. In any case, the public API of the service becomes the interface accessible by clients. In typical OO fashion, the interface revealed in the IDL can be a subset of the available functionality offered by a server. It is not until the implementation of the server (we use Java as the target language) that the developer worries about how much additional functionality (administra- tion, security, etc.) the server is given. If there are data structures that a server must return to a client (or vice versa), the iden- tification and definition of these data structures must be in the IDL file. This is a bit of a throwback to the way languages such as C define data structures, but the CORBA model makes allows non-object-oriented languages to describe non-object-oriented constructs in a “pseudo-object” fashion. Two CORBA constructs support this mechanism—the struct 1442 Common Object Request Broker Architecture (CORBA): Part 1 Chapter 26 and the valuetype. A client and a server pass IDL structs back and forth as raw data for allowing local handling of information. A standard optimization is sending this data directly to the client so the server can handle more demanding requests. The valuetype construct is the IDL description of an entity consisting of both data and behavior. A struct consists of pure data (and a struct compiled into Java defines the instance attributes as public), whereas a valuetype encapsulates the data and adds any logic for making the object as simple or complex as needed. Section 26.8.5 explains a CORBA valuetype in more detail. Performance Tip 26.1 Make all methods transactional. Remember, every method call is a call across the network. The granularity of services should be such that a useful level of functionality is achievable in as few methods as possible (preferably one method call). If you need to get a Customer’s street ad- dress, city, state and zip code, create an Address class that encapsulates this information. The caller can make one call to the Address, rather than make five individual method calls. 26.1 After declaring the server API in an IDL file, the only thing missing is the actual imple- mentation of the server. The IDL compiler parses the completed IDL file and generates a collection of support files needed by the server to handle incoming requests. Once the sup- port files are created, the developer can now write implementation code; until this time, the only thing the developer has done is declare the interface, attributes and data needed by the server to handle requests. As a first cut, a developer could implement a “dummy” server that simply returns test data so another developer could write a system client (or possibly a test client) to exercise the server. A more typical example is to write a server that wraps around a legacy back end but hides that fact from any clients. Assume that the declared server API is in an IDL file and an IDL compiler has com- piled the file. Now the client uses the generated client-side files needed to speak with the server. The client needs only the IDL-generated files to take advantage of the underlying mechanism that allows communication across the network transparently. The client could instantiate a local version of the server (instead of using a CORBA object reference, they could simply perform a new ServerImpl()) and send messages directly, but the server would no longer be a distributed object—the server would be running in the client’s process space having lost the low-coupling advantage we originally had by using the glue code located in the generated files. 26.3 First Example: SystemClock This example provides a basic service (time) and allows a client to query for the current time. The requirements are: • Retrieve the current system time. • Display the current system time in a GUI window. The SystemClock server interface declares a single method current- TimeMillis (which mimics the call in class java.lang.System). The method returns the system time as a long. A Date object would have been more appropriate for Java. If this were an example of the CORBA Time Service, a Universal Time Object would have been even more appropriate. However, a long helps keep this pure-Java example simple (a non-trivial time service factors issues such as network latency). Chapter 26 Common Object Request Broker Architecture (CORBA): Part 1 1443 26.3.1 SystemClock.idl Figure 26.1 declares the IDL for the SystemClock server. Lines 1 and 2 are single-line comments; they follow standard C++ syntax with the double slash (//) denoting a single- line comment. Line 4 is the first real line of “code” (CORBA does not dictate implementa- tion, so the IDL is not technically code). The module keyword maps a given name directly to a Java package. Nested module names concatenated together create a complete package name. The module name in Fig. 26.1 is clock. The curly braces at lines 4 and 10 denote scope boundaries of the block. Note that, in IDL, a semicolon always identifies the end of a block (including the module declaration). Java, C and C++ are block-scoped languages and use a similar syntax but do not consider the block itself as a line that requires a semicolon to be complete. A missing semicolon is a syntax error in IDL. Lines 7-9 declare the interface the SystemClock server. Is the server type actually SystemClock? From the client’s perspective, the answer is yes—the data type of the server is SystemClock. From the server’s perspective, the answer is no—that is not the direct type. The server is a derived class (concrete implementation) of interface Sys- temClock. The indirection to the client is deliberate, allowing an arbitrary server imple- mentation. The curly braces at lines 7 and 9 mark the boundary of the interface declaration. Again, notice the semicolon at the end of line 9 used to identify the end of the block. Line 8 is a method/function/message declaration. Everything declared in IDL is public, so there are no special keywords in IDL interfaces to denote public, pri- vate or protected declarations (although metatypes component and valuetype have keywords private and public). The method currentTimeMillis, by defi- nition, is public and returns an IDL long long, which maps to a Java long (a single IDL long maps to a Java int). The Java IDL compiler, idlj, compiles systemclock.idl with the command line idlj -td c:\src -pkgPrefix clock com.deitel.advjhtp1.idl -fall systemclock.idl We discuss the Java tool idlj and its command line options shortly. The Java IDL compiler generates the following server-side files after compiling systemclock.idl: SystemClock.java SystemClockOperations.java _SystemClockImplBase.java 1 // Fig. 26.1: systemclock.idl 2 // IDL definition of SystemClock. 3 4 module clock { 5 6 // The definition of the CORBA-enabled service 7 interface SystemClock { 8 long long currentTimeMillis(); 9 }; 10 }; Fig. 26.1 Fig. 26.1Fig. 26.1 Fig. 26.1 IDL definition for server SystemClock. [...]... for clarity) (part 1 of 3) 1464 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 Common Object Request Broker Architecture (CORBA): Part 1 Chapter 26 * Generated by the IDL -to -Java compiler (portable), version "3.0" * from maptest.idl * Monday, May 14, 20 01 4:18: 09 PM PDT */ // This comment appears in... System.currentTimeMillis(); } Implementation of the SystemClock server (part 1 of 3) 1446 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 Fig 26 .4 Common Object Request Broker Architecture (CORBA): Part 1 Chapter 26 // initialize SystemClockImpl object by calling method register public SystemClockImpl(... method setAlarm (lines 81– 92 ) , we create a new TaskWrapper and return to the caller as fast as we can 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 // Fig 26 .16: AlarmClockImpl .java // Implementation of AlarmClock server package com.deitel.advjhtp1.idl.alarm; // Java core packages import java. util.*; // Java extension packages import org.omg.CORBA.ORB; import org.omg.CosNaming.*;... to get the object reference to the Naming Service Lines 39 40 cast the object reference from a CORBA Object to a NamingContext object using method NamingContextHelper.narrow 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 // Fig 26 .5: SystemClockClient .java // Client application for the SystemClock example package com.deitel.advjhtp1.idl.clock; // Java core packages import java. text.DateFormat;... startTimer(); } Client that connects to SystemClock (part 1 of 3) 1450 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 Fig 26 .5 Common Object Request Broker Architecture (CORBA): Part 1 Chapter 26 // use NameService to connect to time server private void connectToTimeServer( String params[] )... }; Fig 26 .15 alarmclock1.idl Chapter 26 Common Object Request Broker Architecture (CORBA): Part 1 14 69 26 .6 .2 AlarmClockImpl .java In Fig 26 .16, lines 21 – 52 are the same as method register in SystemClockImpl (Fig 26 .4, lines 26 – 59) Lines 26 29 check the incoming arguments Line 32 creates an ORB using the ORB.init factory method, and line 35 connects with the ORB Lines 38–41 find a reference to a Naming... octet octetValue; string stringValue; wstring wStringValue; short shortValue; Fig 26 .10 IDL file testing many of the IDL keywords and types (part 1 of 2) 1460 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 Common Object Request Broker Architecture (CORBA): Part 1 Chapter 26 unsigned short uShortValue; long longValue; unsigned long uLongValue; long long... Fig 26 .11 IDL-generated file StructMap .java (re-formatted for clarity) (part 2 of 3) Chapter 26 Common Object Request Broker Architecture (CORBA): Part 1 56 57 58 59 60 1465 floatValue = _floatValue; doubleValue = _doubleValue; } // ctor } // class StructMap Fig 26 .11 IDL-generated file StructMap .java (re-formatted for clarity) (part 3 of 3) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 ... if ( response == JOptionPane.CANCEL_OPTION ) break; // Get us out of here } System.exit( 0 ); } Client that connects to SystemClock (part 2 of 3) Chapter 26 Common Object Request Broker Architecture (CORBA): Part 1 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 1451 // main method to execute client application public static void main( String args[] ) throws Exception { // create client try { new... Figure 26 .9 lists the most frequently used specification mappings.11 IDL Java module package interface interface struct class const public static final boolean boolean char char wchar wchar octet octet string java. lang.String Fig 26 .9 IDL keywords, types and their mappings to Java keywords (part 1 of 2) Chapter 26 Common Object Request Broker Architecture (CORBA): Part 1 IDL Java wstring 14 59 java. lang.String . with a back-end system named StockTicker: StockTicker .java StockTickerOperations .java StockTickerHolder .java StockTickerHelper .java _StockTickerStub .java StockTicker .java contains the base definition. CORBA Basics 26 .6 Example: AlarmClock 26 .6.1 AlarmClock.idl 26 .6 .2 AlarmClockImpl .java 26 .6.3 AlarmClockClient .java 26 .7 Distributed Exceptions 26 .8 Case Study: Chat 26 .8.1 chat.idl 26 .8 .2 ChatServerImpl .java 26 .8.3. { 19 private SystemClock timeServer; 20 21 // initialize client 22 public SystemTimeClient( String params[] ) throws Exception 23 { 24 connectToTimeServer( params ); 25 startTimer(); 26 } 27 Fig.