Enterprise Informatization Construction based on SOA--ESB Enterprise Service Bus Technology realization

Absrtact: This paper introduces the interaction and coupling problems in the process of informatization construction of modern enterprises, expounds the solution of service-oriented enterprise application--ESB Enterprise Service Bus, gives the detailed design of this solution, and presents the implementation example.
Keywords: service oriented; enterprise solution; Enterprise Service Bus
Middle Figure category Number: TP391 document identification code: B article number: 1009-3044 (2007) 06-11659-02
　　
1 questions raised
Enterprise information Construction, most of which have ended the independent construction of the various business units, the urgent need for the enterprise has been built, deployed a good business system, unicom, to build the overall enterprise information system.
The unicom mentioned here is not simply connected to each application system through the Internet, but rather the sharing and interaction of business work and business data between the various systems.
At present, in the development of all business systems are ripe, in order to make the network model of the interaction between systems confusing, the development cost can be increased by adding a specific interface to the system and accomplishing the specific data or business interaction of the system. With the continuous development of the new interactive demand, the enterprise informatization construction is always under the bad condition of constantly mending. (Figure 1)
Fig. 1 The bad condition that the enterprise informatization construction has been constantly repaired
With more and more business systems in the enterprise, this complex system interaction will be more and more, each system even appear interdependent, coupled with each other. This situation leads directly to the difficult problems such as repetitive construction of business components, redundancy of business data, different steps in enterprise data, blurred system boundaries, difficulty in maintenance, difficulty in development, etc.
　　
2 ESB Enterprise Service Bus
The ESB (Enterprise service bus) is the product of traditional middleware technology combined with XML, Web services and other technologies. The ESB provides the most basic connection center in the network and is the essential element to construct the enterprise nervous system.
The concept of an enterprise service bus (Enterprise service bus,esb) is developed from a service-oriented architecture (service-oriented architecture, SOA). SOA describes an application integration model for an IT infrastructure in which the set of soft components is coupled with a well-defined hierarchical structure in which an ESB is a pre-assembled SOA implementation that contains the basic functional components necessary to achieve the SOA tiering goals.
The ESB is a product of the combination of traditional middleware technology with XML, Web services and other technologies. The advent of the ESB has changed the traditional software architecture to provide a cheaper solution than traditional middleware products, and it also eliminates the technical differences between different applications, allowing different application servers to work together to achieve communication and integration between different services. Functionally, the ESB provides event-driven and document-oriented processing patterns, as well as distributed operational management mechanisms that support content-based routing and filtering, have the ability to transmit complex data, and can provide a range of standard interfaces.
With a distributed Enterprise service bus, organizations can maximize their existing investments in hardware and software by leveraging standards to provide a flexible, real-time, "on-demand" infrastructure.
　　
3 Enterprise Service Bus Construction conception
3.1 Business model of the period hope
The model of the Enterprise Service Bus provides a common channel for the business flow and data flow of the enterprise, through the standard interface, the application system can provide the service interface and the data interactive interface easily through the ESB. (Figure 2)
Figure 2 Application system provides service interface and data interaction interface through ESB
Here are a few key issues:
(1) interface: Each system, especially the old system, the system interface has been released to deploy, not easy to change, enterprise service Bus ESB must be compatible with these interfaces, which necessarily requires a set of adaptation mechanisms to meet different interfaces through the adaptation mechanism to access to the bus;
(2) The data flow in the bus: in order to facilitate the ESB to manipulate data, the flow of data and traffic flowing from each interface into the bus must be formatted into a standard format, circulated in an ESB, and then translated into a format acceptable to the system when transmitted to a particular system;
(3) Node registration: Access to the ESB application services, must register component information and service information on the ESB;
(4) Automatic transmission: The ESB should be able to control some data flows without manual intervention, such as information synchronization, and control the flow of the process.
3.2 Principle of implementation
By defining the node in the way, define the access and interface rules for the application components, implement different interface access systems by developing adapters for different types of data interfaces, translate the ESB internal data format of the node data, and implement the automatic data transfer process by defining the routing and scheduling of data interchange; through queues, threads, Caching and other methods to achieve multitasking and improve the efficiency of business data transfer. (Figure 3)
Figure 3 Principle of ESB service implementation
　　
4 Enterprise Service Bus Implementation
4.1 Adapter-driver for bus standard interface
For access to the Enterprise Service Bus application system and application services, some of the old system, may or CS structure of the system, some are newly built systems, some deployed on the Internet, using WebService mode of external communication, and some deployed in the production environment, the use of sockets in the way of communication.
In order to connect all kinds of business systems into the ESB bus structure, we need a series of interface programs, which can communicate with each kind of interface, and serve as the data format translation between the system and the bus.
We put such software components, called adapters. Just as a different hardware device is connected to a computer board bus that requires a driver to work, the adapter acts as a driver for an access system or component. There are usually two types of adapters, one is a generic adapter for a particular interface, such as SQL adapters, FTP adapters, webservice adapters, socket adapters, and so on. Another is an adapter for a particular system, such as an adapter that uses a particular encryption algorithm.
The infrastructure of the Enterprise service Bus may provide common adapters for general connections, but it will also provide standard interfaces and development specifications that allow special application systems to develop their own dedicated adapters and access to the Enterprise service bus.
4.1.1 FTP Adapter
The purpose of the FTP adapter is to allow the user to define, to adapt to the FTP data to take the process of data, you can configure FTP to take data, configure FTP data transfer.
We can do this through the adapter:
Define FTP Information--lets users define the FTP server, user name, account number, file definition rules, and so on.
Download ftp Files-Download the required files from the FTP server.
Pack FTP File Information return--Pack The FTP file information that you get to return.
Upload FTP Files--Package The input information into a file and put it on the FTP server.
4.1.2 SQL Adapter
The purpose of the SQL adapter is to enable the user to define SQL statements, the process of fetching data from the database, and implementing SQL statements and stored procedures. We can do this through the adapter:
Define SQL statements, stored procedures--lets users define information such as database links, SQL statements, stored procedures, input parameters, and so on.

Pass execution parameters--pass the input parameters to the SQL execution engine.
Returns the results of SQL execution-Package The results of SQL execution back.
4.1.3 Web Service Adapter
The purpose of the Web service adapter is to enable users to define Web service services by implementing the parameters of the packaged Web service, invoking Web service services, implementing the parameters of the Web service, and invoking Web service services.
We can do this through the adapter:
Define Web Service services--let users define the methods, parameters, and so on for the Web service.
Converts the input parameters of a Web service--converts the input parameters of a node into a method parameter of a Web service.
Invoke Web Service services-invoke Web service services and enter the corresponding parameters for the Web service services.
Package The return result of the Web service--Package the results of the Web service running back.
4.1.4 Access Adapter
　　
In general, applications need to use ESB services by directly invoking the common Web service interface provided by the ESB, but in some cases the application needs to invoke services in other ways, such as sockets, Therefore, it is necessary to provide an access adapter to handle the differences of access ESB. The access adapter currently considers the following types of access, which can be increased according to the situation:
An HTTP access adapter that the application uses to directly use the services provided by the ESB by invoking the Web service.
Socket access adapters that use the socket access adapter provided by the ESB to invoke the services provided by the ESB if the connected node can only use socket communication.
Barcode access adapters that use the barcode access adapter provided by the ESB to invoke the services provided by the ESB if the connected node can only communicate using bar codes.
Infrared access adapters that use the infrared access adapter provided by the ESB to invoke the services provided by the ESB if the connected node can only use infrared communication.
Bluetooth access adapters that use the Bluetooth access adapter provided by the ESB to invoke the services provided by the ESB if the connected node can only use Bluetooth communication.
4.2 Nodes-the business applications plugged into the interface
A node is an application system, or an application service that accesses the connection point of an ESB service bus, which typically represents an application service.
For example, there is an operating system that provides a service to send SMS to a mobile phone and a service that publishes an enterprise bulletin, so it should define two nodes on the ESB.
Node One: SMS Send node, the node defines the service interface type, such as the WebService interface, defines the use of the Universal Adapter-webservice adapter, defines the format of data transfer-a section of the XML description that satisfies the system specification, and also defines some key information, such as system identification, and so on.
Node Two: Announce the publication node, define the message with the message send the node.
As mentioned above, nodes can be understood as an access port, an Access service, and a complete business. The definition of a node satisfies a certain format, some fields that must be defined, and a node definition specification is formed here.
Typically, an application system obtains a node that is registered on the ESB and can send requests to that node. As a service consumer, the requester needs to obtain the request format for that node from the ESB, through the common invocation interface of the ESB, the incoming request and destination, the ESB automatically enables the universal adapter, transmits the request to the node, and returns the result.
When the scheduling mechanism is enabled in the ESB, the system can automatically request, sequentially access the nodes defined in the dispatch sequence, send the request or deliver the request. (Figure 4)
Figure 4 ESB Node model
4.3-node Set-an application set that can perform the same operation
Sometimes, a service consumer wants to pass a request to a group of nodes, but does not want to call it multiple times. For example, a message needs to be sent through short messages and corporate announcements, you can send the SMS node and bulletin release node to form a node set, the service user to the node set to send information.
Nodes in a node set are concurrent, and requests are passed to all nodes in the node set at the same time.
To send the request in order, or to request the data returned by the last node as the next node, you need to define the route.
4.4 System-The owner of the node business
To control the use of nodes on an ESB, or to facilitate the maintenance of a node's source, you need to define the application system information to which the node belongs.
4.5 Routing-the path and order of data transfer or business execution
Sometimes we hope our request is not a single step back, instead, it is hoped that it will be passed to a series of nodes, in some places, the output of a node needs to be the input of the next node, and more complex situations include the logical judgment of the result of the return in the transfer process, and the decision to request the next delivery target. Define the process and path of such a message passing, which we call routing. (Figure 5)
Routing management is defined as the order in which the nodes are executed, and you can define the nesting by, that is, after the node is executed, and then the nested routines are executed, with the following scenario: (Figure 6)
Call a Web service method to get the data, then call the SQL statement to insert into the database to fetch data from an FTP site, then call the SQL statement to insert the data from the database in the database, and then put the data into an FTP site to fetch data from a Windows Catalog, Then call a Web service.
4.6 Scheduling-automatic operation of a series of business processes
Sometimes, some data interactions do not require human intervention, it may be at a certain time of day to run automatically, such as 10 o'clock every night, automatically send the latest user information on the human system to all user systems in the enterprise.
We can design a route for data delivery, then specify the request data source and data transfer rules for the route, and finally define the time rule for the route to run, which is called scheduling, which automatically runs the route according to the schedule.
Figure 6 Execution flow of the action
　　
5 concluding remarks
Enterprise Service Bus is a new idea of enterprise solution, it can effectively communicate enterprise decentralized information system resources, provide a low-cost comprehensive solution for enterprises. By using an ESB, you can make an enterprise's existing systems have a completely new service interface and support any standards in a deployment environment with virtually no change in code, in a seamless, non-intrusive manner. This technology can be said to be a breakthrough new technology in modern enterprise information construction.
Reference documents:
[1] Sun Zhengxing, Sanru. Principle and technology of e-government [M]. People's posts and Telecommunications Press, 2003.
[2] Earl, Wang Manhong, Chen Ronghua, translation. SOA concept, technology and design [M]. Machinery industry Press, 2007.
[3] Liang. Proficient in SOA: Struts+ejb+web Service Integration application development based on services bus [M]. Electronic industry publishing house, 2007.
[4] The Senior Technical Training center of Zhongke Wing Lian [S]. Enterprise Service Bus.
[5] Matt Rothera. Enterprise Portal integration and Enterprise Service Bus (ESB) Hub vandervoort[eb/ol].http://dev2dev.bea.com.cn
[6] Zhang June. Enterprise Service Bus Implementation strategy and bus integration. Developerworks China.
Please read the text in PDF format for the diagrams, annotations and formulas involved in this article.
　　
The original article