SYSTEM AND METHOD FOR PROVIDING A PRODUCTION UPGRADE OF COMPONENTS WITHIN A MULTIPROTOCOL GATEWAY

• US 20100330971A1
• Filed: 06/26/2009
• Published: 12/30/2010
• Est. Priority Date: 06/26/2009
• Status: Active Grant

• Current Assignee: Oracle International Corporation (Oracle Corporation)
• Original Assignee: Oracle International Corporation (Oracle Corporation)
• Inventors: Rajasekar, Sharath, Jansson, Daniel, Selitser, Boris, Modin, Niklas
• Granted Patent: US 8,863,111 B2
• Time in Patent Office: Days
• US Class Current: 455/418
• CPC Class Codes: H04L 41/5041 characterised by the time relationship between creation and deployment of a service
• CPC Class Codes: H04L 67/34 involving the movement of software or configuration parameters network booting or remote initial program loading [RIPL] G06F9/4416

Abstract

A production upgrade is described for a multiprotocol gateway. This upgrade allows various modules and components within the gateway to be upgraded independently without impacting traffic flow in the gateway. The upgrade can be performed by deploying a new version of the module alongside an older version of the same module. New client requests can then be directed to the new version, while requests requiring the older module can be continued to be serviced by the prior version. A distinction is made between stateless and stateful conversation during the upgrade of various components. For stateful conversations, request traffic can be versioned according to the session to which each request belongs. A highly available state storage scheme allows new versions of the module to consume state information used by the older versions. For stateless conversations, all new requests can be immediately routed to the new version of the module.

Claims

1. A method for providing a production upgrade of components in a multiprotocol gateway, said method comprising:

receiving a first request to the multiprotocol gateway;

directing the first request to a component within the gateway;

updating the component by deploying a new version of said component within the gateway;

receiving a second request to the gateway, said second request received after the component has been updated;

routing the second request to the new version of said component and continuing to receive new traffic to the gateway uninterrupted by deployment of the new version of said component.

2. The method of claim 1, wherein updating the component is performed without impacting traffic flow in the gateway, such that the production upgrade is non-visible to external entities and clients interacting with the multi-protocol gateway.

3. The method of claim 1, wherein routing the second request to the new version of said component further includes:

determining whether the second request is associated with an existing session; and

routing the second request to the component if said second request is associated with the existing session, otherwise routing the second request to the new version of the component.

4. The method of claim 1, further comprising:

receiving one or more new requests after the component has been updated;

determining whether the new requests are session-based stateful interactions or a stateless interactions; and

routing the new requests directly to the new version of the component if the new requests are stateless interactions;

otherwise

routing the new requests associated with existing sessions to a previous version of said component and routing the new requests associated with new sessions to the new version of said component.

5. The method of claim 1, further comprising:

retiring a previous version of said component once said previous version of said component has finished processing in-progress traffic.

6. The method of claim 1, wherein said multiprotocol gateway further includes:

a highly available storage scheme that defines the structure of state associated with said requests, wherein the highly available storage scheme includes multiple versions to enable multiple components to access the same state repository.

7. The method of claim 5, wherein the multiple versions of said highly available storage scheme enable state that was relevant to a previous version of said component to be consumed by said new version.

8. The method of claim 1, wherein said multiprotocol gateway further includes:

at least two versions of a plug-in used to translate communications, wherein a single active version of the plug-in is accepting traffic and wherein the active version transitions to administrative state during the update of the component, such that the plug-in does not process traffic while being in the administrative state.

9. The method of claim 1, wherein the component includes an exposure service that translates said request from one protocol to a different protocol.

10. The method of claim 1, wherein said multiprotocol gateway further includes:

an access tier; and

a network tier;

wherein said access tier is upgraded while the network tier is sending northbound traffic and said network tier is upgraded while the access tier is sending southbound traffic; and

wherein the access tier receives traffic from a first set of external clients and the network tier receives traffic from a second set of external clients in the telecommunications network.

11. The method of claim 1, wherein the processing component is packaged as an individual file that can be upgraded independently from other processing components within the gateway.

21. The system of claim 1, further comprising:

an access tier; and

a network tier;

wherein said access tier is upgraded while the network tier is sending northbound traffic and said network tier is upgraded while the access tier is sending southbound traffic.

12. A system for providing a production upgrade in a multiprotocol gateway, said system comprising:

a first version of a component deployed to process telecommunications requests in the gateway; and

a second version of the component deployed after said first version, said second version being contemporaneous for at least a period of time with said first version, wherein the second version includes modified functionality with respect to said first version;

wherein, once deployed, the second version takes over processing one or more new telecommunication requests from said first version such that traffic is continued to be received to the gateway uninterrupted.

13. The system of claim 12, wherein the first version of the component is upgraded to the second version of the component without impacting traffic flow in the gateway, such that the production upgrade is non visible to external entities and clients interacting with the multi-protocol gateway

14. The system of claim 12, wherein the second version taking over processing the new telecommunication requests further includes:

determining whether a request is associated with an existing session; and

routing the second request to the first version if said second request is associated with the existing session, otherwise routing the request to the second version of the component.

15. The system of claim 12, wherein the second version taking over processing the new telecommunication requests further includes:

receiving one or more new requests after the first version of the component has been updated;

determining whether the new requests are session-based stateful interactions or a stateless interactions; and

routing the new requests directly to the second version of the component if the new requests are stateless interactions;

otherwise

routing the new requests associated with existing sessions to the first version of said component and routing the new requests associated with new sessions to the second version of said component.

16. The system of claim 12, wherein the first version of the component is retired once said first version has finished processing in-flight traffic.

17. The system of claim 12, further comprising:

a highly available storage scheme that defines the structure of state associated with said requests, wherein the highly available storage scheme includes multiple versions to enable multiple components to access the same state repository.

18. The system of claim 17, wherein the multiple versions of said highly available storage scheme enable state that was relevant to the first version of said component to be consumed by said second version.

19. The system of claim 12, further comprising:

at least two versions of a plug-in used to translate communications, wherein a single active version of the plug-in is accepting traffic and wherein the active version transitions to administrative state during the update of the component.

20. The system of claim 12, wherein the component is an exposure service that translates said request from one protocol to a different protocol.

22. A computer-readable medium carrying one or more sequences of instructions for providing production upgrades in a telecommunication processing environment, which instructions, when executed by one or more processors, cause the one or more processors to carry out the steps of:

receiving a first request to the multiprotocol gateway;

directing the first request to a component within the gateway;

updating the component by deploying a new version of said component within the gateway;

receiving a second request to the gateway, said second request received after the component has been updated;

routing the second request to the new version of said component and continuing to receive new traffic to the gateway uninterrupted by deployment of the new version of said component.