Chapter 8 Appendix
8.1 Corba Version
There are many CORBA middleware products that can be seen in the software market, but based on different companies' product strategies and R & D directions, each product is in service performance, great differences in high-level language support and system platforms. The following is an analysis of the main products in several ways (see Table 1) for reference.
Main middleware products
8.2 The latest CORBA products currently:
MICO, ORBACUS, ORBACUS 3, The ace ORB (Tao), Visibroker, Jacorb, Omniorb 3, Omniorb 4.0 Preview, Orbix 2000, Businessware, Openorb, OpenFusion, MICO / E, TAO 1.2A (Beta), ORBACUS / E, SmalltalkBroker , ORBIX / E 2.0, ORB2, E * ORB C Edition, E * Orb Java Edition
8.3 Latest standard CORBA3
Corba3 new features
The term CORBA3 refers to a complete set of specifications, which always enhance CORBA performance and availability. All of these specifications have been adopted, and almost all specifications have been released from the OMG organization as part of the officially numbered CORBA version. In a new program of OMG, these specification are divided into "pre-prenors", only after the end of their first maintenance revision, will be converted to "available" (i.e., included in the current already The formal OMG specification in the number of the CORBA version).
The specifications in CORBA 3 can be divided into three categories:
• Java and Internet integration;
• Service quality (QoS) control;
• CORBA component system.
Here will be described in turn:
1. Java and Internet integration
The following specification enhances the integration of CORBA and increasingly popular Java language and Internet:
Objects that can be passed
Corba's Language-Independent Equivalent of Java's Serializable, (愧, I don't know how to translate, if there is a meeting, please enlighten it) value type to increase many characteristics, including Java to IDL (will The XML document can be represented later as the XML / Value mapping of the local CORBA type. Now, as part of CORBA, this feature has been included in the CORBA2.3 standard released in June 1999 and is still retained in the core CORBA specification as Chapter 5, 6. Aspects related to language include in their respective language mapping specifications.
Mapping of Java to IDL
This mapping allows the Java RMI object to interoperate over the network like the CORBA object. They have a CORBA object reference and issue IIOP protocols. Just like the CORBA component model and enterprise JavaBeans help developers and companies build an application component library, this specification will make CORBA component libraries and EJBs to build applications. Like the value type specification, the mapping of Java to IDL is also part of the CORBA 2.3 specification, which can be found in language mapping.
A shared naming service
The CORBA object is referenced to the cornerstone of the CORBA system. Because computer readable IOR (Interoperable Object Reference Object reference) is (until now) unique to connect an instance and call it, there is no way to connect a remote instance - even if you know it The location and it already puts up and runs ---- unless you get its object reference. The easiest way to get an object reference is to get a reference to its naming service, but if you have a reference to the name of the service, what should I do? A shared naming service defines an object reference in a URL form: CORBALOC, in a program, which can be used to connect to a remote location, including naming services. Another URL form, CORBANAME, actually returns the IOR of the object by calling the name service by using the user plus the name behind the URL.
For example, a CORBALOC identifier:
Corbaloc :: www.omg.org/nameservice
A CORBA naming service will be determined. This naming service is running on the IP address corresponding to the Www.omg.org domain name (if we run a naming service in OMG). In late 2000, this service is added to the CORBA2.4 version of the specification. In this specification, the object's URL is defined in Section 13.6.10, the configuration definition of the initial service reference is defined in Section 4.5.3. The standard semantic definition of the object composite name is defined in Section 2.4 of Naming CORBA Services.
Firewall specification
The CORBA 3 specification will define CORBA to be safe to pass through the firewall performance. When we wrote this paper in April 2001, the firewall specification used in 1998 was undergoing a big revision.
You can view the procedures for the revision and download specifications from here. The revision work plan is completed in 2001. When we update this article in July, it is over.
2. Service quality control
Asynchronous message and service quality control
The new message specification defines some asynchronous, time-independent call modes to CORBA, allowing static or dynamic calls to be used in any mode. The results of asynchronous calls can be obtained by the rotational detection or callback, which is determined by the mode used by the client in the original call. Policy can be used to control the quality of service called. Clients and objects can control sorting (according to time, priority, or time); set priority, period, and survival time; start and end time for a time-sensitive call setting; you can control routing policies and network routing jump counts . The message specification contains Chapter 22 of the CORBA 2.4 version of the CORBA 2.4 in 2000.
Minimum CORBA, fault tolerance CORBA, and real time CORBA
The minimum CORBA is mainly for embedded and card-type systems. Once these systems are fixed, they are firing into the core of the product, they are fixed, and their interaction with external networks is foreseeable - they do not need CORBA dynamic characteristics, such as dynamic call interfaces or supports it Warehouse, so these are not included in the minimum CORBA. The minimum CORBA has become part of the CORBA2.4 specification released later in 2000, in Chapter 23.
Real-time CORBA standardizes resource control - threads, protocols, links, etc. - Using priority models to achieve predictable behavior for hard and statistical real-time environments. Dynamic scheduling, is not part of the current specification, has been added in the form of a separate RFP, and the work has been completed when we update this article in July 2001, and entered the final voting phase. Real-time CORBA has become part of the CORBA2.4 specification released later in 2000, in Chapter 24.
Fault Tolerant CORBA Standardization Redundant Software Configuration and System When they run on a redundant hardware device, the reliable and robust performance depends on the CORBA company application. This specification has not been published as a number of Versions of Corba and the minimum CORBA. This specification has been formally adopted, and now its first round of revision, you can find this specification from here. 3. CORBA component package
CORBA components and CORBA scripts
This is one of the most exciting things since the definition IIOP protocol in CORBA2, and the CORBA component has improved many aspects in developers, users, and components consumers. The three most important part of the CORBA component is:
l A container environment that packs business, safe, persistence, and provides interfaces and event processing;
l integrate with enterprise JavaBeans;
l A software distribution form that enables the formation of the CORBA component software market.
The CORBA component container environment is lasting, supporting transactions and security. For programmers, these features are pre-packaged and provided at a higher abstract level than the Corba service. This is equivalent to improving the skills of business programmers: they no longer need to build business and security applications, they can now use their talents to produce commercial applications, and these applications naturally have these necessary features.
The container knows the event type generated and consumed by the component, and provides channels for transfer events. The container also knows the and needs of the components it contains and is suitable for each other. The CORBA component supports multi-port that supports navigation in them.
Enterprise JavaBeans (EJBS) will work as a CORBA component and can be installed in the CORBA component container. Of course, with EBJS, CORBA components can be written and supported in multiple languages.
This specification defines a multi-platform software distribution form, including installers and XML-based configuration tools that have also defined a separate script specification that maps CORBA and component assembly to some scripting languages that have been available.
The CORBA component model is now in the maintenance phase. Before the end, you can download the specifications that have been adopted.
Scripting language
The scripting language is initially assembled from the CORBA component (and Enterprise Javabeans), and now uses to access the CORBA client and object. Extensions assembled to component will follow CCM in CORBA3.0. CORBA supports mapping from two scripting languages: one to Python, another define a scripting language for CORBA. They have been officially released, but because they are mapped in the omg language, rather than in the CORBA book, there is no release version of CORBA.
in conclusion…
After ten years of OMG organization, the basic CORBA architecture has been completed and has been applied at thousands of places. The initial binding expansion of CORBA3 has brought easy to use and accurately controlled the system established by the OMG organization. These extensions ensure the role of CORBA in the future computer world.
