Middleware application environment

Abstract

A software application framework includes a framework interface domain for interfacing a platform domain with application domain software of an application domain. The framework also includes a software application domain that includes a first application entity. The first application entity is adapted to interact with at least one of a second application entity, the framework interface domain, at least one utility entity, and at least one plug-in entity.

Description

RELATED APPLICATION(S)[0001]This application claims priority from and incorporates herein by reference the entire disclosure of U.S. Provisional Application Ser. No. 60 / 412,769, filed Sep. 23, 2002 and bearing Attorney Docket No. 53807-00055USPL. This application claims priority from and incorporates herein by reference the entire disclosure of U.S. Provisional Application Ser. No. 60 / 412,901, filed Sep. 23, 2002 and bearing Attorney Docket No. 53807-00050USPL. This application claims priority from and incorporates herein by reference the entire disclosure of U.S. Provisional Application Ser. No. 60 / 412,902, filed Sep. 23, 2002 and bearing Attorney Docket No. 53807-00057USPL. This application incorporates herein by reference the entire disclosure of each of the following U.S. patent applications: 1) U.S. patent application Ser. No. 10 / 359,911, filed Feb. 7, 2003 and bearing Attorney Docket No. 53807-00023USPT; 2) U.S. patent application Ser. No. 10,359,772, filed Feb. 7, 2003 and be...

AI Technical Summary

Benefits of technology

This framework reduces the need for 'plumbing code' by encapsulating dependencies, allowing for efficient real-time multitasking and flexible development, while enabling seamless integration and porting of legacy code by providing a unified environment for handling different problem areas with minimal OS-specific paradigms.

Problems solved by technology

However, developers of real-time application software are often required to spend an inordinate amount of time writing code that only serves the purpose of supporting actual application-related functionality (i.e., so-called plumbing code) for new software applications.

In addition, writing this lower-level plumbing code is usually considered to be more error-prone than writing higher level application software.

Most existing frameworks offer an environment that is either too generic or too restricted.

Most frameworks are too generic in the sense that they offer only low-level services that are similar to primitives supported by most operating systems (OS) and that offer considerable flexibility but also require generation of considerable plumbing code.

Other frameworks are too restricted in terms of flexibility in that they: 1) offer limited possibilities to dynamically add new functionality to the framework or scale away code or functionality not needed; 2) do not offer multithreading capabilities; or 3) support only one event notification model (e.g., message (event pull) or callback (event push), but not both).

In addition, most frameworks do not address legacy problems that are created when a developer ports previous investments in code to a new framework.

Many of the legacy problems listed above arise from a structural mismatch (e.g., different OS paradigms) between an old system and the framework to which the code is to be ported.

From an application programmers' perspective, it would thus be desirable to maximize a ratio between application code and necessary, but from an application developer's point of view, unproductive support code.

However, many frameworks do not provide a high-level application-domain environment, but instead merely allow a system to be divided into low-level processes, etc .

Images