System and method for a functional extensibility framework

Abstract

There is disclosed a framework which utilizes contemporaneous assembly of processing modules, strong typing, and integrated caching to assemble processing elements from different sources robustly and minimize system failures as software modules are upgraded.

Description

BACKGROUND OF THE INVENTION

Run-time loading of compiled code into a running program is supported within the Unix operating system (via the DLOPEN command) and within the Windows operating system (via dynamic linked libraries (DLLs)).

In general, a dynamic library interface allows a calling program to load and call function ‘Y’ from a library file ‘X’. The library file is opened either automatically by the program or via explicit library calls. Plug-ins use fixed data structures (for parameters) and database schema changes (to introduce new sets of data to be processed rather than simply populating data in schema) to support these calls. But plug-ins have no “data type” safety at either compile or run time on the data interchanged. Therefore, data can be freely misinterpreted. Some shared library implementations may support type checking by compiling stubs (a stub is a small program routine that substitutes for a longer program, possibly to be loaded later or that is located remotely) with the linked module. Here, however, the calling code needs to be recompiled to use a new function interface. This sometimes results in “bringing down” servers in a production environment for an indeterminate length of time.

Most interpreted script environments can support run-time loading of script code. Hybrid environments are also available where a script engine can load script code to interpret and execute, and also load compiled code registered as functions that can be invoked explicitly from the script language (e.g., the LUA script engine described at http://wwwluaorg).

In a conventional system, few safeguards can be provided to ensure that only code modules with the same application inputs and outputs can be assembled together. Such checking cannot, normally, be undertaken at run-time as new code modules and new application types are defined. Known partial solutions, such as JAVA, include the use of a strongly-typed object-oriented language with compile time checking. However, these solutions do not operate with a) simple procedural code development tools based on simple types; b) environments with different plug-in language, or c) new type definition, validation and invocation at runtime.

Finally, plug-ins also do not provide any integrated caching support.

SUMMARY OF THE INVENTION

When an event is presented to a system, embodiments of the invention (collectively, hereinafter, referred to as FEF for embodiments of a Functional Extensibility Framework) may be used to enhance processing for that event.

A data type in a programming language is a set of data with values having predefined characteristics. Examples of data types are: integer, floating point unit number, character, string, and pointer. Usually, a limited number of such data types come built into a language. The language usually specifies the range of values for a given data type, how the values are processed by the computer, and how they are stored. A data type is a programming language concept that is used to put a meaning on data that is stored in memory of a computer. Programming systems also allow programmers to extend simple types by defining user-defined types based on the fundamental types defined in the programming language.

With object-oriented programming, a programmer can create new data types to meet application needs. Such an exercise is known as “data abstraction” and the result is a new class of data. Such a class can draw upon the “built-in” data types such as integers and characters. For example, a class could be created that would abstract the characteristics of a purchase order. The “purchase order” data type would contain the more basic data types of integers and characters and could also include other objects defined by another class. The “purchase order” data type would have all of the inherent services that a programming language provided to its built-in data types.

Languages that leave little room for programmers to define their own data types are said to be strongly-typed languages. A strongly-typed programming language is one in which each type of data (such as integer, character, hexadecimal, packed decimal, and so forth) is predefined as part of the programming language and all constants or variables defined for a given program must be described with one of the data types. Certain operations may be allowable only with certain data types. The language compiler enforces data typing and use compliance. An advantage of strong data typing is that it imposes a rigorous set of rules on a programmer and thus guarantees a certain consistency of results. A disadvantage is that it prevents the programmer from inventing a data type not anticipated by the developers of the programming language and it limits how “creative” one can be in using a given data type.

A “basic data type” or “weak data type” may be a simple type such as string or integer. An attribute type may be a strong (specific, non-simple) type such as ‘DistanceMiles’ or ‘Cellular Base Station Location’. An attribute may comprise a specific instance of an attribute type (i.e., ‘Calling Base Station Location’ or ‘Called Base Station Location’). Data Extensions (DEA) comprise weakly-typed code modules imported/registered into the FEF, which have been associated with (strong) attribute types. A Data Extension Library may comprise a number of data extensions in one file or library. A Data Extension Language may be the run-time language or script environment required to run a particular data extension. Data Enhancements (enhanced code modules) comprise specific instances of a DEX with associated Attributes. An Attribute Set comprises a set of Attributes, together with references to the Data Enhancements used to determine those Attributes not provided as inputs.

Multiple processing functions may be registered in any form of computer-readable storage/memory including, but not limited to, a database or a cache, to form the appendages of the FEF. In a preferred embodiment, a database or other form of non-transient memory may be used to store the processing functions. These may be assembled into a processing (dependency) chain at run-time. The processing chain is not predetermined. Rather, an implicit execution chain based on defined input/output data dependencies may be created. Alternatively, the framework may call the functions, in turn, without using a chain, in response to requests for values of strong attribute types. Such requests may be received from the program originating the request or from the processing modules themselves.

The processing modules may be written in different compiled languages or use one or more interpreted script languages. The parameter passing and invocation of the different processing modules for different tasks may be orchestrated through run-time data structures. The complete system may be date aware so that different connections between functions can be invoked dependent on the dates associated with the data being processed.

The modules loaded into the FEF may be written by third parties. Customers may be given access to the FEF framework to build and register their own code modules using a developer kit or graphical user interface (GUI).

The Functional Extensibility Framework may include one or more of the following features:

A) Strong typing: Processing modules can be written using a number of different compiler or interpreter technologies with simple types (e.g., integer and string), but may be configured and assembled at run-time through strong typing. Configuration error and enhanced system configuration productivity may be ensured by providing user interfaces that display only those modules which have matching data types for a given context.

B) Set based processing: Processing models may be automatically assembled and invoked based on the required data values, rather than by providing explicit procedural instructions.

C) Integrated caching support: The FEF has an integrated caching model to allow data required by the processing modules to be effectively extracted, cached, and partitioned. This feature enables the processing modules used with the FEF to have high performance access to any data required by the processing module, via a generic cache infrastructure which keeps the data resident in memory. The model may also integrate output value caching and lazy evaluation to ensure that processing modules are only called once, and only if their output values are required to be used.

Lazy evaluation may delay the call to a function until it is known to be needed. Suppose, for example, one has three DEX: A, B, and C. If A and/or B are required to generate the output of extension C, then A and/or B will always be called if the output C is required. However if the output C is never used, then none of A, B, and/or C may be called. A and/or B might be called if another extension used the output of A and/or B or the values of A and B were used directly. Caching minimizes the number of times that A and/or B may be evaluated. If extensions C and/or D both use A and/or B, then A and/or B may be evaluated and the output values may be cached for the use of the second extension. In another scenario, the system may support the following: C needs output of B, B needs output of A. Output of B would be considered optional because if C is not called, then B will not be needed. Likewise, if B is not needed then A will not be needed.

The environment of the plug-in may be unaware of the application in which the code could be used. Such plug-in code modules may have little or no library code to build, and the plug-in should be able to be moved between very different systems. For example, a generic table look-up component could be deployed in one system to look up cellular base stations, and, in another system, to book prices—all that would be changed is the registration of the code and the reference data that is used.

Other features of the FEF include the ability for many Data Enhancements to use a single DEX and many Attributes to use a single Attribute Type.

When an event is presented to a system, embodiments of the invention (collectively, hereinafter, referred to as FEF for embodiments of a Functional Extensibility Framework) may be used to populate an Attribute Set for that event. The FEF accepts inputs associated with that event and returns both input and derived attributes which may be used by the system to process the event. For each transaction, input and derived attributes may be grouped into an Attribute Set. Derived attributes may be determined using Data Enhancements. Data Enhancements are specific versions of the more general Data Extension. Using Data Extensions allows strong typing and attribute definitions to be held in a database.

This framework enables the robust assembly of processing elements from different sources. It further minimizes system failures as software modules are upgraded. A software framework is a partially complete, or semi-finished software (sub-)system that is intended to be instantiated. It defines the architecture for a family of (sub-)systems and provides the basic building blocks to create them. It also defines the places where adaptations for specific functionality may be made. In an object-oriented environment, a framework comprises abstract and concrete classes. Instantiation of such a framework comprises composing and sub-classing the existing classes. In short, a software framework is a set of cooperating classes that make up a reusable design for a specific class of software. User-defined classes (for example, new subclasses), receive messages from the predefined framework classes. These are usually handled by implementing super-class abstract methods.

A software framework can be geared toward building graphical editors for different domains like artistic drawing, music composition, and mechanical CAD.

Another software framework can help build compilers for different programming languages and target machines. Yet another might help build financial modeling applications or decision support systems.

An embodiment may comprise a framework for assembling processing modules to return and/or derive data in response to a request for such data from an external program. The term, external program, may refer to the application from which the request originates. There may also exist additional programs between the originating program and the FEF supplemented, possibly, by a variety of application programming interfaces for feeding the request to the FEF. These intermediate programs may also be external to the FEF, linked to the FEF, or may be bound to the FEF as a single program. Such an external program may comprise one or more libraries of registered code modules. The code modules may be registered in a database associated with the framework and be further defined (redefined) with a set of strongly-typed inputs and outputs. An external program may process an event by interacting with the framework to determine if any data needed to process the event is present in a cache or derivable through a dependency chain (path) of specialized processing modules that are linked together based on the specific strongly-typed inputs and outputs exposed by the specialized processing modules.

In another embodiment, there may be a computerized method for assembling code modules. A computerized method includes any method which employs a computer to accept and manipulate input based on a program or sequence of instructions. The method includes pre-registering at least one weakly-typed code module, wherein the weakly-typed code module comprises one or more weakly-typed variables, in a database; and pre-creating an enhanced code module by pre-associating at least one of the weakly-typed variables with at least one strong attribute type. Pre-registering refers to storing, at least, a pointer (a variable that contains the address of a location in computer-readable memory) to a code module. A code module may comprise a portable unit of software that may function as a component in a variety of systems. Weak types generally comprise simple data types. Strong types generally comprise more specific data types and may be user-defined. A data type in a programming language is a set of data with values having predefined characteristics.

The method may then include accepting a request for a value for a variable of said strong attribute type from an external program at runtime (runtime generally refers to when a program is running or being executed); accessing a database comprising a list of said strong attribute types and their associated enhanced code modules (a database is a computer-readable collection of information that is organized so that it can easily be accessed, managed, and updated); determining which enhanced code module is associated with the strong attribute type associated with the requested variable; executing the enhanced code module to determine the value for the variable; and returning the value, of the strong attribute type, to the external program.

In another embodiment, there may be a computerized method for assembling code modules comprising pre-registering at least one weakly-typed code module, herein said weakly-typed code module comprises one or more weakly-typed variables, in a computer-readable storage and pre-creating an enhanced code module by pre-associating at least one of said weakly-typed variables with at least one strong attribute type. The method may then include accepting a request for a value for a variable of said strong attribute type from an external program at runtime; accessing a computer-readable storage comprising a list of said strong attribute types and their associated enhanced code modules; determining which enhanced code module is associated with said requested strong attribute type; executing said enhanced code module to determine said value for said variable of said strong attribute type and, if said enhanced code module requires a value for an additional variable of a strong attribute type: (a) accessing a computer-readable storage comprising a list of said strong attribute types and their associated enhanced code modules; (b) determining which additional enhanced code module is associated with said requested strong attribute type; (c) executing said additional enhanced code module to determine said value for said additional variable of said strong attribute type and, if said additional enhanced code module requires a value for an additional variable of a strong attribute type, repeating steps (a)-(c). Finally, the sub-routine may include returning said value for said additional variable to said enhanced code module. Once all of the sub-routines have been executed, the method may include returning said value to said external program. This illustrates the potential for the FEF to call a series of nested processing modules without constructing a dependency chain beforehand. The FEF reacts to the need of processing modules to utilize values for variables characterized by strong types. One processing module may utilize additional strongly-typed variables that need to be calculated before it can be finally executed.

In another embodiment, one weakly-typed code module may be used as the base to create any number of enhanced code modules using the previously described method.

In another embodiment, the step of creating the enhanced code module may include assigning a value to a variable (setting a record) representing a particular execution environment/operating system environment (this may also be referred to as the platform and generally comprises the combination of hardware and software in a computer, i.e., an operating system, the computer system's coordinating program, which is built on the instruction set for a processor or microprocessor) for the enhanced code module.

In another embodiment, the pre-creating step may also or alternatively include setting a record in the enhanced code module indicative of a range of dates during which the enhanced code module may be executed. This allows the enhanced code modules to be date-sensitive. Date ranges may include, but are not limited to, time-of-day ranges and/or calendar date ranges.

In another embodiment, the invention comprises a method for assembling code modules comprising pre-registering a plurality of weakly-typed code modules, wherein the weakly-typed code modules comprise one or more weakly-typed variables, in a database, and pre-creating at least one enhanced code module by associating at least one of the weakly-typed variables with at least one strong attribute type. The method then comprises accepting a request for a value of said strong attribute type from an external program at runtime; accessing a database comprising a list of said strong attribute types and their associated enhanced code modules; determining a dependency path of said enhanced code modules to derive said requested value; executing the enhanced code modules in the dependency path to determine the value; and returning the value to the external program.

A dependency path (chain) comprises a group of two or more specialized processing modules (enhanced code modules) that are linked together based on the specific strongly-typed inputs and outputs exposed by the specialized processing modules. In this way, if a first code module requires a value for an input variable that is computed as output in a second code module, the two code modules may be linked in a dependency path to ensure that the first code module receives, as input, the output of the second code module. The second code module may be executed first and then feed its output into the first code module. Compatibility of the modules may be ensured by matching the strong types of the input and output variables used by each of the modules. A dependency chain is not limited to only two modules but may require further links (possibly nested) as needed. The dependency path may be constructed in advance and then executed or it may be contemporaneously assembled. For contemporaneous assembly, the FEF would run a specialized code module to attempt to derive a value for a strongly-typed variable. In the course of running the specialized code module, the FEF may determine that it needs to run additional code modules to obtain inputs that are necessary to derive requested value.

In another embodiment, the method may include storing the values calculated by an enhanced code module in a cache. Input values, intermediate values, and output values may all be stored in a cache. In a preferred embodiment, these values may be stored in transient computer-readable memory rather than the, preferably, less transient memory used to store the processing functions. It should be noted, however, that computer memory may be allocated in a variety of ways. While it is preferred to store functions in less transient computer-readable memory and to store values in a temporary cache (e.g., random access memory), any variation on these theme may be implemented. Thus, when a value is requested by an external program, the FEF may check the cache to see if an unexpired value for that variable is present in the cache. The cached values may be date-sensitive. If the value is not present in the cache, then the FEF may proceed to the other steps of deriving that value through the execution of a single enhanced code module or via a dependency path as described above. If the value is present in the cache, the FEF will simply return the value to the external program without executing the enhanced code module or constructing/executing a dependency path. The FEF may also check the cache in the course of executing a dependency path to determine if any intermediate values have been cached in previous runs of such enhanced code modules.

In another embodiment, a computerized method for assembling one or more code modules to calculate a rate associated with a phone call may comprise pre-programming a generic code module (a generic code module generally includes weakly-typed code modules but also or alternatively may include a code module designed to perform a simple function) configured to return a derived (calculated) value based on a difference between a first and second value; pre-registering the generic code module in a database; and pre-creating an enhanced code module to be associated with the generic code module by associating a strong attribute type with the derived value wherein the strong attribute type is of type zone (zone, here, generally refers to geographical divisions for rate plans but may be interpreted as any kind of division whether geographic, economic, population-based, etc.). Then the method may include the steps of accepting a request for the value of a variable of type zone from an external program; determining which enhanced code module returns a value for a variable of type zone; executing the enhanced code module; and returning the value to the external program. Please note that the specificity of this claim is not intended to limit variations involving other variables that might be used to zone a call or arrive at an actual rate.

In another embodiment, a computerized method for assembling code modules may comprise pre-registering a data extension module comprising one or more weakly-typed variables in a database and pre-creating a data enhancement module by associating at least one of said weakly-typed variables with a strong attribute type. It may further include accepting a request for a value for a variable of said strong attribute type from an external program at runtime; accessing a database comprising a list of said strong attribute types and their associated data enhancement modules; determining which data enhancement module is associated with said requested strong attribute type; executing said data enhancement module; and returning the value to the external program.

Embodiments other than a computerized method may be encompassed by the invention including software and systems.

In another embodiment, the invention comprises a system for assembling code modules which includes a database component, a first interface component, a second interface component, and a processing component. The database component operates to pre-store a pointer to at least one weakly-typed code module wherein said weakly-typed code module utilizes one or more weakly-typed variables. The first interface component operates to allow a user to pre-associate at least one of said weakly-typed variables with a strong type in said database component. This may be accomplished via a graphical user interface or any other programming interface now known or to be developed. The second interface component operates to receive a request for data from an external program wherein said request for data is of said strong type. The processing component may be configured to access said database component to determine which weakly-typed code module is associated with said strong type; execute said weakly-typed code module determined in the previous step to derive a value; and return said value to said external program.

In another embodiment, the invention comprises a system for assembling code modules which includes a database component, a first interface component, a second interface component, and a processing component. The database component operates to pre-store a pointer to at least one weakly-typed code module wherein said weakly-typed code module utilizes one or more weakly-typed variables. The first interface component operates to allow a user to pre-associate at least one of said weakly-typed variables with a strong type and to pre-store the association in said database component. The second interface component operates to receive a request for data from an external program wherein said request for data is of said strong type. The processing component may be configured to access said database component to determine a dependency path of said weakly-typed code modules to derive a value associated with said strong type; execute said dependency path determined in the previous step to derive said value; and return said value to said external program.

In another embodiment the first interface component may further allow a user to designate a range of dates during which said weakly-typed code module may be executed.

In another embodiment the system may include a cache component wherein said value is stored in said cache component. The cache component may be checked by said processing component, prior to accessing said database component, to determine if said value is stored thereon and, if said value is present in said cache component, to return said value to said external program.

In another embodiment, the dependency path of said code modules may be constructed by matching said input and output variables of the various code modules by their strong attribute types.

There may also be software embodiments of the invention.

In such an embodiment, a computer readable medium may have computer executable instructions for pre-registering at least one code module wherein said code module comprises at least one weakly-typed variable and pre-associating at least one of said weakly-typed variables with a strong type. The software may be programmed to accept a request for a value for a variable of said strong type from an external program; determine which of said pre-registered code modules will return a value for said requested strongly-typed variable; execute said code module determined in the previous step; and return said value to said external program.

In another embodiment, the software may also be programmed to assemble a dependency path of said code modules to derive said value. The dependency path of said code modules may be constructed by matching said variables by their strong types.

Additional steps/components/operations may occur throughout the embodiments disclosed above without impacting the sequence/construction/programming described and/or claimed herein.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows the Attribute Types that may be registered with each of the above example DEX.

FIGS. 2A-2B, a schema, shows how the Attribute Types may be represented in a conventional relational database which represents the registration table of the FEF.

FIG. 3 illustrates an example flow of a calculation to support a simplified, for purposes of explanation, telephony tariff based on call distance.

FIG. 4 illustrates a table and a schema to define various DEX to support the calculation of a telephony tariff.

FIGS. 5-6 illustrate a table displaying the definition of various Data Enhancements to the generic DEX which supports the calculation of a telephony tariff.

FIG. 7 illustrates a dependency graph for the data in the Attribute Set of the Data Enhancements depicted in FIG. 6.

FIGS. 8-9 are a time-sensitive version of FIGS. 6-7.

FIG. 10 represents one possible schema for the caching infrastructure.

FIG. 11 demonstrates the ability of the caching infrastructure to categorize its data.

DETAILED DESCRIPTION OF THE INVENTION

To support a given vertical market application a number of vertical market code modules may be developed. Such code modules are called ‘Data Extensions’ or ‘DEX’. Non-limiting examples of DEX may include:

• • “Cell Site Lookup” which may look up a map grid reference of a cellular phone base station.
  • “Distance Measurement” which may calculate the distance between two map references.
  • “Distance Zoning” which may return a zone code based on a number of different distance ranges.

More specific Data Enhancements within the same DEX may share the same Attribute Set but (may) use and return different Attributes (i.e., Data Enhancements within the DEX Cell Site Lookup may include the following enhanced code modules: Calling Site Lookup and Called Site Lookup). It should be noted that, although the examples are related to the telecom-industry for consistency and ease of understanding, there is no limit to what industry might be supported through the FEF.

When the DEX are registered within FEF, additional type information may be registered and saved (typically using relational database, or object/XML storage technologies) to provide strong type information (‘Attribute Types’) about each DEX (thus creating a Data Enhancement). Registering DEX to the FEF with strong Attribute Types allows a host system using those same Attribute Types to interface with the FEF. This minimizes invalid linkages from the extension code (DEX) to the host system. Thus, a plug-in may be loaded at run time.

Referring to FIG. 1, the table provides a sampling of three DEX (Cell Site Lookup, Distance Measurement, and Distance Zoning). The table further delineates the inputs and outputs for each DEX, their basic data types and the “strong” attribute type associated with the DEX by pre-registering it in the FEF.

Referring to FIGS. 2A-2B, a schema shows how the information from the table in FIG. 1 may be represented in a conventional relational database which represents the registration table of the FEF. A number of attribute types (HYD_AttributeType) may be defined, based on ‘Basic Data Types’, with associated type name (Attribute Type) and labels for unit display. For instance, an attribute type of ‘CellName’ or ‘LatLong’ may be registered.

Each ‘HYD_DataExtension’ represents an external code module registered within the FEF. A number of DEX, which are packaged within one library, may be referred to as a ‘HYD_DataExtensionLibrary’.

Associated with each DEX there may be a ‘HYD_DEXLanguage’ record that allows the FEF to invoke the correct binary or script execution environment. Different DEX could therefore be written in binary, Perl, Python, TCL etc.

The types of inputs and outputs may be defined for each DEX in ‘HYD_DataExtensionInput’ and ‘HYD_DataExtensionOutput’.

The registration information may be used to assemble the DEX/Data Enhancement into a particular dependency path during the design phase or during runtime. The assembly process may check that the DEX uses both the correct basic data types for their input and output sets and the correct Attribute Types.

At design time, the Attribute Types may be used by an interface to ensure that compatible Data Enhancements are assembled into a dependency path.

The FEF may implement the processing as a number of stateless functions, with no provision for one function to directly call another (for example the FEF environment may not have a conventional stack that can be used for parameter passing and return address saving). At runtime, the processing (and processing order) of the Data Enhancements may be demand driven by the required data output values.

The FEF environment may recognize and optimize intermediate values of calculations that may be reused by a number of processing modules. It may also make these intermediate values available to construct audit trails. Thus, the result of each Data Enhancement may be calculated once but used one or more times for various modules.

Referring to FIG. 3, an example of a calculation to support a simplified (imaginary) telephony tariff based on call distance is illustrated. This example uses a DEX, described earlier, which calculates the distance in miles for the call, based on the call start and end locations, and uses this value to determine the resultant zoning code (effectively determining if the call is local or long distance).

In a conventional processing system this would normally be reduced to a procedural solution. For example the ‘Cell Zoning’ code (340) could call the ‘Inter-cell Calculation’ code (330) that in turn could call the ‘Cell Site Lookup’ code (310, 320) twice to lookup the geographical location of the calling and called sites (305).

To implement this within the FEF, a number of DEX instances may be defined to reflect each possible usage of the DEX. Referring to FIG. 4, the tables shown represent a simplified version of the DEX for supporting a tariff calculation. FIG. 5 illustrates that a Data Enhancement may be coded to be date-sensitive so that after a certain date, a different version of the Data Enhancement may be called by the FEF.

Referring to FIG. 6, a set of data (an ‘Attribute Set) may be defined that specifies all the values within one grouping of data that is to be processed (in this example, “Zone Based Pricing”). The set includes information if the value is present (typically in memory) when the FEF is invoked for that set or if it must be derived using a specific DEX instance (Data Enhancement).

Information in this table can then be validated against the DEX definition to ensure that all of the Data Enhancements use Attributes with compatible ‘Basic Data Types’ and ‘Attribute Types’.

Referring to FIG. 7, the information in the table can then be used to build a dependency graph (800) for the data in the Attribute Set, using the Data Enhancement information. The boxes represent the Attributes or strongly-typed variables (810, 820, 830, 840, 850, and 860). The ‘circles’ represent the Data Enhancements (815, 835, 845, 855). In this example, the cost of a call from a calling cell site to the called cell site needs to be calculated. To get the price zone (860), the Data Enhancement “Distance Zoning” (855) may be called but it cannot calculate the required value without further inputs than merely the “Calling Cell Site Name” (810) and the “Called Cell Site Name” (830). Distance Zoning (855) requires the distance between the calling site and the called site as input. To obtain this input, another Data Enhancement, “Inter-cell Distance Calculation” (845) may be called. This Data Enhancement requires as input the “Calling Cell Location” (820) and the “Called Cell Site Location” (840). These locations may be determined by calling the respective Data Enhancements “Calling Site Lookup” (815) and “Called Site Lookup” (835). Incidentally, each of these Data Enhancements may be based on the same generic code module but simply registered with the applicable strong types in the FEF to create the specific module used.

To process a specific Attribute Set, the Attribute Set is first created in the FEF environment. Those values that are identified as input are loaded into the Attribute Set (in this example the Calling Cell Site Name, and the Called Cell Site. Name). The FEF is invoked and external code can request any of the Attribute values. An external program may issue a request to the FEF through an application programming interface (API) or via a library linked to the external program. Values marked as input are returned directly. Values derived from DEX are checked, in the associated cache, to see if they have been previously accessed. If the value is not present, then the dependency graph (800) is traversed, and all of the dependent DEX are called in order using the associated Data Enhancement data to marshal the input and output values. For example, in FIG. 7, the site lookup functions (815, 835) would be called first as being at the ‘far end’ of the dependency tree (800).

Attribute values may be cached. So, for example, if the first Attribute requested is the ‘Price Zone’ (860) then all of the Data Enhancements would be called, starting with the Data Enhancements to undertake site lookup (though the data does not dictate if the ‘Called’ or ‘Calling’ lookup is evaluated first). However if the ‘Call Distance’ (850) has been previously requested, a request for ‘Price Zone’ (860) will only invoke the ‘Distance Zoning’ (855) Data Enhancement.

As outlined earlier each Data Enhancement individually runs to completion; there is no direct mechanism for one Data Enhancement to call another Data Enhancement, and each Data Enhancement may not have knowledge of the dependent Data Enhancements. This provides for a robust execution environment which minimizes the problems associated with stack tracing and dumping on failure, recursion, and undetected loops in infinite recursion and/or stack overflow between Data Enhancements.

Referring to FIGS. 5 and 8-9, the HYD_AttributeSetAttributes table allows the processing to be varied based on the date for which the request is being processed. For example, if a new ‘Call Distance’ (850) algorithm/code/module has to be introduced from a given date (e.g. to meet a regulatory change as to how the distance is calculated) then the table could be extended with a variety of date ranges. This will result in a revised dependency graph, and different Data Enhancements being invoked dependent on the date used in conjunction with the Attribute Set.

Other features, besides date sensitivity, that are associated with the context of the data, may be employed to vary dependency paths (e.g., execution environments, preferred customer discounts, geographic modules, etc.).

DEX may also have access to reference data (e.g. read only data such as cell site location lookup tables) or specific customer data (e.g. customers location, address, birthday etc).

The FEF includes a data caching infrastructure, so that DEX may make use of data which is external to the standard event-processing application, and not provided as part of any attribute set. The cache infrastructure provides the DEX with a means (e.g., an application programming interface) to access any required data via in-memory, read-only access techniques, to minimize the latency and cost of data access. Thus, the DEX can make use of additional data types without the overhead of conventional data access techniques (i.e. relational database query, file I/O, etc.). The cache infrastructure may be a framework comprising fixed processes which work with abstract plug-in classes to facilitate the retrieval and caching of the operator-defined data types. The operator is free to declare and implement any number of custom data types for use with this framework. The cache infrastructure may comprise the following components: data fetchers, serializable data types, key translation, and processes for acquiring and loading the data into memory.

Data fetchers are plug-in classes derived from a common abstraction. The data fetchers, as defined by the operator at run-time, may be loaded as a plug-in module at run-time. Thus new data fetchers may be added to a running system at any time. The data fetchers provide the logic to extract a specific type of data from an external system or database. The fetcher may be a configurable generic code module (e.g. to access an Oracle database, SAP system, or to invoke a web service), or a dedicated code module to extract data from a custom system. The data fetcher may be invoked by the standard extract processes of the host system so that the DEX are able to ensure that the necessary data is extracted into the caches.

The Serializable Data Type is an abstract class defining the methods which a cacheable data type must support. The operator is free to derive any number of data types—each representing a particular data type which is to be stored in the in-memory caches of the FEF. Such classes represent the external data type that is being cached by the FEF (ex. Customer, Cell Site, etc.). There are no restrictions on the amount or complexity of such classes. The data class provides for the composition, validation, optional compaction and serialization of the fetched data into a binary block (‘blob’) that can be passed between processes and stored in the memory caching infrastructure. The data object may be an object type generated directly from an external database schema, XML schema/WSDL, or may be a dedicated representation of data from a custom system.

Key translation may comprise a long key (e.g. customer reference number) by which to reference external data. This may be inefficient to cache (in terms of memory use) and may be slow to access when compared with a simple, internally allocated 32-bit or 64-bit integer reference number. The key translation and allocation support allows all of the internal accesses to be tied to the internally allocated ID. This service may be, normally, used for customer or other non-global data (e.g., using the Hydra ‘InternalConsumerId’). Global reference data can use an external key if required as such data is normally only read once at start-up and only one key is use to reference each block of reference data as opposed to millions of customer keys

Referring to FIG. 10, the cache infrastructure may include the following schema elements: HYD_DEDataType and HYD_DEUsesDEDataType

The ‘HYD_DEDataType’ table defines each type of cached data that may be accessed by a Data Extension. Associated with each ‘HYD_DEDataType’ are details of the location of the data fetcher (‘de_datatypetype’ & ‘de_datatype_class_name’).

The ‘HYD_DEUsesDEDataType’ table defines the ‘HYD_DEDataType’ that may be used by each of the DEX. A number of DEX may use the same ‘HYD_DEDataType’, and a DEX may use a number of different ‘HYD_DEDataType’. This table insures that the cache data required by the DEX may be available by loading it into memory.

Every cached item may have an external key ‘HYD_ExternalEntityKey’. This may be related to a number of internal keys (‘HYD_IntConsidHasExtKey’). Note that the ‘HYD_IntConsidHasExtKey’ has a date range so that the internal key may be associated with a number of external keys over time.

Referring to FIG. 11, in order to meet the isolation or data consistency requirements of the plug-in data extensions, the caching infrastructure may categorize the external data into one of three categories: partitionable, global, reference data.

Partitionable data refers to external data which has a clear relationship to specific instances of data in the core system (e.g., the data is related to specific consumers). The core data type provides the basis for the partitioning of work across multiple machines (i.e., each consumer may be assigned to a particular machine which handles the rating of that consumer's events). Because of this association, the external data can likewise be partitioned so that it is only loaded into the memory of those machines where it is needed. The caching subsystem also provides for the replication of changes to the external data into the running system continuously.

Global data cannot be clearly partitioned, either because its associations to core entities do not reflect the way in which work is partitioned, or because there are no clear associations. Such data is loaded into the memory cache of all processing machines, so as to be available globally. As with partitionable data, the caching subsystem also provides for the replication of changes to the external data into the running system continuously.

Reference data also cannot be clearly partitioned and is required on every processing node. However, unlike global data, the caching subsystem does not continually replicate changes to reference data into the memory caches. Rather, a mechanism is provided to take a single, point-in-time extract of all reference data types in order to produce a new reference data set. This mechanism provides support for data which may have complex relationships, and insures that the plug-in DEX are not exposed to data inconsistencies which might otherwise result from a continuous replication strategy.

The caching infrastructure comprises a number of processes which may use the fetcher and serializable data type classes previously described to acquire and load the cached data into memory. These processes are the extractor, change replicator, bulk loader, and refresh agent.

The extractor may use the operator-created fetcher classes to acquire data (serializable data objects) for a particular cache. The serialized form of these objects may be written to files which are suitable for loading into the in-memory caches on the various processing nodes. The extractors load fetcher classes at run-time based on the definitions given in the HYD_DEDataType table, using plug-in techniques. This process may be used to create new versions of reference data as needed.

The change replicators effect changes to the data being cached. The change replicator responds to such signals sent to the FEF by invoking the fetcher classes to re-acquire the particular data objects which have been modified. This may be performed continually for partitioned and global data in order to get all changes into memory as quickly as possible after the change occurs. As with the extractor, the change replicator may load fetchers at run-time, and as needed, based on the signaled changes.

The bulk loaders insure that data, required by the DEX, is loaded into memory. It provides start-up loading of all data needed by particular DEX into the in-memory caches which the DEX will use. The bulk loaders also continue to bring all changes posted by the change replicator into memory as they occur. The loader also handles work partitioning changes for those data caches which are so partitioned, and can likewise unload and load other caches as different DEX are themselves unloaded and loaded into the FEF.

The refresh agent is a process which can perform on-demand loading of particular data object (identified by key) into the in-memory region in the event that the DEX is unable to find expected objects when it is run.

Many other embodiments are possible using the principles illustrated herein and the examples presented herein should not be considered limiting in any fashion.

Claims

1. A computerized method for assembling code modules comprising: pre-registering one or more weakly-typed code modules, wherein each module from said one or more weakly-typed code modules comprises one or more weakly-typed variables, in a computer-readable storage;pre-creating one or more enhanced code modules by performing, for each enhanced code module, one or more steps comprising storing an association between the enhanced code module and a set of data comprising: i) a weakly-typed variable from a weakly typed code module from the one or more weakly typed code modules, andii) a strong attribute type,in the computer-readable storage, such that the pre-creation of the one or more enhanced code modules results in the computer-readable storage containing a list comprising each of said one or more enhanced code modules and the associated strong attribute types;accepting a request for a value for a variable of a requested strong attribute type from an external program at runtime;retrieving said list from said computer readable storage;using said list, determining which enhanced code module is associated with said strong attribute type of said requested variable;executing said enhanced code module to determine said value for said variable of said strong attribute type; andreturning said value to said external program.

2. A computerized method for assembling code modules, as claimed in claim 1, wherein pre-creating one or more enhanced code modules comprises: a) storing an association between a first enhanced code module and: i) a first weakly typed variable from a first weakly typed code module; andii) a first strong attribute type;b) storing an association between a second enhanced code module and: i) the first weakly typed variable from the first weakly typed code module; andii) a second strong attribute type.

3. A computerized method for assembling code modules, as claimed in claim 1, wherein said pre-creating step includes setting a record in said enhanced code module indicative of a particular execution environment.

4. A computerized method, as claimed in claim 1, wherein said pre-creating step includes setting a record in at least one enhanced code module indicative of a range of dates during which said at least one enhanced code module may be executed.

5. A computerized method for assembling code modules comprising: pre-registering a plurality of weakly-typed code modules, wherein said weakly-typed code modules comprise one or more weakly-typed variables, in a computer-readable storage;pre-creating at least one enhanced code module by associating at least one of said weakly-typed variables with at least one strong attribute type;accepting a request for a value for a variable of said strong attribute type from an external program at runtime;accessing a computer-readable storage comprising a list of said strong attribute types and their associated enhanced code modules;determining a dependency path of said enhanced code modules to derive said requested value;executing the enhanced code modules in said dependency path to determine said value; andreturning said value to said external program.

6. A computerized method for assembling code modules as claimed in claim 5, wherein said value is stored in a cache.

7. A computerized method for assembling code modules as claimed in claim 6, wherein said cache is checked after said “accepting a request for a value” step and, if said value is present in said cache, returning said value to said external program.

8. A computerized method, as claimed in claim 5, wherein said pre-creating step further includes setting a record in said enhanced code module indicative of a range of valid dates during which said enhanced code module may be executed.

9. A computerized method, as claimed in claim 5, wherein said dependency path of said enhanced code modules is automatically constructed by matching a set of inputs and outputs for said enhanced code modules by their strong attribute types.

10. A computerized method for assembling one or more code modules to calculate a rate associated with a phone call comprising: pre-programming a generic code module configured to return a derived value based on a difference between a first and second value;pre-registering said generic code module in a computer-readable storage;pre-creating an enhanced code module to be associated with said generic code module by associating a strong attribute type with said derived value wherein said strong attribute type is of type zone;accepting a request for a value of type zone from an external program;determining which enhanced code module returns a value of type zone;executing said enhanced code module; andreturning said value of type zone to said external program.

11. A computerized method for assembling code modules comprising: pre-registering a data extension module comprising one or more weakly-typed variables in a computer-readable storage;pre-creating a data enhancement module by performing one or more steps comprising storing an association between a weakly-typed variable from said one or more weakly-typed variables and a strong attribute type in the computer-readable storage, such that said pre-creation results in the computer-readable storage containing a list comprising the data enhancement module and an association with the strong attribute type as output of the data enhancement module;accepting a request for a value of said strong attribute type from an external program at runtime;retrieving the list from said computer readable storage;based on the association between the strong attribute type and the data enhancement module in the list, identifying the data enhancement module for execution;executing said data enhancement module; andreturning said value to said external program.

12. A computer readable medium having computer executable instructions for performing a method comprising: pre-registering at least one code module wherein said code module comprises at least one weakly-typed variable;pre-associating at least one of said weakly-typed variables with a strong type;accepting a request for a value for a variable of said strong type from an external program;determining which of said pre-registered code modules will return a value for said requested strongly-typed variable;executing said code module determined in the previous step; andreturning said value to said external program.

13. A computer readable medium having computer executable instructions for performing a method as claimed in claim 12 wherein said determining step further comprises assembling a dependency path of said code modules to derive said value.

14. A computer readable medium having computer executable instructions for performing a method as claimed in claim 13 wherein said dependency path of said code modules is automatically constructed by matching said variables by their strong types.

15. A computerized method for assembling code modules comprising: pre-registering a plurality of weakly-typed code modules, wherein each weakly-typed code module from said plurality of weakly-typed code modules comprises one or more weakly-typed variables, in a computer-readable storage;pre-creating a plurality of enhanced code modules by performing, for each enhanced code module, one or more steps comprising storing an association between the enhanced code module and a set of data comprising:i) a weakly-typed variable from a weakly-typed code module, andii) a strong attribute type,such that the pre-creation of the plurality of enhanced code modules results in the computer-readable storage containing a list comprising each of said plurality of enhanced code modules and the associated strong attribute types;accepting a request for a value for a variable of a requested strong attribute type from an external program at runtime;retrieving the list from the computer-readable storage;using the list, determining which enhanced code module is associated with said requested strong attribute type;executing said enhanced code module to determine said value for said variable of said requested strong attribute type and, if said enhanced code module requires a value for an additional variable of a different strong attribute type: a) using the list, determining which additional enhanced code module is associated with said different strong attribute type;b) executing said additional enhanced code module to determine said value for said additional variable of said different strong attribute type and, if said additional enhanced code module requires a value for another additional variable of a further strong attribute type, repeating steps (a)-(b);c) returning said value for said additional variable to said enhanced code module;returning said value for said variable of said requested strong attribute type to said external program.