Appendix A Use non-Java code Java language and its standard API (Application Programming Interface) to pay for applications. But in some cases, it is also necessary to use non-Java encoding. For example, we sometimes access the specific features of the operating system, deal with special hardware devices, reuse existing non-Java interfaces, or use "Time-sensitive" code segment, and so on. Communication requirements with non-Java codes to obtain specialized support for compilers and "virtual machines", and require additional tools to map Java code into non-Java code (there is also a simple way: in "a web application" section in Chapter 15 There is an example explains how to use the standard input to output with a non-Java code connection). At present, different developers provide us with different programs: Java 1.1 has "Java Native Interface, JNI), and Netscape proposes its own" Java runtime interface "program, and Microsoft provides J / Direct, "Raw Native Interface, RNI), and Java / COM integration scheme. Different attitudes held on this issue are very disadvantageous on this issue. If the Java application must call the inherent method, the programmer may implement different versions of the inherent method - the platform determined by the platform running. Programmers may actually need different version of Java code, as well as different Java virtual machines. Another solution is CORBA (General Object Request Agent Structure), which is an integration technology developed by OMG (object management group, a non-profit company association). CORBA is not part of any language, just a standard for universal communication bus and service. With its ability to achieve "interoperability" between objects implemented by different languages. The name of this communication bus is called ORB (Object Request Agent), which is a product implemented by other developers, but is not part of the Java language specification. This appendix will be an overview of JNI, J / Direct, RNI, Java / COM integration, and CORBA. However, it will not make a deeper discussion, and even sometimes readers have had a certain degree of understanding of the relevant concepts and technologies. But in the end, everyone should be able to compare different methods, and select the most appropriate kind according to the issues you have to solve. A.1 Java Insufficient Interface JNI is a wide range of programming interfaces that allow us to call inherent methods from the Java application. It is new in Java 1.1, maintaining the corresponding characteristics of Java 1.0 - "Inherent Method Interface" (NMI) - some level of compatibility. Some features in NMI design make it supported by all virtual machines. Considering this reason, the future version of Java language may no longer provide support for NMI, which is not prepared to discuss it. At present, JNI can only deal with inherent methods written with C or C . Using JNI, our inherent ways: ■ Creating, checking, and updating Java objects (including arrays and strings) ■ Call Java method ■ Capture and discard "exception" ■ Load classes and get class information ■ Perform time period type check, Almost everything you can do in Java can also do it in an inherent method. A.1.1 Call Inherent Method Let us start from a simple example: a Java program calls inherent method, the latter, then call the WIN32 API function messagebox (), showing a graphical text box. This example will be used later with the J / Direct one.
If your platform is not Win32, simply consolidate the following content: #include
For non-Static methods (also called instance methods) like this, the second argument is equivalent to the "THIS" pointer equivalent to C , and is similar to the "THIS" of Java: That object that calls the inherent method is referenced. . For Static methods, it is a reference to a specific Class object, and the method is implemented in that Class object. The remaining auto-variable representative passes the Java object in the inherent method call. The main type is also passed in this form, but their "value" is passed. In the subsequent section, we are ready to explain how to access and control the JVM from an inherent method, while more detailed explanation of the above code. A.1.2 Access JNI Functions: JNIENV Argument uses JNI functions, programmers can deal from the JVM from an inherent method. As everyone sees in the previous example, each JNI inherent method will receive a special self-variable as its first parameter: jnienv argument - it is a special JNI data structure that is pointing type JNIENV_ Pointer. One element of the JNI data structure is a pointer to an array generated by the JVM; each element of the array is a pointer to a JNI function. The call to the JNI function can be issued from the inside of the inherent method, and the practice is to undo a reference to these pointers (the specific operation is actually very simple). Each JVM implements a JNI function in its own way, but their addresses are affirm that they are predefined. Using JNIENV arguments, programmers can access a range of functions. These functions can be divided into the following category: ■ Get Version Information ■ Control Class and Object Operation ■ Controls Global and Local references to Java objects ■ Accessing instance fields and static fields ■ Call instance methods and static methods ■ Execute strings and array operations ■ The number of Java exception JNI functions is quite large, which is no longer detailed here. Instead, I will reveal some of the basic principles behind the use of these functions. For more detailed information, see the JNI documentation of your compiler. If you observe the jni.h header file, you will find the inside of the #ifdef _cplusplus preprocessor condition, and when compiled by the C compiler, the JNIENV_ structure is defined as a class. This class contains a large number of internal embedders. Through a simple and familiar syntax, these functions allow us to access JNI functions. For example, the precedent includes the following line code: (* JENV) -> ReleaseStringutfchars (JENV, JMSG, MSG); it can be rewritten in C looks below: JENV-> ReleaseStringutfchars (JMSG, MSG); everyone can notice You no longer need to undo two references to JenV, the same pointer no longer passed to the JNI function call as the first parameter. In these examples, I will use the C style code. 1. Access the Java string as an example of accessing the JNI function, consider the above code. Here, we use JNienv's own argument JENV to access a Java string. The Java string takes a Unicode format, so if you receive such a string, you want to pass it to a non-Unicode function (such as Printf ()), you must first convert it into an ASCII character with the JNI function getStringutFchars (). This function can receive a Java string, then convert it into a UTF-8 character (accommodate the ASCII value with the 8-bit width, or accommodate Unicode with 16-bit width; if the content of the original string is completely composed of ASCII, then the result string Also ascii). GetStringutfchars is a field in the structure that jnienv points to the structure, and this field is a pointer to a function.
To access the JNI function, we call a function (by pointer) with a traditional C syntax. Access to all JNI functions can be implemented using the above form. A.1.3 Transfer and use the Java object In the precedent, we pass a string to the inherent method. In fact, you can also pass your Java object to an inherent method. Inside our inherent method, you can access the fields and methods of those objects received. To transmit an object, the original Java syntax is to be used when there is inherent method. As shown in the following example, Myjavaclass has a public (public) field, as well as a public method. The UseObjects class declares an inherent method for receiving an object of the Myjavaclass class. In order to investigate whether the solid method can control your own argument, we set the non-variable public field, call the inherent method, and then print the value of the public field. On the 1004 page, the program is compiled and passed to Javah after passing the .class file to Javah, the inherent method can be implemented. In the following example, once the fields and method IDs are obtained, they are accessed through the JNI function. Page 1004-1005 In addition to the first argument, the C function will receive a Jobject, which represents the "Solid" of the Java object - that reference is transferred from the Java code. We simply read Avalue, print it out, change this value, call the DivbyTwo () method of the object, and then re-print the value again. To access a field or method, you must first get its identifier. With proper JNI functions, it is convenient to obtain class objects, element names, and signature information. These functions return an identifier that uses it to access the corresponding elements. Although this approach seems to be twisted, our inherent approach does not know anything about the internal layout of the Java object. Therefore, it must access fields and methods by the index returned by the JVM. In this way, different JVM can achieve different internal object layouts, and will not affect the inherent methods. If you run the Java program, you will find that the object from the side of Java is processed by our inherent methods. But what is the passing? Is it a pointer or a Java reference? And what is the garbage collector during the inherent method call? The garbage collector continues to operate during the implementation of the inherent method, but during the inherent method call, our objects ensure that they will not be treated as "garbage". To ensure this, "local reference" is created in advance, and immediately cleared immediately after the inherent method call. Since their "life period" is closely related to the calling process, it is possible to ensure the effectiveness of the object during inherent method calls. Since these references are created and destroyed at each function call, the local copy of the inherent method (local copy) cannot be created in the Static variable. If a reference is intended to be valid during the function, you need a global reference. The global reference is not created by JVM, but by calling a specific JNI function, the programmer can extend the local reference extension into a global reference. When you create a global reference, you need to be responsible for the "survival time" of the reference object. Global references (and the object it reference) will stay in memory until this reference is explicitly released with a specific JNI function. It is similar to Malloc () and Free (). A.1.4 JNI and Java exceptions utilize JNI, discard, capture, print, and re-discard Java exception, just like in a Java program. But for programmers, you need to call the dedicated JNI function to process an exception. Some JNI functions for exception processing are listed below: ■ throw (): Discard an existing exception object; used to re-discard an exception in an inherent method.
■ thrownew (): Generates a new exception object and discarders. ■ EXCEPTIONOCCURRED (): Judging whether an exception has been discarded, but has not been cleared. ■ ExceptionDescribe (): Print an exception and stack tracking information. ■ ExceptionClear (): Clear a pending exception. ■ Fatalerror (): Causes a serious error, not returning. In all of these functions, it is the least ignore to exceptionoCcurred () and ExceptionClear (). Most JNI functions can produce an exception, and there is no such language characteristic in the Java's TRY block. So after each JNI function is called, you must call EXCEPTIONOCCURRED () to understand whether the exception has been discarded. If an exception is detected, you can choose to control it (it may also be re-discarded). However, it must be ensured that the abnormality is finally cleared. This can be implemented in your own function; if the exception is re-discarded, it is also possible to do in some other functions. But in any case, this work is essential. We must ensure that the abnormality is completely cleared. Otherwise, if a JNI function is called in an abnormally pending, the result is often unpredictable. There are also a few JNI functions to be safely called at an abnormality; of course, they are specialized exception control functions. A.1.5 JNI and Thread Process Due to Java is a multi-threaded language, several threads may simultaneously send calls to an inherent method (if another thread is called, the inherent method may be suspended during operation). At this point, it is entirely necessary to ensure that the inherent call is safe in the multi-threaded environment. For example, to prevent shared data with a method that is not monitored. At this point, we mainly have two options: declare the inherent method as "synchronization", or take some other strategies inside the inherent method to ensure that the data processing is correctly concurrently. In addition, it is absolutely not to deliver Jnienv through threads because the internal structure it points to is allocated on the basis of each thread, and includes only information on those specific threads. A.1.6 Using ready-made code To implement JNI inherent methods, the easiest way is to write an inherent method's prototype, compile the class, and run the .class file through Javah. But if we have a large, early existing code base, and want to call them from Java, how is it? All functions in the DLL cannot be renamed, which makes it in line with the JNI naming rules, which is not feasible. The best way is to write a package DLL in the original code library. The Java code will call the function in the new DLL, and the latter calls the original DLL function. This method is not just a solution; in most cases, we must even do this because it is necessary to call the JNI function or not. A.2 Microsoft's solution is dialum, and Microsoft still does not provide support for JNI, just provide support for non-Java code calls with its own patent method. This support is built into the compiler Microsoft JVM and the external tool. Only the program is compiled with the Microsoft Java compiler, and only when running on the Microsoft Java Virtual Machine (JVM), this section will be valid. If you plan to issue your own app on the Internet, or on the basis of the inner network of the unit is established on different platforms, it may become a serious problem.
Microsoft and Win32 code interface provides us with three ways to connect WIN32: (1) J / Direct: It is convenient to call a Win32 DLL function with some limits. (2) This original interface (RNI): You can call the Win32 DLL function, but you must solve the "garbage collection" problem. (3) Java / COM integration: COM service can be directly revealed from Java. The subsequent section will discuss these three technologies respectively. When writing this book, these features have been supported by Microsoft SDK for Java 2.0 Beta 2. This development platform can be downloaded from Microsoft's Web Site (to experience a painful selection process, they are called "Active Setup"). Java SDK is a collection of command line tools, but the compile engine can easily embed the developer Studio environment so that we can compile Java 1.1 code with Visual J 1.1. A.3 J / DirectJ / Direct is the simplest way to call the Win32 DLL function. Its main design goal is to deal with Win32API, but it can be used to call other APIs. However, although this feature is very convenient, it also causes certain restrictions and reduces performance (compared to RNI). But J / Direct also has some obvious advantages. First, in addition to the code in the DLL you want to call, there is no need to write additional non-Java code, in other words, we do not need a package or agent / stub DLL. Second, automatic conversion is achieved between the function index and the standard data type. If you have to pass a user-defined data type, then J / Direct may not work according to our hopes. Third, it is very simple and straightforward like the following example. Just a few lines, this example can call the Win32 API function messagebox (), which pops up a small modal window and has a title, a message, an optional icon, and a few buttons. The 1008 page program is shocking is that this is the entire code required for us to use J / Direct to call the Win32 DLL function. The key is the @ DLL.Import boot command before the MessageBox () declaration at the bottom of the demonstration code. It is a comment on the surface, but it is not true. Its role is to tell the compiler: The following function below is implemented in the USER32 DLL and should be called accordingly. All what we have to do is to provide a prototype that is consistent with the function implemented in the DLL, and calls the function. However, there is no need to type every Win32 API function you need in the Java version, a Microsoft Java package will help us do this (soon explained in detail). In order to make this example work normally, the function must "press the name" by the DLL. However, you can also use the @ DLL.Import boot command "to" link. For example, we can specify the entry location of the function in the DLL. Tell the characteristics of the @ DLL.Import boot command later. An important issue for linking with non-Java code is the automatic configuration of the function parameters. As everyone saw, the Java declaration of Messagebox () uses two string independent variables, but the original C program uses two char pointers. The compiler will help us to automatically convert standard data types, follow the rules to be described in the next section of this chapter. Best, everyone may notice that the unsatisfiedlinkerror exception in the main () declaration. At the time of the running period, once the linker cannot resolve the symbol from a non-Java function, this exception is triggered (event).
This may be caused by many reasons: .dll files are not found; not a valid DLL; or J / Direct is not supported by the virtual machine you are using. In order to make the DLL can be found, it must be in a Windows or Windows / System directory, located in a directory listed by the PATH environment variable, or the same directory as the .class file. J / Direct has received support for Microsoft Java compilers 1.02.4213 and higher, and also supports Microsoft JVM 4.79.2164 and higher. In order to solve the version number of your compiler, run the JVC in the command line, do not add any parameters. To understand the version number of the JVM, find the icon of MSJava.dll and use the right-click pop-up menu to observe its properties. A.3.1 @ DLL.Import Boot Command As the only way to use J / Direct, the @ DLL.Import boot command is quite flexible. It provides a number of modifications that can be used to customize ways to establish a link relationship with non-Java code. It can also be applied to some methods within the class, or applied to the entire class. That is, all methods we declared in that class are implemented in the same DLL. Let us study these features. 1. Alias Processing and Press Sequential Link To make the @ DLL.Import boot command to work like it is displayed above, the functions in the DLL must be exported by name. However, we sometimes want to use a name different from the original name (alias processing) in the DLL, otherwise the function may be exported as number (such as sequential) instead of being exported by name. The following example declares that FinestradimsAGGIO () ("MessageBox" said with Italian). As everyone saw, the syntax used is very simple. Page 1010 Program The following example shows how to establish a link with a function that is defined in the DLL, which is exported in the location of their DLL. This example assumes a DLL named mymath, which contains a function at position number 3. That function acquires two integers as an argument and returns two integers. The following can be seen from the 1010 page, the only difference is the form of entryPoint arguments. 2. Apply @ DLL.IMPORT to the entire class @ DLL.Import boot command to be applied to the entire class. That is, all methods of that class are implemented in the same DLL and have the same link attribute. The boot command will not inherit by subclass; considering this reason, and because the function in the DLL is a natural Static function, the better design is to encapsulate the API function into a separate class, as shown below: 1011 Page Program Because MessageBeep () and MessageBox () functions have been declared in different classes to be static functions, the scope must be specified when they call them. Everyone may think that all Win32 APIs (functions, constants, and data types) must be mapped into Java classes with the above methods. But fortunately, you don't have to do this. A.3.2 com.ms.win32 package Win32 API is quite large - containing thousands of functions, constants, and data types. Of course, we don't want to write each Win32 API function in the form of corresponding Java. Microsoft told this problem and released a Java package that map Win32 API into Java classes via J / Direct. The name of this package is called com.ms.win32. When you install Java SDK 2.0, if the corresponding setting is performed in the installation option, this package is installed into our classpath. This package consists of a large number of Java classes that completely reproduce the constant, data types, and functions of the Win32 API.
The three categories of inclusive capabilities are user32.class, kernel.class, and gdi32.class. They contain the core content of the Win32 API. To use them, just import in your Java code. The front SHOWMSGBOX example can be rewritten into the following (here, using a more appropriate manner): 1012 Page Program Java package is imported in the first line. Now, you can call the messagebeep () and messagebox () functions without other statements. In MessageBeep (), we can also declare Win32 constants when they see the package. These constants are defined in a large number of Java interfaces, all named WinX (X represents the first letter of the constant who wants to use). When writing this book, the development of com.ms.win32 pack is still not officially completed, but it is already used. A.3.3 Collection "Collection" means that a function independent variable is converted from its original binary form into some form that is independent of the language, and then converts this general form to a binary format adopted by the call function. In the previous example, we call the MessageBox () function and pass two strings to it. Messagebox () is a C function, and the binary layout of the Java string is different from the C string. But despite this, the independent transfer is still passed. This is because J / Direct has helped us to convert Java strings into C strings in consideration. This situation is suitable for all standard Java types. The following table summarizes the default correspondence of simple data types: Java Cbyte Byte or Charshort Short or Wordint Int, Uint, long, ulong, or dword floatdouble DoubleBoolean BoolString LPCTSTR (only in OLE mode as return value) byte [ ] Byte * short [] word * int [] DWORD * This list can also continue, but it is already possible to explain the problem. In most cases, we don't have to care about the conversion problem between the simple data type. But once you have to pass the user's own self-variable, the situation will become different. For example, it may be necessary to pass a structured, user-defined data type, or you need to pass a pointer to the original memory area. In these cases, some special compilation boot commands marked a Java class so that it can be transmitted as a pointer (@ DLL.STRUCT boot command). For details on using these keywords, please refer to the product documentation. A.3.4 Writing a callback function Some Win32 API functions require a function pointer as its own parameters. The Windows API function can then call the own variable function (usually when a specific event will occur later). This technology is called "callback function". Examples of the callback function include a window process and the callback we set in the printing process (providing the back-up printer address to update the status, and abort printing when necessary). Another example is the API function EnumWindows (), which enumerates all top windows in the current system. EnumWindows () requires a function pointer as its own parameters and then searches for a list of maintained by Windows. For each window in the list, it calls the callback function and pass the window handle to the callback. In order to use the same purpose in Java, you must use the Callback class in com.ms.dll. We inherit from Callback and cancel Callback ().
This method can only be close to the int parameter and will return INT or VOID. Method signatures and specific implementation depends on this callback to Windows API function. Now, all our work we have to do is an instance of this Callback derived class and passed it as a function pointer to the API function. Subsequently, J / Direct will help us complete the remaining work. The following example calls the Win32 API function EnumWindows (); the callback () method in the EnumWindowsProc class gains the handle of each top window, get the title text, and print it to the console window. 1014 Program The call to sleep () allows window processes to complete before main () exit. A.3.5 Other J / Direct features can be used in another two features of J / Direct through the modifier (tag) in the @ DLL.Import boot command. The first item is a simplified access to the OLE function, the second item is the ANSI and Unicode version of the API function. According to the convention, all OLE functions return a value of the type HRESULT, which is a structured integer value defined by the COM. If you write a program at COM, you want to return some different things from an OLE function, you must pass a special pointer to it - the pointer points to the memory area that will populate the data. But in Java, we don't have a pointer; in addition, this method is not concise. Using J / Direct, we can use the OLE modifier in the @ DLL.Import boot command to easily call the OLE function. A inherent method labeled OLE function will automatically convert from the method of Java (by determining return type) to a COM form. The second feature is to select an ANSI or Unicode string control method. Most Win32 API functions for controlling strings provide two versions. For example, suppose we observe the symbols exported by user32.dll, then a messagebox () function will not be found, and will see the MessageBoxa () and MessageBoxw () functions - the ANSI and Unicode versions of the function, respectively. If you don't specify which version is trying to call in the @ DLL.Import boot command, JVM will try your own judgment. But this will take a longer time during the execution. So, we can generally use ANSI, Unicode or Auto modifier hard specification. For more detailed information, please refer to Microsoft's technical documentation. A.4 This original interface (RNI) is compared with J / Direct, RNI is a much more complicated than non-Java code; but its function is also very powerful. RNI is closer to JVM than J / Direct, which allows us to write more efficient code, can handle Java objects in the inherent method, and achieve more integrated integration with the JVM internal operation mechanism. RNI is conceptually similar to Sun's JNI. Considering this reason, and because the product has not been formally completed, I only point out the main differences between them. For more detailed information, please refer to Microsoft's documents. There is a few aspects between JNI and RNI. The following is a C header generated by Msjavah (Microsoft's MSJAVAH is functionally equivalent to Sun's Javah), which is applied to the Java class file ShowMSGBox used in front of the JNI example. 1016 Program In addition to readability, some technical issues are hidden in the code, and I will come one by one. In RNI, the programmer of the inherent method knows the binary layout of the object. This allows us to directly access the information you want; we don't have to get a field or method identifier as in JNI.
However, because not all virtual machines need to apply the same binary layout to its own object, the above inherent method can only run in Microsoft JVM. In JNI, a large number of functions can be accessed through JNienv's own variable to deal with JVM. In RNI, functions for controlling the operation of JVM becomes directly called. Some of them (such as the one of the control abnormal) is similar to their JNI "Brothers". But most RNI functions have different names and uses in JNI. The most significant difference between JNI and RNI is the model of "garbage collection". In JNI, garbage collection complies with the same rules as Java code during execution of the Java code during execution. In RNI, the launch and suspension of the "garbage collector" device is responsible for the "garbage collector" unit by the programmer during the inherent method activity. By default, the garbage collector is in an inactive state before entering the inherent method; in this way, the programmer can assume that the object that is ready for use does not cover garbage collection in that time period. However, once inherent methods are ready for a long time, the programmer should consider the activation of the garbage collector - by calling the gcenable () RNI function (GC is "Garbage Collector" abbreviation, "garbage collection"). There is also a mechanism similar to global handle characteristics - programmers can take advantage of how to be "garbage" during GC activity during GC activity. The concept is similar, but the name is different - in RNI, people call it GCFrames. A.4.1 RNI Summary RNI and Microsoft JVM Tight Complex This fact is both its advantages and its shortcomings. RNI is much more complicated than JNI, but it also provides us with high control of JVM internal activities; including garbage collection. In addition, it clearly optimizes speed, adopted some of the compromise and techniques familiar to programmers. But except for Microsoft's JVM, it is not suitable for other JVMs. A.5 Java / COM Integration COM (previously known as OLE) represents Microsoft's Component Object Model, which is the basis of all ActiveX technology (including ActiveX controls, Automation, and ActiveX documents). But COM also contains more things. It is a special specification that implements "interoperability" through the component objects it developed. In practical applications, all new software developed for Win32 system has a certain relationship with COM - the operating system reveals some of its characteristics through the COM object. Components developed by other vendors can also be based on COM, we can create and register your own COM components. Through this or such form, if we want to write Win32 code, you must deal with COM. Here, we will only refer to the basic concept of COM programming, and the reader has mastered the COM server (any COM object that can serve the COM customer) and a COM customer (can apply for a service from the COM server) the concept of. This section will make the narrative as much as possible. The practical functionality of the tool is much stronger, and we can use them through a higher pathway. But this also requires a more profound understanding of COM, which has exceeded the scope of this appendix. If you are powerful, interested in characteristics related to different platforms, you should study the documentation of COM and Microsoft, and read the part of the Java / COM integration. If you want to get more information, you recommend Dale Rogerson's "Inside CoM", which is published by Microsoft Press in 1997. Since COM is the structure of all new Win32 applications, it is especially important to use the Java code (or revealed) COM services. Java / COM integration is undoubtedly a Microsoft Java compiler, as well as the most interesting feature of the virtual machine.
Java and COM are so similar to their models, so this integration is very intuitive, and it can easily achieve seamless binding in technology - for accessing COM, almost no need to write any special code. Most technical details are controlled by compilers and / or virtual machines. The final result is that the Java programmer can treat COM objects like the original Java object. And COM customers can use the COM server implemented by Java like using other COM servers. Here you remind everyone, although I use a general term "COM", but according to the extension, you can use Java to implement an ActiveX Automation server in Java programs, or an ActiveX control in the Java program. Java and COM most striking similarities are the relationship between COM interface and Java's "interface" keyword. This is close to the perfect match because: ■ COM object reveals the interface (only interface) ■ The COM interface does not have an implementation; the COM object to reveal the interface is responsible for its implementation ■ COM interface is Description of a set of functions related to semantics; no data ■ COM class combines COM interfaces together. The Java class can realize any number of Java interfaces. ■ COM has a reference object model; programmers can never "have" an object, only reference to object one or more interfaces. Java also has a reference object model - reference to an object can be "style" into a reference to its interface. ■ The "living time" of the COM object in memory depends on the number of customers who use the object; if this number is changed to zero, the object will delete yourself from memory. In Java, an object's survival time is also determined by the number of customers. If there is no longer a reference to that object, the object will wait for the processing of the garbage collector. This tight correspondence between Java and COM not only allows Java programmers to easily access COM features, but also make Java a valid language to write COM code. COM is independent of language, but the language used in COM develops is C and Visual Basic. Compared with Java, C is more powerful when making COM development, and can generate more effective code, but it is difficult to use. Visual Basic is much simpler than Java, but it is too far from the underlying operating system, and its object model does not implement a good correspondence with COM. Java is a good compromise between the two. Next, let's discuss some of the key issues developed by COM. These issues are first required when writing Java / COM customers and servers. A.5.1 COM Basic COM is a binary specification that is committed to implementing interoperable objects. For example, COM believes that an object's binary layout must be able to call another service in another COM object. Since it is a description of the binary layout, as long as some language can generate such layouts, the COM object can be implemented by it. Typically, programmers don't have to pay attention to some of the low level details like this because the compiler can automatically generate the correct layout. For example, suppose your program is written with C , then most compilers can generate a virtual function table that conforms to the COM specification. For those languages that do not generate executable code, such as VB and Java, automatically hang from COM during the runtime period. The COM library also provides several basic functions, such as functions for creating an object or looking for a registered COM class in the system. Basic objectives of a component object model include: ■ Let the object call services in other objects ■ Allow new type objects (or update objects) Seamless insertion Environment The first point is an object-oriented program design to solve the problem: We have a customer Object, it can send a request to a server object. In this case, the two terms used in "customers" and "servers" are used in conventional sense, and they do not refer to some specific hardware configurations.
For any object-oriented language, the first goal is very easy to achieve - as long as your code is a complete code block, the server object code and customer object code are implemented. If you change the communication form between customers and server objects, just simply recompile and link it again. When you restart your application, it automatically uses the latest version of the component. However, if the application consists of some component objects that are not controlled, the situation will become very different - we can't control their source code, and their updates may be fully independent of our app. For example, when we use the ActiveX control developed by other vendors in its own program, it will face this situation. The control will be installed into our system, our program is able to locate the server code, activate the object, and build a link with it, and then use it. In the future, we can install the new version of the control. Our application should still be able to run; even in the worst case, it should also politely report an error message, such as "control is not found", etc. Hang up or crash. In these cases, our components are implemented in a separate executable code file: DLL or EXE. If the server object is implemented in an independent executable code file, you need a standard method provided by the operating system to activate these objects. Of course, we don't want to use DLL or EXE physical names and locations in our own code, because these parameters may often change. At this point, we want to use some identifiers maintained by the operating system. In addition, our application needs a description of the services displayed by the server. Below these two sections will discuss these two questions. 1. GUID and Registry COM uses structured integer values (length 128 bits) uniquely identifies the COM project registered in the system. The official name of these numbers is called GUID (Global Unique Identifier, globally unique identifier), can be generated by special tools. In addition, these numbers guarantee that there is no one in "any space and time", no repetition. In space, because the digital generator reads the ID number of the NIC; at time, it is due to the date and time of the system. You can use the GUID to identify the COM class (called CLSID) or COM Interface (IID). Although the name is different, the basic concepts are the same and the binary structure. GUID can also be used in other environments, and details will not be described here. GUID and related information are saved in the Windows registry, or stored in the Registration Database (Registration Database). This is a hierarchical database, built in the operating system, accommodating a lot of information related to the system software and hardware configuration. For COM, the registry will track the components installed in the system, such as their CLSID, implement their executable name and location and other large amounts of details. One of the more important details is the components' progID; ProgID is conceptually similar to the GUID because they are identified a COM component. The difference is that the GUID is a binary and generated by the algorithm. And ProgID is a string value defined by the programmer. PROGID is allocated with a CLSID. We say that a COM component has been registered within the system, at least one condition is its CLSID and its executable file already existing in the registry (Progid usually also is in place). In the following example, our main task is to register and use COM components. An important feature of the registry is that it is used as a decoupling layer between the customer and server object. With some information saved within the registry, the customer will activate the server; one of the information is the physical location of the server execution module.
If this location changes, the information within the registration table will be updated accordingly. But this update process is "transparent" for customers. The latter only needs to use Progid or CLSID directly. In other words, the registry makes the location of the server code become possible. With the introduction of DCOM (Distributed COM), one server running on the local machine can even be moved to a remote machine in the network, and the entire process will not even cause the customer to pay attention to it (most case) . 2. Type library Because COM has the ability to dynamically link, the customer must detect the service displayed by the server at any time due to the independent development of customers and server codes. These services are described in "Type Library", which is not related to language-independent forms (as icon interfaces and method signs). It can be an independent file (usually using a .tlb extension), or a Win32 resource that links to the execution program. During operation, customers use the function of the type library to call the function in the server. We can write a Microsoft Interface Definition Language (Microsoft Interface Definition Language, MIDL) source file, compile it with the MIDL compiler to generate a .tlb file. The role of the MIDL language is to describe COM classes, interfaces, and methods. It is similar to OMB / CORBA IDL in name, grammar, and use. However, Java programmers do not have to use MIDL. There will be another different Microsoft tools, which can read the Java class file and generate a type library. 3. Com: The function in HRESULT returns a COM function displayed by the server that returns a value, using a pre-defined HRESULT type. HRESULT represents an integer containing three fields. This can use multiple failures and success code, and other information can also be used. Since the COM function returns a HRESULT, the original data cannot be retrieved from the function call from the function call. If you have to return data, you can pass the pointer to a memory area, and the function will populate the data in that area. We call this "external parameters". As a Java / COM programmer, we don't have to pay too much attention to this problem because the virtual opportunity helps us automatically take care of everything. This issue will be described in the subsequent section. A.5.2 MS Java / COM integrates with C / COM programmers, Microsoft Java compiler, virtual machines, and a wide variety of tools greatly simplify the work of Java / COM programmers. The compiler has special boot commands and packages to treat Java classes as COM classes. However, in most cases, we only need to rely on Microsoft JVM for support, while using two powerful external tools. Microsoft Java Virtual Machine (JVM) plays a bridge between COM and Java objects. If the Java object is created into a COM server, then our object will still run within the JVM. The Microsoft JVM is implemented as a DLL, which shows the operating system with a COM interface. Internally, the JVM will map the function calls of these COM interfaces into methods in the Java object. Of course, JVM must know which Java class file corresponds to the server execution module; the reason why it can find out this is because we have used Javaareg to register a class file in the Windows registry. Javaareg is a tool program provided with Microsoft Java SDK, which can read a Java class file to generate the corresponding type library and a GUID and register the class into the system. You can also register the remote server with Javareg. For example, it is available to register a server running on different machines.
If you want to write a Java / COM customer, you must experience a range of different steps. Java / COM "Customer" is some special Java code that wants to activate and use a COM server registered within the system. Similarly, the virtual opportunity communicates with the COM server and provides the services it provides as a variety of methods (revelation) in the Java class. Another Microsoft Tool is JACTIVEX, which can read a type library and generate the corresponding Java source file where special compiler boot commands. The generated source file belongs to the part of our package named after the specified type library. The next step is to import that package in your own COM customer Java source file. Let us first discuss two examples. A.5.3 Designing the COM Server with Java This section describes the development process of ActiveX controls, Automation servers, or any other server that meets the COM specification. The following example implements a simple Automation server that performs an integer addition. We use the setaddend () method to set the value of Addend. When the SUM () method is called each time, Addend will add to the current result. We use getResult () to get the Result value and reset the value with clear (). Java classes for implementing this behavior are very simple: 1023 Page Program To use this Java class as a COM object, we apply the Javareg tool to compile good adder.class files. This tool provides a range of options; in this case, we specify the Java class file name ("adder"), wanting to put it in the registry in the registry ("javaadder.adder.1"), and want For the name of the ready-to-generated type library ("javaadder.tlb"). Since the CLSID has not been given, Javaareg will automatically generate one. If we call Javareg again to call Javareg, you will use the ready-made CLSID. Javaareg / register / class: adder /progid:javaadder.adder.1/typelib:javaadder.tlbjavareg also registers the new server to the Windows registry. At this point, we must remember copying the adder.class to the Windows / Java / TrustLib directory. These servers are only activated only when considering security reasons (especially those involving the CM service), only these servers are activated only when the COM server is installed to the TrustLib directory. Now, we have installed a new Automation server in your own system. For testing, we need an Automation controller, and the Automation controller is Visual Basic (VB). Below, everyone will see a few line VB code. According to VB's format, I set a text box and use it to receive the value to be added from the user. And use a label display result, use two downstall buttons to call the SUM () and CLEAR () methods, respectively. At the beginning, we declare an object variable called Adder. In the Form_Load subroutine (loaded when the form is displayed first), a new instance of the Adder Auto Server is called, and the text field of the form is initialized. Once the user presses the "SUM" or "Clear" button, the corresponding method in the server will be called. 1024 Page Program Note that this code does not know that the server is implemented with Java. After running this program and calls the createObject () function, you will search for the specified ProgID in the Windows registry. In information related to ProgID, the most important thing is the name of the Java class file.
As a response, the Java virtual machine is started, and an instance of the Java object is called inside the JVM. From that time, JVM will automatically take over the communication between customers and server code. A.5.4 Design COM customers with Java now, let us go to the other side and develop a COM customer with Java. This program calls the service within the COM server installed. For this example, we use a customer that is implemented for the server in the previous example. Although the code seems familiar in the eyes of Java programmers, everything happened behind the scenes is unusual. This example uses a server written with Java, but it can be applied to any ActiveX control, ActiveX Automation server, or ActiveX component installed in the system - as long as we have a type library. First, we apply the JACTIVEX tool to the server's type library. JACTIVEX has a range of options and switches available. But its most basic form is to read a type library and generate a Java source file. This source file is saved in our Windows / Java / TrustLib directory. By the following line of code, it is applied to the type library generated for the external COM Automation server: JACTIVEX / JAVATLB JAVAADER.TLBJACTIVEX is complete, let's take a look at your Windows / Java / TrustLib directory. At this point you can see a new subdirectory, named JavaAdder. This directory contains source files for new packages. This is a library that is similar to the functionality of the type library in Java. These files need to use the dedicated boot command for the Microsoft compiler: @com. JACTIVEX Generates Multiple Files is that COM uses multiple entities to describe a COM server (another reason is that I have no meticulous adjustment to the MIDL file and Java / COM tool). A file equivalent to adder.java is equivalent to a CoClass boot command in the MIDL file: it is a declaration for a COM class. Other files are Java equivalents for the COM interface revealed by the server. These interfaces (such as adder_dispatchDefault.java) belong to the "Dispatch" interface, which belongs to a part of the communication mechanism between the Automation controller and the Automation server. The Java / COM integration feature also supports the implementation and use of dual interfaces. However, IdisPatch and dual interfaces have exceeded the scope of this appendix. Below, you can see the corresponding customer code. The first line is only imported from the packet generated by JactiveX. Then create and use an instance of the COM Automation server, just like it is a primitive Java class. Note the type model in the line, "Explain" COM object (ie, an instance of generating and calling it). This is consistent with the COM object model. In COM, programmers will never get a reference to the entire object. Instead, they can only have references to one or more interfaces implemented within the class. After a Java object of the Adder class, it is equivalent to an instance of the COM activation server and creates this COM object. But then we must then specify which interface you want to use, pick one in the interface implemented by the server. This is exactly the work of the type model. The "default send" interface is used here, which is a standard interface for the Automation controller for communication with the same Automation server. For details on this, please refer to "INSIDE COM" by IBID. Please pay attention to activating the server and choosing a COM interface! 1026 Page Program Now we can compile it and start running the program. 1. Com.ms.com package COM.ms.com package is a large number of classes for COM development.
It supports the use of GUID -variant and SafeArray Automation - can deal with ActiveX controls in a deeper level and control COM exception. Due to limited space, it is impossible to involve all of these topics. But I want to emphasize the problem of COM abnormalities. According to the specification, almost all COM functions returns a HRESULT value, which tells us whether the function calls are successful, and the reason for failure. But if you observe the Java method signature in the server and customer code, you will find that there is no HRESULT. Instead, we use the function return value to retrieve the data from some functions. "Virtual Machines" (VM) converts the Java style function call into a COM-style function call, even returns the parameters. But if a function we call in the server fails at COM, what will happen in the virtual machine? In this case, JVM will think that the HRESULT value is a failure, and generates an inherent Java exception in class com.ms.com.comfailexception. In this way, we can manage COM errors in Java anomaly control, not check the return value of the function. For more information on the class contained in this package, please refer to Microsoft's product documentation. A.5.5 ActiveX / Beans Integration Java / COM integrates an interesting result is the integration of ActiveX / Beans. That is, the Java Bean can contain an ActiveX container like VB or any Microsoft Office product. And an ActiveX control can contain Beans containers like Sun Beanbox. Microsoft JVM will help us take into account all the details. An ActiveX control is just a COM server, which shows a pre-defined, requested interface. Bean is just a special Java class that follows a specific programming style. But when writing this book, this integration is still not perfect. For example, a virtual machine cannot map a JavaBeans event to a COM event model. If you want to control events from a bean inside the ActiveX container, Bean must use a system event such as a low-level technology to move such a system event such as a standard JavaBeans entrustment event model. Think of this problem, ActiveX / Beans integration is still very interesting. Since the concepts and tools involved are exactly the same as discussed above, please refer to your Microsoft documentation for further details. A.5.6 Inherent Methods and Capture Precautions Inherent methods bring us some considerations for security issues. If your Java code issues a call to an inherent method, it is equivalent to passing control to the outside of the virtual machine "system". Inherent methods have full access to the operating system! Of course, if you write an inherent method, this is what we hope. But this is unacceptable to the block - at least can't make this way. We don't want to see a program from the Internet Remote Server to freely operate the file system and other sensitive areas of the machine unless it is allowed to do so. In order to use J / Direct, RNI, and COM integration to prevent this happening, only the Java code that is trusted (delegate) is authorized to send a call to the inherent method. Depending on the specific use of the program, you must meet different conditions. For example, a block using J / Direct must have a digitized signature, pointing out that you are fully trust. When writing this book, not all of these security mechanisms have been implemented (for Microsoft SDK for Java, Beta 2 versions). So after the new version appears, be sure to pay attention to its documentation. A.6 CORBA In large distributed applications, some of our requirements are not previously described.
For example, we may want to deal with the data warehouse left, or you need to obtain services from a server object, where there is no matter where it's physical location. In these cases, some form of "remote procedure call" (RPC) is required, and may be required to be independent of language. At this point, CORBA can provide us with great help. CORBA is not a language characteristic, but an integration technology. It represents a specific specification, and all developers can design integrated products that meet CORBA standards by complying with this specification. The CORBA specification is developed by OMG. This non-profit body is committed to defining a standard framework to achieve distributed, unrelated to language-independent objects. With CORBA, we can implement remote calls for Java objects and non-Java objects, and communicate with traditional systems - uses a "position transparent" form. Java adds network support, an excellent "object-oriented" programming language that can build graphical and non-graphical applications (programs). There is a good correspondence between Java and OMG object models; for example, regardless of Java or CORBA, "interface" is implemented, and all have a reference (reference) object model. A.6.1 The CORBA foundation is often referred to as "Object Management Architecture, OMA) by OMG. OMA defines two components: "Core Object Model" and OMA Reference Model. The OMA reference system defines a set of grassroots service structures and mechanisms that realize the ability of objects to operate intermove each other. The OMA reference system includes "Object Request Broker, ORB)," Object Services, also known as Corbaservices) and some general mechanisms. ORB is a communication bus with inter-object mutual request. When performing a request, there is no need to care about the physical location of the other party. This means that the process of appearing in the customer code is actually a very complicated operation. First, there must be a connection pathway with the server object. And in order to create a connection, the ORB must know where the code that implements the server is stored. After the connection is built, the method is "collected" must be made. For example, convert them to a binary stream to transfer through network. Additional information that must be passed includes a server name, server process, and information identified by server objects within that process. Finally, this information passes through a low-level line protocol, and the information is decoded at one end of the server and finally performs calls. ORBs have hidden all of these complex operations from programmers and make programmers work almost as simple as the method of calling local objects. There is no hard specification to implement ORB core, but in order to implement a basic compatibility between different developers' ORBs, OMG defines a series of services that can be accessed through standard interface. 1. CORBA Interface Definition Language (IDL) CORBA is a language-oriented transparent: a customer object can call a different class server object method, regardless of the language implementation of the other party. Of course, the customer object must know the method name and signature of the method disclosed by the server object. The idl is used at this time. CORBA IDL is a designed approach to language that can be used to specify data type, attribute, operation, interface, and more. The syntax of IDL is similar to C or Java syntax. Here's the form summarizes three languages, and demonstrates their correspondence.
CORBA IDL JAVA C Module (Package) Method (Method) Method (METHOD) method (MEMBER FUNCTION) inheritance concept Get support - like C , use the colonal operator. The programmer should write an IDL description for the properties, methods, and interfaces that need to be implemented and used by the server and customers. Subsequently, the IDL will be compiled by the IDL / Java compiler provided by the vendor, and the latter reads the IDL source code and generates the corresponding Java code. IDL compiler is a quite useful tool: it not only generates Java source code with IDL equivalence, but also generates code for bringing the method's own variable, and can issue remote calls. We call this code as "STUB and Skeleton" code that organizes multiple Java source files, and usually belongs to a part of the same Java package. 2. Naming Service Naming Services belongs to one of CORBA's basic services. The CORBA object is accessed through a reference. Although the reference information does not make sense to use our eyes, it can be assigned a string name that is defined by the programmer. This operation is called "referenced string". A OMA component called "Naming Service" is specifically used to perform "string to object" and "object-to-string" conversion and mapping. Since the naming service plays a server and a customer's role of a phone book, it runs as a separate process. The process of creating an object to a string mapping is called "Binding an object"; the process of deleting the mapping relationship is called "cancel binding"; and let the object reference to pass a string process is called "Resolution Name". For example, when starting, the server application creates a server object and binds the object with the naming service, and then waits for a request. Customers first get a server reference, parsing the word string name, and then issues a call to the server by reference. Similarly, the "Naming Service" specification also belongs to a part of CORBA, but implements its application is provided by ORB Vendor (developer). Due to the different manufacturers, the way we have access to naming services may also be different. A.6.2 An example is that the code displayed here may not be exhausted, because different ORBs have different methods to access the CORBA service, so no matter what example depends on the specific manufacturer (Javaidl, this is Sun A free product. It supports a simplified version of ORB, a naming service, and an "IDL → Java" compiler). In addition, since Java is still in the early stages of development, it is not included in different Java / Corba products. All CORBA features. We want to implement a server, which make it run on some machines, and other machines can query the correct time. We also want to implement a customer, requiring it correct time. In this case, we let two programs are implemented in Java. But in practical applications, different languages are often used. 1. Write an IDL source code The first step is to write an IDL description for the service provided. This is usually done by the server programmer. Subsequently, the programmer can implement the server in any language, only one CORBA IDL compiler is present in that language. The IDL file has been distributed to the client's programmer and becomes a bridge between two languages.
The following example shows the IDL description of the time server: 1031 Page Program This is a declaration for the EXACTTIME interface in the RemoteTime namespace. This interface is composed of a single method, which returns the current time in a string format. 2. Creating the root of the root is to compile IDL and create a Java root dry code. We will use these codes to implement customer and server. Tools provided with Javaidl products are IDLTOJAVA: IDLTOJAVA -FSERVER -FCLIENT RemoteTime.IDL, two tags that tell IDLTOJAVA simultaneously for roots and dry generation code. IDLTOJAVA generates a Java package, which is named after the IDL module, RemoteTime, and the generated Java file are named after the RemoteTime subdirectory. _Exacttimeimplbase.java represents "dry" we used to implement server objects; _exactTimeStub.java will be used for customers. In ExactTime.java, the IDL interface is represented by Java. Also included other support files, such as files for simplifying access to naming services. 3. Implement the server and the customer, you can see the code used by the server side. Server objects are implemented in the ExactTimserver class. RemoteTimeServer's application is: Create a server object, register with ORB, specify the name used when the object reference is referenced, and then "quiet" waiting for the customer to issue a request. 1031-1033 Page Program As everyone's opinion, the implementation of the server object is very simple; it is a normal Java class that inherits from the "dry" code generated by the IDL compiler. However, when contacted the ORB and other CORBA services, the situation has become slightly complex. 4. Some CORBA services are here to briefly introduce the work made by JavaIDL-related code (note that the CORBA code is related to the facts of different vendors). The first row code of Main () is used to start the ORB. And according to it, this is why the server object needs to communicate with it. After the ORB initialization, a server object is created immediately. In fact, its official name should be "short-term service object": Receive requests from customers, "Survival Time" is the same as creating it. After creating a short-term service object, it will be registered via ORB. This means that the ORB has known its existence to forward the request to it. So far, all of us is a TimeServerObjref - an object reference only in the current server process. The next step is to assign the name of a string form for this service object. Customers will look for service objects based on that name. We complete this by name service (Naming Service). First, we need an object reference to the naming service. By calling resolve_initial_references (), you can get a string object reference to the naming service ("Nameservice" in Javaidl) and returns this reference. This is a model that uses a specific NAMINGCONTEXT reference to the Narrow () method. We can now start using naming services. In order to bind the object reference object in the same string form, we first create a NameComponent object and initialize with "EXACTTIME". "Exacttime" is the name string we want to bind the service object. Subsequent use rebind () methods, which is limited to the object reference reference. We assign a reference with rebind () - even it already exists. If the reference already exists, then bind () will cause an exception. In CORBA, the name consists of a series of NameContext - this is why we use an array to bind the name and object reference to the object. The service object is best prepared by the customer. At this point, the server process will enter a waiting state.
Similarly, because it is a "short-term service", the survival time is subject to the limitations of the server process. Javaidl has not yet provided support for "lasting objects" (as long as you create their processes remains running, the object will always exist). Now, we have had a certain understanding of the work of the server code. Next, look at the customer code: 1034 Page before the program is working in the server process: ORB gets initialization, and resolves a reference to the naming service. Next, we need to use an object reference to the service object, so transfer the object reference in the form of the string to the resolve () method, and use the Narrow () method to make the result into the ExactTime interface reference. Finally call gettime (). 5. Activate Name Service Process Now, we have obtained a server and a customer application, which has been prepared to communicate with each other. Everyone knows that both need to use the naming service binding and solve the object reference form. We must start the naming service process before running a service or customer. In Javaidl, the naming service belongs to a Java application, which is provided with the product support. But it may differ from other products. Javaidl Naming Services run in one instance of JVM, and (default) Monitor Network Port 900.6. Activation Server and Customer Now, we are ready to start servers and client applications (whose reason for this order is due to server existence It is "short"). If all aspects are set, it is obtained by outputting the text in the customer console window, reminding us that the current time is. Of course, this result is not exciting. However, attention should be paid to a question: Even if you are on the same machine, the client and server application still run in different virtual machines. Communication between them is performed by a basic integrated layer - ie integration of ORB and naming services. This is just a simple example, facing non-network environment. However, the ORB is usually configured to "unrelated to position". If the server is on a different machine, the ORB can use a component called "installation repository" to resolve the remote string reference. Although the "installation library" belongs to a part of CORBA, it has little specific specifications, so the implementation of each manufacturer is not the same. As everyone saw, Corba has many questions that have not been described in detail here. However, through the above introduction, it should have a basic understanding. If you want to get more detailed information, the most faxed starting point is too OMB Web site, the address is http://www.omg.org. This place offers a rich documentation, white pages, procedures, and links to other CORBA resources and products. A.6.3 Java block and Corbajava program play a role of a CORBA customer. In this way, the sector can access remote information and services disclosed by the CORBA object. However, the block can only be connected to the server that originally downloads it, so all CORBA objects that the program to communicate with it must be on the server. This is contrary to CORBA's purpose: it promises to achieve "transparent location", or "unrelated to location". When using the Java program as a CORBA customer, it will also bring some security issues. If you are in the Inland Network, a way is to relax the security restrictions on the browser. Or set a firewall to establish a secure connection to an external server. For this issue, some Java ORB products provide their own solutions. For example, some products have realized a technology called "HTTP Tunneling), and others provide special firewall functions. As the content in the appendix, all these topics are too complicated. But they do need a question that needs attention.
