CN1767530A - adapter - Google Patents

Abstract

This invention relates to an adapter including: a service issuing module analyzing the service description file of XML form generated by a service component of a left system, which describes the service provided by the left system, the related position information to said service and interface parameter, a register module for fetching and analyzing the description file of the adapter and service description file of the left system and registering them to the information bus of a newly developed platform, a message process module processing messages according to the transmission protocol, a service call module used in analyzing and calling SOAP massage block to locate the being called service based on the service call file generated by the service issuing module and feed back the result to the message module in the way of SOAP message block to realize the interaction between the left system and the operation platform.

Description

adapter

technical field

The invention belongs to the category of application middleware platform, and in particular relates to an adapter.

Background technique

The adapter mainly uses middleware technology to add an adapter middle layer between the functional components of the legacy system and the supporting platform, and uniformly describe the data, functions and protocols of the legacy system through the adapter layer, and provide a unified access interface to the management platform. In this way, differences in mutual access between legacy systems are shielded, and the purpose of interoperability between different systems is achieved.

With the vigorous development of telecommunication network and technology, my country's telecommunication industry has gradually shifted from the stage of network construction with high-speed development to the stage of pursuing network quality assurance and good operation management that can provide various services. Telecom operators currently use a variety of telecom operation management application software to provide users with various services. Therefore, it is very necessary to establish a support platform for telecom operation management that can integrate the functions of multiple heterogeneous telecom management software systems.

Contents of the invention

The purpose of the present invention is to solve the heterogeneity problem of mutual access and data sharing of the telecom operation management support platform in the integration of the existing legacy telecom application software system, thereby providing an adapter to integrate and integrate the existing telecom application software system legacy system.

The adapter provided by the technical solution of the present invention is used to realize the interaction between the legacy system and the new development platform, and the adapter includes a service publishing module, a registration module, a message processing module and a service calling module;

The service release module is used to parse the legacy system business components to generate a service description file in the corresponding XML (Extensible Marked Language) format, which describes the service that the legacy system can provide and the service-related location information and interface parameters;

The registration module is used to read and parse the description file of the adapter and the service description file of the legacy system, and register the registration information of the adapter obtained by parsing and the service information of the legacy system on the message bus of the new development platform;

The message processing module is used to process messages according to the transport protocol, parse messages transmitted by the JMS (Java Messaging Service) protocol or the HTTP (HyperText Transfer Protocol) protocol on the message bus to obtain a SOAP (Simple Object Access Protocol) message body, and encapsulate The SOAP message body of the call result returned by the service call module;

The service calling module is used to analyze and call the SOAP message body, locate the service to be called according to the service description file generated by the service publishing module, and return the call result to the message processing module in the form of a SOAP message body.

The service publishing module generates a service description file by analyzing the program code of the business component of the legacy system.

The service description file describes in XML format the name of the service provided by the functional component, the type of service call, the name and relative position of the class corresponding to the service, the type and name of the service input parameter, and the type and name of the return parameter.

The service registration module includes an adapter registration module and a legacy system service registration module.

The registration information of the adapter includes an adapter name (adapterName), an adapter IP address (addr), an adapter type (type), an adapter number (adapterId), and a service configuration file (Server_Config_file).

The service registration information of the legacy system includes the name of the service, the location of the WSDL (Web Service Description Language) file of the service, the additional description of the service, and the name of the adapter to which the service belongs.

The message processing module is used to listen to the message transmitted from the JMS protocol or the HTTP protocol on the bus and return the call result, which includes a message parsing unit and a message encapsulation unit;

The message parsing unit, according to the transmission protocol format of the message bus, selects a corresponding processing method to parse the message to obtain a SOAP message body, and simultaneously records the source of the message;

The message encapsulation unit, according to the transmission protocol format of the message bus, encapsulates the SOAP message body of the call result returned by the service call module to generate a message, and sends the message to the corresponding caller through the message bus according to the above-mentioned recorded message source Corresponding locations of business components or relevant parts of the platform.

The interface parameters include: the class name of the service to be called, the name of the method in the service, and the name and type of the input parameter in the method.

As shown in Figure 1 and Figure 2, legacy systems or newly developed components (collectively referred to as business components here) are connected to the message bus of the platform through adapters, and interact with other functional components of the platform through the message bus. Here, the work of the adapter includes two aspects. On the one hand, the work is to register the functions of each business component to the message bus for other components to query; Return the call result.

Among them, the service release module analyzes the functions of the business components of the legacy system, and generates corresponding service description files in XML format. The registration module reads the adapter configuration file and parses the service description file, registers the adapter information and the service information of the business components connected to it on the message bus, and then waits to receive the calling information from the bus. In this way, other business components on the platform can discover the services provided by the business components connected to the adapter through the registration information. Once the SOAP information on the bus is transmitted to the adapter, the message processing module parses the content of the message, obtains the interface parameters necessary for invoking the service, and transmits the information to the service invoking module. The service invoking module parses the service description file according to the transmitted interface parameters, locates the position of the service in the business component of the legacy system and calls it. Finally, the message processing module packs the result returned by the service calling module into a SOAP message that can be transmitted and recognized by the bus, and returns it to the message bus.

Since the message bus of the platform usually uses multiple transport protocols for message transmission, such as JMS or HTTP, the adapter needs to have the function of self-configuring these transport protocols so that the bus can adapt to the needs of different transport protocols. In addition, since each legacy system may be developed in different languages, in order to shield the heterogeneity of the transmission message format of each legacy system, the messages transmitted on the message bus mostly adopt the SOAP message format. Parsing and other operations, in order to achieve a unified description of the different processing methods and processing protocols for the heterogeneous data of the legacy system, and finally realize the integration of the legacy system.

The advantage of the present invention is that the present invention uses adapter technology to shield the differences in data, methods, and protocols of heterogeneous systems, integrates and integrates legacy systems, and realizes mutual access and collaboration between heterogeneous systems, and heterogeneous information Sharing and support for plug-and-play and dynamic discovery of newly developed business components to achieve intercommunication between legacy systems and operating platforms. The invention can also be applied to other industries that require system integration and mutual access of heterogeneous systems.

Description of drawings

Fig. 1 is the architecture of the present invention applied to the telecom operation management platform

Fig. 2 is the structural representation of adapter of the present invention

Fig. 3 is the workflow diagram of the service publishing module of the adapter of the present invention

Fig. 4 is the workflow diagram of the registration module of the adapter of the present invention

Fig. 5 is the workflow diagram of the message parsing module of the adapter of the present invention

Fig. 6 is the working flowchart of the message forwarding of the adapter of the present invention

Fig. 7 is the working flowchart of calling SOAP message analysis of the adapter of the present invention

Fig. 8 is the working flowchart of the SOAP encapsulation of the return message of the adapter of the present invention

Detailed ways

The adapter of the present invention will be described below by taking the telecom operation management support platform as an example.

The adapter mainly uses middleware technology to add an adapter middle layer between the legacy system or functional components and the support platform, and uniformly describe the data, functions and protocols of the legacy system through the adapter layer, and provide a unified access interface to the management platform , so as to shield the differences in mutual access between legacy systems, and achieve the purpose of interoperability between different systems.

As shown in Figure 2, the adapter is mainly composed of four parts: service publishing module, service calling module, message processing module, and registration module. The functions and working mechanisms of each part can be described as follows:

1. Service publishing module

The service publishing module generates its service configuration file by analyzing the program code of the business component of the legacy system. Service configuration files are described as files in XML format. The file can describe the name of the service provided by the functional component, the type of service call, the name and relative position of the class corresponding to the service, the type and name of the service input parameter, the type and name of the return parameter, etc. A service configuration file description fragment is as follows:

<? xml version="1.0" encoding="UTF-8"? >

<deployment xmlns=http://xml.apache.org/axis/wsdd/

xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">

<servicename="FaultdispatchSessionFacadeTestClient4"

provider="java:RPC">

<parameter name="allowedMethods" value="faultsDispatch"/>

<parameter name="scope" value="Request"/>

<parameter name="className"

value = "pjt_dispatch_fault.FaultdispatchSessionFacadeTestClient4"/

>

<typeMapping

deserializer="org.apache.axis.encoding.ser.BeanDeserializerFactory"

encodingStyle=http://schemas.xmlsoap.org/soap/encoding/

qname="ns1:Status"

serializer="org.apache.axis.encoding.ser.BeanSerializerFactory"

Type = "java:pjt_dispatch_fault.Status"

xmlns:ns1="http://pjt_dispatch_fault"/>

</service>

</deployment>

Among them, servicename indicates the name of the service, allowedMethods indicates the specific method in the service, scope indicates the call type, className indicates the location of the specific program corresponding to the service, and typeMapping indicates the type of the incoming parameter and return value in the service method.

As shown in Figure 3, the adapter first determines the location of the legacy system through the input legacy system location parameter, and then resolves the legacy system at the specified location. During the parsing process, if the parsing is passed, a service description file will be generated according to the parsed content; if the parsing fails due to errors in location information or the legacy system itself, the adapter will report a corresponding error and prompt to re-parse.

2. Registration module

The registration module is mainly used to register the services provided by the adapters and legacy system business components. The registration module registers the adapter information and the service information of the functional components attached to it on the message bus, so that other business components can obtain the location information and interface information of the required services by querying the information on the bus, so as to call related services .

2.1 Adapter registration

The adapter registration module registers the adapter information to the message bus. The registration information mainly includes adapter name (adapterName), adapter IP address (addr), adapter type (type), adapter number (adapterId), and service configuration file (Server_Config_file). The name of the adapter can be freely named according to relevant regulations; the adapter IP address refers to the IP address of the machine on which the adapter runs; the adapter type is used to describe which type of adapter it is, for example, whether it is a CORBA/SOAP adapter or an EJB/SOAP adapter, etc. ;The adapter type mainly depends on the implementation language and implementation method of the legacy system; the adapter number is mainly used to uniquely identify an adapter, so as to be queried by the platform or other functional components; the service configuration file location attribute is used to describe the location of the service configuration file. The above adapter information is read from the adapter configuration file, and the adapter configuration file is as follows:

adapterName=yujiguang

addr=192.168.6.188

type=EJB/soap

adapterId=00001

Server_Config_file=server-config-locate.wsdd

The adapter registration is mainly implemented by calling the registerAdapter method in the registration module. This method includes three parameters, which are respectively the adapter name, the adapter IP address, and the adapter type. These three parameters are all character types. The return value of this method is the adapter information (AdapterInfo) type, which mainly includes the connection factory (connectionFactory), naming and directory service factory (jndiFactory), JMS address (jmsUrl), request queue (requestQueue), The adapter number (adapterId) and the adapter name (adapterName) parameters passed in during registration. By obtaining these parameters, the message bus of the platform can establish a message channel with the adapter, through which specific message content can be transmitted. Successful establishment of the channel indicates that the adapter has been attached to the platform.

2.2 Service registration

The service registration module registers the service information of the legacy system business components connected by the adapter to the message bus, so that the platform or other business components can discover and call these services, and the platform can manage these services uniformly. The service registration information is mainly recorded by parsing the service configuration file of the service. Service configuration files are generated in the service publishing module. The service registration information includes the name of the service, the location of the WSDL (Web Service Description Language) file of the service, the additional description of the service, and the name of the adapter to which the service belongs. The bus manages and controls the services of the adapter access functional components through these information.

The service registration module is realized mainly by calling the service registration (registerService(SvcIf)) method in the registration module. This method passes a service information (ServiceInfo) type parameter to the message bus, and the structure mainly includes the service name (serviceName), comment (comment), wsdl file location (wsdl), and the name of the adapter (adapterName). , where serviceName is the name of the service, comment refers to the description of the service, wsdl refers to the location of the WSDL file of the service, and adapterName refers to the name of the adapter to which the service belongs. The return value of this interface is Boolean to determine whether the service registration is successful.

As shown in Figure 4, first register the adapter, first read the adapter information from the adapter configuration file, then call the adapter registration interface adapter registration (registerAdapter) method, and use the adapter information read from the configuration file as a calling parameter. If the call fails, report the corresponding error and return to the step of reading the configuration file to start again. If the call succeeds, perform service registration. When performing service registration, first read the service description file, read the service description information from it, and then call the service registration interface service registration (registerService(SvcIf)) method, and use the service description information as the call parameter. If the call fails, report a corresponding error and return to the step of reading the service description file to start over. If the call is successful, the service registration process ends. After the above registration process is completed, the adapter starts to listen to the bus all the time, and once a SOAP call message comes, it can call the service.

3. Message processing module

The message processing module of the adapter mainly provides the interface for the interaction between the adapter and the message bus, listens to the messages from the bus at the same time, and returns the calling result. The message processing module mainly has two functions of message parsing and message encapsulation; it can accept and identify messages transmitted by JMS protocol or HTTP protocol on the bus.

3.1 Message Analysis

According to the different transmission protocols of the message, the message parsing module selects the corresponding processing method to parse the message to obtain the SOAP message body, and also records the source of the message so that the call result can be returned to the message source after the call is completed.

As shown in Figure 5, the message processing module first obtains the service call message transmitted by the bus, then analyzes the message, judges the type of the transmission protocol of the message, and records the source of the message at the same time. If the analysis object is a message delivered by the JMS protocol, the JMS message parsing program is invoked to obtain the SOAP message body in the JMS message. If it is a message transmitted by the HTTP protocol, the HTTP parser is invoked to obtain the SOAP message body in the HTTP message. The message processing module transmits the obtained SOAP message body to the service calling module for calling.

3.2 Message Forwarding

When the service call ends, the result returned by the service call module is sent to the message processing module. The message processing module encapsulates the returned result according to the transport protocol format of the bus, and sends the message through the message bus to the corresponding Place. In this way, the originator of the service call can conveniently obtain the returned result.

As shown in Figure 6, the message processing module first obtains the SOAP message with the call result returned by the service call module, reads the previously recorded message source, and then encapsulates the SOAP message with the returned result into the In the corresponding transport protocol, the encapsulated message is finally sent to the message bus. The message bus then sends the returned result to the corresponding business component that initiated the call or related components of the platform according to the source of the message.

4. Service call module

The service call module mainly analyzes the service call SOAP message obtained by the message processing module, and transmits the analysis result to the service call module, and completes the final service call through the service call module; at the same time, after obtaining the returned result, it packs the result value into a SOAP message Return to the message processing module. The service calling module mainly completes two functions: parsing the SOAP message calling the service and encapsulating the returned result in SOAP.

4.1 Calling SOAP message parsing

The service call module parses the service call SOAP message obtained by the message processing module, and obtains the following service call parameters: 1. the class name of the service to be called; 2. the name of the method in the service; 3. the name of the input parameter in the method and type. During the parsing process, if the call parameter is a composite type, the composite type must be deserialized, and if it is a simple type, it can be directly parsed. The module transmits the above information obtained by parsing to the service calling module, and the service calling module can locate the specific method of the service to be called according to the information, and complete the final service calling. An example of invoking a SOAP message is as follows:

<soapenv:Envelope

xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<soapenv:Body>

<ns1:startRequest

soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

xmlns:ns1="DPRequestEJB"/>

</soapenv:Body>

</soapenv:Envelope>

As shown in Figure 7, the service call module first obtains the SOAP call message from the message processing module, and then parses the message to obtain the incoming parameters. If the parameter contains multiple types, it deserializes the composite type and passes it to Call module, if it is a simple type, pass it directly to the call module, call the service through the call module, and return the call result.

4.2 SOAP encapsulation of returned message

When the call ends, the service call module returns the call return result to the message bus in the form of a SOAP message. Therefore, it is necessary to perform SOAP encapsulation on the returned result, and the encapsulation is completed by the service call module.

There may be two situations in the return result. One is that the return result is simple type of data, such as character or integer. At this time, the type of SOAP encapsulation is relatively simple. You only need to specify the return value name and return value type in the SOAP message. and specific values. If the return result is a compound type, such as a structure or an array, in this case, the service call module needs to indicate the name of the structure in the return value, the name, type, and value of each simple type in the structure, and set these types and values to serialize. The specific encoding rules follow the standard SOAP encoding rules. The encoding examples of composite SOAP messages are as follows:

<? xml version="1.0" encoding="UTF-8"? >

<soapenv:Envelopexmlns:soapenv="http://schemas.xmlsoap.org/soap/

envelope/″ xmlns:xsd=″http://www.w3.org/2001/XMLSchema″

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<soapenv:Body>

<ns1:queryFaultsResponsesoapenv:encodingStyle="http://schemas.xm

lsoap.org/soap/encoding/″

xmlns:ns1="FaultquerySessionFacadeTestClient2">

<ns1: queryFaultsReturn href="#id0"/>

</ns1:queryFaultsResponse>

<multiRefid="id0" soapenc:root="0"

soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

xsi:type="ns2:FaultsList" xmlns:soapenc="http://schemas.xmlsoap.org/soap

/encoding/"xmlns:ns2="http://pjt_query_fault">

<DeviceFaultList xsi:type=″xsd:string″>2004-3-27 0:00:00::Dayun

Village::TRH::Universiade Village Base Station Equipment::shenzw::</DeviceFaultList>

<TransportationFaultListxsi:type=″xsd:string″>2004-3-230:0 Universiade

Village::</TransportationFaultList>

</multiRef>

</soapenv:Body>

</soapenv:Envelope>

The service call module sends the encapsulated SOAP message body as a semantic description protocol to the message processing module, and the message processing module encapsulates the SOAP message body according to the established transmission protocol of the bus and then sends it to the bus.

As shown in Figure 8, after the service calling module obtains the returned result, it first judges the type of the returned value. If the result is a composite type, it calls to serialize the composite type. Then, the calling module encapsulates the returned value into a SOAP message body, and finally Pass it to the message processing module for encapsulation of the transport protocol. If the result is a simple type, call the service invocation module to directly parse and encapsulate and generate a SOPA message body, and finally pass it to the message processing module for encapsulation of the transport protocol.

The heterogeneous system integration adapter technology of the present invention is a general adaptation technology, and its implementation and operation are not directly related to specific applications. The above is only an application example in the telecommunications field. It can be used not only in the telecommunications field but also in other industrial applications that require system integration and mutual access of heterogeneous systems.

Claims (8)

1. An adapter, which is used to realize the interaction between the legacy system and the new development platform, is characterized in that the adapter includes a service publishing module, a registration module, a message processing module and a service calling module; The service publishing module is used to parse the legacy system business components to generate a corresponding service description file in XML (Extensible Marked Language) format, which describes the service that the legacy system can provide and the location information and interface parameters related to the service ; The registration module is used to read and parse the description file of the adapter and the service description file of the legacy system, and register the registration information of the adapter obtained by parsing and the service information of the legacy system on the message bus of the new development platform; The message processing module is used to process the message according to the transport protocol, parse the message transmitted on the message bus with the JMS protocol or the HTTP protocol, obtain the call SOAP message body, and encapsulate the SOAP message body of the call result returned by the service call module to generate a message and sent to the message bus; The service calling module is used to analyze and call the SOAP message body, locate the service to be called according to the service description file generated by the service publishing module, and return the call result to the message processing module in the form of a SOAP message body. 2. The adapter according to claim 1, wherein the service publishing module generates the service description file by analyzing the program code of the business component of the legacy system. 3. The adapter according to claim 1, wherein the service description file describes the name of the service provided by the functional component in XML format, the type of service call, the name and relative position of the class corresponding to the service, the service transfer The type and name of the input parameter and the type and name of the return parameter. 4. The adapter according to claim 1, wherein the service registration module includes a registration module of the adapter and a service registration module of the legacy system. 5. The adapter according to claim 1 or 4, wherein the registration information of the adapter includes adapter name (adapterName), adapter IP address (addr), adapter type (type), adapter number (adapterId), service Configuration file (Server_Config_file). 6. The adapter according to claim 1 or 4, wherein the service registration information of the legacy system includes the name of the service, the location of the WSDL (Web Service Description Language) file of the service, the additional description of the service, and the The name of the adapter. 7. The adapter according to claim 1, wherein the message processing module is used to listen to messages transmitted by JMS protocol or HTTP protocol on the bus and return the call result, which includes a message parsing unit and a message encapsulation unit; The message parsing unit, according to the transmission protocol format of the message bus, selects a corresponding processing method to parse the message to obtain a SOAP message body, and simultaneously records the source of the message; The message encapsulation unit, according to the transmission protocol format of the message bus, encapsulates the SOAP message body of the call result returned by the service call module to generate a message, and according to the above-mentioned recorded message source, the message is sent to the corresponding caller through the message bus Corresponding locations of business components or related parts of the platform. 8. The adapter according to claim 1, wherein the interface parameters include: the class name of the service to be called, the name of the method in the service, and the name and type of the input parameter in the method.

Images