International Business Machines Corporation

Logiclibrary, Inc.

Akana, Inc.

Brent Allen Carlson

Timothy James Graser

Dave H Gross

Debra L Mariner

John J Palof

Paul W Tamminga

Frederic Lawrence Huss

Nancy M Schmucki

Richard E Zelenski

Torbjorn Harald Pernbeck

Ulf Jesper Thomas Lindblom

James E Carey

Randy Dee Baxter

Tim Graser

Moon Jung Kim

Anthony Richard Bonaccio

Casper A Scalzi

Richard I Baum

Michael Gerard Mall

Andre Tost

Bhaskar Sinha

Anders Magnus Nilsson

Vincent Edmund Price

Tore Magnus Dahl

Lloyd S Heim

Dale Henry Manthei

Steven A Schmitt

Mircea P Marandici

Kenneth A Moe

Anders Mangus Nilsson

Barbara Regine Proske

Jan Olof Engstrom

Gary Joseph Pietrocarlo

Albert S Lee

Simon Paul Reason

Ravindran Yelchur

Craig Dean Woods

Valquiria Cristina Da Cruz

Neil Patterson

Peter Taube

In general, techniques are described that facilitate the reuse of software assets within an enterprise. A software asset, as used herein, refers to a set of one or more related artifacts that have been created or harvested for the purpose of applying that asset repeatedly in subsequent development environments. A system, for example, is described that includes a repository to store artifacts, and an asset source to generate a software asset based on the artifacts. The system further includes an asset management system to receive the software asset from the asset source and store the software asset within an asset library. The system may further include a model having one or more elements, and an asset retrieval module to selectively retrieve a subset of the software assets from the asset library based on input from a user identifying one or more of the elements.

Generating reusable software assets from distributed artifacts

In general, techniques are described that facilitate the reuse of software assets within an enterprise. A system, for example, is described that includes a repository to store artifacts, and an asset source to generate a software asset based on the artifacts. The system further includes an asset management system to receive the software asset from the asset source and store the software asset within an asset library. The system may further include a model having one or more elements, and an asset retrieval module to selectively retrieve a subset of the software assets from the asset library based on input from a user identifying one or more of the elements. The system may also include a subsystem that allows users to customize asset governance processes and tailor system behavior through an event-driven mechanism.

Customizable asset governance for a distributed reusable software library

Managing reusable software assets

In general, techniques are described for dynamically generating schema information for data description languages. The techniques include receiving a schema defining a class of elements that conform to a data description language, and receiving a constraint template that defines requirements for instances of the elements. The techniques further comprise dynamically generating schema information based on the schema and the constraint template, and validating a document in accordance with the schema information.

Dynamic generation of schema information for data description languages

A targeted asset capture system that maps software resources to a domain model, and search and management tools for retrieving asset information and controlling asset acquisition. The domain model may include a process-centered organization and/or a structural organization of model tasks, functions, and data types. Capture includes mapping to the model functions and data types, and preferably also includes capturing other information about the asset and about the quality of mapping. The domain model may be used to build a search specification for searching for available assets that meet some or all of a set of functional (and/or nonfunctional) requirements. The search specification may also be published in part or in whole as a development specification.

Targeted asset capture, identification, and management

A system, method, and computer program for the creation and implementation of configurable Java classes on a computer platform executing instructions based upon at least a set of Java language instructions. The configurable Java class is created as an instance of a metaclass object included within the set of Java language instructions, and the configurable metaclass object includes a plurality of subclasses and interfaces wherein each interface includes one or more methods to alter the attributes and methods of the Java class instance of the metaclass object. The metaclass object is preferably implemented as an Enterprise JavaBean.

System and method for defining, configuring and using dynamic, persistent Java classes

In an object oriented computer system, a framework mechanism defines an infrastructure for allowing a user to flexibly define keys and their corresponding attributes. A special type of key called a specification key allows combinations of attributes to be specified, as well as set and range capabilities. An attribute retrieval policy is defined by a programmer to specify an algorithm or criteria that is used to calculating the desired attribute value. An attribute key controller contains key/value pairings for the attribute, contains the attribute retrieval policy, provides a maintenance interface for changing the attribute values; and provides a client interface for retrieving the attribute according to the attribute retrieval policy. The framework thus allows a user great flexibility in defining a suitable key/attribute retrieval mechanism by defining a suitable policy, defining one or more specification keys, and defining an associated controller.

Object mechanism and method for retrieving attribute values in a object oriented framework

An object oriented framework defines a generic order processing interface that creates an order, and that processes the order and generates requests to one or more fulfillment systems to fill the order. The generic order suitably includes one or more line items. One or more extensible interface classes are provided in the framework, which allows a user to define the order entry protocol for the relevant order fulfillment systems. Once properly extended, the framework is used to generate an executable framework application, which allows a client to enter a generic order, and which then generates the appropriate requests to fill the order with the appropriate order fulfillment system or systems. The framework of the preferred embodiments thus allows the specific knowledge of the back-end order fulfillment systems to be isolated to the extended portions of the framework, while the front-end order entry system has no knowledge of the order fulfillment systems that may be called upon to fill an order. The framework of the present invention thus allows adding a new order fulfillment system by simply extending the framework to define the attributes of the new fulfillment system without making changes to the core portion of the framework that governs how generic orders are processed.

Object oriented framework mechanism and method for providing a generic order entry processing interface for one or more order fulfillment systems

A method of developing a software system using Object Oriented Technology. The present invention addresses the problem of providing a technical foundation for the development of software applications using Object Oriented Technology and frameworks. The present invention solves this problem with a framework supporting flexible interchange of domain algorithms. The present invention is applicable in the technical field of application development of software systems, e.g. for a business application as Financial or Logistic and Distribution, wherein it is the purpose of frameworks to provide significant portions of the application that are common across multiple implementations of the application in a general manner, easy to extend for specific implementation.

Method of using decoupled chain of responsibility

In an object oriented computer system, a framework mechanism defines one or more run-time extensible items that may be dynamically reconfigured as required to support different interfaces at run-time. Each extensible item has one or more adapters that correspond to the extensions owned by the extensible item. The extensible item class defines a castTo( ) method. The castTo( ) method is invoked to logically cast an instance of the extensible item class to a desired class so that a selected method on that class can be called. When the castTo( ) method is invoked on an instance of the extensible item class, the extensible item object determines if any of its extensions have an adapter that supports the class specified in the castTo( ) method call. If an adapter does support the specified class, the adapter corresponding is returned, and the selected method is then invoked on the adapter. In this manner, class casting of run-time extensible items is achieved.

Class casting support for run-time extensible items in an object oriented framework

In an object oriented computer system, a framework mechanism defines a mechanism that separates the ability to complete a process from the results of that process. A task is defined in the framework in terms of a sequence of processes. The framework includes a coupling mechanism for flexibly coupling any of these processes together in any suitable order to define the run-time behavior of the framework without changing the core functions of the framework. The coupling mechanism includes the definition of a processable interface and a processing interface. A particular process generally takes detail information as input and produces detail information that is used in a subsequent process. The detail information input into a process is said to be &ldquo;processable&rdquo;, and therefore implements the &ldquo;processable&rdquo; interface. The detail information output from a process is said to be &ldquo;processing&rdquo; detail that is output to the next process, and therefore implements the processing interface. Thus, an object that uses &ldquo;shippable&rdquo; detail information as input through its processable interface generates corresponding &ldquo;shipping&rdquo; detail information for each shippable detail, which is output to one or more subsequent processes via the processing interface. A particular processable can be associated with any processing interface that supports the processable interface. In other words, any process-related class in the framework can be coupled to any other process-related class, provided one class has a processing interface that corresponds to the processable interface of the subsequent class. In this manner, classes in the framework mechanism can be flexibly coupled together in any suitable order or fashion to accommodate a great variety of different configurations. The framework mechanism therefore provides a high degree of implementation while maintaining the ability to achieve a high degree of customization.

Mechanism and method for flexible coupling of processes in an object oriented framework

In an object oriented computer system, a domain-neutral object is modified with domain-specific run-time extensions to customize the object to a particular domain. A special factory uses the extension identifier to create the domain-neutral object with appropriate extensions in a collection that corresponds to the domain extension. If the special factory is not available, or if a specialized collection associated with the particular extension type has not been previously created, the domain-neutral object with appropriate extensions is created in a default collection. In this manner, an object that is domain-neutral can be customized to a particular domain and created in an appropriate collection for objects of that type.

Object mechanism and method that creates domain-neutral objects with domain-specific run-time extensions in an appropriate collection

In an object oriented computer system, a framework mechanism defines an infrastructure for allowing a user to couple processes in the framework together in any suitable way to define a desired process flow. A user first defines a static object structure that corresponds to the specific process flow from one process to the next. The processes in the framework may be flexibly coupled in any suitable order, so a process does not have knowledge of its predecessor or successor processes. Thus, at run-time, a process determines the next step in the process flow from the static object structure. Once a process determines its subsequent process, a client may then create the next process and invoke methods on one or more objects corresponding to the newly-created process. Each process thus determines at run-time the next step in the process flow from the static object structure that the user statically defined to configure the process flow, which defines the desired processing environment.

Object mechanism and method for coupling together processes to define a desired processing environment in an object oriented framework

Growing community of inventors

Rochester, MN, United States of America

Brent Allen Carlson