CN101207517B - Method for reliability maintenance of distributed enterprise service bus node - Google Patents
Method for reliability maintenance of distributed enterprise service bus node Download PDFInfo
- Publication number
- CN101207517B CN101207517B CN2007101647540A CN200710164754A CN101207517B CN 101207517 B CN101207517 B CN 101207517B CN 2007101647540 A CN2007101647540 A CN 2007101647540A CN 200710164754 A CN200710164754 A CN 200710164754A CN 101207517 B CN101207517 B CN 101207517B
- Authority
- CN
- China
- Prior art keywords
- node
- nodes
- information
- bus
- service
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Abstract
The invention relates to a method which can maintain the reliability of the service bus nodes of distributed enterprises. The method comprises the following steps: according to the node functions of the service bus nodes and the stored environment information, the nodes can be divided into four types: standard nodes, a host node, candidate nodes and proxy nodes; the extensible event mechanism is defined, when discovering that the environment changes in the service bus nodes, the nodes construct the corresponding event and inform the host node, so as to enable the information to be transmittedin the whole bus, and the important information in the bus can be copied through the candidate nodes in real time. The invention has the advantages that the normal operation of the bus can be ensuredto the maximum extent under the condition that any node in the enterprise service bus fails, thereby reducing the influence to an enterprise information system; besides, after being recovered, the failure node reenters the bus environment and operates smoothly. A relative centralized information register center, namely the host node, is established; the event mechanism with the uniform interface is adopted.
Description
Technical field
The present invention relates to the method for information synchronization between method that distributed enterprise service bus node collapse recovers and node corresponding, mainly is a kind of method for reliability maintenance of distributed enterprise service bus node.
Background technology
" ESB " is to construct the essential elements that SOA (Service Oriented Architecture, Service-Oriented Architecture Based) is the enterprise information system on basis as the connection maincenter of application system.The definition of ESB can simply be interpreted as: realize and support one group of architecture of SOA by middleware Technology, support service, message and mutual based on incident in the isomerous environment, and have suitable service class and manageability.Realize the quick access of application system by ESB, and by more senior incident, flow processing ability, can be good at enterprise information system and practical business are coordinated, under the condition that guarantees original investment, realize more flexible and quick enterprise information system transformation.
The implementation pattern of ESB has varied, but mainly comprises two big classes: simple central radiant type ESB and full distributed ESB.Central authorities' radiation mode all is registered to all services in the unified central authorities " hub ", promptly all service messages all need through a central server, though this mode subordinate and management are than being easier to, but shortcoming is also apparent, the performance of enterprise information system will be limited by central server message transfer ability, when central server breaks down, the function of whole enterprise information system will be subjected to very large influence.Full distributed ESB is then different, it does not have tangible central server, bus is disposed with distributed framework in enterprise information system, function such as each bus node all comprises complete access, route, call, no longer there is a concentrated bottleneck, can very effectively utilize the hardware resource and the network bandwidth of enterprise, under the situation that individual nodes lost efficacy, the loss function of enterprise information system is less even be zero.
The node of distributed enterprise service bus often with the service operation of its access in same physical computer, its operation may be at any time owing to the fault of hardware or software stops, how to guarantee under the situation of a certain node failure, other nodes still can true(-)running, after restarting, failure node how to guarantee simultaneously its accurate synchronization existing information, the loss function of enterprise information system in failure process is reduced to minimum, problem to be solved by this invention just.
Summary of the invention
The present invention will solve the existing defective of above-mentioned technology, and a kind of method for reliability maintenance of distributed enterprise service bus node is provided.
The technical solution adopted for the present invention to solve the technical problems: this method for reliability maintenance of distributed enterprise service bus node, step is as follows:
1) according to the environmental information of nodal function in the ESB and storage, it is divided into four types, standard nodes, host node, both candidate nodes and agent node:
Standard nodes: have the standard feature of ESB, comprise that service inserts, the message route;
Host node: except that the function that has standard nodes, also the environment to whole ESB monitors, to the adding of node with remove and control, stores all important services and environmental correclation information, and unified management is carried out in the access of service;
Both candidate nodes:, be used to back up all environmental informations in the bus by the standard nodes that set algorithm is selected;
Agent node: under the situation of the inefficacy of host node, temporarily carry out the function of host node; After host node recovers, the information of changing is passed to host node;
2), define extendible case mechanism, during environmental change, the joint structure events corresponding is also notified host node, makes this information at whole bus internal communication in finding ESB;
3), in real time by important information in the both candidate nodes backup bus; When host node lost efficacy, form the agent node of a telotism according to the backup information of both candidate nodes, and, be the service search alternative service in the failure node by the message routing mechanism; When host node recovers, search agent node according to the communication modes of node in the persistent storage, and carry out information synchronization with it; After finishing smoothly, host node will make ESB return to normal operating condition by all nodes of event notice.
Wherein environmental change comprises the withdrawing from of the adding of new service, original service, node failure or the like in the ESB.
Wherein important information comprises the address of each node communication modes, each service and details or the like in the both candidate nodes backup bus.
The effect that the present invention is useful is:
1, can under the situation that the ESB arbitrary node lost efficacy, guarantee the normal operation of bus to greatest extent, reduce its influence enterprise information system; And can after recovering, failure node insert bus environment and trouble-free operation again.
2, set up information registration center one host node of concentrating relatively, can make things convenient for enterprise that its information system all service in inside is managed concentratedly on the one hand, on the other hand owing to the transmission of message and without host node, thereby can not cause structural performance bottleneck, relatively be fit to the metastable running environment of enterprise, between Service Management and running efficiency of system, find a balance point;
3, owing to adopted the case mechanism of unified interface, so the framework of bus is more flexible, and enterprise can pass through customized event, and functions such as more management, audit, charging are provided for bus itself, the application integration of more effective realization enterprise.
Description of drawings
Fig. 1 flow process classification chart;
The synchronous flow chart of Fig. 2 information on services;
Fig. 3 standard nodes starts flow chart;
Fig. 4 standard nodes closing flow path figure;
Fig. 5 host node normally starts flow chart;
The normal closing flow path figure of Fig. 6 host node;
Information synchronization flow chart after Fig. 7 standard nodes lost efficacy;
Information synchronization flow chart after Fig. 8 host node lost efficacy;
Information synchronization figure when Fig. 9 host node recovers;
Embodiment
The invention will be described further below in conjunction with drawings and Examples:
Extensible event mechanism
JTang Synergy is that a distributed enterprise service bus of following the JBI standard is realized, it has comprised the extensible event mechanism of a cover based on dynamic proxy, and this case mechanism mainly is made up of two parts: incident, incident distribution mechanisms and monitor.
Incident comprises event type, event report person (whom this incident constructed by), incident source (main body that information changes) and the relevant information of other incidents own in order to describe the information change in the current system.But incident all is serializings, that is to say that can be converted into byte stream transmits by network.In JTang Synergy, incident mainly is divided into following three classes: Service events, in order to the access of describing service, withdraw from etc.; Node Events, in order to the startup of description standard node, close, inefficacy etc.; Environment event, in order to the startup of describing host node, close, the startup of recovery and agent node etc.
Monitor then in order to monitor the incident of particular type, by the callback method of realizing defining, is made respective handling to this incident.Monitor is to preserve with the structure of Hash table and chained list at intra-node, node is after receiving certain incident, at first find the monitor chained list of the type incident according to Hash table, be parameter with this incident then, call the callback method of all correlation type monitors one by one, realize processing this incident.
The incident distribution mechanisms comprises two parts transmission and distribution.The transmission of incident realizes that by the mode of dynamic proxy dynamic proxy is a basic function among the JDK, can generate special agency for specific object, in order to when allocating object directly can not reach, calls transmission with return value by acting on behalf of implementation method.In JTang Synergy, each node all can produce a corresponding agency, and this is acted on behalf of bottom and realizes by the RMI far call, so the far call communications protocol of incident by Java itself is delivered to the destination.The distribution of incident, the flow direction of incident is specific in JTang Synergy, under the situation that host node (or agent node) exists, the direct transmission of incident is not allowed between standard nodes.If certain node need upgrade environmental information, must notify host node (or agent node) earlier, be distributed to other nodes of bus inside then by host node (or agent node).This ways of distribution can prevent the environmental information confusion of inner each node of bus, also can clash when inconsistent at the node cycle environment information simultaneously, is undertaken synchronously and coordinates by host node.
In addition, the normal operation of case mechanism also has relation with the state of ESB.Briefly, when bus is unusual (comprise that node is synchronous first, agent node starts, migration, and host node is closed), bus state inquiry, if bus state is " READ_WRITE " time, this incident is passed to host node, otherwise, service inserts and can wait for 1 second, bus state inquiry once more is if 5 inquiry back bus states still be " READ_ONLY ", then tell customer incident to handle and fail by control desk output.
The classification of Synergy synchronous regime
Synergy is based upon on the basis of event system, and the flow process that the transmission by incident and each node are taked at different event and the current different conditions of living in of Synergy realizes that environmental information synchronously and fault recovery.Therefore, we can mainly contain two states according to difference: the information synchronization after information synchronization the when information synchronization when normally moving, node failure and host node recover.
Information synchronization during normal the operation is meant when all nodes all normally move, the process that the incident of service access (or withdrawing from) node access (or withdrawing from) is transmitted in all nodes, mainly comprise 5 flow processs, be respectively: information on services is synchronous, standard nodes starts, standard nodes is closed, host node normally starts, host node is normally closed.
Information synchronization during node failure is meant that node occurs when unusual, and required incident affirmation, transmission and the synchronizing process of carrying out of variant type node mainly comprises standard nodes back information synchronization, host node two flow processs of back information synchronization that lost efficacy that lost efficacy.
Information synchronization when host node recovers returns to the required measure of taking of normal running environment after then being meant the unexpected inefficacy of host node.The time that this state exists is very of short duration, therefore only comprises a flow process, information synchronization when promptly host node is replied.
Concrete classification can will divide state to elaborate the concrete steps of each flow process referring to Fig. 1 below.
Information synchronization during normal the operation
Information synchronization under this state mainly comprises three aspects: information on services registration and cancellation, standard nodes start and close, host node starts and close.
Fig. 2 information on services is meant synchronously when service inserts or withdraws from node, by Service events with this information in whole bus internal delivery.Concrete steps can be described as:
When node was found new service access (or existing service is withdrawed from), the joint structure service inserted (or service is withdrawed from) incident.
Host node verifies at first whether corresponding information on services conflicts with existing information after receiving this incident, whether the service that whether address information of for example new access service unique, name compliant whether, need to nullify exists etc.If be proved to be successful, then in the information on services registration table, add (or cancellation) this service, and this incident is put into pending list of thing, the waiting event dispatch thread is distributed; Otherwise, notice access node event handling failure.
After this incident was distributed to each node, the Service events monitor of each node was responsible for responding this incident, will register (or cancellation) in the corresponding information on services registration table.
The standard nodes information synchronization is meant when standard nodes starts or closes, by Node Events with this information in whole bus internal delivery.
The concrete steps that Fig. 3 standard nodes starts can be described as:
When new standard nodes starts, at first according to configuration file medium-long range RMI registry information, the agency who searches host node.Then, the structure node corresponding starts incident, comprises that this node name claims, IP address, agency and other relevant informations.
After host node is received this incident, for this node produces a UID (Universal ID, unique identifier), this incident is put into pending list of thing, the waiting event dispatch thread is distributed.Simultaneously, host node is put into last position of node listing with newly added node, and this tabulation is carried out serializing to JTang Synergy working directory " succlist " in the file.
The host node bus state is set to " READ_ONLY ", and web services registry passed to this standard nodes, and after finishing, bus state is set at last " READ_WRITE ".
If this node is the unique node except that host node, then this node is set to both candidate nodes.
After this incident was distributed to each node, the Node Events monitor of each node was responsible for responding this incident, and node corresponding information is registered.If both candidate nodes is received this incident, then newly added node is put into last position of node listing, simultaneously this tabulation is carried out serializing to JTang Synergy working directory " succlist " in the file.
The concrete steps that Fig. 4 standard nodes is closed can be described as:
When the existing standard node was closed, this joint structure node corresponding close event comprised this node UID and other relevant informations.
After host node is received this incident, in the information on services registration table, nullify the service that all insert by this node, and from node listing with this knot-removal, simultaneously this tabulation is carried out serializing to JTang Synergy working directory " succlist " in the file.If this node is a both candidate nodes, then select node listing first, with it as new both candidate nodes.
After this incident was distributed to each node, the Node Events monitor of each node was responsible for responding this incident, and all are nullified from the information on services registration table by the service that this node inserts.If both candidate nodes is received this incident, then also will with this node from node listing with this knot-removal, simultaneously this tabulation is carried out serializing to JTang Synergy working directory " succlist " in the file.
The host node information synchronization is meant when standard nodes starts or closes, by Node Events with this information in whole bus internal delivery.
When host node starts, at first in the judgment task catalogue " .running " whether file exist, this time start to recovering the collapse back if exist then judge, otherwise be normal startup.The normal concrete steps that start of Fig. 5 host node can be described as:
In working directory, search " succlist " file and " registry " file, if exist then information unserializing wherein, respectively as node listing and information on services registration table; Otherwise, create empty node listing and information on services registration table.
Check whether node communications all in the node listing is normal, withdraw from, then this node is removed from tabulation, and nullify the service that all insert by this node if find the node accident.After check finishing, with the node listing serializing to the working directory " succlist " file.
The structural environment incident notify other node host nodes to start, and the state of bus is set to " READ_WRITE ", make bus can serve information synchronization with node.
In working directory, create " .running " file.
The concrete steps that Fig. 6 host node is normally closed can be described as:
The state of bus is set to " READ_ONLY ", make bus can't serve information synchronization with node.
With the serializing of information on services registration table to the working directory " registry " in the file, with the node listing serializing to the working directory " succlist " file.
In the deletion working directory " .running " file.
The structural environment incident notifies other node host nodes to close.
Information synchronization behind the node failure
Node in the ESB often with service operation in same virtual machine or physical machine, therefore after the machine of delaying unusually took place machine, the also corresponding inefficacy of node need be revised synchronously existing bus message, to compensate the inefficacy of node.Information synchronization mainly comprises three aspects under this state: the node abnormality detection; Information synchronization after ordinary node lost efficacy; Information synchronization after host node lost efficacy.
Node abnormality detection among the JTang Synergy only illustrates in the node communication process and produces, and is not equivalent to this node failure, after needing further to confirm, could judge a certain node failure.The discovery of abnormal nodes may produce in two processes, and the one, the periodic polling thread, this thread starts with host node (or agent node), attempts connecting each node every 5 seconds, obtains the state information of node; The 2nd, in the incident distribution procedure.In above two processes,, judge that then a certain node is unusual if certain node of discovery connects overtime or is rejected.
The concrete steps of information synchronization can be described as after Fig. 7 standard nodes lost efficacy:
If abnormal nodes is a standard nodes, then the structure node anomalous event comprises the UID of abnormal nodes and the information such as UID of self, and this incident is sent to host node.
After host node is received the node failure incident, will attempt connecting abnormal nodes, if can then ignore this incident by normally associate; If can't get in touch this abnormal nodes, then judge this node failure.
Main predicate node was deleted failure node after losing efficacy from node listing, and the serializing node listing.
Nullify all services that insert by failure node in the service information table.
If failure node still is a both candidate nodes simultaneously, then classify primary node in the node listing as both candidate nodes.
This incident is distributed to other nodes.
Standard nodes is nullified all services that insert by this container in the service information table after receiving the node failure incident.
The concrete steps of information synchronization can be described as after Fig. 8 host node lost efficacy:
If abnormal nodes is a host node, then the structural environment incident comprises the UID of host node and the information such as UID of self, and this incident is sent to both candidate nodes.
After both candidate nodes is received the node failure incident, will attempt connecting host node, if can then ignore this incident by normally associate; If can't get in touch this abnormal nodes, judge that then host node lost efficacy.
After both candidate nodes judged that host node lost efficacy, bus state was set to " READ_ONLY ".
Nullify all services that insert by host node in the service information table.
Self is upgraded to agent node, and structural environment incident (host node inefficacy) is notified other nodes.
Be positioned at the deputy node of node listing and be set to both candidate nodes.
Bus state is set to " READ_WRITE ".
All the other nodes are nullified all services that insert by host node in the service information table after receiving the incident of certain node failure.
Information synchronization when host node recovers
The concrete steps of the information synchronization when Fig. 9 host node recovers can be described as:
When host node starts, in working directory, search " succlist " file, if exist then information unserializing wherein, as node listing; Otherwise, create empty node listing and information on services registration table, remaining step is according to 2～4 steps of normal startup.
Check whether node communications all in the node listing is normal, withdraw from, then this node is removed from tabulation if find the node accident.After check finishing, with the node listing serializing to the working directory " succlist " file.
Structural environment incident (UID, agency, IP address and other relevant informations that comprise host node) notify other node host nodes to start, and the state of bus is set to " READ_ONLY ", waiting agents node and host node are got in touch.
After agent node is received this environment event, get in touch by the agency and the host node of incident inside, and all environmental informations are returned to host node, then self is downgraded to both candidate nodes.
Host node obtains after the information on services registration table after the renewal, and the state of bus is set to " READ_WRITE ", and in working directory, create " .running " file.
The foregoing description is used for the present invention that explains, rather than limits the invention, and in the protection range of spirit of the present invention and claim, any modification and change to the present invention makes all fall into protection scope of the present invention.
Claims (3)
1. method for reliability maintenance of distributed enterprise service bus node, it is characterized in that: step is as follows:
1) according to the environmental information of nodal function in the ESB and storage, it is divided into four types, standard nodes, host node, both candidate nodes and agent node:
Standard nodes: have the standard feature of ESB, comprise that service inserts, the message route;
Host node: except that the function that has standard nodes, also the environment to whole ESB monitors, to the adding of node with remove and control, stores all important services and environmental correclation information, and unified management is carried out in the access of service;
Both candidate nodes:, be used to back up all environmental informations in the bus by the standard nodes that set algorithm is selected;
Agent node: under the situation of the inefficacy of host node, temporarily carry out the function of host node; After host node recovers, the information of changing is passed to host node;
2), define extendible case mechanism, during environmental change, the joint structure events corresponding is also notified host node, makes this incident at whole bus internal communication in finding ESB;
3), in real time by important information in the both candidate nodes backup bus; When host node lost efficacy, form the agent node of a telotism according to the backup information of both candidate nodes, and, be the service search alternative service in the failure node by the message routing mechanism; When host node recovers, search agent node according to the communication modes of node in the persistent storage, and carry out information synchronization with this agent node; After finishing smoothly, host node will make ESB return to normal operating condition by all nodes of event notice.
2. method for reliability maintenance of distributed enterprise service bus node according to claim 1 is characterized in that: environmental change comprises the withdrawing from of the adding of new service, original service, node failure in the ESB.
3. method for reliability maintenance of distributed enterprise service bus node according to claim 1 is characterized in that: important information comprises the address of each node communication modes, each service in the both candidate nodes backup bus.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2007101647540A CN101207517B (en) | 2007-12-12 | 2007-12-12 | Method for reliability maintenance of distributed enterprise service bus node |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN2007101647540A CN101207517B (en) | 2007-12-12 | 2007-12-12 | Method for reliability maintenance of distributed enterprise service bus node |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN101207517A CN101207517A (en) | 2008-06-25 |
| CN101207517B true CN101207517B (en) | 2010-06-02 |
Family
ID=39567420
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN2007101647540A Expired - Fee Related CN101207517B (en) | 2007-12-12 | 2007-12-12 | Method for reliability maintenance of distributed enterprise service bus node |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN101207517B (en) |
Families Citing this family (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101674255B (en) * | 2008-09-12 | 2012-01-11 | 北京东方通科技股份有限公司 | Method, server and system for forwarding messages of enterprise service bus |
| CN101800739B (en) * | 2010-01-15 | 2012-09-05 | 山东电力集团公司 | Service-oriented loose coupling information exchange system and method |
| CN102486725A (en) * | 2010-12-02 | 2012-06-06 | 上海可鲁系统软件有限公司 | Distributed platform and method for managing life cycle of functional module in platform |
| CN102571879B (en) * | 2010-12-27 | 2015-04-22 | 中国移动通信集团公司 | Burglary prevention method, system and equipment |
| CN102158361A (en) * | 2011-04-15 | 2011-08-17 | 浙江大学 | Equipment and method for maintaining reliability of distributed enterprise service bus intermediate flow |
| CN102868736B (en) * | 2012-08-30 | 2015-09-02 | 浪潮(北京)电子信息产业有限公司 | A kind of cloud computing Monitoring framework design basis ground motion method and cloud computing treatment facility |
| CN105657033B (en) * | 2016-02-02 | 2019-04-23 | 明博教育科技股份有限公司 | A kind of user-isolated resource access method and system |
| CN109167690A (en) * | 2018-09-25 | 2019-01-08 | 郑州云海信息技术有限公司 | A kind of restoration methods, device and the relevant device of the service of distributed system interior joint |
| CN111798118B (en) * | 2020-06-30 | 2023-08-18 | 中国工商银行股份有限公司 | Enterprise operation risk monitoring method and device |
| CN113157615B (en) * | 2021-02-02 | 2023-05-23 | 浙江大华技术股份有限公司 | Service bus communication method, electronic equipment and computer storage medium |
| CN113259445B (en) * | 2021-05-25 | 2021-11-09 | 广州市玄武无线科技股份有限公司 | Service management method and system in mixed cloud mode |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1949763A (en) * | 2005-10-11 | 2007-04-18 | 北京航空航天大学 | Shared message server system |
| CN101001189A (en) * | 2006-06-30 | 2007-07-18 | 华为技术有限公司 | System and method for lowering load of enterprise service bus |
-
2007
- 2007-12-12 CN CN2007101647540A patent/CN101207517B/en not_active Expired - Fee Related
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1949763A (en) * | 2005-10-11 | 2007-04-18 | 北京航空航天大学 | Shared message server system |
| CN101001189A (en) * | 2006-06-30 | 2007-07-18 | 华为技术有限公司 | System and method for lowering load of enterprise service bus |
Non-Patent Citations (2)
| Title |
|---|
| 李晓东等.基于企业服务总线的数据共享与交换平台.计算机工程32 21.2006,32(21),全文. |
| 李晓东等.基于企业服务总线的数据共享与交换平台.计算机工程32 21.2006,32(21),全文. * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN101207517A (en) | 2008-06-25 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN101207517B (en) | Method for reliability maintenance of distributed enterprise service bus node | |
| CN112000448B (en) | Application management method based on micro-service architecture | |
| US7539744B2 (en) | Network operating system for maintaining redundant master control blade management information | |
| US7844851B2 (en) | System and method for protecting against failure through geo-redundancy in a SIP server | |
| EP3138003B1 (en) | System and method for supporting a bypass-domain model and a proxy model and updating service information for across-domain messaging in a transactional middleware machine environment | |
| CN107465721B (en) | Global load balancing method and system based on double-active architecture and scheduling server | |
| US8756455B2 (en) | Synchronized failover for active-passive applications | |
| US8719780B2 (en) | Application server with a protocol-neutral programming model for developing telecommunications-based applications | |
| US20070198709A1 (en) | OPC server redirection manager | |
| EP2281240A1 (en) | Maintaining data integrity in data servers across data centers | |
| CN105630589A (en) | Distributed process scheduling system and process scheduling and execution method | |
| US9569224B2 (en) | System and method for adaptively integrating a database state notification service with a distributed transactional middleware machine | |
| CN110674192A (en) | Redis high-availability VIP (very important person) drifting method, terminal and storage medium | |
| CN112000444B (en) | Database transaction processing method and device, storage medium and electronic equipment | |
| WO1997049034A1 (en) | Job taking-over system | |
| CN101459690A (en) | Error tolerance method in wireless public object request proxy construction application | |
| CN107888491A (en) | HSB standby systems and the AC double hot standby methods based on two layers of networking VRRP agreements | |
| Curic et al. | SDN on ACIDs | |
| CN103001798A (en) | Application service management method, device and system | |
| Wagealla et al. | Error detection algorithm for agent-based distributed applications | |
| JP2002084279A (en) | System and method for managing snmp network | |
| KR20240027928A (en) | Worker node, and supporting method for distributed architecture | |
| Zhang et al. | Research and Design on Network Topology Management System of EJB Clustering | |
| Yadava | Distributed Transactions and Data-Distribution Strategies |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| C14 | Grant of patent or utility model | ||
| GR01 | Patent grant | ||
| CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20100602 Termination date: 20171212 |
|
| CF01 | Termination of patent right due to non-payment of annual fee |