Corba introduction

Introduction to CORBA

(This article is reproduced from Software Engineering Expert Network www.21cmm.com)

Su Yang

Corba (Common Object Request Broker Architecture, Public Object Request Agent Architecture) is a technical specification for application software architecture and object technology proposed by OMG (object management organization, Object Management Group). The core is a standard language, interface and protocol. To support interoperability between heterogeneous distribution applications and objects independent of platforms and programming languages.

After nearly ten years of development, CORBA has gradually been mature, and successfully applied in many large software systems in my country, thereby producing a lot of demand for software developers who grasp CORBA technology. Here, we have organized this lecture at the request of the readers. This series introduces the basic idea, architecture, and development of CORBA, and the design and development of CORBA applications. I hope to help the majority of software development, designers, open ideas, and deepen the understanding of CORBA, and then truly master this technology. And can develop a more powerful software system in actual work, more efficient and rapidly developing a stronger software system, and ultimately promoting the booming of my country's software career.

Corba generated background

In recent years, with the increasing maturation of Internet technology, public and commercial companies are enjoying the high-quality digital life brought by high speed and low-cost network information transmission. However, due to the continuous expansion of network size and the rapid speed of computer hardware and software technology, it has brought great challenges to the traditional application software system.

First, in enterprise applications, hardware system integrators are based on performance, price, service, etc., usually integrate hardware devices, operating systems, database platforms, etc. from different manufacturers, etc. in the same system, resulting in Isomerism has brought serious problems with interoperability, compatibility, and smooth upgrade capabilities for application software.

In addition, as the network-based business is increasing, the distributed application of traditional client / server (C / S) mode is increasingly displayed in the limitations of operational efficiency, system network security, and system upgrade capabilities.

In order to solve the interconnection of different hardware devices and software systems in the distributed computing environment (DCE, DISTRIBUTED Computing Environment), enhance interoperability between network software, solve the shortcomings in traditional distributed computing models, etc., object management organization (OMG) A common object requesting agency architecture (CORBA) is proposed to enhance the interoperability between software systems to make the construction flexible distributed application system possible.

It is based on the development and maturity of object-oriented technology, the general application of customer / server software system model and integration of existing systems, and promoting the maturation and development of CORBA technology. As the core of object-oriented system, CORBA has brought a true interconnection for today's network computing environment.

CORBA development process

1. Object Management Organization (OMG)

OMG was established in 1989, as a non-profit organization, focusing on the development of advanced technology, commercially feasible and independent of the manufacturer's software interconnection, promoting object-oriented model technology, enhancing software Portability, Reusability and Interoperability.

At the beginning of the organization, members include Unisys, Sun, Cannon, Hewlett-Packard, Philips, etc., Which have reputable hardware and software in the industry, and currently has more than 800 members.

2. The main version of CORBA

● In November 1990, OMG issued the "Object Management System Guide", preliminantly clarified the idea of ​​CORBA; ● October 1991, OMG launched version 1.0, which defines the interface definition language (IDL), object management model, and dynamic request Contents such as API and interface warehouses; ● In December 1991, OMG launched the CORBA version 1.1, and introduced the concept of object adapter on the establishment of the second-edition of the second edition; ● In August 1996, OMG Based on the previous upgrade version, completed version 2.0 development, the important content in this version is the introduction of the object request Agent Agreement (IIOP, Internet Inter-ORB Protocol) to implement interoperability in the true meaning of different manufacturers; ● In September 1998, OMG issued the CORBA version 2.3, which added asynchronous real-time transmission, service quality specification, and so on supporting CORBA objects. Currently, middleware manufacturers who announced support for Corba 2.3 specifications include the famous CORBA product manufacturer such as Inprise (Borland), Iona, Bea System. CORBA Architecture Overview

The CORBA specifications make full use of the latest achievements in the development of today's software technology, implementing integration of application software in a network-based distributed application environment, making it reusable, portable and interoperable in distribution and heterogeneous environments. Its characteristics can be summarized as the following aspects:

1. Introducing Middleware (MiddleWare) as a transaction agent, completes the service request proposed by the client (client) (introduced into the middleware concept, and shown in Figure 1);

Figure 1 Relationship between the client and the server is introduced into the middleware

2. Realize the complete separation of customer and service objects, customers do not need to understand the implementation process of the service object and the specific location (see the CORBA system architecture shown in Figure 2);

3. Provide soft bus mechanisms such that in any environment, software developed by any language can be integrated into a distributed system as long as it meets the definition of the interface specification;

4. The CORBA Specification Software System uses object-oriented software implementation methods to develop application systems, realize the full package of internal details, retention the external interface definition of the object method.

In the above features, the most prominent is the introduction of the middleware, referred to as the object request agent (ORB, Object Request Broker) and an object-oriented development mode in the CORBA system.

Object models are specific abstractions for applying developers' properties and functions of objective things. Since CORBA uses an object model, all applications in the CORBA system are viewed as a collection of objects and related operations, so through the object request Agent (ORB), the acquisition of the application objects distributed in the network in the CORBA system depends only on the network. The exact degree of smoothness and service object feature acquisition is independent of the location of the object and the device environment where the object is located.

Figure 2 CORBA system architecture

Main application direction and middleware product introduction of CORBA

The launch of the CORBA specification is re-adjusted the relationship between the client and the server. The client can propose transaction requests to the server, and can also serve as the server role for the next request.

Since the CORBA system introduces the concept of the middleware, the transaction agent completes the communication between the client and the server by the middleware, so that the server is relatively transparent to the client's location, and the original distributed computing model is canceled client, server Part of the correspondence between. The CORBA client can dynamically obtain the location of the service object at runtime, and can submit a transaction request for multiple service objects, so greatly drive the development of the distribution calculation.

Distribution calculations refer to two or more software in the network share information resources to each other. These software can be located in the same computer, or may be deployed anywhere in the network node. Software systems based on distributed model have technical advantages of balanced operation system loads and sharing network resources. In addition, the CORBA specification constraints uses the structure of the object-oriented distributed software to realize the intact package of internal details in the interface definition language, thereby reducing the complexity of the software system, increasing the reusability of software functions. CORBA provides mapping of advanced languages ​​such as C / C , Java, SmallTalk, which greatly reduces the dependence of programming language, so that software developers can share existing results over larger ranges.

It is the above characteristics to promote the development of distributed multi-layer software architecture. At present, CORBA technology has a wide range of applications in banks, telecommunications, insurance, electricity and e-commerce.

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. According to the sorted information, the author analyzed the main products (see Table 1) for the reader to be referenced at the time of choice. Develop CORBA application instances with Java

General Object Agent Architecture Corba (Common Object Request Broker Architecture) is a solution defined by the Object Management Organization to implement a large number of hardware and software, and CORBA is also an important step towards object-oriented standardization and interoperability. ■ Introduction to CORBA Technical, CORBA is allowed to communicate with each other, regardless of where they exist and who is designed. CORBA1.1 is published by OMG in 1991, which defines an Interface Definition Language (IDL) and an application programming interface (API) that implements interaction between customer objects and server objects in the Object Request Agent (ORB). CORBA2.0 is released in 1994 that specifies the communication rules of ORB between individual suppliers. The CORBA standard is mainly divided into three parts: Interface Definition Language (IDL), Object Request Agent (ORB), and ORB Interoperability Protocol IIOP. ORB is an middleware that establishes a Client / Server relationship between an object. Using ORB, customers can transparently call methods on a service object, which can be locally or on other machines connected through the network. ORB intercepted this call to find an object to implement the service and pass parameters to it, and the call method returns the final result. Customers don't know where the service object is located, what is the programming language and the operating system, and does not know other system parts that are not object interface. Thus, ORB provides interoperability in different machines in a heterogeneous distribution environment, and seamlessly integrates a variety of object systems. When developing traditional Client / Server applications, developers use their own or a recognized standard to define an agreement for communication between devices. The definition of the protocol relies on the implementation of language, network transmission, and many other factors, and the argument of ORB simplifies this process. When using ORB, the protocol is defined using the Interface Definition Language (IDL), and the IDL is independent of language. And ORB provides strong flexibility, which allows programmers to choose the most suitable operating system, execute the environment, and even system each component can also be implemented in different programming languages. More importantly, it allows integration of existing components. In an ORB-based solution, developers can model the legacy system with the same IDL as creating new objects, and they create "Packaging" to deliver information between standardized software bus and legacy system interface. Using CORBA, users can transparently access information, do not need to know what software is existing, what hardware platform is used, and where it is located in the corporate network. As a communication core for object-oriented systems, CORBA has truly interoperability to today's computing environment. ■ Corba and Java's interrelationship CORBA does not mean object request agency (ORB), it is also a very comprehensive distributed object platform. Corba allows Java applications to span networks, language, and operating systems, and provides a set of distributed services, such as distributed self-observations, dynamic discovery, transactions, relationships, security, and naming. Java is not only a language, it is still a dynamic code system, which is a portable virtual machine (JVM) for running objects. Java provides simpler ways for development, management, and release of Client / Server applications. People can publish this app to thousands of users by placing the app on a web server without having to care about its installation and upgrade. Java is also very suitable for the development of the server, which can dynamically move the service code to the most needed. Java will enable CORBA objects to run on various machines such as hosts, network computers to cellular phones, and simplify the code release of large CORBA systems.

Java is an ideal programming language for customers and service objects, Java built-in multi-thread, garbage collection, and error handling make it easy to write robust network objects. These two object models can be supplemented well, and the transparency of the CORBA processing network, the transparency of Java processing, and CORBA provides a distributed structure for the Java portable application environment. ■ Using Java Development CORBA Application Let me briefly introduce the steps to develop CORBA. Developing CORBA applications using Java requires the following five steps: 1. Use the IDL to create an interface (About.IDL) 2. The following OMG IDL describes a CORBA object. Module About {interface show {string showname ();};}; saves it to show.idl. 3. Compile the interface and generate the CORBA support file. We use the following command to compile this IDL interface: IDLTOJAVA Show.IDL IDLTOJAVA is Sun's IDL compiler, you can download it from Sun Company Site. Because iDLTojava needs to be precompiled before compiling the IDL file, if there is no precompiler on your machine, you can use the following command: idltojava -fno-cpp show.idl will generate the About subdirectory in the current directory, of which It will include some support files. If you are interested, you can look at it, but you must do not modify it.

4. Implement the main () method of the server (Showserver.java) Showserver, you can complete the following tasks: (1) Creating an ORB instance (2) Creating a service object instance (implementation of the CORBA About object) and inform ORB (3) get A CORBA object reference to a named context, registering a new CORBA object (4) in the name context (4) Register the new object in the "About" name (5) Waiting for the new object to implement the server source program: import About.; import org.omg.CosNaming.; import org.omg.CosNaming.NamingContextPackage.; import org.omg.CORBA.; class ShowObject extends _ShowImplBase {public String ShowName () {return "/ nMy name IS Seymour !! / N ";}} public class showserver {public static void main (string args []) {TRY {// created and initialize orb orb = orb.init (args, null); // Create service object and register the ORB ShowObject ShowRef = new ShowObject (); orb.connect (ShowRef); // get the root naming context org.omg.CORBA.Object objRef = orb.resolve_initial_references ( "NameService"); NamingContext ncRef = NamingContextHelper. Narrow (Objref); // Binding objects in NameComponent NC = New NameComponent ("About", "); NameComponent Path [] = {nc}; ncref.rebind (path, showref); // Wait from Client call java.lan G.Object sync = new java.lang.object (); synchronized (SYNC) {sync.wait ();}} catch (exception e) {system.err.println ("Error:" E); E.PrintStackTrace (}});}}} 4. Implementing the application client under the client (ShowClient.java) will complete the following tasks: (1) Create an ORB; (2) Get a reference to named a name; (3) ) Find "show" in the name context and get a reference to the CORBA object; (4) call the SHOWNAME () operation of the object and print the result.

Import About. ; Import Org.comg.cosnaming.; Import Org.Mg.Corba.; Public Class ShowClient {Public Static Void Main (String Args []) {Try {// Create and initialize Orb orb = ORB .init (args, null); // Get root name context org.omg.corba.object objref = orb.resolve_initial_reference ("nameservice"); NamingContext ncref = NamingContextHelper.narrow (Objref); // Analyze object reference in Naming NameComponent nc = new namecomponent ("about", ""); nameComponent Path [] = {nc}; about.show showref = showhelper.narrow (ncref.resolve (path)); // Call the show service object and print results String Show = showref.showname (); system.out.println (show);} catch (exception e) {system.out.println ("error:" e); E.PrintStackTrace (System.out);}}} 5. Build and run the Showname program (1) Compile .java file, including Stub and Skeleton (in the About Directory): javac java about / .java (2) Start a MS-DOS command interpreter, enter the following command Make sure the name server is running: TNAMESERV -ORBINIALPORT 1050 (3) Start another MS-DOS command interpreter, enter the following command, start the show server: Java Showser -orbinitialPort 1050 (4) Start a MS-DOS command Interpreter show application client: Java ShowClient -orbinitialPort 1050 The word "My Name is Seymour!" Appears on the screen, indicating that the experiment has been successful. EAI technology analysis

Author: Sha Jin (savorjava@yahoo.com.cn)

Keywords: Eai, Eis, Corba, J2EE, JCA

Abstract: With the further acceleration of social informationization, many companies have begun to discover new applications and systems while introducing new applications and systems, not being abandoned or Replacement is an important means of saving the company's operating costs and utilizing the company's resources. However, due to the fact that the architecture and new systems used by the old applications and systems often make these applications into new systems are not easy. This article is for all kinds of integration requirements in such enterprise applications. The technology can be analyzed and suggested.

The problem that hinders enterprises to integrate new and old application systems seems to be obvious, not consisting of two points below:

The architecture used is different; the techniques used are different; but there is a huge difficulty in all dividends that integrate these two enterprise applications. In order to better solve these problems, many related technologies and programs have emerged, such as CORBA, J2EE, XML, DCOM, and more. This article is not to specifically introduce the implementation of these technologies and programs to the reader. The purpose of this paper analyzes different technologies in accordance with various situations in the integration of enterprise applications, and gives corresponding feasible recommendations.

Introduction EAI

EAI, that is, enterprise application integration is not a new concept. But after entering the 1990s, EAI's importance begins to reflect and pay attention. The reason is very simple, and companies need to constantly improve their application system. As a tool that maximizes corporate interests, the company's manager wants their investment to be rewarded. Obviously, the managers of the company gradually began to realize that if the introduction of new application systems cannot work with old application systems, they will cause past investment waste, older application system features or all being abandoned. This is obviously unwilling to see the company's managers, so it has developed the new architecture to develop the old system effective integration to start formal walking on the research desktop of each company.

In this article, we call the company's application system as enterprise information system EIS. EAI's ultimate goal is to integrate various EIS of the company, this process should not make (too much) modifications to existing applications as much as possible, and implement the integration of data sharing and business processes.

Of course, companies need planning before EAI to determine implementation of EAIs in time and cost in terms of complete introduction of new application systems. Because failure EAI processes will bring greater losses to companies, the proportion of integration risks should be adequately followed.

Next, a number of different integration techniques will be given in the article, indicating appropriate technologies that should be adopted. However, it should be noted that integrated technology is still constantly developing, and the recommendations given are not necessarily the best or in the future, this is also related to the author's experience, we must recognize that integrated work requires too much knowledge, It is also quite complicated, especially when the number of EIs desired is large and the architecture is rare, and the integrated difficulty is rising. Therefore, how to use and combined integration techniques and suggestions are needed to consider it, do not treat them as a model, they are just some options that are optional and not optimal, maybe EAI will never have a fixed mode.

One thing to explain is that the heterogeneous system using different languages ​​is as an example in Java and C , which believes that they can represent the current popular case to facilitate the reader's understanding and application.

It is also important to emphasize that the integration cases involved in this article are integrated with the application and business, and the data integration is too much to integrate the discussion scope of this article.

2. Technical analysis

The problem will make people think that EAI needs to drive the rapid development of related technologies, although these technologies have not yet made EAI, but they do make greater guarantees of EAI success. In this article, we will relate to some of the following technical specifications. Here we don't have to describe each technical specification in detail, because each item is enough to use a few books to explain, and these books already exist, this should be a good news. What we need to do is just to understand and analyze their advantages and disadvantages and applicability.

2.1 General object request agency structure CORBA

It is difficult to say that EAI is hard to think about CORBA. After all, one of the main methods of co-work with different programming languages ​​is to use CORBA. As an architecture of a distributed object, the initial purpose of CORBA is to work together between different programming languages, operating systems, and software platforms. Moreover, the development of CORBA2 has been fully based on object-oriented technology, and CORBA3 develops towards the component-based direction, and its openness makes communication between different CORBA implementations, and can even reach 100% source. Code is compatible. advantage:

The possibility of synergy in different programming languages ​​in a middleware; there is no special requirement and dependence on the operating system, depending on the implementation, but the real agent can choose; effective and mature development history, with many popular The application system (such as J2EE) is closely related to the architecture.

Disadvantages:

The specific performance is related to the achievement of the selected implementation, and the performance is good. Some of the services of the middleware are always bottleneck; in general, the source code needs to be modified to implement packaging of the old application software;

Be applicable:

When the two enterprise applications that need to be integrated are interacting, Java and C are a good example when implemented by different programming languages. Almost the almost the only way to work together in these two languages ​​is to use CORBA. Of course, the functional characteristics provided by JDK are also possible, but their complexity and the destruction of Java portability make it unable to compete for the integration. And the ability of JNI does not have distributed implementation, and its goal is not here.

CORBA is well suited to package existing application software by modifying source code, providing new CORBA distributed objects for other heterogeneous systems. For remote approach, the IIOP protocol will be a good choice, such as a distributed object of CORBA through J2EE's RMI-IIOP.

2.2 Java2 Platform Enterprise Edition J2EE

In recent years, J2EE undoubtedly play an important foot. The most important technique for developing business logic or intermediate components is EJB, which provides a support for major enterprise technologies such as transactions, security, and persistent support to facilitate the development of business components. Although EJB is limited to Java programming languages, this technology does not have problems. At the same time, J2EE and CORBA technology have provided feasible roads for low-level components, and RMI-IIOP and JMS such as RMI-IIOP and JMS have undoubtedly provide a powerful functional core for J2EE.

advantage:

Based on the standardized platform, there is a large number of implementations can be selected; providing a modern component architecture, which simplifies the development of complex components; providing major corporate technology such as affairs, security Sex and persistent support and support these services in declaration and editing. Relative maturity, supporting a large number of middleware technologies, can provide satisfactory performance and upgradeability for EAI.

Disadvantages:

Limited from Java programming languages, although other middleware technologies (such as CORBA) support; the displacement between real companies is less than 100%; compared to implementation technology specific to an operating system or platform And the performance needs to be further improved, and the resources are large.

Be applicable:

The J2EE specification itself provides a huge enterprise application integrated platform, based on Java, which makes it not dependent on the hardware platform and operating system, but also makes it limited to single language development. But this development platform, there are currently different manufacturers with a variety of implementation methods that meet specifications. J2EE supports a large number of middleware technology, and the existing system can work together. HTTP, RMI-IIOP, JMS, JDBC, JCA, and support for XML, corporate affairs, and enterprise security have made it a preferred choice in several enterprises application integration platforms. 2.3 XML and XSLT

In addition to a large number of applications in Internet technology and document description, XML is also an important role in data exchange. As a stand-alone platform, just use standard text, XML can be read and written in all program languages. Once the DTD or Schema, XML interpretation can verify and process the file content. XSLT is also based on XML technology, but its role is to reformat and transmit an XML data file, resulting in a new designated XML document, believes that the reader can imagine that these technologies have occurred during data exchange in different application systems. Great role.

advantage:

The content is composed of standard text, any platform and program language can be used; interpretation of various programming languages ​​can verify and process file content according to DTD or Schema; the format conversion is basically unrestricted, which can meet the needs of different application systems .

Disadvantages:

DTD is used in a lot of use in the past, but the DTD itself is not XML, but based on regular expression; when XML content is large, the execution efficiency of the interpretation program will be a problem;

Be applicable:

When different application systems use their respective data formats, or complicated with complex industry standards, it is now necessary to exchange data between each application system, then XML and XSLT provide a viable means. Of course, XML does not solve all data exchange issues, how to record a variety of different raw data formats in XML documents is a tricky problem. But a good side is that various platforms and programming languages ​​have now been well supported by XML and XSLT. Once XML is ready, XSLT is ready to convert it into data format required by other application systems.

2.4 Distributed Component Object Model DCOM

DCOM expands objects supported by COM in the network and allows COM applications to be distributed over multiple computers in the LAN. DCOM communicates through the network protocol definition process. At runtime, COM serves the client and serves the client and uses the RPC component and follows the DCOM protocol standard.

advantage:

A distributed process based on a COM architecture is provided on the Windows platform; useful on Windows platforms to achieve more satisfactory performance requirements.

Disadvantages:

There is difficulties in cross-platform use, and performance cannot be guaranteed.

Be applicable:

The preferred choice for integration on the Windows platform, but synergy with other platforms and programming languages ​​needs to be supported by third party manufacturers.

2.5 Message Middleware MOM

Enterprise messaging allows applications to perform reliable transmission across multiple platforms. By using a reliable message queue, providing the directory, security, and management services required to transfer messaging, MOM ensure the security of the message transfer between the validated applications, which typically provides synchronous and asynchronous transmission mode. The most common way to ensure reliable transmission within the company is to use a message delivery system. Corba and J2EE currently support MOM industry standard interfaces.

advantage:

For different enterprise applications, messaging is provided across multiple platforms; in addition to supporting synchronous transmission mode, asynchronous transmission is supported, it helps to transmit messaging reliably in the application.

Disadvantages:

As with other middleware technology, high flow performance bottleneck is improved;

Be applicable:

If a reliable transmission is guaranteed between applications to be on multiple platforms, and these applications do not run at the same time, the RPC direct communication or transmission data between applications will not be competent, and the message middleware MOM will be one Good choice. Even when the request is established, the receiver application is not running, this request will not be lost, this is the advantage of asynchronous transmission. 2.6 J2EE Connector Architecture JCA

JCA is made in J2EE1.3, which is implemented and provided by the EIS manufacturer. The JCA resource adapter is a standardized EIS agent, which can be inserted into the task compliant with the J2EE specification, and the EIS execution operation is performed by the standard EIS access interface CCI provided by the application server. JCA provides EAI-based application developers with standard methods that integrate EIS into J2EE. This method defines a common API and service that developers can use in the J2EE environment.

advantage:

JCA can not only integrate the EIS system to the J2EE application in the data, but it can also involve safety and transaction into the eligible EIS system. The emergence of JCA enables the integration of the legacy EIS system to the J2EE application to decrease from NXM to n m. JCA Due to Java technology, Java technology is small during the transplantation process of multi-platform.

Disadvantages:

JCA is a tight coupling problem, which requires an API that is desired to be integrated, and packages these operations. JCA is based on Java technology, although not needed to be integrated, the EIS system is also implemented, but customer applications that use this EIS through JCA must be Java implementation. The implementation of JCA is not easy. If the connection management part is required by JCA, the complexity will rise sharply once it joins transaction and security management, if it is implemented in CCI, it may be more.

Be applicable:

The benefits of JCA are basically the J2EE application server and the EIS system vendor, because their products are often in line with various standards and norms, and the unified norms given by JCA are undoubtedly reducing risks and decreased. A good weapon for development costs. But for the general enterprise self-produced application system, JCA may not play a lot of roles. In contrast, it may become bottlenecks in the development process. There are several reasons, the first, JCA is not the development of the resource adapter, and all developers can be competent. Its development model is different from the writing of ordinary code, and JCA will play the Factory model in the design mode. Second, JCA acts as a unified specification, and its implementation requires a lot of standards and specifications to support, such as XA distribution transactions. The self-produced application system of an enterprise often does not have these standards and specifications, and the resource adapters that are implemented are not available to the many advantages provided by JCA. Third, the resource adapter developed by the company will eventually insert into various J2EE application servers, but as a third-party developer, do not understand the related features of the J2EE application server used, even the defects existing in the application server, Although both parties follow the JCA specification, the different achievements makes the resource adapter developed by third parties may not be available or applied.

EAI technology analysis

Author: Sha Jin (savorjava@yahoo.com.cn)

Keywords: Eai, Eis, Corba, J2EE, JCA

Abstract: With the further acceleration of social informationization, many companies have begun to discover new applications and systems while introducing new applications and systems, not being abandoned or Replacement is an important means of saving the company's operating costs and utilizing the company's resources. However, due to the fact that the architecture and new systems used by the old applications and systems often make these applications into new systems are not easy. This article is for all kinds of integration requirements in such enterprise applications. The technology can be analyzed and suggested. The problem that hinders enterprises to integrate new and old application systems seems to be obvious, not consisting of two points below:

The architecture used is different; the techniques used are different;

However, there is a huge difficulty in full crossing these two enterprise applications. In order to better solve these problems, many related technologies and programs have emerged, such as CORBA, J2EE, XML, DCOM, and more. This article is not to specifically introduce the implementation of these technologies and programs to the reader. The purpose of this paper analyzes different technologies in accordance with various situations in the integration of enterprise applications, and gives corresponding feasible recommendations.

Introduction EAI

EAI, that is, enterprise application integration is not a new concept. But after entering the 1990s, EAI's importance begins to reflect and pay attention. The reason is very simple, and companies need to constantly improve their application system. As a tool that maximizes corporate interests, the company's manager wants their investment to be rewarded. Obviously, the managers of the company gradually began to realize that if the introduction of new application systems cannot work with old application systems, they will cause past investment waste, older application system features or all being abandoned. This is obviously unwilling to see the company's managers, so it has developed the new architecture to develop the old system effective integration to start formal walking on the research desktop of each company.

In this article, we call the company's application system as enterprise information system EIS. EAI's ultimate goal is to integrate various EIS of the company, this process should not make (too much) modifications to existing applications as much as possible, and implement the integration of data sharing and business processes.

Of course, companies need planning before EAI to determine implementation of EAIs in time and cost in terms of complete introduction of new application systems. Because failure EAI processes will bring greater losses to companies, the proportion of integration risks should be adequately followed.

Next, a number of different integration techniques will be given in the article, indicating appropriate technologies that should be adopted. However, it should be noted that integrated technology is still constantly developing, and the recommendations given are not necessarily the best or in the future, this is also related to the author's experience, we must recognize that integrated work requires too much knowledge, It is also quite complicated, especially when the number of EIs desired is large and the architecture is rare, and the integrated difficulty is rising. Therefore, how to use and combined integration techniques and suggestions are needed to consider it, do not treat them as a model, they are just some options that are optional and not optimal, maybe EAI will never have a fixed mode.

One thing to explain is that the heterogeneous system using different languages ​​is as an example in Java and C , which believes that they can represent the current popular case to facilitate the reader's understanding and application.

It is also important to emphasize that the integration cases involved in this article are integrated with the application and business, and the data integration is too much to integrate the discussion scope of this article.

2. Technical analysis

The problem will make people think that EAI needs to drive the rapid development of related technologies, although these technologies have not yet made EAI, but they do make greater guarantees of EAI success. In this article, we will relate to some of the following technical specifications. Here we don't have to describe each technical specification in detail, because each item is enough to use a few books to explain, and these books already exist, this should be a good news. What we need to do is just to understand and analyze their advantages and disadvantages and applicability. 2.1 General object request agency structure CORBA

It is difficult to say that EAI is hard to think about CORBA. After all, one of the main methods of co-work with different programming languages ​​is to use CORBA. As an architecture of a distributed object, the initial purpose of CORBA is to work together between different programming languages, operating systems, and software platforms. Moreover, the development of CORBA2 has been fully based on object-oriented technology, and CORBA3 develops towards the component-based direction, and its openness makes communication between different CORBA implementations, and can even reach 100% source. Code is compatible.

advantage:

The possibility of synergy in different programming languages ​​in a middleware; there is no special requirement and dependence on the operating system, depending on the implementation, but the real agent can choose; effective and mature development history, with many popular The application system (such as J2EE) is closely related to the architecture.

Disadvantages:

The specific performance is related to the achievement of the selected implementation, and the performance is good. Some of the services of the middleware are always bottleneck; in general, the source code needs to be modified to implement packaging of the old application software;

Be applicable:

When the two enterprise applications that need to be integrated are interacting, Java and C are a good example when implemented by different programming languages. Almost the almost the only way to work together in these two languages ​​is to use CORBA. Of course, the functional characteristics provided by JDK are also possible, but their complexity and the destruction of Java portability make it unable to compete for the integration. And the ability of JNI does not have distributed implementation, and its goal is not here.

CORBA is well suited to package existing application software by modifying source code, providing new CORBA distributed objects for other heterogeneous systems. For remote approach, the IIOP protocol will be a good choice, such as a distributed object of CORBA through J2EE's RMI-IIOP.

2.2 Java2 Platform Enterprise Edition J2EE

In recent years, J2EE undoubtedly play an important foot. The most important technique for developing business logic or intermediate components is EJB, which provides a support for major enterprise technologies such as transactions, security, and persistent support to facilitate the development of business components. Although EJB is limited to Java programming languages, this technology does not have problems. At the same time, J2EE and CORBA technology have provided feasible roads for low-level components, and RMI-IIOP and JMS such as RMI-IIOP and JMS have undoubtedly provide a powerful functional core for J2EE.

advantage:

Based on the standardized platform, there is a large number of implementations can be selected; providing a modern component architecture, which simplifies the development of complex components; providing major corporate technology such as affairs, security Sex and persistent support and support these services in declaration and editing. Relative maturity, supporting a large number of middleware technologies, can provide satisfactory performance and upgradeability for EAI.

Disadvantages:

Limited from Java programming languages, although other middleware technologies (such as CORBA) support; the displacement between real companies is less than 100%; compared to implementation technology specific to an operating system or platform And the performance needs to be further improved, and the resources are large.

Be applicable:

The J2EE specification itself provides a huge enterprise application integrated platform, based on Java, which makes it not dependent on the hardware platform and operating system, but also makes it limited to single language development. But this development platform, there are currently different manufacturers with a variety of implementation methods that meet specifications. J2EE supports a large number of middleware technology, and the existing system can work together. HTTP, RMI-IIOP, JMS, JDBC, JCA, and support for XML, corporate affairs, and enterprise security have made it a preferred choice in several enterprises application integration platforms.

2.3 XML and XSLT

In addition to a large number of applications in Internet technology and document description, XML is also an important role in data exchange. As a stand-alone platform, just use standard text, XML can be read and written in all program languages. Once the DTD or Schema, XML interpretation can verify and process the file content. XSLT is also based on XML technology, but its role is to reformat and transmit an XML data file, resulting in a new designated XML document, believes that the reader can imagine that these technologies have occurred during data exchange in different application systems. Great role.

advantage:

The content is composed of standard text, any platform and program language can be used; interpretation of various programming languages ​​can verify and process file content according to DTD or Schema; the format conversion is basically unrestricted, which can meet the needs of different application systems .

Disadvantages:

DTD is used in a lot of use in the past, but the DTD itself is not XML, but based on regular expression; when XML content is large, the execution efficiency of the interpretation program will be a problem;

Be applicable:

When different application systems use their respective data formats, or complicated with complex industry standards, it is now necessary to exchange data between each application system, then XML and XSLT provide a viable means. Of course, XML does not solve all data exchange issues, how to record a variety of different raw data formats in XML documents is a tricky problem. But a good side is that various platforms and programming languages ​​have now been well supported by XML and XSLT. Once XML is ready, XSLT is ready to convert it into data format required by other application systems.

2.4 Distributed Component Object Model DCOM

DCOM expands objects supported by COM in the network and allows COM applications to be distributed over multiple computers in the LAN. DCOM communicates through the network protocol definition process. At runtime, COM serves the client and serves the client and uses the RPC component and follows the DCOM protocol standard.

advantage:

A distributed process based on a COM architecture is provided on the Windows platform; useful on Windows platforms to achieve more satisfactory performance requirements.

Disadvantages:

There is difficulties in cross-platform use, and performance cannot be guaranteed.

Be applicable:

The preferred choice for integration on the Windows platform, but synergy with other platforms and programming languages ​​needs to be supported by third party manufacturers.

2.5 Message Middleware MOM

Enterprise messaging allows applications to perform reliable transmission across multiple platforms. By using a reliable message queue, providing the directory, security, and management services required to transfer messaging, MOM ensure the security of the message transfer between the validated applications, which typically provides synchronous and asynchronous transmission mode. The most common way to ensure reliable transmission within the company is to use a message delivery system. Corba and J2EE currently support MOM industry standard interfaces.

advantage:

For different enterprise applications, messaging is provided across multiple platforms; in addition to supporting synchronous transmission mode, asynchronous transmission is supported, it helps to transmit messaging reliably in the application.

Disadvantages:

As with other middleware technology, high flow performance bottleneck is improved;

Be applicable:

If a reliable transmission is guaranteed between applications to be on multiple platforms, and these applications do not run at the same time, the RPC direct communication or transmission data between applications will not be competent, and the message middleware MOM will be one Good choice. Even when the request is established, the receiver application is not running, this request will not be lost, this is the advantage of asynchronous transmission. 2.6 J2EE Connector Architecture JCA

JCA is made in J2EE1.3, which is implemented and provided by the EIS manufacturer. The JCA resource adapter is a standardized EIS agent, which can be inserted into the task compliant with the J2EE specification, and the EIS execution operation is performed by the standard EIS access interface CCI provided by the application server. JCA provides EAI-based application developers with standard methods that integrate EIS into J2EE. This method defines a common API and service that developers can use in the J2EE environment.

advantage:

JCA can not only integrate the EIS system to the J2EE application in the data, but it can also involve safety and transaction into the eligible EIS system. The emergence of JCA enables the integration of the legacy EIS system to the J2EE application to decrease from NXM to n m. JCA Due to Java technology, Java technology is small during the transplantation process of multi-platform.

Disadvantages:

JCA is a tight coupling problem, which requires an API that is desired to be integrated, and packages these operations. JCA is based on Java technology, although not needed to be integrated, the EIS system is also implemented, but customer applications that use this EIS through JCA must be Java implementation. The implementation of JCA is not easy. If the connection management part is required by JCA, the complexity will rise sharply once it joins transaction and security management, if it is implemented in CCI, it may be more.

Be applicable:

The benefits of JCA are basically the J2EE application server and the EIS system vendor, because their products are often in line with various standards and norms, and the unified norms given by JCA are undoubtedly reducing risks and decreased. A good weapon for development costs. But for the general enterprise self-produced application system, JCA may not play a lot of roles. In contrast, it may become bottlenecks in the development process. There are several reasons, the first, JCA is not the development of the resource adapter, and all developers can be competent. Its development model is different from the writing of ordinary code, and JCA will play the Factory model in the design mode. Second, JCA acts as a unified specification, and its implementation requires a lot of standards and specifications to support, such as XA distribution transactions. The self-produced application system of an enterprise often does not have these standards and specifications, and the resource adapters that are implemented are not available to the many advantages provided by JCA. Third, the resource adapter developed by the company will eventually insert into various J2EE application servers, but as a third-party developer, do not understand the related features of the J2EE application server used, even the defects existing in the application server, Although both parties follow the JCA specification, the different achievements makes the resource adapter developed by third parties may not be available or applied.