Design of ESB for modern airport informatization construction

1. OverviewThere are more than dozens of different business systems in the construction of modern airport informationization, different business systems are often developed by different companies adopting different standards and different interfaces, there is a large amount of data exchange between these business systems, and it is necessary to use EAI technology to deal with the data exchange between different business systems.     Under the current SOA architecture, EAI is different from the traditional EAI, the EAI technology under SOA is the way of adopting the Enterprise Service bus ESB, and the unified standard interface is used to connect different business systems. There are two main business models in the construction of airport informatization, one is publish/subscribe  wo fast Sulphon Chowa creating nano Chu  file Kenya obi SCR drop patchwork P stop  eggplant 肐 BM ESB Product WebSphere Message broker and WebSphere MQ to build an enterprise service Bus (ESB) platform for the construction of the airport informatization, and introduce the design process. 2. Evolution of the Enterprise service bus ESBThe Enterprise service Bus ESB originates from EAI technology, and the development of EAI to an ESB has undergone three phases: 2.1 Custom connection, 22 interconnectThe earliest EAI solution was to bridge the 22 of systems in the enterprise that needed to exchange information and share data. Bridging technology is also a special custom communication link for two specific systems to transform the interface of these two systems, protocols and data formats and other differences. Figure 1 Traditional point-to-point mode disadvantage: all use of the connection specifically for two specific systems, in the case of enterprise systems in a large number of cases connected sharply increased, difficult to develop, later maintenance more difficult. The results of a survey released by Gartner Group in April 2003 show that about 35% of the enterprise software budget is used to maintain a large number of existing point-to-point application connections. CIO Insight also made a similar point in February 2003, where they found that maintaining and managing these point-to-point connections averaged 29% of the corporate IT budget. Because these private connections are completely independent, they can only meet the requirements of system 22 interconnection communication, and cannot implement complex business processes involving multiple application systems. 2.2-Star (Hub/spoke) architectureFigure 2 As a result of the 22 interconnection mode with the above obvious flaws, the solution of star-based architecture emerged. This approach provides an application integration Center (hub), which has its own connection protocol, and all systems that need to be integrated (spoke) are connected to the hub, and the integration center often acts as a core business system. The original user every integration of a system, the system and all other systems to consider the point-to-point connection of the protocol data structure conversion, and in the star schema, the user only need to consider the system and Integration center point-to-point connection on the conversion. Thus, n * (n-1)/2 point-to-point connections between n systems are reduced to n connections. Disadvantage: The centralized structure is prone to the bottleneck of efficiency, and the problem of single-point failure exists at the same time. Once the server crashes, the entire system cannot be run. In this mode, to achieve the scalability of the system only by joining the multi-integrated server, which creates additional structure and management complexity. At the same time, the hub, adapter, workflow programming and management is more expensive, and less reusability. 2.3 Total Linetype Architecture With the development of it technology, the demand for enterprise application integration has increased sharply, the simple star structure can not meet these requirements, bus-based enterprise service bus system structure gradually surfaced. This architecture inherits the idea that the Star (Hub-spoke) architecture transforms each system point-to-point connection into a central connection for multiple systems. However, in this architecture, the integration Center is extended into a bus that can be distributed over multiple physical nodes, which effectively solves the problem of single point failure and efficiency of center-spoke mode. Figure 3 Total Linetype architecture [ESB/EAI Solution]   ESB technology is not simply a simple extension of the integration center into a bus. The Enterprise service bus itself provides support for various EAI modes such as message routing, data conversion, and so on. This kind of bus generally uses the mature application integration middleware as its physical messaging backplane to ensure the reliable and efficient transmission of messages in distributed environment. At the same time, Enterprise service Bus is the basic framework of application integration System, most of which adopt component-oriented technology, which is actually the embryonic form of SOA. The bus structure is more scalable and provides better performance than the Hub-and-spoke structure. As a bus-shaped structure, when to integrate into a new application, just add a adapte plug into the bus, you can do a plug-and-play function. For message delivery, the integration server is just a control, the real transmission is on the information bus, so that the load of integrated server is much lighter. In addition, ESB architecture often includes implementations of business process management (BPM) and Business Activity Monitoring (BAM) modules. BPM, as the consumer of an ESB, can assemble the various services (or components, adapters, etc.) on the bus in accordance with the business logic required by the user, so that these services are executed in the order of business logic, thus enabling the complete business function of the user. BAM provides monitoring and management of the operational status of services and BPM across the ESB,ESB. SOA (service-oriented architecture) Figure 4 Service-oriented architecture service oriented Architecture is currently the most advanced architecture in the field of EAI. In fact, the proposed SOA is to a large extent to better meet the needs of enterprise application integration. SOA emphasizes multiplexing pine coupling, focusing on interfaces and their standardized descriptions, all of which provide a very good framework architecture for enterprise application integration planning. In addition to having the advantages of the previous ESB structure, SOA-based application integration systems are more scalable and flexible, allowing users to develop new business modules (services) or modify existing modules with minimal impact on existing systems to quickly meet changes in business requirements. Essentially, the SOA architecture applies to the application set.The basic requirements are as follows: SOA encapsulates and reuses application services or business modules on a relatively coarse granularity. This is a requirement for the service provider itself. The service is loosely coupled, based on open standards, and the interface description of the service is independent of the implementation. This is what the service provider should look like from the perspective of the service consumer. Flexible architecture-the implementation details of the service, the location of the service, and the underlying protocol of the service request should be transparent. This is a requirement for the way services are provided by consumer consumer service providers. EAI products based on SOA architectures typically use an enterprise service bus (ESB) to meet this requirement. As you can see, the architecture of SOA generally also requires the support of the Enterprise service bus, but it has more explicit requirements on the function and location of the service on the bus and the bus itself. A good SOA-compliant EAI system also integrates support for BPM and BAM. In particular, there are more advantages to BPM support in SOA-compliant EAI systems. In traditional ESB systems, BPM is often a vendor-specific module that exists on the ESB and is not replaceable. In an SOA-compliant EAI system, the BPM module also acts as a service (orchestration Service) with no difference in nature from other services, which makes it possible for users to choose multiple service orchestration methods (i.e. different BPM implementations). 3. Modern airport information construction needsModern civil aviation airport information construction needs more and more urgent, throughout the domestic civil aviation industry of all major links, the airport information level is relatively poor. Since 2006, the airport for the level of information technology to pay more attention to the importance of marketing, through the integration of e-commerce, departures, passenger, meteorological and other systems to improve the level of resources and management. The trend of 2006 shows that the construction of airport informatization is developing from Operation Informationization to management informationization, one sign is that the data integration of the airport is being gradually launched, that is, through the Enterprise service bus, the dispersed data in the airport system is integrated, thus laying the foundation for improving the level of management informatization. The airport ESB information construction needs to integrate the system has the production system, the navigation display system, the departure system, the security inspection system, the broadcast system, the CCTV system, the internal communication system, the building control system, the parking system, the Internet system, the clock system, the baggage system, the airport GIS system, the meteorological system, the electronic commerce system. The construction of these systems, the technical standards used, application interfaces and data formats are not uniform problems, the information systems become a single island, in order to improve the efficiency of airport operations, these IT systems need information integration, the use of IBM WebSphere message Broker V6.x can meet this requirement well and realize the following functions: Protocol conversion data format conversion data routing event and transaction support 4. Design of airport information ESB 4.1 OverviewAccording to the specific requirements of the application of airport informatization, we designed two kinds of ESB function applications, namely pub/sub and request/reply, according to this application, the ESB architecture design as shown in Figure 5 Figure 5 The ESB platform overall architecture is logically divided into two layers: the information interaction layer and the application integration layer. which Information Interaction layer:The ESB adapter provides access to a large number of existing applications and data in the enterprise, simply providing an interface to the ESB for applications, weak electronic systems, and external systems. The implementation of WebSphere MQ 6.0 for the message middleware is the base platform for the ESB platform. Application integration layer:The information interaction layer can meet the various types of interaction in the airport, and further integrate the application system, weak electronic system and external system in the information and application, complete various kinds of information in the interactive process involved in the format conversion, content routing and other issues, in improving the performance of the information interaction layer, Based on the concept of service-oriented construction of information flow, for the airport implementation of business process integration and Portal Integration reservation interface. Its implementation mainly through IBM middleware IBM WebSphere Message Broker, its application mode mainly in the Publish/subscribe (PUB/SUB) mode, request/Response mode (REQ/RESP) and customizable service Unit mode. 4.2 Implementation Mode Publish/Subscribe modeThe Publish/subscribe pattern is one of the messaging applications in which the relationship between the publisher of the message and the Subscriber to the message is loosely coupled. In a publish/subscribe system, the Publisher does not need to know who will use the information it provides, and the Subscriber does not need to know who is providing the source of information it needs. In contrast to other application patterns, the application that sends the message needs to know where the message is destined. So, in the Publish/Subscribe mode, the system can grow or shrink dynamically. The implementation of Pub/sub through Webspher MESSAGE broker mainly involves several concepts: Publisher (publisher ):The provider of information is called a publisher. The publisher assigns a topic to each message, but he does not know the purpose of applying the message to which topic is interested. Subscribers (subscriber ):The subscriber decides which topic information it is interested in, and then receives the message for that topic. Each Subscriber can receive messages from multiple message publishers, and they receive messages that can also be published to other subscribers. Theme (Topic ):Create a connection between the Publisher and the Subscriber through the topic. Messages that are used for pub/sub purposes require a topic. Agent (Broker ):The agent is responsible for the interaction between the Publisher and the Subscriber. It receives the message from the publisher, gets a request to subscribe to the message from the Subscriber, and then takes care of routing the message from the former to the latter. In a large system in some subsystems, when not sure from where to receive messages or send messages, in a complex application, the communication program is not only a one-off relationship, but also can be a pair of many or many pairs, or even many-to-many relationships, in such a complex situation, the connection of communication increases the complexity of the program, So you can use the Publish/Subscribe mode in the system to shield the user from the changeable connection, make the application more simple, block out the changes of the network, and provide greater network independence. And because of the reduced communication connection, it makes the system easier to manage. The principle of pub/sub is that a conference is sent by the publisher to the agent, a subscription is sent from the subscriber to the agent, and the publication is sent from the agent to the Subscriber. And in a typical publish/subscribe system that contains multiple publishers and multiple subscribers, or even multiple agents (which is required for connection performance), and possibly an application that is both a publisher and a subscriber, in this case the Publish/subscribe system architecture is typically shown in the following figure: Figure 6 Release/ Subscription mode The application mode is the main application mode of information interaction of various kinds of application system in the airport, taking the flight dynamic release as an example: the production system application sends the flight news message to the information interaction layer through the adapter, without specifying the user of the message; Flight display, Other applications, such as luggage, can subscribe to the flight plan through the information interaction layer to the application integration layer, and once the subscription is successful, the system will automatically receive a copy of the flight's dynamic information whenever the production system releases the flight, and the system does not need to know the source of the message. Request/Reply modeThe request/reply pattern consists of two procedures: one is to send a message and expect a reply (in other words, to send a request message or to send a request through the publishing process), and the other is to send a reply message after the request message is received. The system or application issues a request message and waits for a reply message. The responder uses the request message, generates a reply message, and then sends it back to the initiator. When the initiator receives a reply message, it marks the completion of the message flow. Request/reply mode in the application of this architecture, MQSeries provides the convenience of identifying the request message and its reply message using the correlation ID. The affinity ID is set by the application that issued the request message. The application that generates the reply message copies the affinity ID from the request message to the reply message and sends it back to the application that originally made the request message. The application that sends the request message can use the affinity ID to map the reply message to the message that the request was sent earlier. In this mode, the request and response are two messages defined within a single request/reply operation and sent as two independently independent transport layers. Figure 7 Request/Reply mode This application pattern complements the Publish/subscribe model, which effectively solves the impact of message loss or information synchronization in specific situations that may result in an application system. Take flight status as an example, the production system for the day of a flight will be based on the status of the flight issued a number of status information, at this time, for the current application system (such as navigation) can receive the flight status information, can also be requested by the way to the information interaction layer sent request information, the production system received the request information, The latest flight of the flight will be sent to the application dynamically. This model can effectively solve the problems of different application system data in the airport. 4.3 Customizable service Unit modeIn order for the airport business environment to have a flexible infrastructure and processing environment, the EAI platform also needs to support the SOA expansion capabilities, so that the self-demand analysis, the design of the information interaction platform, the definition of message format must take into account the future expansion, to achieve the maximum degree of loose coupling between the airport application systems, We can use WebSphere MB efficient message format conversion, message routing and other functions, the use of service-oriented design concept, the existing business defined as a separate "Atomic service" (minimum feature set), by the "Atomic Service" to construct "composite services" through the "Service dictionary" Query the definition of related services, as business changes or customer demand for services change, the original defined atomic services do not need to change, simply to re-assemble the changed services, or on the basis of existing composite services to be modified into a new "composite services" can be. For example, the dynamic release of inbound and outbound flights of production systems is defined as a separate atomic service, and flight dynamics is defined as a combination of inbound and outbound flights. For applications that only care about outbound flights (such as the baggage system), only one atomic service is requested, that is, the outbound flight is dynamically released, and the application system (such as the flight display system) that cares about the port of departure and cares about inbound flights, upon request, specifies that the request is "dynamic" and, after the request is sent, The EAI application integration platform obtains the definition of this composite service through a query service dictionary, and then passes through two data flow messages in parallel to obtain and transmit the dynamic information of the inbound and outbound flight to the navigation system. Figure 8 Customizable Service Unit application architecture 4.4 Functional Components Information Interaction LayerThe information interaction layer, developed by IBM Websphere MQ, is IBM's powerful messaging middleware offering, with its proven technology and world-leading products, providing us with an economical, reliable, and easy-to-use solution for messaging in today's heterogeneous network environment. It is the only product that can ensure your data is stable and reliable without losing or re-sending it, and has been hailed by PC Magazine as: MQ is one of the most successful software in the world. The current market share of the message class middleware 87%, has become the de facto industry standard. In the enterprise's various applications have assumed the reliable information data Transmission Foundation support. MQ is basically comprised of an information transfer system and an application interface whose resources are information and queues (Messaging and Queuing). Information:A message consists of two factors: a description of the information (used to define information such as the destination of the message) and data information (such as application data or database queries). Communication between programs is done by passing information rather than invoking the program directly. Queue:A secure information store. Because information is stored in the queue, applications can run independently of each other at different speeds, at different times, at different locations. Information Transmission system:Used to ensure that information is provided between queues, including information provided between remote queues on different systems in the network. and ensure a network failure or recovery after shutdown. Application Interface:The interface Mqseriesapi implemented between applications and information systems through MQSERIESAPI is consistent across all MQSeries platforms. The API has only 11 calls, 2 key verbs: Send (PUT) and receive (GET). In the information interaction layer each application system uses the client/server mode to connect with the WebSphere MQ server, the client uses the MQ dynamic link library to develop or adopt the appropriate adapter, through the MQI, or the JMS interface accesses the message queue on the WebSphere MQ server. As shown in the following figure. Figure 9 MQ client/server application Application Integration LayerThe application integration layer is implemented primarily through the IBM WebSphere message broker, which uses the reliable messaging service provided by WebSphere MQ (not lost, no longer transmitted) to integrate application systems through message-based asynchronous methods across applications. The message BROKER provides a specialized format code converter (Formatter) for automatic format conversions between different message formats, in accordance with predefined conversion rules, and then automatically routes the results to the target application system, depending on the characteristics of the different messages processed by the system. In the process of message conversion, the message broker can recognize XML,C structure, jms,soap and other kinds of messages, and various operations on the message include the source of the message, the target application of the message, the desired message format, etc. by defining various operation rules (rules). Its functional components are shown in the following figure: Figure 10 Application integration layer Functional components MESSAGE BROKER toolkit[ Tool Set] :Message BROKER Toolkit is a toolset for developing and deploying message flow, message set applications that communicate with Configuration Manager to deploy message flows and message sets to one or more brokers. BROKER domain[ Proxy domain] :You can group agents into proxy domains, and each agent domain is coordinated by a Configuration manager. BROKER [ Agent] :As the core component of the application integration layer, it is also the core component of WebSphere MB, primarily based on message flow and message set processing messages, which describe the operations to be performed on the incoming messages to the final destination and the order in which they are executed, and the message flow runs on the execution group. The agent can exist more than one. USER NAME server[ user Name server] :is an optional component, mainly used in pub/sub mode, through which you can set whether an application has permission to publish or subscribe to a topic, primarily to provide permission control at the topic level. CONFIG manager[ Configuration Manager] :Created by the system administrator on the server, primarily to coordinate the communication between Message Broker Toolkit and the agents in its domain, and to monitor the state of the message flows deployed on the broker. Each configuration Manager has a corresponding storage unit to store the relevant configuration management information for broker domain. EXECUTE group[ Execution Group] :Multiple message flows on a broker can be organized by an execution group, an execution group acting as a process on the broker, and multiple message flows can be deployed on the same execution group for increased efficiency. Odbc[odbc Connector] :As a connector between the application integration layer and the database, you can interact with the database through ESQL or the Java programming interface. The above types of components are connected and communicated through MQ, and the communication between MB and the application system can also be connected via MQ. 5. SummaryUsing the IBM WebSphere message Broker v6.x and WebSphere MQ 6.x can be a good way to achieve the modern civil airport informatization Enterprise Service Bus construction needs, WebSphere Message In addition to the application of the mentioned basic ESB functions such as pub/sub, request/Reply data routing in this article, broker also has powerful conversion capability of data format, such as the conversion of different messages between the airport and customs and other units. 1