CN100512132C - Method for implementing service logic operation environment - Google Patents

Abstract

The invention discloses a method for realizing a service logic operation environment, and relates to the field of telecommunication service operation environment. The method comprises: a communication entity sends a message middleware event message to an event scheduler; , obtain the corresponding service instance in the service type pool, and control the obtained service instance to complete the corresponding operation. In the structure of the distributed business logic running environment, business instances in a session can share the business session context data generated in the session, and the business instances can perform corresponding operations on it. Provide a common communication platform for the business logic operating environment through message middleware technology. The invention realizes the operating mechanism of the service logic operating environment independent of the application program server platform through the message middleware technology, and can realize the data sharing among nodes of the distributed service logic operating environment through the message middleware technology.

Description

A Method for Realizing Business Logic Running Environment

technical field

The invention relates to the field of telecommunication service operating environment, in particular to a method for realizing a business logic operating environment.

Background technique

JAIN (JAVA API for Intelligent Network) technology is committed to providing an integrated application program interface (API) and interface framework based on the JAVA platform to establish or integrate a unified telecom service solution that can span various networks. Among them, various networks include packet-switched networks based on Internet Protocol (IP) or Asynchronous Transfer Mode (ATM), wireless networks and traditional public switched telephone networks (PSTN); telecom service solutions include service portability and consistency , external business access to the security of the integrated network and other features. The JAIN technology enables the protocols of the Internet (Internet) and the Intelligent Network (Intelligent Network) to be integrated to form a new Integrated Network (Integrated Network). Many participants in the JAIN technical organization have developed a series of API and interface frameworks based on a well-defined work process. Business developers follow these API and interface frameworks to achieve the purpose of rapid development and deployment of diverse services.

The work output of the JAIN technical organization includes two main development areas: API protocol specification and API application specification. The API protocol specification is to formulate a standardized signaling protocol interface specification for accessing IP, wired networks and wireless networks. The signaling protocol includes: transaction processing capability application part (TCAP), integrated service service network user part (ISUP), intelligent network application Protocol (INAP), Mobile Application Part (MAP), Session Initiation Protocol (SIP) and H.323, etc. The API application specification is to formulate interface framework recommendations for network security access (JAIN Parlay), connectivity management, JAIN session/call control (JCC/JCAT), and JAIN service generation/telecom-level business logic operating environment (JSC/SLEE), etc. and API specifications.

Figure 1 is a schematic diagram of the JAIN API specification architecture, as shown in Figure 1, the JAIN API architecture can be composed of three layers: JAIN application layer 104, JAIN business layer 110 and JAIN network protocol layer (Protocol Layer) 111.

The JAIN network protocol layer 111 supports protocols such as TCAP, ISUP, INAP, MAP, SIP, H.323, Media Gateway Control Protocol (MGCP) and Megaco. The role of the JAIN network protocol layer 111 is to adapt specific network messages from the actual network layer below into the API call form of the JAIN protocol. The actual network layer includes IP112, broadband network (Broadband) 113, wired network (Wireless) 114, PSTN115 and satellite network (Satellite) 116, etc.

The JAIN business layer 110 includes a JAIN business logic execution environment (JSLEE, JAIN ServiceLogic Execution Environment) 108 and a JAIN session/call control (JCC, JAIN CallControl/JCAT, JAIN Coordination and Transactions) 109. After the business is developed, the business is deployed in JSLEE 108, and the business handles network events in the mode of JCC/JCAT 109. JSLEE 108 is an important part of a series of JAIN API integrations, and is at the core of the entire JAIN API architecture. JSLEE is the JAIN business logic operating environment, which can be regarded as a virtual operating system environment supporting business operation. Its typical functions include managing the business life cycle and providing various system services for business operation.

The JAIN application layer 104 includes untrusted third-party applications (Untrusted third-party applications) 101, JAIN service creation environment (JSCE, JAIN Service CreationEnvironment) 102 and trusted third-party applications (Trusted third-party applications) 103. The untrusted third-party application 101 discovers and accesses the services deployed in the JSLEE 108 and the capabilities of each service through the JAIN service provider interface (JSPA, JAIN Service Provider Access) 105 . The trusted third-party application 103 accesses the services in the JSLEE 108 through a standard security interface (Security Interface) 106. JSCE 102 belongs to the JAIN specification and can be independent. It is a set of API specifications that can quickly develop JSLEE 108 services.

The JAIN service layer 110 communicates with the JSPA 105 and the secure interface 106 through the secure telecommunication space 107.

Fig. 2 is a simplified logical functional block diagram of SLEE. As shown in Fig. 2, the basic components of SLEE 201 mainly include service type instance pool (Service Instance Pool) 202, event dispatcher (ED, Event Dispatcher) 204, system service (SLEE Resource ) 205 and data pool 206. The service type instance pool 202 includes a plurality of service instances 203 , and the event scheduler 204 searches and obtains the required service instance 203 in the service type instance pool 202 . The system service 205 manages the service life cycle, timer service, alarm service and so on. The data pool includes a database (DataRepository) 207 for storing various data during operation, data describing services—service description (Service Description) 209, and event information (Event Information) 208 describing possible scheduling events of the ED 204. ED204 receives event information (Event Source) 211 from the underlying network protocol stack through different network adapters (Network Adapter) 210.

The integration of JAIN SLEE API provides an interface framework for the specific implementation of SLEE. Its advantages include: providing a series of precisely defined APIs in a standard and reusable manner, through which public functions can be called, and service providers follow These APIs can quickly develop new services and applications; business developers can only focus on the implementation logic of the business in the process of developing the business, and do not need to care about the underlying network protocol and technical details of running the business. Protocol changes are shielded; service developers can quickly generate new services, and can also use existing service features to combine new services; after the service is developed, the new service can run on all interface frameworks compatible with JSLEE.

In addition to the JAIN SLEE API, the JAIN technical organization also provides the specification for implementing SLEE, which describes the life cycle model of the business, the deployment mechanism of the business, and so on. The service deployment mechanism includes the structure of service packaging and the definition of service content, how to define the deployment descriptor (Deployment Descriptor) used to guide service deployment, service deployment and subscription interface, etc. In addition, it also defines the operation mechanism of the business, including the definition of the operation management interface, the asynchronous communication mechanism between the business and so on.

JSLEE architecture and API are constantly evolving with the improvement of existing network technology and software implementation technology. The advantage of JSLEE is also reflected in its openness. It does not specify specific implementation details, but only provides an architecture-level interface framework and a standard API-level interface. In this way, different developers can implement a specific SLEE according to their own technical characteristics. Using different technologies will have differences in performance and cost, which will help the competition and development of SLEE products in the market, and in turn will promote the continuous improvement of JSLEE architecture and API.

To implement a carrier-class SLEE, technical details such as distributed processing, load balancing, effective storage of databases, and management of object and connection service type instance pools must be considered. From a technical point of view, JAIN SLEE can be realized with component technology. EJB (Enterprice JAVA BEAN) component technology is a feasible technology to realize JSLEE. In addition, JINI, JINI JAVASpace, and JES are all optional component technologies that can realize JSLEE. Some features of JSLEE, such as distributed processing, load balancing, processing power, etc., are completely dependent on the performance of the application server platform used.

If JSLEE is implemented using EJB component technology, the performance of JSLEE depends entirely on the performance of the adopted application server platform that supports EJB. Although some commonly used application server platforms claim to be able to achieve very high performance indicators, the actual test results are not ideal. The processing capacity of some application server platforms for EJB requests is about 1600 requests/second, and as the number of clients increases, the response time increases significantly. Although the performance of the application server platform can be improved by optimizing the system parameters, the performance improved by the optimized parameters will not change substantially. In addition, some application server platforms can use group machine superposition technology, although it will greatly improve the performance of JSLEE, but it is realized on the basis of increasing software and hardware investment. Implementing JSLEE using EJB component technology needs to fully follow the EJB1.0 or 2.0 specification. Using a specific application server platform will make appropriate extensions to the EJB specification, so as to achieve specific performance indicators or provide some features that are not involved in the EJB specification.

The development of JSLEE based on certain application server platforms also needs to follow the development specifications of the adopted application server platform, and implement JSLEE within the range of performance characteristics supported by the application server platform. However, for some features, such as the asynchronous callback feature, most application server platforms do not support it, and only some workarounds can be adopted in the design.

JSLEE is implemented using EJB component technology. When deploying JSLEE, the process will be more complicated. Firstly, the application server platform needs to be deployed, and the performance parameters are tuned to be optimized first, and then JSLEE is deployed on the application server platform. If you use a commercial application server platform, you need to pay expensive software usage fees and maintenance fees.

Contents of the invention

In view of this, the object of the present invention is to provide a method for realizing a business logic running environment, which realizes the running mechanism of the business logic running environment independent of the application server platform.

In order to achieve the above object, the present invention provides a method for implementing a business logic operating environment, which is characterized in that the communication entities that send and receive message middleware event messages are initialized, and all communication entities that need to receive message middleware event messages are assigned a unique Message middleware address, the method also includes the following steps:

S. Execute the initialization process for reading the initialization configuration file including the message middleware address of the event dispatcher;

A. The communication entity uses the acquired message middleware address of the event scheduler to send the message middleware event message to the event scheduler;

B. The event scheduler acquires the corresponding service instance in the service type pool according to the received message middleware event message, and controls the acquired service instance to complete the corresponding operation.

The communication entity is a network protocol stack; the step A is that the network protocol stack uses the message middleware address of the acquired event scheduler to send the message middleware service session initial event message to the event scheduler; the step B is the event scheduler According to the received message middleware service session initial event message, obtain an idle service instance in the service type pool, and activate the service instance, and the business logic running environment node assigns the service instance ID to the service instance, and then controls the obtained service instance The business instance completes the corresponding operation.

The communication entity is a network protocol stack; the step A is that the network protocol stack uses the message middleware address of the acquired event scheduler to send the message middleware business session process event message to the event scheduler; the step B is the event scheduler According to the received message middleware business session process event message, obtain the corresponding activated service instance in the service type pool, and control the obtained service instance to complete the corresponding operation.

The communication entity is a business instance; the step A is that the business instance sends the message middleware business instance event message to the event scheduler using the message middleware address of the event scheduler obtained; the step B is that the event scheduler receives the The message middleware business instance event message, obtains the corresponding target business instance in the business type pool, and the event scheduler sends event processing information to the target business instance according to the business instance event message, and controls the target business instance to complete the corresponding operation.

For the structure of the distributed business logic running environment, the step B further includes: after the event scheduler receives the event message, it judges whether the corresponding business instance is located on the business logic running environment node where it is located, and if so, when the business logic runs Get the corresponding business instance from the business type pool on the environment node; otherwise, the business logic running environment node where the event scheduler is located finds the target business logic running environment node where the corresponding target business instance is located according to the initialization configuration file, and obtains the target The message middleware address of the target event scheduler on the business logic running environment node, the event scheduler sends a message in the message middleware format to the target event scheduler, and the target event scheduler obtains the corresponding business instance.

For the distributed service logic operating environment structure, the step B further includes: setting the service instance as the main service instance at the logical operating environment node where the obtained service instance is located.

Preferably, for a distributed business logic runtime environment structure, the business instance located at the same logic runtime environment node as the main business instance is set as a local business instance; the method further includes the following steps:

D. The local business instance calls the data access interface;

E. The data access interface accesses the business session context data by calling the local data access tool, and operates the business session context data;

F. The local data access tool returns the operation result on the business session context data to the local business instance.

The business session context data is stored in the business logic running environment node where the main business instance is located.

Preferably, for a distributed business logic operating environment structure, a business instance located at a different logical operating environment node from the main business instance is set as a remote service instance; the method further includes the following steps:

D1. The remote business instance invokes the data access interface;

E1. The data access interface invokes the remote data access tool. The remote data access tool sends a message middleware message to the remote data agent of the business logic operating environment node where the main business instance is located. After receiving the message middleware message, the remote data agent calls the local data access tool Tools access business session context data and operate on business session context data;

F1. The local data access tool returns the operation result of the business session context data to the remote data proxy, and the remote data proxy returns the operation result of the business session context data to the remote data access tool, and the remote data The access tool returns the operation result on the context data of the business session to the remote business instance.

The local data access tool and the remote data access tool are generated during initialization.

For the distributed service logic execution environment structure, the step A further includes: the network protocol stack sends a service session initial event message to the event scheduler on any node of the service logic execution environment.

The invention realizes the SLEE operating mechanism independent of the application program server platform through the message middleware technology. The invention provides a general communication platform for the SLEE through the message middleware technology. Moreover, in the distributed SLEE structure, the service deployer can comprehensively consider which SLEE node the service is deployed on according to load balancing, geographical location and other conditions, achieving the purpose of flexible service deployment, and the distributed SLEE can be realized through message middleware technology data sharing.

Description of drawings

Figure 1 is a schematic diagram of the JAIN API architecture;

Fig. 2 is a simplified logic functional block diagram of SLEE;

FIG. 3 is a schematic diagram of a non-distributed SLEE structure;

FIG. 4 is a schematic diagram of a distributed SLEE structure;

Figure 5 is a schematic diagram of distributed SLEE Session Context data sharing.

Detailed ways

In order to make the purpose, technical solution and advantages of the present invention clearer, the present invention will be further described in detail below in conjunction with the accompanying drawings.

The present invention introduces message middleware (MOM, Message Oriented Middleware) technology in SLEE, realizes the interaction of information between communication entities through MOM technology, firstly MOM technology is introduced below.

MOM technology is used to provide an efficient and general communication platform between communication objects. MOM technology supports both synchronous and asynchronous messages. When sending a synchronous message, the sender process will be blocked until the return value of the message is received before continuing to perform subsequent work. There is no blocking problem in sending asynchronous messages. After the sender sends the message, it can handle the follow-up process. Each communication entity object that needs to receive MOM messages needs to be assigned a pair of unique module identifier (MID) and process identifier (PID). MID represents a physically independent module number; PID represents a process number, which can be used to identify a specific program module in an application program that needs to receive MOM messages. To send the MOM message to the target communication entity, the sender of the MOM message must know the MID and PID of the target communication entity. A pair of unique MID and PID constitutes the address for sending MOM messages, which can also be called MOM address.

The communication entity at the receiving end of the MOM message needs to implement the functions of two specific JAVA interfaces, which are respectively used for processing after receiving an asynchronous message and a synchronous message. When the MOM receiver communication entity receives the MOM message, it will call one of the two interfaces according to the type of the MOM message to trigger the MOM message event.

SLEE can be divided into non-distributed SLEE and distributed SLEE from its operating environment. Among them, the non-distributed SLEE can only run on one physical node, that is, one JAVA virtual machine (JVM). For services, all services are deployed on the same physical node, and the communication between services is performed on the same JVM; distributed SLEE can only run on different physical nodes, that is, different JVMs.

FIG. 3 is a schematic diagram of a non-distributed SLEE structure. As shown in FIG. 3 , the network protocol stack 302 runs on a physical node or JVM different from the SLEE 301. The service manager 307 manages multiple service type instance pools 202 . The network message 306 from the network protocol stack 302 is sent to the ED 204 of the SLEE 301 in the format of MOM message, and the ED 204 performs subsequent processing according to the type identification of the event.

In order to obtain better scalability and higher system processing capacity, SLEE must support a distributed operating mechanism, and the system load can be shared by multiple physical nodes. For services, the services are deployed on different physical nodes, and the communication between services may be performed on different JVMs.

FIG. 4 is a schematic diagram of a distributed SLEE structure. As shown in FIG. 4, each SLEE node has an ED 204. Through ED 204, distributed SLEE nodes can communicate with each other, for example, SLEE node A 401 and SLEE node B 402. The network protocol stack A 403 sends the network message 306 to the ED 204 of a certain SLEE node in the format of a MOM message, for example, the ED 204 of the SLEE node A 401, and the ED 204 processes it according to the type identification of the event. At the same time, the ED 204 can forward the network message 306 from the network protocol stack A 403 to the ED 204 of other SLEE nodes, such as the ED 204 of the SLEE node B 402.

The service instance A203 in the SLEE node A 401 can call the service instance in the SLEE node B 402 through the distributed call 406. The following will introduce the distributed calls between business instances.

The entire distributed SLEE platform can be composed of multiple SLEE nodes running in different physical locations, and services can be deployed on any SLEE node. Which SLEE node the business is specifically deployed on can be comprehensively considered according to the load balancing of each SLEE node, or the convenience of the geographical location.

In addition, no matter it is a non-distributed SLEE structure or a distributed SLEE structure, all business instances can directly communicate with the network protocol stack. The business instance constructs a MOM message, and sends the MOM message to the target network protocol stack, so that the target network protocol stack Take appropriate action.

All communication entities that need to receive the MOM message need to be assigned a unique address identifier, that is, a combination of a unique pair of MID and PID, as the destination address for the sender to send the MOM message. For the non-distributed SLEE structure, the communication entity that needs to allocate MID and PID is ED. In addition, the network protocol stack that needs to communicate also needs to assign MID and PID to it.

In the non-distributed SLEE structure, SLEE will configure an initialization configuration file, which contains the MID and PID assigned to its ED, and the MID and PID assigned to the network protocol stack.

In the non-distributed SLEE structure, if it is a service session initial event (Service InitialEvent), the service session initial event message received by the ED carries the service type identifier, and the ED searches the service type instance pool of the corresponding type through the service manager And get an idle business instance. SLEE activates idle service instances and initializes them, and configures some initial parameters. At the same time, SLEE assigns a business instance ID (Instance ID) to the business instance. If the current business session has not allocated a business session ID (Session ID), then SLEE allocates a Session ID for the current business session, and the subsequent processing is basically the same as the events in the business session described below.

If it is an event during a business session, the ED finds the corresponding activated service instance in the service type instance pool through the service manager according to the Session ID and Instance ID carried in the event message of the business session process. In the process of processing events, a business instance may communicate with other business instances in the same business session, or communicate with the underlying network protocol stack. When the above service instance communicates with other service instances, the service instance sends a service instance event message to the ED. The ED sends the event processing information to the corresponding service instance according to the service instance event message, so that the service instance processes the corresponding event.

In the distributed SLEE structure, the MOM technology also provides an efficient and general communication platform for the communication entities. The communication entities communicate with each other based on the communication platform. The communication between the communication entities in all distributed SLEE nodes is based on MOM messages are carried out. The communication between EDs uses synchronous MOM messages, which can simplify the design of EDs. ED's MOM message processing adopts a multi-thread mechanism. ED needs to maintain a thread resource pool, that is, every time ED receives a MOM message, it takes out an idle thread from the thread resource pool and activates the thread, and processes the MOM message by running the thread. Synchronous MOM messages are used between EDs. After sending a MOM message, the ED at the sending end waits for the response of the MOM message. Only this thread is blocked, and other threads can process other MOM messages in parallel. From a macro point of view, ED can process multiple MOM messages in parallel, and the scheduling efficiency and throughput of ED only depend on the JVM's scheduling efficiency of threads and the size of the thread resource pool.

In the process of deploying distributed SLEE nodes, a unique SLEE identifier (SLEE ID) is assigned to each SLEE node to identify the SLEE node. Each network protocol stack is also assigned a unique identifier (ID).

All communication entities that need to receive the MOM message need to be assigned a unique address identifier, that is, a combination of a unique pair of MID and PID, as the destination address for the sender to send the MOM message. For distributed SLEE nodes, the communication entity that needs to allocate MID and PID is the ED of each SLEE node. In addition, all network protocol stacks that need to communicate need to allocate MID and PID.

In the distributed SLEE structure, each SLEE node will be configured with an initialization configuration file, which contains the SLEE ID assigned to the SLEE node and the MID and PID of its ED, and the SLEE IDs of all other SLEE nodes and their corresponding The MID and PID of the corresponding ED, the IDs assigned to all network protocol stacks and their MIDs and PIDs.

When each SLEE node starts the initialization process, it will read the initialization configuration file, read the SLEE ID of its own SLEE node, the MID and PID of its ED into the memory, and initialize the communication entity for sending and receiving MOM messages, such as configuring some initial parameters, etc. , and bind the MID and PID of the communication entity to the MOM communication entity, so that the communication entity can receive the MOM message. In this way, communicating entities are able to receive MOM messages sent from other communicating entities. At the same time, the SLEE initialization process also reads the SLEE IDs of other SLEE nodes, the MID and PID of the corresponding ED, the IDs of all network protocol stacks, and the MID and PID allocated to all network protocol stacks into the memory, and respectively establishes the SLEE ID The corresponding relationship between the MID and PID of the ED of the SLEE, the ID of the network protocol stack, and the MID and PID allocated thereto. In this way, the address of the MOM that communicates with the corresponding communication entity can be found through the ID.

The process of establishing a business session (Session) starts when the ED of a SLEE node on the SLEE platform receives a business session initial event message sent by the network protocol stack, and the business session initial event message carries the service type identifier. The network protocol stack randomly sends the service session initiation event message to any SLEE node.

After the SLEE node receives the service session initial event message, if the service type is deployed on the SLEE node that receives the service session initial event message, the following processing procedure is the same as that of the service session initial event establishment in the non-distributed SLEE structure described above The process is basically the same, and the business instance needs to be set as the main business instance of the current business session.

If the service type is not deployed on the SLEE node where the ED that receives the service session initial event message is located, each SLEE node maintains a SLEE ID relationship table of the SLEE node where each service type is located when all service types are deployed. The SLEE node will find the SLEE ID of the SLEE node where the current service type is located, and find the MOM address of its ED through the SLEE ID of the SLEE node, that is, the MID and PID of the ED. The ED of the SLEE node that receives the service session initial event message constructs a MOM message for communication between EDs, encapsulates the service session initial event message in the MOM message, and sends it to the ED of the target SLEE node where the service type is deployed. After the ED of the target SLEE node receives the service session initiation event message, its processing process is basically the same as the above-mentioned process.

Session ID includes SLEE ID and Call ID, where SLEE ID is the identification of the SLEE node that initiates the business session process, and Call ID is the identification of this call (distributed call between this business instance), which is used to organize data and realize business session process.

Instance ID includes SLEE ID, Self ID and ServiceKey. SLEE ID is the identification of the SLEE node running the business instance, Self ID is the identification of different business instances, and ServiceKey is the identification of the business type to which the business instance belongs.

If it is an event in the process of a business session, the ED judges whether the service type is deployed on the SLEE node where it is located according to the Session ID carried in the event message of the business session process. If so, the ED finds it in the service type instance pool through the service manager The corresponding active service instance; otherwise, the SLEE node where the ED is located finds the MOM address of the ED according to the SLEE ID contained in the Session ID, that is, the MID and PID of the ED. The ED of the SLEE node that receives the service session process event message constructs a MOM message for communication between EDs, encapsulates the service session process event message in the MOM message, and sends it to the ED of the target SLEE node where the service type is deployed. After the ED of the target SLEE node receives the service session process event message, its processing process is basically the same as the above-mentioned process.

When a service instance communicates with service instances of other service types, the service instance sends a service instance event message to the ED. ED judges whether the service type is deployed on the SLEE node where it is based on the Session ID carried in the service instance event message. If so, ED sends the event processing information to the corresponding service instance according to the service instance event message, so that the service instance Process the corresponding event; otherwise, the SLEE node where the ED is located finds the MOM address of the ED according to the SLEE ID contained in the Session ID, that is, the MID and PID of the ED. The ED of the SLEE node that receives the service instance event message constructs a MOM message for inter-ED communication, encapsulates the service instance event message in the MOM message, and sends it to the ED of the target SLEE node where the service type is deployed. After the ED of the target SLEE node receives the service instance event message, its processing procedure is basically the same as that described above.

Issues to be considered in implementing distributed SLEE include: shielding physical locations between services, shielding physical locations of services by network protocol stacks, and data sharing.

The physical location shielding between services means that when service A calls service B, service A does not need to know the specific physical location of service B, and only needs to use the same interface for mutual calls.

The shielding of the physical location of the service by the network protocol stack means that the network protocol stack starts a service instance by sending a service session initial event message to the SLEE node. The network protocol stack does not need to know the specific physical location of the service instance, but only needs to send the service session initial event message to To any SLEE node, the ED forwards the service session initial event message.

In addition to the main business instance, a business session process can contain multiple business instances of other business types. In the process of a business session, business instances may call each other, which is the distributed call between business instances. Distributed invocation among service instances is realized by forwarding MOM messages through EDs of distributed SLEE nodes. The calling service instance sends the service instance event message to the ED of the node where it is located. The ED sends the event processing information to the target service instance according to the service instance event message, so that the service instance performs related operations.

The SLEE node where the calling business instance is located allocates an Event ID for this calling, and the called business instance learns about related operations through the Event ID. At the front end of the message, there are Event ID, Session ID, the business instance ID of the calling party (Source Instance ID) and the ID of the called target business instance (Destination Instance ID). Source Instance ID is the ID of the business instance that initiates the call between business instances, and Destination Instance ID is the ID of the target business instance being called. Both Session ID and Instance ID are serializable classes that can be transmitted on the network.

When the ED handles the distributed call between business instances, and when the ED processes the MOM message of the distributed call between the business instances according to the SLEE ID in the Destination Instance ID, if the SLEE ID is its own SLEE ID, the called business instance will run on the On the SLEE node, the ED only needs to find the corresponding service instance and call the event processing interface of the service instance; if the SLEEID is not its own SLEE ID, the ED can find the corresponding service instance according to the initialization configuration file of the SLEE node where it is located. The SLEE ID of the SLEE node. The ED constructs a MOM message for communication between EDs, encapsulates the distributed invocation message between service instances in the MOM message, and sends the synchronous MOM message to the ED of the target SLEE ID to realize the distributed invocation among service instances. After the ED of the target SLEE ID receives the MOM message, the processing steps are basically the same as the above-mentioned service instance calling process between the same SLEE nodes.

A business session (call) process will generate a large amount of data, which is collectively referred to as business session context (Session Context) data, which is used to centrally store data related to attributes and parameters in the business session process, and the business instances participating in the business session will Access and modify these SessionContext data. Since business instances will frequently access and modify Session Context data, in order to ensure access efficiency and the security and integrity of Session Context data, Session Context data is stored and managed in a centralized manner. The storage location is the SLEE node running by the main service instance (Main Instance) that initiates a business session process. For multiple business instances participating in a business session, they can be distributed in physical locations, so the way they access the corresponding Session Context data is also distributed. However, the physical location of the Session Context data should be transparent to all business instances. That is to say, the interface for the business instance to access the Session Context data should be unified, that is, the physical location of the Session Context data should be the same for the business instance. Shielded, in order to realize the sharing of Session Context data.

For a large amount of Session Context data generated during a business session, the business instances participating in the business session will frequently access and modify it during the business session. In order to ensure the integrity and security of the data, these Session Context data are managed and stored in a centralized manner. The storage location is the SLEE node running on the main business instance that initiates a business session process, that is, the SLEE contained in the Session ID The SLEE node identified by the ID. Because multiple business instances participating in a business session process may be distributed on different SLEE nodes, a unified interface for accessing Session Context data must be provided for all business instances, so that the storage location of Session Context data is the same when the business instance accesses Session Context data blocked.

When a business instance accesses Session Context data, the business instance will be located on a different SLEE node from the main business instance, so the business instance located on the same SLEE node as the main business instance is called a local service instance, correspondingly, the same as the main business instance Service instances located on different SLEE nodes are called remote service instances.

Figure 5 is a schematic diagram of distributed SLEE Session Context data sharing, as shown in Figure 5, if the business instance A501 is the main business instance, then the Session Context data is stored in the distributed SLEE node A401 where the main business instance 501 is located. Service instance A501 and service instance B502 are different service instances belonging to the same session process. A unified Session Context data access interface (DataAccess) 503 is provided for all business instances to access SessionContext data. The data access interface 503 defines all operations for business instances to access Session Context data, such as access and modification. The data access interface 503 provides two different classes to realize data access, one is a local data access tool (LocalDataAccessImp1) class 504 for accessing local Session Context data, and the other is a remote data access tool (LocalDataAccessImp1) for accessing remote SessionContext data RemoteDataAccessImp1) class 505. SLEE node A401 also needs to realize a remote data agent (RemoteDataAgent) class 506, this class visits the agent of the Session Context data of SLEE node A 401 as remote service instance B502 on the SLEE node B 402, and it can receive the synchronization of remote data access MOM message, and parse the MOM message, and convert each remote data access MOM message into a different call. Only the LocalDataAccessImp1 class 504 can access the local Session Context data center, so the RemoteDataAgent class 506 will generate a reference to the LocalDataAccessImp1 class 508 in the initialization process, access the local Session Context data by calling the operation in the corresponding LocalDataAccessImp1 class 508, and synchronize the MOM message Return the result to the remote business instance that initiated the SessionContext data access call.

The RemoteDataAgent class in each SLEE node needs to receive MOM messages, so it is also necessary to assign a MOM address to the RemoteDataAgent class, that is, a pair of unique MID and PID. The MOM address is also configured in the initial configuration file during the SLEE node initialization process, and the MOM address of each RemoteDataAgent class is associated with the SLEE ID to which it belongs. The SLEE node reads and stores the MOM address of the RemoteDataAgent class of all SLEE nodes from the initial configuration file when starting.

The implementation of the LocalDataAccessImp1 class can directly access the Session Context data center by calling the local API.

For the realization of the RemoteDataAgent class, different MOM messages can be constructed for each data access interface that needs to be implemented, and the operation type and the parameters carried can be encapsulated into the MOM message. The RemoteDataAccessImp1 class can know the Session ID of the business instance according to the Instance ID of the business instance calling the data access interface. Through the Session ID, the SLEE ID of the SLEE node where the SessionContext data is located can be known, and the MOM of the RemoteDataAgent class can be known through the SLEE ID of the SLEE node. Address, send a synchronous MOM message to the MOM address, and the returned result of parsing the synchronous MOM message is the result obtained by accessing the Session Context data this time.

During the initialization process, associate DataAccess with the corresponding class. If the DataAccess is on the same SLEE node as the main business instance, then associate DataAccess with the local class; if the DataAccess is not on the same SLEE node as the main business instance, then Map DataAccess to the remote class. DataAccess provides a unified interface for business instances to access Session Context data, making the storage location of Session Context data transparent to the business instances accessing it.

When the local business instance accesses the Session Context data, because DataAccess corresponds to the local class, DataAccess automatically calls the LocalDataAccessImp1 class, and the LocalDataAccessImp1 class accesses the Session Context data and performs related operations on it, and then returns the operation result to the local business instance.

When a remote business instance accesses Session Context data, because DataAccess corresponds to the remote class, DataAccess automatically invokes the RemoteDataAccessImp1 class, and the RemoteDataAccessImp1 class sends a synchronous MOM message to the RemoteDataAgent class of the SLEE node where the main business instance is located according to the initialization configuration file. In the MOM message Carry the operation type of the SessionContext data and the parameters corresponding to the operation type. After the RemoteDataAgent class receives the MOM message, it parses the MOM message, and then calls the LocalDataAccessImp1 class generated during its initialization process. The LocalDataAccessImp1 class accesses the Session Context data and It performs related operations, and then returns the operation results to the RemoteDataAgent class. The RemoteDataAgent class returns the operation results to the RemoteDataAccessImp1 class of the SLEE node where the remote business instance is located through a synchronous MOM message. Finally, the RemoteDataAccessImp1 class returns the operation results to the remote business instance.

In a word, the above descriptions are only preferred embodiments of the present invention, and are not intended to limit the protection scope of the present invention.

Claims (11)

1. A method for implementing a business logic operating environment, characterized in that, initializing the communication entity sending and receiving the message middleware event message, and distributing a unique message middleware address to all communication entities that need to receive the message middleware event message, the method Also includes the following steps: S. Execute the initialization process for reading the initialization configuration file including the message middleware address of the event dispatcher; A. The communication entity uses the acquired message middleware address of the event scheduler to send the message middleware event message to the event scheduler; B. The event scheduler acquires the corresponding service instance in the service type pool according to the received message middleware event message, and controls the acquired service instance to complete the corresponding operation. 2. The method according to claim 1, characterized in that: the communication entity is a network protocol stack; Said step A is that the network protocol stack utilizes the message middleware address of the acquired event scheduler to send the message middleware business session initial event message to the event scheduler; The step B is that the event scheduler obtains an idle service instance in the service type pool according to the received initial event message of the message middleware service session, and activates the service instance, and the business logic operating environment node allocates services for the service instance Instance identification, and then control the obtained business instance to complete the corresponding operation. 3. The method according to claim 1, characterized in that: the communication entity is a network protocol stack; The step A is that the network protocol stack uses the message middleware address of the acquired event scheduler to send the message middleware business session process event message to the event scheduler; The step B is that the event scheduler obtains the corresponding activated service instance in the service type pool according to the received message middleware service session process event message, and controls the obtained service instance to complete the corresponding operation. 4. The method according to claim 1, characterized in that: the communication entity is a business instance; Said step A is that the service instance sends a message middleware business instance event message to the event scheduler by using the message middleware address of the acquired event scheduler; Said step B is that the event scheduler obtains the corresponding target service instance in the service type pool according to the received message middleware service instance event message, and the event scheduler sends event processing information to the target service instance according to the service instance event message, and controls The target business instance completes the corresponding operation. 5. The method according to claim 1, characterized in that: for the distributed business logic operating environment structure, the step B further comprises: after the event scheduler receives the event message, it judges whether the corresponding business instance is located in the On the business logic running environment node, if yes, obtain the corresponding business instance from the business type pool on the business logic running environment node; otherwise, the business logic running environment node where the event scheduler is located finds the corresponding service instance according to the initialization configuration file The target business logic running environment node where the target business instance is located, and obtains the message middleware address of the target event scheduler on the target business logic running environment node, and the event scheduler sends a message in the middleware format to the target event scheduler, and the target event The scheduler obtains the corresponding business instance. 6. The method according to claim 2, characterized in that, for the distributed business logic operating environment structure, the step B further comprises: setting the business instance as the main business instance at the logical operating environment node where the acquired business instance is located . 7. The method according to claim 6, characterized in that, for the distributed business logic operating environment structure, the business instance located at the same logical operating environment node as the main business instance is set as a local business instance; The method further comprises the steps of: D. The local business instance calls the data access interface; E. The data access interface accesses the business session context data by calling the local data access tool, and operates the business session context data; F. The local data access tool returns the operation result on the business session context data to the local business instance. 8. The method of claim 7, wherein: The business session context data is stored in the business logic running environment node where the main business instance is located. 9. The method according to claim 6, characterized in that, for the distributed business logic operating environment structure, the service instance located at a different logical operating environment node from the main service instance is set as a remote service instance; The method further comprises the steps of: D1. The remote business instance invokes the data access interface; E1. The data access interface invokes the remote data access tool, and the remote data access tool sends a message middleware message to the remote data agent of the business logic operating environment node where the main business instance is located. After receiving the message middleware message, the remote data agent calls the local data access Tools access business session context data and operate on business session context data; F1. The local data access tool returns the operation result of the business session context data to the remote data proxy, and the remote data proxy returns the operation result of the business session context data to the remote data access tool, and the remote data The access tool returns the operation result on the context data of the business session to the remote business instance. 10. The method according to claim 9, characterized in that the local data access tool and the remote data access tool are generated during initialization. 11. The method according to claim 2, wherein, for the structure of the distributed business logic running environment, the step A further comprises: the network protocol stack sends the service session initial event message.

Images