This application is related to U.S. patent application entitled “Data Flow System and Method For Heterogeneous Data Integration Environments,” Ser. No. 11/373,685, filed on Mar. 10, 2006, which is incorporated by reference herein.
The present invention relates generally to data processing, and more particularly to managing parameters associated with an application.
In many data processing applications—e.g., data integration or Extract, Transform, Load (ETL) processes—execution of jobs commonly involves use of parameters (or variables) as arguments for specific invocations of a job. Parameters includes, for example, frequently changing values such as a password for a database connection, or performance tuning values (e.g., “maximum number of threads”). Parameters can even include specific semantic variations in a job such as a “date range” parameter (e.g., “between (Jan. 1, 2001, Jan. 1, 2006)”). Generally the values of parameters (or variables) are changed depending upon various circumstances; for example, for daily runs of a particular job (e.g., a report for “date range”), or for rare occurrences (like changing the URL of a database, if the database has been moved). Typically, there are also programmatic interfaces that may be used to automatically set the values of some parameters, for example, “today's date”.
Typically, to manage the development and administration of complex data processing applications, the lifecycle of such data processing applications are loosely organized into phases. Examples of phases include a design (or development) phase (during which each component or job of an application is modeled or coded), a deployment preparation phase (during which the components of an application are uniquely identified and configured, compiled or built, the total set of database resources are identified, and so on), a packaging (or assembly) phase (during which an application installing package is assembled, including all code, shared libraries, and configuration files), a deployment (or install) phase (during which the application package is installed onto a data processing runtime environment, and resource references are mapped to live resources), an administration phase (during which deployed jobs may be configured or administered), and an execution instance phase (during which instances of deployed jobs are executed). During each phase, different users are generally involved—e.g., during the design phase, software programmers develop specific components or jobs, while during the administration phase, administrators typically deploy and monitor applications and jobs in the production runtime environment.
Due to the large number of parameters that are typically involved in large enterprise data processing applications, not every user may have a sufficient semantic understanding about each job and the parameters associated with each job, especially since there are usually multiple different users involved in the different stages of an application's development. For example, an administrator who executes a specific job may not be aware of the specific semantics associated with the setting of a particular parameter value. Thus, as a result, only the most common or well understood parameters (such as “password”) are the only parameters implemented within a job. Generally, there is also no easy way to determine the effect of a change in the value of a parameter at any point in the lifecycle of a job in a data processing application. For example, changing a parameter that was previously assigned the name of a particular database table could significantly affect an entire application. In general, there also is not a standard way to restrict when the value of a parameter can be safely changed.
In general, in one aspect, this specification describes a computer-implemented method for managing a parameter of an application. The method includes identifying a plurality of phases associated with the application, in which each phase conesponds to a time period during a lifecycle of the application. The method further includes defining a range of phases among the plurality of phases associated with the application during which a value of the parameter can be changed.
Implementations can include one or more of the following features. Identifying a plurality of phases can include receiving user input identifying the plurality of phases associated with the application or include identifying the plurality of phases associated with the application based on pre-defined settings. Defining a range of phases associated with the application during which a value of the parameter can be changed can be based on a parameter type associated with the parameter. The plurality of phases associated with the application can comprise one or more of a design phase, a deployment preparation phase, a packaging phase, a deployment phase, an administration phase, or an execution instance phase. The method can further include defining an attribute of the parameter. The attribute can be indicative of one of the following: whether the parameter is useable among different jobs of an application; that the value of the parameter is not changeable or is for meant for display purposes only; whether the parameter requires a valid current value; each job where the parameter is referenced; or a group to which the parameter belongs.
In general, in another aspect, this specification describes a computer-implemented method for managing a parameter of an application. The method includes receiving a request to change a value of a parameter associated with the application, and determining a current phase associated with the application. The current phase corresponds to a time period during a lifecycle of the application. The method further includes changing the value of the parameter if the current phase is within a permissible range of phases during which the value of the parameter can be changed.
Implementations can include one or more of the following features. The permissible range of phases can include one or more of a design phase, a deployment preparation phase, a packaging phase, a deployment phase, an administration phase, or an execution instance phase. The permissible range of phases during which the value of the parameter can be changed can be defined by a user.
In general, in another aspect, this specification describes a computer program product, tangibly stored on a computer-readable medium, for managing a parameter of an application. The computer program product comprising instructions for causing a programmable processor to identify a plurality of phases associated with the application, in which each phase corresponds to a time period during a lifecycle of the application. The computer program product further comprises instructions for causing a programmable processor to define a range of phases among the plurality of phases associated with the application during which a value of the parameter can be changed.
In general, in another aspect, this specification describes a computer program product, tangibly stored on a computer-readable medium, for managing a parameter of an application. The computer program product comprising instructions for causing a programmable processor to receive a request to change a value of a parameter associated with the application, and determine a current phase associated with the application. The current phase corresponds to a time period during a lifecycle of the application. The computer program product further comprises instructions for causing a programmable processor to change the value of the parameter if the current phase is within a permissible range of phases during which the value of the parameter can be changed.
Implementations can provide one or more of the following advantages. In one aspect, the concept of phases (or stages) in the development life cycle of a data processing application are used to show only a specific set of parameters that pertains to a specific user action at any given time, add semantics to enforce the safe changing of parameter values, and allow specific users (at the right stages in the development lifecycle) to decide whether individual parameters can be changed and when the parameters can be changed for a final time (e.g., by setting a “maxChangePhase” attribute of a parameter, as discussed below). Additionally, the concept of sharing of parameters discussed below provides richer mechanisms to enforce editing semantics as well as specialized overriding of some semantics. Further, the concept of parameter usage references discussed below provides better feedback for users to evaluate the effect of changing a value of a shared parameter, and the concept of parameter groups can be used together with phase values to provide focused sets of parameters as well as provide “virtual” groups to show additional information to a user.
In general, in another aspect, this specification describes a computer-implemented method for managing a parameter of an application. The method includes determining a group associated with a user of the application, and displaying a parameter that is associated with the group to the user. The parameter is associated with a defined range of phases of the application during which the value of the parameter can be changed.
In general, in another aspect, this specification describes a computer program product, tangibly stored on a computer-readable medium, for managing a parameter of an application. The computer program product comprises instructions for causing a programmable processor to determine a group associated with a user of the application, and display a parameter that is associated with the group to the user. The parameter is associated with a defined range of phases of the application during which the value of the parameter can be changed.
In general, in another aspect, this specification describes a system for managing a parameter of an application. The system includes a first component to determine a group associated with a user of the application, and a second component to display a parameter that is associated with the group to the user. The parameter is associated with a defined range of phases of the application during which the value of the parameter can be changed. The first component and the second component can form a parameter handing component of the system.
The details of one or more implementations are set forth in the accompanying drawings and the description below. Other features and advantages will be apparent from the description and drawings.
Like reference symbols in the various drawings indicate like elements.
The present invention relates generally to data processing, and more particularly to restricting the scope of parameters associated with data processing applications. The following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements. The present invention is not intended to be limited to the implementations shown but is to be accorded the widest scope consistent with the principles and features described herein.
Running on the programmed computer 104 are one or more application(s) 108 (e.g., data processing applications) and a parameter administration component 110. In one implementation, the programmed computer 104 includes a graphical user interface (GUI) (not shown) that permits users to manage the development and administration of the application(s) 108 throughout the lifecycle of the application(s) 108.
In one implementation, the parameter administration component 110 uses specific phases of an application lifecycle to manage parameters associated with an application, including defining a range of phases during which a value of a given parameter can be changed and when the parameters (safely) may not be changed, as discussed in greater detail below. For example, as shown in the graph 300, the range of phases during which a value associated with parameter 1 can be changed spans from lifecycle phase 1 (e.g., design phase) though lifecycle phase 2 (e.g., deployment preparation phase). The range of phases during which a value associated with parameter 2 can be changed spans from lifecycle phase 2 through a portion of lifecycle phase 4 (e.g., runtime phase). The range of phases during which a value associated with parameter 3 can be changed spans from lifecycle phase 1 through a portion of lifecycle phase 3 (e.g., deployment phase). More generally, the range of phases during which a value of a given parameter can be changed can span at least a portion of one or more phases associated with an application.
Once the data processing system 100 has identified the phases associated with the lifecycle of a given application, the parameter administration component 110 defines a range of phases among the identified phases during which a value of the parameter can be changed (step 204). As discussed above, the range of phases during which a value of a parameter can be changed can span at least a portion of one or more phases associated with an application (as shown in
Parameter Data Structure
Data processing or integration systems typically have a parameter (or variable) data structure. Parameter data structures commonly include the following attributes shown in Table 1 below.
Some systems also have additional attributes or operations associated with parameter data structures—for example, a “validRange” attribute (to identify which values are permitted for the parameter), or a “validator” method reference (either selected from a library of routines or user-provided) that validates a value that is entered for the parameter.
In one implementation, the data processing system 100 (
For example, developers of jobs can set the “maxChangeValue” of a given parameter to enforce the notion that the value of the parameter should not be changed beyond a specified phase. So, for the example discussed above, a developer could set the “maxChangeValue” for the “SchemaName” parameter to be “Deployment” phase (e.g., a value of “2”), meaning that the last time that the parameter's value can be changed is, e.g., during the deployment of the application to the production system. For example, in the data processing system 100, the parameter administration component 110 (or other administration component) would not permit users to change (or alter) the “SchemaName” parameter (referring to the example above) when executing jobs, since the current phase would be “EXECUTION_INSTANCE” which is beyond (or numerically greater according to the phase enumeration listed above than) the “DEPLOYMENT” phase assigned to the “maxChangePhase” attribute of the “SchemaName” parameter.
An advantage of using phases to restrict when changes (or edits) can be made to values of parameters is that the number of parameters available for a user (i.e., only those parameters that the user can edit) can be significantly reduced. Optionally, the parameters that are not available for a user (i.e., those parameters that the user cannot edit), can still be presented to a user for viewing purposes only, e.g., by setting the “readOnly” attribute of such parameters to “TRUE”.
Shared Parameter References
To further reduce the number of parameters associated with an application, as well as to provide very specific semantics, sharing of parameters can be introduced within jobs inside the context of an application of the data processing system 100. In one implementation, an application is composed of many different executable jobs and, accordingly, parameters may be shared between these different jobs.
Every parameter is typically uniquely designated by a corresponding identifier. Accordingly, whenever a variable value is to be used in a job, a user can usually select a parameter that is already defined or a new parameter may be created. Thus, when two different jobs refer to a particular parameter ID, then the two jobs are referring to the same parameter. This is very useful in situations, where the values that the two (or more) jobs are referencing are indeed the same. For example, a first job may be producing a file with a parameter ID “FILE_123”, and a second job may need to consume the same file, and therefore the parameter reference of the second job should also be the same “FILE_123”. In conventional data processing systems, in which there may be two different parameters used among two different jobs, responsibility for ensuring that values for these two different parameters are the same typically falls into the hands of an administrator (or executor of the jobs). Such reliance on an administrator is error-prone, and can be avoided by using shared parameters.
In one implementation, the data processing system 100 implements shared parameters by assigning unique identifiers (or IDs) to each parameter created by a user. In design and development environments, developers are presented (e.g., in a GUI) with an option of selecting an existing parameter (shared) or creating a new parameter. For example, in one implementation, the parameter administration component 110 includes user interfaces that permit users to add parameters for use in various data flow and control jobs. For some scenarios, developers may wish to keep a parameter unique to a particular location in which the parameter is used—i.e., to not allow the parameter to be shared. In such a case, (in one implementation) developers can set the “allowShared” attribute of the parameter to “FALSE” to inform the data processing system that the parameter can only be used at a single location. In one implementation, the data processing system restricts the scope of shared parameters based on life cycle phases of an application, as discussed in greater detail below.
Parameter Usage References
In one implementation, the sharing of a given parameter is allowed whenever the user has set the “allowShared” attribute of the parameter to “TRUE”. In one implementation, when a user selects a parameter for use in a particular job, a reference to that job (or to the specific location in that job where the parameter is used) is maintained by the “usedin” attribute of the parameter. For example, in the IBM DWE system, through a data flow tool, a parameter may be assigned for the value of an operator's property and, therefore, the “usedIn” attribute of the parameter will contain a reference to that operator property. Accordingly, any user who may change the value of the parameter can identify exactly where else the parameter is used, and determine the potential impact, if any, of changing the value of the parameter.
Generally, when executing a job, only the parameters that are specifically referenced inside of the job are needed. In addition, only the parameters that are not shared need to be displayed during execution of a job. This is because shared parameters are “global” and, therefore, should be update-able at the scope of the application as a whole and not necessarily for every job. Thus, in one implementation, to permit more flexibility for developers, parameters are attached the “EXECUTION_INSTANCE” phase scope. This phase is used as a way to indicate an exception that that particular parameter, even if shared, may be editable while executing a job. Thus, the concept of phases can be used to enrich conventional data processing systems that may rely on simple sharing of parameters to reduce the scope of parameters. For example, a “database user” parameter would be typically shared as the same user may be used in multiple jobs, however, for maximum flexibility, attaching the “EXECUTION_INSTANCE” phase will let administrators run one-off jobs with alternate user names.
Groups
In one implementation, parameters are grouped into different groups. The groups can have unique identifiers and can have different semantics depending upon application requirements. For example, each group may have unique access control lists (ACLs) to allow individual users permissions to access or change parameter values. The access control lists provide a mechanism within a data processing system to control which specific user may use or alter variables. In one implementation, to further limit the complexity of parameter management, groups are used as a means of reducing the number of variables in scope at any given time. For example, (in one implementation) developers can use “basic”, “intermediate”, and “advanced” groups to indicate the level of user awareness needed to alter values of parameters that are within a particular group. In one implementation, the data processing system 100 further provides “virtual” groups. For example, the data processing system 100 can provide “virtual” groups in the form of a list of “read-only” (or for display only) parameters in a “read-only” group, or a group of “global parameters”, when a job is being executed (i.e., when the phase is EXECUTION_INSTANCE). Thus, only the “EXECUTION_INSTANCE” phase parameters are shown as editable for the user when executing the job, and also the parameters in a “virtual” group can be (optionally) shown to the user as well to give more information to the user (or administrator).
Parameter Type-Specific Semantics
Parameter types are typically used to enforce the data-type of values that are permissible for a given parameter.
In one implementation, additional semantics can be attached to parameter types within the data processing system 100. For example, one useful semantic that can be attached to parameter types is a “maxPhase” setting to indicate that there is a further restriction on when parameters of a particular type can be changed. For example, in one implementation, in the data processing system 100, parameters of the “TableName” type are not meant to be changed anytime during or after deployment—this is because code or SQL expressions have been previously generated after the deployment preparation stage that refers to the TableName type. Thus, the “TableName” type can have a maxPhase setting of “DEPLOYMENT_PREPARATION” to indicate that any parameter of this type cannot be changed after the deployment preparation phase.
In one implementation, in the data processing system 100, a property type is introduced with the following XML text (in one implementation, the data processing system 100 uses Eclipse Modeling Framework (EMF) classes to introduce types into the data processing system).
Accordingly, in one implementation, the data processing system 100 uses this additional type-specific attribute (or setting) in limiting the value of the “maxChangePhase” attribute that is permissible for a parameter that uses a given type. So, for example, if a parameter called “SalesTgtTable” is of type “TableName” (instead of a type “String”), then the highest value that a developer can set the “maxChangePhase” attribute for the “SalesTgtTable” parameter is “DEPLOYMENT_PREPARATION” (since, as discussed above, (in one implementation) parameters of the “TableName” type are not meant to be changed anytime during or after DEPLOYMENT. If the “SalesTgtTable” parameter were of type “String”, then a developer could have set the “maxChangeValue” attribute of the parameter to any value up to “EXECUTION_INSTANCE”. Accordingly, the additional attribute “maxphase” that is associated with a parameter type can further provide an additional mechanism for managing parameters in a data processing system.
One or more of method steps described above can be performed by one or more programmable processors executing a computer program to perform functions by operating on input data and generating output. Generally, the invention can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In one implementation, the invention is implemented in software, which includes but is not limited to firmware, resident software, microcode, etc.
Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk—read only memory (CD-ROM), compact disk read/write (CD-RJW) and DVD.
Memory elements 704A-B can include local memory employed during actual execution of the program code, bulk storage, and cache memories that provide temporary storage of at least some program code in order to reduce the number of times the code must be retrieved from bulk storage during execution. As shown, input/output or I/O devices 708A-B (including, but not limited to, keyboards, displays, pointing devices, etc.) are coupled to data processing system 700. I/O devices 708A-B may be coupled to data processing system 700 directly or indirectly through intervening I/O controllers (not shown).
In one implementation, a network adapter 710 is coupled to data processing system 700 to enable data processing system 700 to become coupled to other data processing systems or remote printers or storage devices through communication link 712. Communication link 712 can be a private or public network. Modems, cable modems, and Ethernet cards are just a few of the currently available types of network adapters.
Various implementations for managing parameters of an application associated with a data processing system have been described. Nevertheless, various modifications may be made to the implementations described above, and those modifications would be within the scope of the present invention. For example, although the above techniques are described in the context of data processing applications and/ETL jobs, the techniques can be applied generally to a variety of other applications. Also, although the phases listed above are described in the context of lifecycle phases of an application, any suitable criteria may be used to demarcate a phase (or time period). Accordingly, many modifications may be made without departing from the scope of the present invention.
Number | Name | Date | Kind |
---|---|---|---|
4813013 | Dunn | Mar 1989 | A |
4901221 | Kodosky et al. | Feb 1990 | A |
5379423 | Mutoh et al. | Jan 1995 | A |
5497500 | Rogers et al. | Mar 1996 | A |
5577253 | Blickstein | Nov 1996 | A |
5586328 | Caron et al. | Dec 1996 | A |
5729746 | Leonard | Mar 1998 | A |
5758160 | McInerney et al. | May 1998 | A |
5850548 | Williams | Dec 1998 | A |
5857180 | Hallmark et al. | Jan 1999 | A |
5920721 | Hunter et al. | Jul 1999 | A |
5940593 | House et al. | Aug 1999 | A |
5966532 | McDonald et al. | Oct 1999 | A |
6014670 | Zamanian et al. | Jan 2000 | A |
6044217 | Brealey et al. | Mar 2000 | A |
6098153 | Fuld et al. | Aug 2000 | A |
9707504 | Banavar et al. | Nov 2000 | |
6202043 | Devoino et al. | Mar 2001 | B1 |
6208345 | Sheard et al. | Mar 2001 | B1 |
6208990 | Suresh et al. | Mar 2001 | B1 |
6243710 | DeMichiel et al. | Jun 2001 | B1 |
6282699 | Zhang et al. | Aug 2001 | B1 |
6434739 | Branson et al. | Aug 2002 | B1 |
6449619 | Colliat et al. | Sep 2002 | B1 |
6480842 | Agassi et al. | Nov 2002 | B1 |
6604110 | Savage et al. | Aug 2003 | B1 |
6668253 | Thompson et al. | Dec 2003 | B1 |
6687735 | Logston | Feb 2004 | B1 |
6738964 | Zink et al. | May 2004 | B1 |
6772409 | Chawla et al. | Aug 2004 | B1 |
6795790 | Lang et al. | Sep 2004 | B1 |
6807651 | Saluja et al. | Oct 2004 | B2 |
6839724 | Manchanda et al. | Jan 2005 | B2 |
6839726 | Kawamoto | Jan 2005 | B2 |
6850925 | Chaudhuri et al. | Feb 2005 | B2 |
6928431 | Dettinger et al. | Aug 2005 | B2 |
6968326 | Johnson et al. | Nov 2005 | B2 |
6968335 | Bayliss | Nov 2005 | B2 |
6978270 | Carty et al. | Dec 2005 | B1 |
7003560 | Mullen et al. | Feb 2006 | B1 |
7010779 | Rubin et al. | Mar 2006 | B2 |
7031987 | Mukkamalla et al. | Apr 2006 | B2 |
7035786 | Abu El Ata et al. | Apr 2006 | B1 |
7076765 | Omori | Jul 2006 | B1 |
7103590 | Murthy et al. | Sep 2006 | B1 |
7191183 | Goldstein | Mar 2007 | B1 |
7209925 | Srinivasan et al. | Apr 2007 | B2 |
7272815 | Eldridge | Sep 2007 | B1 |
7340718 | Szladovics et al. | Mar 2008 | B2 |
7343585 | Lau et al. | Mar 2008 | B1 |
7493311 | Cutsinger et al. | Feb 2009 | B1 |
7499917 | Purcell et al. | Mar 2009 | B2 |
7526468 | Vincent et al. | Apr 2009 | B2 |
7689576 | Rao et al. | Mar 2010 | B2 |
7689582 | Behnen et al. | Mar 2010 | B2 |
7739267 | Jin et al. | Jun 2010 | B2 |
7747563 | Gehring | Jun 2010 | B2 |
7810067 | Kaelicke et al. | Oct 2010 | B2 |
7860863 | Bar-Or et al. | Dec 2010 | B2 |
7895639 | Spataro | Feb 2011 | B2 |
7941460 | Bar-Or et al. | May 2011 | B2 |
8230384 | Krishnan et al. | Jul 2012 | B1 |
8839724 | Allen et al. | Sep 2014 | B2 |
8903762 | Jin et al. | Dec 2014 | B2 |
20020046301 | Shannon et al. | Apr 2002 | A1 |
20020066077 | Leung | May 2002 | A1 |
20020078262 | Harrison et al. | Jun 2002 | A1 |
20020116376 | Iwata et al. | Aug 2002 | A1 |
20020162090 | Parnell et al. | Oct 2002 | A1 |
20020170035 | Casati et al. | Nov 2002 | A1 |
20020198872 | MacNicol et al. | Dec 2002 | A1 |
20030033437 | Fischer et al. | Feb 2003 | A1 |
20030037322 | Kodesky et al. | Feb 2003 | A1 |
20030051226 | Zimmer et al. | Mar 2003 | A1 |
20030100198 | Hicks et al. | May 2003 | A1 |
20030101098 | Schaarschmidt | May 2003 | A1 |
20030110470 | Hanson et al. | Jun 2003 | A1 |
20030149556 | Riess | Aug 2003 | A1 |
20030154274 | Nakamura | Aug 2003 | A1 |
20030172059 | Andrei | Sep 2003 | A1 |
20030182651 | Secrist et al. | Sep 2003 | A1 |
20030229639 | Carlson et al. | Dec 2003 | A1 |
20030233374 | Spinola et al. | Dec 2003 | A1 |
20030236788 | Kanellos et al. | Dec 2003 | A1 |
20040054684 | Geels | Mar 2004 | A1 |
20040068479 | Wolfson et al. | Apr 2004 | A1 |
20040073886 | Irani | Apr 2004 | A1 |
20040107414 | Bronicki et al. | Jun 2004 | A1 |
20040143811 | Kaelicke et al. | Jul 2004 | A1 |
20040220923 | Nica | Nov 2004 | A1 |
20040254948 | Yao | Dec 2004 | A1 |
20050022157 | Brendle et al. | Jan 2005 | A1 |
20050044527 | Recinto | Feb 2005 | A1 |
20050055257 | Senturk et al. | Mar 2005 | A1 |
20050066283 | Kanamaru | Mar 2005 | A1 |
20050091664 | Cook et al. | Apr 2005 | A1 |
20050091684 | Kawabata et al. | Apr 2005 | A1 |
20050097103 | Zane et al. | May 2005 | A1 |
20050108209 | Beyer et al. | May 2005 | A1 |
20050131881 | Ghosh et al. | Jun 2005 | A1 |
20050137852 | Chari et al. | Jun 2005 | A1 |
20050149914 | Krapf et al. | Jul 2005 | A1 |
20050174986 | Emond et al. | Aug 2005 | A1 |
20050174988 | Bieber et al. | Aug 2005 | A1 |
20050187935 | Kumar | Aug 2005 | A1 |
20050188353 | Hasson et al. | Aug 2005 | A1 |
20050216497 | Kruse et al. | Sep 2005 | A1 |
20050227216 | Gupta | Oct 2005 | A1 |
20050234969 | Mamou et al. | Oct 2005 | A1 |
20050240354 | Mamou et al. | Oct 2005 | A1 |
20050240652 | Crick | Oct 2005 | A1 |
20050243604 | Harken et al. | Nov 2005 | A1 |
20050256892 | Harken | Nov 2005 | A1 |
20050283473 | Rousso et al. | Dec 2005 | A1 |
20060004863 | Chan et al. | Jan 2006 | A1 |
20060015380 | Flinn et al. | Jan 2006 | A1 |
20060036522 | Perham | Feb 2006 | A1 |
20060047709 | Belin et al. | Mar 2006 | A1 |
20060066257 | Chou | Mar 2006 | A1 |
20060074621 | Rachman | Apr 2006 | A1 |
20060074730 | Shukla et al. | Apr 2006 | A1 |
20060101011 | Lindsay et al. | May 2006 | A1 |
20060112109 | Chowdhary et al. | May 2006 | A1 |
20060123067 | Ghattu et al. | Jun 2006 | A1 |
20060167865 | Andrei | Jul 2006 | A1 |
20060174225 | Bennett et al. | Aug 2006 | A1 |
20060206869 | Lewis et al. | Sep 2006 | A1 |
20060212475 | Cheng | Sep 2006 | A1 |
20060218123 | Chowdhuri et al. | Sep 2006 | A1 |
20060228654 | Sanjar et al. | Oct 2006 | A1 |
20070061305 | Azizi | Mar 2007 | A1 |
20070078812 | Waingold et al. | Apr 2007 | A1 |
20070157191 | Seeger et al. | Jul 2007 | A1 |
20070169040 | Chen | Jul 2007 | A1 |
20070203893 | Krinsky et al. | Aug 2007 | A1 |
20070208721 | Zaman et al. | Sep 2007 | A1 |
20070214111 | Jin et al. | Sep 2007 | A1 |
20070214171 | Behnen et al. | Sep 2007 | A1 |
20070214176 | Rao et al. | Sep 2007 | A1 |
20070244876 | Jin et al. | Oct 2007 | A1 |
20070244976 | Carroll et al. | Oct 2007 | A1 |
20080092112 | Jin et al. | Apr 2008 | A1 |
20080127040 | Barcellona | May 2008 | A1 |
20080147703 | Behnen et al. | Jun 2008 | A1 |
20080147707 | Jin et al. | Jun 2008 | A1 |
20080168082 | Jin et al. | Jul 2008 | A1 |
Entry |
---|
Arusinski et al., “A Software Port from a Standalone Communications Management Unit to an Integrated Platform”, 2002, IEEE, pp. 1-9. |
Carreira et al., “Execution of Data Mappers”, IQIS, 2004, pp. 2-9, 2004 ACM 1-58113-902-0/04/0006, Paris, France. |
Carreira et al., “Data Mapper: An Operator for Expressing One-to Many Data Transformations”, Data Warehousing and Knowledge Discovery, Tjoa et al, editors, 7th International Conference DaWaK 2005 Copenhagen, Denmark, Aug. 22-26, 2005, pp. 136-145. |
Ferguson et al., “Platform Independent Translations for a Compilable Ada Abstract Syntax”, Feb. 1993 ACM 0-89791-621-2/93/0009-0312 1.50, pp. 312-322. |
Friedrich, II, Meta-Data Version and Configuration Management in Multi-Vendor Environments, SIGMOD, Jun. 14-16, 2005, 6 pgs., Baltimore, MD. |
Gurd et al., “The Manchester Prototype Dataflow Computer”, Communications of the ACM, Jan. 1985, pp. 34-52, vol. 28, No. 1. |
Hernandez et al., “Clio: A schema mapping tool for information integration”, IEEE Computer Society, 2005. |
Haas et al., “Clio Grows Up: From Research Prototype to Industrial Tool”, SIGMOD, Jun. 14-16, 2005, 6 pgs., Baltimore, MD. |
Jardim-Gonçalves et al., “Integration and adoptability of APs: the role of ISO TC184/SC4 standards”, International Journal of Computer Applications in Technology, 2003, pp. 105-116, vol. 18, Nos. 1-4. |
Poess et al., “TPC-DS, Taking Decision Support Benchmarking to the Next Level”, ACM SIGMOD, Jun. 4-6, 2002, 6 pgs., Madison, WI. |
Ramu, “Method for Initializing a Plateform and Code Independent Library”, IBM Technical Disclosure Bulletin, Sep. 1994, pp. 637-638, vol. 37, No. 9. |
Rafaieh et al., “Query-based data warehousing tool”, DOLAP, Nov. 8, 2002, 8 pgs., McLean, VA. |
Simitsis, “Mapping Conceptual to Logical Models for ETL Processes”, ACM Digital Library, 2005, pp. 67-76. |
Stewart et al., “Dynamic Applications from the Ground Up”, Haskell '05, Sep. 30, 2005, Tallinn, Estonia, ACM, pp. 27-38. |
Vassiliadis et al., “A generic and customizable framework for the design of ETL scenarios”, Information Systems, Databases: Creation, Management and Utilization, 2005, pp. 492-525, vol. 30, No. 7. |
Werner et al., “Just-in-sequence material supply—a simulation based solution in electronics”, Robotics and Computer-Integrated Manufacturing, 2003, pp. 107-111, vol. 19, Nos. 1-2. |
Yu, “Transform Merging of ETL Data Flow Plan”, IKE '03 International Conference, 2003, pp. 193-198. |
Zhao et al., “Automated Glue/Wrapper Code Generation in Integration of Distributed and Heterogeneous Software Components”, Proceedings of the 8th IEEE International Enterprise Distributed Object Computing Conf. (EDOC 2004), 2004, IEEE, pp. 1-11. |
Method and Apparatus for Modelling Data Exchange in a Data Flow of an Extract, Transform, and Load (ETL) Process, SVL90060126US1, U.S. Appl. No. 11/621,521, filed Jan. 9, 2007. |
Tjoa, et al. (Eds.), “Data Warehousing and Knowledge Discovery—Data Mapper: An Operator for Expressing One-to-Many Data Transformations,” Proceedings of 7th International Conference, DaWaK 2005, Copenhagen, Denmark, Aug. 22-26, 2005, 12 pages. |
Konstantinides, et al., “The Khoros Software Development Environment for Image and Signal Processing,” May 1994, IEEE, vol. 3, pp. 243-252. |
“Method and system for generating data flow execution components in heterogeneous data integration environments”, U.S. Appl. No. 11/372,540, filed Mar. 10, 2006. |
“Dilation of sub-flow operations in a data flow”, U.S. Appl. No. 11/372,516, filed Mar. 10, 2006. |
“Classification and sequencing of mixed data flows”, U.S. Appl. No. 11/373,084, filed Mar. 10, 2006. |
“Data flow system and method for heterogeneous data integration environments”, U.S. Appl. No. 11/373,685, filed Mar. 10, 2006. |
Ives, Zachary E, et al.; “An Adaptive Query Execution System for Data Integration”; Jun. 1999; pp. 299-310; vol. 28, Issue 2; ACM, New York, New York, USA. |
Number | Date | Country | |
---|---|---|---|
20080147703 A1 | Jun 2008 | US |