CN103944902B - Realize the method, apparatus and equipment of business polymerization Mashup business - Google Patents

Abstract

Embodiments of the present invention provide a method, device and equipment for realizing a Mashup service, relate to the field of communication technology, and are used to support Mashup services of various types of data sources. The method for realizing the service aggregation Mashup service provided by the embodiment of the present invention includes: registering the components of the data source and generating a service providing interface for the component according to a unified first format; according to the service request message of the service requester, in the registered Query the required components in the components, and generate a service request interface for the required components according to the unified second format, and match the service provision interface with the service request interface; use the service request The interface receives the service request message, uses the service providing interface to invoke services to the required components, and uses the service request interface to send the generated Mashup service response message to the service requester.

Description

Method, device and equipment for realizing service aggregation mashup service

technical field

The present invention relates to the technical field of communication, in particular to a method, device and equipment for realizing Mashup service.

Background technique

Business aggregation (Mashup) is a new type of Web application formed by stacking and aggregating multiple different applications that support Web Application Interface (API). Mashup server is a web integration platform that allows users to easily integrate data and resources from any application with Web API. Its main functions include providing aggregated application logic orchestration function, aggregated application execution environment, and external data sources and sub-services To communicate, etc.

Mashup originated from the Internet and is a new application of WEB2.0. At present, the solutions of many manufacturers in the industry focus on web applications and the integration and fusion of Internet data sources, such as web service (webservice) data sources, aggregation business (Really Simple Syndication, RSS) data sources, subscription blog (ATOM) data source etc.

In the process of realizing the present invention, the inventor finds that there are at least the following problems in the prior art:

As telecom operators open up their business capabilities, service creators, such as third-party developers, users, operators, etc., have been able to integrate stable, reliable and high-quality telecom service data sources into Mashup business. However, the mashup server in the existing solution does not support the mashup service of the telecommunication service data source, which cannot meet the needs of users.

Contents of the invention

In order to solve the problems existing in the prior art, the embodiments of the present invention provide a method, device and equipment for realizing the Mashup service.

In order to achieve the above object, embodiments of the present invention adopt the following technical solutions:

A method for realizing business aggregation Mashup business, said method comprising:

Register the components of the data source and provide an interface for the components to generate services according to a unified first format;

According to the service request message of the service requester, query the required components in the registered components, and generate a service request interface for the required components according to the unified second format, and provide the service interface and the required components Match the above service request interface;

Using the service request interface to receive the service request message, using the service providing interface to call services to the required components, and using the service request interface to send the generated Mashup service response message to the service requester.

A device for realizing business aggregation Mashup service, said device comprising:

A service providing interface generating unit, configured to register the components of the data source and generate a service providing interface for the components according to a unified first format;

A service request interface generation unit, configured to query the required components among the registered components according to the service request message of the service requester, and generate a service request interface for the required components according to a unified second format, matching the service providing interface with the service request interface;

The service implementation unit is configured to use the service request interface to receive the service request message, use the service provision interface to call services to the required components, and use the service request interface to send the generated Mashup service response message to business requester.

A network device comprising:

The request message analysis unit is configured to analyze the received component registration request message, send the component registration request message to the component registration unit, the component registration request message carries the component identification ID, and the received service request The message is analyzed, and the service request message is sent to the component request processing unit,

The component registration unit is configured to send a component query request to the component storage unit according to the component ID carried in the component registration request message, and query whether all registered components in the component storage unit have a component with the same ID registered, If there is no component registration with the same ID, call the Mashable API creation unit, so that the Mashable API creation unit provides an interface for component generation services in a unified first format; the component storage unit is used to store components and component descriptions Information, the description information includes the component ID;

The component request processing unit is configured to generate a service request interface for the component according to a unified second format according to the service request message, or call the Mashable API creation unit to make the Mashable API creation unit follow the unified second format Generate a service request interface for the component, and use the service request interface to receive the service request message, use the service providing interface to request service from the corresponding component, and use the service request interface to send the generated Mashup service response message to the service requester.

The technical solution provided by the embodiment of the present invention implements a unified encapsulation mechanism for various data sources by adopting a unified format to generate service providing interfaces or service request interfaces for components of each data source, thereby being able to support data sources including telecommunication services in Various types of data sources in the system create and request Mashup services through this interactive interface, which enhances the scalability of Mashup services and meets the needs of users.

Description of drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings that need to be used in the description of the embodiments or the prior art. Obviously, the accompanying drawings in the following description are only These are some embodiments of the present invention. Those skilled in the art can also obtain other drawings based on these drawings without creative work.

Fig. 1 is the flow chart of the method for realizing the Mashup service provided by one embodiment of the present invention;

Fig. 2 is the Mashup system structural representation that an embodiment of the present invention provides;

Fig. 3 is a schematic diagram of the registration process of the non-Mashup Service data source component provided by another embodiment of the present invention;

Figure 4(a) is a schematic diagram of the deployment process of the Mashup Service data source provided by another embodiment of the present invention;

Figure 4(b) is a schematic diagram of the registration process of the Mashup Service data source component provided by another embodiment of the present invention;

Fig. 5 is a schematic diagram of a predetermined structure provided by another embodiment of the present invention;

FIG. 6 is an example of a predetermined structure provided by another embodiment of the present invention;

FIG. 7 is a schematic diagram of a scenario of dynamically generating a service request interface provided by another embodiment of the present invention;

FIG. 8 is a schematic flowchart of the interaction between the Mashup system, the AAA system and the billing system provided by another embodiment of the present invention;

FIG. 9 is a schematic structural diagram of an apparatus for implementing a service aggregation Mashup service according to another embodiment of the present invention.

detailed description

The following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only some, not all, embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by persons of ordinary skill in the art without creative efforts fall within the protection scope of the present invention.

The technical idea of the embodiment of the present invention is to provide an innovative scheme for dynamically creating a Mashup service. The scheme uses a unified application interface (Application Interface) for components of various data sources including Internet data sources and telecommunication service data sources. , API) format for encapsulation and registration, so that the Mashup server supports the Mashup business of various data sources.

The method for realizing the Mashup service provided by one embodiment of the present invention, referring to Fig. 1, includes:

11: Register the components of the data source and provide an interface for the components to generate services according to the unified first format;

12: According to the service request message of the service requester, obtain the required components from the registered components, and generate a service request interface for the required components according to the unified second format;

13: Utilize the service request interface to receive the service request message, utilize the service provision interface to request services from the required components, and utilize the service request interface to send the generated Mashup service response message to the service requester.

The aforementioned data sources include various data sources including telecommunication service data sources. Mashup business can be used as a source of Mashup data to provide secondary development or reuse

In order to clearly describe the technical solutions of the embodiments of the present invention, in the embodiments of the present invention, words such as "first" and "second" are used to distinguish the same or similar items with basically the same functions and functions. Those skilled in the art can understand that words such as "first" and "second" do not limit the quantity and execution order.

Wherein, the first format and the second format are the same format, or the first format and the second format are different formats. That is, all service request interfaces have the same format, and all service providing interfaces have the same format, and the formats of the service request interface and the service providing interface may be the same or different.

Wherein, the above-mentioned format can be understood as a specific message composition when requesting or invoking a service, for example, the message can be composed of functions and parameters or the message can be composed of protocol calls.

Exemplarily, a format that can be adopted is as follows:

function(parameter); such as Weather(city)

Another possible format is represented as follows:

protocol: parameters; such as Http: /GET/POST…

Further, before step 11, it may also include creating a Mashup business according to a predetermined structure, for example, business developers follow the component imports (Component imports), namespace definition (Mashup namespace definition), syntax definition (Schema definition), operation (Operation) Part of the four-layer structure uses a dynamic scripting language (such as JavaScript) to create a Mashup business. In the traditional Mashup business development method, because the format of the Mashup data source is not uniform, business developers need to master specific programming technologies such as Web Service, Rest, C++, and Java at the same time, which makes development difficult and requires high requirements for business developers. With this method of the present invention, business developers do not need to learn additional development languages (including Mashup Server label language and web page language), and can create Mashup services only by using the extended dynamic scripting language, which reduces the difficulty of business development and requirements for business developers.

The service requester obtains the corresponding Mashup service through the request information and the response information, and enjoys the corresponding service.

Exemplarily, a request information may be: HTTP://www.sina.com.cn/user=123&password=123 and the corresponding response information is the content of the webpage requested by the user, for example, the webpage that has passed the verification. The request information is carried in the above service request message, and the response information is carried in the Mashup service response message.

The components in the embodiment of the present invention are agents between the service requester and the actual service (such as data source). The component uses the service provider interface to call the corresponding service from the data source, uses the service request interface to receive the service request message sent by the service requester, and requests the actual service provided operation (Operation) according to the service request message.

The Mashable API is composed of the service providing interface, service request interface and related parameters. Utilize MashableAPI to manage the components in a unified way, and the components open the Mashable API with a unified format to the outside for the creation and request of Mashup services.

The service provider interface is automatically generated when the component is registered and stored with the component, while the service request interface is dynamically generated when the service request is initiated or the component is called. The service request interface is determined according to the actual situation of the service requester and the service provider. There is no need to store service request interfaces in advance. This approach meets the dynamic characteristics of component registration and the need to save memory.

The technical solution provided by the embodiment of the present invention implements a unified encapsulation mechanism for various data sources by adopting a unified format to generate service providing interfaces or service request interfaces for components of each data source, thereby being able to support data sources including telecommunication services in Various types of data sources in the system create and request Mashup services through this interactive interface, which enhances the scalability of Mashup services and meets the needs of users.

In order to clearly describe the technical solution of the embodiment of the present invention, first, referring to FIG. 2 , the structure of the Mashup system provided by the embodiment of the present invention is introduced. The system mainly includes the following units:

Request Analysis Unit (Request Analysis Unit) 201: This unit is used to receive various request messages from the client, that is, the client used by the service requester 200 in Figure 2, including mashup deployment request messages, component registration request messages, business Request message, and analyze the received request message and forward it to the corresponding unit in the system for processing.

Mashup deployment unit (Mashup Deployer Unit) 202: this unit is used to process the mashup deployment request message, and deploy the Mashup service data source to the Mashup server. And call the corresponding unit to provide an interface for the components of the Mashupservice data source to generate services.

Component Generator Unit (Component Generator Unit) 203: this unit is used to generate components corresponding to the Mashup data source.

Script parsing unit (Script Parser Unit) 204: This unit is used to parse the mashup business described in a dynamic language (such as Java Script), and assist the component generation unit 203 to generate components for the mashup business.

Component Registration Unit (Component Registration Unit) 205: This unit is used to process component registration request messages, generate interaction codes for interaction with service requesters (the interaction codes are based on scripting language), and provide corresponding codes for requesting components. After the registration process is completed, the unit can also call the components and component detailed descriptions stored in the component storage unit 207 .

Mashable API creation unit 206: create a Mashable API for the component, and the Mashable API includes a service providing interface and a service request interface.

Components Repository Unit (Components Repository Unit) 207: This unit is equivalent to a storage pool (Pool), and is used to store registered components and component detailed descriptions.

Component Request Unit (Component Request Unit) 208: This unit is used to process the component request process.

Component Management Unit (Component Management Unit) 209: This unit is used to manage some operations related to the use of components, such as verification, authentication and billing. The Mashup system shown in Figure 2 can receive a request from a business requester (Requestor) 200, perform processes such as deployment (Deploy) or component registration, or interact with an external service (ExternalService) function 210, or interact with other systems such as The billing (Billing) system 211 and the authentication authentication system (such as AAA) 212 interact.

The above is only an exemplary description of the main functional units. For example, the component request processing unit 208 in the system may also include a script execution engine (Script) 2081 for testing and executing the script description of the Mashup.

The method for implementing the Mashup service provided by another embodiment of the present invention will be described in detail below with reference to FIG. 2 . Specifically include the following processing:

11: Register the components of the data source and provide an interface for the components to generate services according to a unified first format.

In the embodiment of the present invention, data sources are divided into business aggregation service (Mashup Service) data sources and non-Mashup Service data sources, and the two types of data sources are registered in different ways. Among them, the telecom service data source is a non-Mashup Service data source.

This method is adopted because non-Mashup Service data source components, such as Java components, C++ components, Representational State Transfer (REST) components or Web Services Description Language (WebServices Description Language, WSDL) Web components, These components are usually released or used and deployed before implementing the Mashup service, and the component registration process can be directly performed. As for the MashupService data source, corresponding components need to be generated during the process of deploying the Mashup Service data source on the Mashup server. These two situations are introduced respectively below.

In the first case, registration of non-Mashup Service data source components

Referring to Figure 3, the registration process of non-Mashup Service data source components includes the following steps:

1: The registration requester sends a registration component request message to the request message analysis unit, and the registration component request message carries component information, such as component data and component identification (ID). The component ID can be a string that uniquely identifies the component, such as "SMS", "MMS", and "WeatherInfo". The component ID is provided by the component provider or component generator. But not limited thereto, component information can also include component keywords, which can indicate the type of service supported by the component, and different components can have the same component keyword, for example, the component IDs are SMS1 and SMS2 respectively and SMS3 components, the component keyword can be SMS.

The component information carried in the registration component request message of different components is also different.

For example, when the component is a C++ component, the above-mentioned registration component request message carries C++ dynamic link library file (.dll file) data and component ID; when the component is a Java component, the above-mentioned registration component request message carries java data Package, component ID and data type description, a data type provided by the embodiment of the present invention is described as an object name (attribute value 1, attribute value 2, ...); when the component is a REST component, the above registration component request message Carry a REST uniform resource locator (Universal Resource Locator, URL) and a component ID; when the component is a WSDL Web component, the above registration component request message carries an HTTP URL and a component ID.

2: The request message analysis unit forwards the registration request message to the component registration unit after analyzing the received component registration request message.

3: The component registration unit sends a component query (Query Component) request to the component storage unit, queries all registered components in the component storage unit, and determines whether the same component has been registered. Here, the same component mainly refers to components with the same component ID.

4: After the component storage unit receives the component query request, it searches the stored component IDs of the registered components to see if there is a component ID that is the same as the component ID (such as SMS) carried in the above-mentioned registered component request message, and if it exists, then It means that the component whose component ID is SMS has been registered. If it does not exist, it means that the component whose component ID is SMS has not been registered yet. The component storage unit feeds back the query result to the component registration unit.

5a: If there is a component registration with the same ID, the component registration unit will feedback and send registration failure information to the registration requester, so that the registration requester can know the registration failure in time for subsequent processing. For example, the registration requester can update the component ID, for example, set Change the string SMS of the component ID to SMS1, SMS2 or SMS3, and restart the registration process.

5b: If there is no component registration with the same ID, the component registration unit sends an interactive interface generation request (Generate Script Adaptor) to the Mashable API creation unit. The Mashable API creation unit provides interfaces for corresponding component generation services, and the methods and codes used to provide interfaces for component generation services of different data sources are also different.

For example, the Mashable API creation unit uses Java Native Interface (JNI) to provide an interface for C++ component generation services based on the dynamic link library file (.dll file) data and component ID;

According to the java data package and component ID, generate a service provider interface for the Java component with the Java class and component ID, and the service provider interface calls the actual service through the classes and functions provided by Java;

According to the REST URL [HTTP URL] and component ID, it provides an interface for the REST component to generate services.

When the component is a Web component of the Web service description language WSDL, a service providing interface is generated according to the HTTP URL of the Web component and the component ID.

The service providing interface generated above has a unified format, such as the first format.

6b: The Mashable API creation unit returns the creation success information to the component registration unit, and provides interface parameters for component generation services. If the creation fails, the Mashable API creation unit sends a creation failure message to the component registration unit, and only the scene of successful creation is shown in the figure.

7b: The component registration unit sends a store message (Store Component) to the component storage unit, and the component storage unit stores the above-mentioned successfully registered components and related information, such as the service provider interface of the component, component data and component ID, etc.

8b: After the component storage is successful, the component storage unit returns the storage success information of the component registration unit.

9b. The component registration unit returns a component registration success message to the request message analysis unit.

10b. The request message analysis unit feeds back a successful registration component message to the registration requester.

In addition: if the component storage in 8b is unsuccessful, the subsequent steps feed back information about component registration failure to the registration requester.

In the second case, registration of Mashup Service data source components

First, generate components through the process of deploying the Mashup Service data source on the Mashup server, see Figure 4(a), including the following steps:

401: The service deployer sends a Mashup deployment request message to the request message analysis unit, and the message includes the Mashup service and parameters. Mashup services are mainly composed of Mashup script descriptions, and parameters mainly include component IDs, service descriptions, and access policies.

It should be noted that before component registration, the embodiment of the present invention also includes creating a mashup service according to a predetermined structure, for example, a service developer uses a dynamic script according to the four-layer structure of component import part, namespace definition part, syntax definition part and operation part Languages such as JavaScript create Mashup businesses. In the traditional Mashup business development method, because the format of the Mashup data source is not uniform, business developers need to master specific programming technologies such as Web Service, Rest, C++, and Java at the same time, which makes development difficult and requires high requirements for business developers. With this method of the present invention, business developers do not need to learn additional development languages (including Mashup Server label language and web page language), and can create Mashup services only by using the extended dynamic scripting language, which reduces the difficulty of business development and requirements for business developers.

402: The request message analysis unit forwards the message to the mashup deployment unit after analyzing the mashup deployment request message.

403: The mashup deployment unit sends a component generation request to the component generation unit, requesting the component generation unit to generate components for the Mashup Service data source.

404: The component generation unit sends a script parsing request, requesting the script parsing unit to parse the script description of the Mashup business and obtain the keywords and parameters in it. The keywords include imports, namespace, schema, and operation ( operation).

405: The script parsing unit feeds back parsing results, such as keywords and parameters, to the component generating unit.

406: The component generating unit parses and obtains corresponding components and operations of the Mashup service according to the parameters fed back by the script parsing unit and keywords such as imports, namespace, schema, and operation.

The component generating unit analyzes and obtains corresponding components of the Mashup service according to a predetermined structure, and the predetermined structure is consistent with the predetermined structure adopted when creating the Mashup service. Referring to FIG. 5 , the predetermined structure includes a component imports part (Component imports), a namespace definition part (Mashup namespace definition), a syntax definition part (Schema definition), and an operation part. Wherein, the operation part may include one or more operations, such as including operation 1 to operation n, where n is a serial number. Referring to FIG. 6 , it is an example of a predetermined structure provided by an embodiment of the present invention.

The corresponding components of the Mashup service refer to the imported components when creating the Mashup service, and the imported one or more components are obtained by analyzing the component ID, keywords and parameters. For example, when the component ID is identifier, the component whose component ID is identifier in the Mashup business can be parsed out according to the command importComponent("identifier") of the import operation.

407: After parsing and obtaining the corresponding components, the component generation unit sends a deployment success message to the Mashup deployment unit.

408: The Mashup deployment unit feeds back a deployment success message to the request message analysis unit.

409: Request the message analysis unit to forward the deployment success message to the service deployer.

Note: If an error occurs during parsing or deployment, the deployment failure message will be fed back in 407-409.

After the deployment is successful, the components of the Mashup Service data source are registered. The registration process is basically the same as that shown in Figure 3 and will not be repeated here. The main difference is that, as shown in Figure 4(b), registration can be performed after the component is generated, and the component generation unit sends a registration query request (Query Component) directly to the component storage unit, see step 411 in Figure 4(b), The component registration process is initiated, and in step 412, the component storage unit feeds back the query result to the component generation unit, which simplifies the processing process. For steps 413 and 414 in FIG. 4(b), refer to steps 5b and 6b in FIG. 3 , and for steps 415 and 416, refer to steps 7b and 8b in FIG. 3 . During the registration process, for the components of the Mashup Service data source, a service provider interface is generated according to the script description (such as javascript code) of the Mashup Service data source.

Through the above-mentioned component registration process, the components of each data source have a service providing interface, and the actual service can be directly invoked by using the service providing interface. For example, a Java component can use the service provider interface to create an object of the java class and call a java function.

12: Obtain a corresponding component from the registered components according to the service request, and dynamically generate a service request interface for the obtained component according to a unified second format.

The service request interfaces generated by all components have a unified format, such as the second format. The second format corresponding to the service request interface may be the same as or different from the first format corresponding to the service providing interface.

The technical solution of the embodiment of the present invention provides a portal function to the service requester, and the service requester can query the registered components. For each registered component, the Mashup server generates a service request interface on demand. The so-called on-demand mainly refers to generating a service request interface for a component according to the state of the service requester and the state of the data source of the component.

The status of the business requester mainly includes one or more of the status of the initiator of the business requester (such as a traditional terminal or a new terminal), business presentation mode and response time; the status of the data source of the component includes the load capacity of the data source, The quality of service (Quality of Service, QoS) of the components of the data source and the reliability of the data source.

When the above state changes, the generated service request interface also changes. For example, when the registration information of a user (business requester) accessing a registered component through a browser changes, the generated service request interface will also change. Therefore, the service request interface is dynamically generated and not stored in advance, which avoids the problem of occupying a large amount of memory due to the pre-stored service request interface. The method of dynamically generating the service request interface can meet the dynamic characteristics of component registration and save memory requirements.

The process of dynamically generating the service request interface based on the query of the service requester will be specifically described below in conjunction with the scenario shown in FIG. 7 .

701: The service requester sends a service request message to the request message analyzing unit, and the service request message carries a component keyword or a component ID.

702: After analyzing the service request message, the request message analyzing unit forwards the service request message to the component request processing unit.

703: The component request processing unit sends a component query request to the component storage unit to query the requested component.

704: The component storage unit returns the query result to the component request processing unit;

If there is a corresponding registered component in the component storage unit, that is, when the component ID of the registered component matches the component keyword carried in the service request message, the query is successful, and step 705 is executed.

If there is no component information corresponding to the component ID in the component storage unit, that is, when the component ID of the registered component does not match the component keyword carried in the service request message, the query fails, and the query failure information is sent to the request message analysis unit .

705: Determine whether the component request processing unit itself can generate a service request interface, and if the component request processing unit itself can generate the service request interface of the component, perform step 708;

When the component request processing unit cannot generate a corresponding service request interface, step 706 is performed.

706: The component request processing unit sends an interactive interface generation request to the Mashable API creation unit to create a service request interface of the component.

707: The Mashable API creation unit creates a service request interface and returns a creation result. When the creation is successful, execute step 708.

Among them, when there are multiple components, and the component IDs of these components all match the component keywords in the service request message, the component request processing unit or the Mashable API creation unit State, select the appropriate registered components, and dynamically generate business request interfaces for the selected components.

708: When generating the service request interface, the component requests the processing unit to send a response message, such as an interface generation success message, to the request message analyzing unit.

709: The request message analysis unit generates a success message to the service requester feedback interface.

The following takes a specific mashup business "Etour" as an example for illustration.

The mashup service Etour is composed of weather service and FlightSearchService service. For the weather service, if the component key is a weather series component is stored in the component storage unit, for example, the Java component weather service, the REST component weather service, etc. When a business requester requests an Etour service, the Mashup server considers the state of the data source of the component (load, QoS of the component, reliability of the data source, etc.) etc.) to select the most suitable component, such as a Java component, and dynamically generate a business request interface for the component, which includes component calling protocol, calling function and parameters and other information. The FlightSearchService business is handled in the same way.

According to the protocol of the service request interface, the service requester calls functions and parameters, etc., and requests to call the actual service. Examples of calling functions, calling protocols and parameters involved in the business request interface are as follows:

The service request interface of the java component weather service corresponds to the Java call function Weather (city), city is a parameter indicating the city name, the calling protocol is the SOAP protocol, and can also include other parameters, such as parameters indicating the QoS that can be provided. The response time is 0.3s, and the feedback information format is SMS;

The service request interface of the weather service of the WSDL Web component corresponds to the call function provided according to the WSDL description, the parameters are x, y, where x and y represent longitude and latitude respectively, and are bound to the SOAP call protocol. It may also include other parameters, such as a parameter indicating the QoS that can be provided, the parameter indicates that the response time is 0.5s, and the format of the feedback information is a web page.

13: Utilize the service request interface to receive the service request message, utilize the service provision interface to request services from the required components, and utilize the service request interface to send the generated Mashup service response message to the service requester.

Match the service provider interface with the service request interface, that is, match the service provider interface with the service request interface. One service provider interface can correspond to one service request interface, and one service provider interface can also correspond to multiple service request interfaces. The service providing interface includes calls to one or more services, and the service request interface includes calls to single or combined mashup services. The service provider interface and service request interface corresponding to a component constitute the Mashable API of this component, and the Mashable API is the interface exposed by the component to the outside.

The following uses a specific Mashup business "Etour" as an example to illustrate the use of components.

The process of using components includes querying registered components according to business request messages. Registered components are aggregated (Mashup) according to simple load balancing principles (such as sequential calls, random allocation, etc.) and the actual needs of business creators. Call the corresponding imported component according to the operation definition. The mashable API used by the component can be imported with the standard HTML tag <script>, for example:

<script type='text/javascript'src='.../stub/sms'></script>

where "sms" is a component ID.

Table 1

See Table 1, which shows the information list of the service request interface and the service provision interface.

The mashup business "Etour" is composed of components weather and flightSearchService, which can be expressed as component ID (Identifier1): Weather; component ID (Identifier2): FlightSearchService

The component ID provides interface information for the service of the Weather component as follows:

Weather, method Getweather, parameter city, component type JAVA, calling method Java MethodInvocation.

The component ID is the service interface information of the component of FlightSearchService, which is expressed as follows: FlightSearchService, method GetFlightList, parameter FlightSearchRequest, component type webservice, calling protocol SOAP/HTTP.

As mentioned above, the service requester sends a service request message, and the service requester uses a browser or a client. The browser can be a PC browser or a terminal browser or the browser is a hypertext transfer protocol (HyperText Transfer Protocol, HTTP) is a widget that interacts with the Internet and sends a business request message, which is expressed as import webRMI.js, where webRMI.js is a static javascript file sent by the Mashup server to the business requester, and the javascript file supports AJAX The technology's ability to send requests and parse responses. After the business requester obtains the webRMI.js file from the server, the client shows the user interface provided by the Mashup server to the business requester. The service requester sends a service request message according to the user interface.

The business requester sends a business request message to the Mashup server to request the Mashup business Etour. After receiving the request, the Mashup server inquires whether there is a component corresponding to Etour that is registered and stored. , to dynamically generate a service request interface. For example, the Mashup server returns the dynamically generated js file (Etour.js) to the business requester, and the business requester feeds back relevant parameters, such as city, date, etc., and the webRMI.js of the client sends the request to Mashup according to the instructions of Etour.js server.

The Mashup server requests the Etour service from the Etour components through the service providing interface, and the Etour component calls the actual service through the service providing interface, such as weather service and FlightSearch service. The function calls the actual business to complete the weather query, provides the WSDL web component of the FlightSearch business, calls the actual business through the HTTP protocol, and the Etour component combines the business of the above components and feeds back the result to the business requester.

The solution for realizing the Mashup service provided by the embodiment of the present invention can support the interaction between the Mashup system and other systems (such as the AAA system and/or billing system), and ensure the security of operation. Among them, security includes verification of user identity, verification of authority of users to use services, support for single sign-on, etc. See Figure 8, the specific process is described as follows:

801: The service requester sends a service request message to the request message analysis unit.

802: After analyzing the request message, the request message analysis unit forwards the service request message to the component request processing unit.

803: The component request processing unit sends a verification, authentication or accounting request message to the component management unit.

804: The component management unit triggers a corresponding operation, such as a verification and authentication process, or a charging operation process. The solution provided by the invention supports mechanisms of authentication, authentication and charging.

The component management unit requests verification of user identity and user access rights from the verification and authentication system. After the verification is passed, the verification and authentication system performs subsequent operations, for example, requests resource reservation and other requests from the charging system (such as OCS or OFCS).

When the verification is passed and the resource reservation is successful, the Mashup system executes step 805b; otherwise, if the verification fails or the resource reservation fails, the Mashup system executes 805a:

805a: The component management unit sends a request failure message to the component request processing unit.

806a: The component request processing unit sends a request failure message to the request message analysis unit, wherein, if the reason for the failure is failure to pass the verification, the request failure message may indicate that the verification failed, and if the reason for the failure is insufficient reserved resources, then The request failure message may indicate insufficient resources, such as insufficient balance.

807a: The request message analysis unit forwards the request failure message to the service requester.

805b: The component management unit sends a verification, authentication or accounting request to the component request processing unit successfully.

806b: The component request processing unit sends a query request to the component storage unit to query the registered component corresponding to the component ID in the call request message.

807b: The component storage unit feeds back the component query result to the component request processing unit.

808b: The component request processing unit generates a service request interface through the fed back component information, and feeds back the service request interface to the service requester.

809b: The service requester sends a service request message to the request message analysis unit to request a service according to the service request interface. That is, the request message analysis unit uses the service request interface to receive the service request message.

810b: The request message analysis unit forwards the service request message to the component request processing unit.

811b: After receiving the service request message, the component request processing unit uses the service providing interface to request a service from the component corresponding to the service request message.

812b: The component request processing unit sends the generated Mashup service response message to the request message analysis unit.

813b: The request message analysis unit forwards the Mashup service response message to the service requester.

814b: The component management unit sends component invocation information to the component request processing unit.

The component request processing unit notifies the component management unit which components are called and the relevant information of these components.

815b: The component management unit generates a service use detailed list according to the component call information, for example, records a call detailed record (Call Detailed Record, CDR), and then, the billing system charges the use of the Mashup service according to the CDR.

For example, when the weather component and the fight component are invoked, the component management unit will generate a service usage bill according to the invocation information of the weather component and the fight component; the billing system can perform billing according to the billing policy, such as calling the weather component once and charging 1 yuan fee, 1 yuan fee is charged for each call of the flight component, and the total charge for this mashup business is 2 yuan.

816b: After the accounting ends, the component management unit sends an accounting success message to the component request processing unit.

817b: The component request processing unit forwards the charging success message to the request message analyzing unit.

818b: The request message analyzing unit returns the charging success message to the service requester.

For the process of generating the service request interface in step 808b and the process of service query in step 806b, please refer to the relevant content above, and the description will not be repeated here.

Further, in the embodiment of the present invention, the components of the Mashup service created according to the predetermined structure can be used by other Mashup services, such as registering the components of the created Mashup service and generating a MashupAPI according to a unified format, and repackaging it to be open to the outside It has an interface with a unified format, so as to create a new Mashup service based on this component.

It can be seen from the above that the embodiment of the present invention implements a unified encapsulation mechanism for various Mashup data sources, uses a unified format for registration and encapsulation, has strong scalability, wide coverage of data sources, and avoids business The inconvenience caused by creators using APIs of traditional data sources to develop mashup applications.

The embodiment of the present invention provides an extended dynamic scripting language, so that business creators do not need to learn additional languages, such as each specific component language, such as Java, C++, and Mashup Server tag language, etc., only need to use the extended dynamic scripting language Scripting language can create Mashup business.

The embodiment of the present invention manages the registered reliable data sources in the format of Mashable API, guarantees the stability and reliability of the data sources, and performs certain user management and operation management on the user access and use of the data sources, such as computing Fees and verification authorization, etc.

The embodiment of the present invention can repackage the created Mashup service into a component with a unified interactive interface, so as to facilitate the invocation of secondary development.

Another embodiment of the present invention also provides a device for realizing the service aggregation Mashup service. Referring to FIG. 9, the device includes:

The service providing interface generating unit 91 is configured to register the components of the data source and generate a service providing interface for the components according to a unified first format.

A service request interface generation unit 92, configured to obtain the required components from the registered components according to the service request message of the service requester, and generate a service request interface for the required components according to a unified second format . The first format and the second format are the same format, or the first format and the second format are different formats.

The service realization unit 93 is configured to use the service request interface to receive the service request message, use the service provision interface to request services from the required components, and use the service request interface to send the generated Mashup service response message to the business requester.

Further, the device also includes:

The component obtaining unit is configured to, during the deployment process of deploying the Mashup service data source on the Mashup server, analyze the Mashup business of the Mashup service data source according to a predetermined structure to obtain the components of the Mashup service data source. The device also includes a service creation unit for creating a Mashup service using a dynamic scripting language according to the following predetermined structure:

Component import section, namespace definition section, syntax definition section, and operation definition section.

Wherein, the service providing interface generation unit includes:

The first receiving module is used to receive the registration component request message, and the registration component request message carries the component ID; the query processing module is used to query whether the component corresponding to the component ID has been registered in the stored registered components , if registered, update the component ID, re-execute the registration process, if not registered, generate and store the service providing interface according to the unified first format.

Wherein, the service request interface generation unit includes:

The second receiving module is configured to receive a service request message, and the service request message carries a component keyword;

An acquisition module, configured to acquire the registered component when the component ID of the registered component matches the component keyword carried in the service request message;

The generating module is used to select an appropriate component according to the status of the service requester and the status of the data source of the registered component, and dynamically generate a service request interface for the selected component.

Another embodiment of the present invention also provides a communication system, the system includes a mashup server, and the mashup server includes the above-mentioned device for realizing the mashup service.

For the specific working mode of each functional module and unit in the device embodiment of the present invention, refer to the method embodiment of the present invention. Each functional module and unit in the device embodiment of the present invention can be implemented independently, or integrated in one or more units.

The technical solution provided by the embodiment of the present invention implements a unified encapsulation mechanism for various data sources by adopting a unified format to generate service providing interfaces or service request interfaces for components of each data source, thereby being able to support data sources including telecommunication services in Various types of data sources within the Mashup service are performed through this interactive interface, which enhances the scalability of the Mashup service and meets the needs of users.

Another embodiment of the present invention also provides a network device, including:

The request message analysis unit is configured to analyze the received component registration request message, send the component registration request message to the component registration unit, the component registration request message carries the component identification ID, and the received service request The message is analyzed, and the service request message is sent to the component request processing unit,

The component registration unit is configured to send a component query request to the component storage unit according to the component ID carried in the component registration request message, and query whether all registered components in the component storage unit have a component with the same ID registered, If there is no component registration with the same ID, call the MashableAPI creation unit, so that the Mashable API creation unit provides an interface for component generation services in a unified first format; the component storage unit is used to store components and component description information , the description information includes a component ID;

The component request processing unit is configured to generate a service request interface for the component according to a unified second format according to the service request message, or call the Mashable API creation unit to make the Mashable API creation unit follow the unified second format Generate a service request interface for the component, and use the service request interface to receive the service request message, use the service providing interface to request service from the corresponding component, and use the service request interface to send the generated Mashup service response message to the service requester.

Further, the request message also includes a mashup deployment request message, and the above-mentioned network device also includes:

The Mashup deployment unit is used to deploy the Mashup service data source on the Mashup server and request the component generation unit to generate components for the Mashup business of the Mashup service data source according to the mashup deployment request message;

The component generation unit is used to send a script analysis request to the script analysis unit according to the request of the Mashup deployment unit, request the script analysis unit to analyze the script description of the Mashup service and obtain the analysis result, so as to generate the Mashup service according to the predetermined structure components;

The script analysis unit is used to analyze the Mashup business of the Mashup Service data source described in a dynamic language, and send the analysis result to the component generation unit, so that the component generation unit generates components for the MashupService data source.

Further, the above-mentioned network device also includes: a component management unit, configured to receive a verification, authentication or accounting request message from the component request processing unit, and request the verification and authentication system to verify the user identity and user access rights, according to the component The information is invoked to generate a detailed service use bill, so that the charging system uses the detailed service use bill for charging.

Refer to the embodiments shown in FIGS. 2 to 8 for specific working modes of the foregoing network devices.

For the specific working mode of each functional module and unit in the device embodiment of the present invention, refer to the method embodiment of the present invention. Each functional module and unit in the device embodiment of the present invention can be implemented independently, or integrated in one or more units.

The technical solution provided by the embodiment of the present invention implements a unified encapsulation mechanism for various data sources by adopting a unified format to generate service providing interfaces or service request interfaces for components of each data source, thereby being able to support data sources including telecommunication services in Various types of data sources in the system create and request Mashup services through this interactive interface, which enhances the scalability of Mashup services and meets the needs of users.

Those skilled in the art can clearly understand that the present invention can be realized by means of software plus necessary general hardware platform. Based on this understanding, the essence of the technical solution of the present invention or the part that contributes to the prior art can be embodied in the form of software products, and the computer software products can be stored in storage media, such as ROM/RAM, disk, A CD, etc., includes several instructions to make a computer device (which may be a personal computer, a server, or a network device, etc.) execute the methods described in various embodiments or some parts of the embodiments of the present invention.

The above is only a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Anyone skilled in the art can easily think of changes or substitutions within the technical scope disclosed in the present invention. All should be covered within the protection scope of the present invention. Therefore, the protection scope of the present invention should be based on the protection scope of the claims.

Claims (13)

1. A kind of 1. method for realizing business polymerization Mashup business, it is characterised in that methods described includes：

   The component of data source is registered and generates business according to the first unified form as the component interface is provided；

   According to service requester business request information, required component is inquired about in the registered component, and according to system One the second form generates service request interface for the required component, and a business provides interface and corresponds to one or more industry Business request interface；

   Using business request information described in the service request interface, interface is provided to described required using the business Component call business, the Mashup business response messages of generation are sent to service requester using the service request interface.
2. 2. according to the method for claim 1, it is characterised in that the component to data source is registered and according to unified The first form generate business for the component and interface is provided included：

   Component registration request message is received, portable unit identifies ID in the component registration request message；

   In the registered component of storage, inquire about whether the component corresponding to the component ID has been registered, if having registered, more The new component ID, re-executes register flow path, if unregistered, provide interface according to unified the first form generation business and deposits Storage.
3. 3. method according to claim 1 or 2, it is characterised in that the component to data source registered and according to The first unified form provides interface for component generation business to be included：

   When the component is C++ components, according to the dynamic link library file of C++ components and component ID, locally connect by Java Mouth Java Native Interface generate the business and provide interface；

   When the component is Java component, the business offer is generated according to the java packets of Java component and component ID and connect Mouthful；

   When the component is that declarative state shifts REST components, according to the REST URLs of the REST components URL and component ID generates the business and provides interface；

   When the component is web service description language WSDL Web components, according to the HTTP URL and group of the Web components Part ID generates the business and provides interface.
4. 4. according to the method for claim 1, it is characterised in that the business request information according to service requester, Inquiring about required component in the registered component includes：

   Business request information is received, portable unit keyword in the business request information；

   When the component keyword match carried in the component ID of registered component and the business request information, described in acquisition The component of registration.
5. 5. the method according to claim 1 or 4, it is characterised in that second form according to unification is described required Component generation service request interface include：According to the shape of service requester state and the data source of the registered component State, suitable registered component is selected, and be the component dynamic generation service request interface of the selection；

   The state of the service requester comprises at least following one kind or its combination：

   Terminal, business presentation mode and response time used in service requester；

   The state of the data source of the component comprises at least following one kind or its combination：

   The load capacity of the data source, the service quality QoS of component of the data source and the reliability of the data source.
6. 6. method according to claim 1 or 2, it is characterised in that the component to data source registered and by Before providing interface according to the first unified form for component generation business, methods described also includes：

   The data source includes business polymerization service Mashup service data sources and non-Mashup service data sources；

   During the deployment that Mashup service data sources are deployed on Mashup servers, to the Mashup The Mashup business of service data sources is parsed to obtain the group of the Mashup service data sources according to predetermined structure Part.
7. 7. according to the method for claim 6, it is characterised in that Mashup service data sources are being deployed in Mashup Before on server, methods described also includes：

   Using dynamic script language Mashup business is created according to following predetermined structure：

   Component lead-in portion, NameSpace definition part, syntactic definition part and Operation Definition part.
8. 8. a kind of device for realizing business polymerization Mashup business, it is characterised in that described device includes：

   Business provides interface generating unit, for being registered to the component of data source and being described according to the first unified form Component generation business provides interface；

   Service request interface generating unit, for the business request information according to service requester, in the registered component Component needed for middle inquiry, and generate service request interface, an industry according to the second unified form for the required component Business provides interface and corresponds to one or more service request interfaces；

   Business realizing unit, for using business request information described in the service request interface, being carried using the business For interface to the required component call business, using the service request interface by the Mashup business response messages of generation Send to service requester.
9. 9. device according to claim 8, it is characterised in that the data source includes business polymerization service Mashup Service data sources and non-Mashup service data sources, described device also include：

   Component obtaining unit, in the deployment process being deployed in Mashup service data sources on Mashup servers In, the Mashup business of the Mashup service data sources is parsed according to predetermined structure to obtain the Mashup The component of service data sources.
10. 10. device according to claim 8, it is characterised in that described device also includes service creation unit, for utilizing Dynamic script language creates Mashup business according to following predetermined structure：

    Component lead-in portion, NameSpace definition part, syntactic definition part and Operation Definition part.
11. 11. device according to claim 8, it is characterised in that

    The business, which provides interface generating unit, to be included：

    First receiving module, for receiving component registration request message, portable unit ID in the component registration request message；

    Query processing module, for whether in the registered component of storage, inquiring about the component corresponding to the component ID Registration, if having registered, updates the component ID, re-executes register flow path, if unregistered, is given birth to according to the first unified form Interface is provided into business and is stored.
12. 12. device according to claim 8, it is characterised in that

    The service request interface generating unit includes：

    Second receiving module, for receiving business request information, portable unit keyword in the business request information；

    Acquisition module, for when the component keyword match carried in the component ID of registered component and the business request information When, obtain the registered component.
13. 13. the device according to claim 8 or 12, it is characterised in that

    The service request interface generating unit further comprises：

    Generation module is suitable for the state according to service requester and the state of the data source of the registered component, selection Registered component, and for the selection component dynamic generation service request interface.