Data processing: software development – installation – and managem – Software program development tool – Managing software components
Reexamination Certificate
1999-06-30
2004-01-13
Ingberg, Todd (Department: 2124)
Data processing: software development, installation, and managem
Software program development tool
Managing software components
C717S122000, C709S241000
Reexamination Certificate
active
06678882
ABSTRACT:
TECHNICAL FIELD
The present invention relates generally to collaborative applications, and more particularly to a collaboration model which can support the introduction of new object types into deployed network environments.
BACKGROUND ART
When a software system is to support an organization of software elements and humans working together, system designers must be concerned with certain community acts. The least complex of these acts is known as coordination, i.e., the act of harmonizing the performance of activities that may or may not have a common purpose such as the avoidance of resource conflicts. This harmonizing introduces the basic notions of concurrent systems, such as mutual exclusion, deadlock, and starvation. The act of working together toward a common purpose or end is known as cooperation, and typically involves coordination plus a synchronization of efforts. For example, the ordering of events among objects in order to achieve a certain goal requires an agreement among them to transmit signals indicating when certain events have taken place.
The most complex of the community acts is known as collaboration. This involves cooperation on a common effort requiring intelligence, defined here as the ability to acquire knowledge through experience, i.e., to learn, and to apply that knowledge. Arguably, both humans and software have the potential to exhibit intelligence.
A collaborative system is a software system that allows multiple agents to collaborate and communicate by sharing objects. An agent is a human or a software element possessing some degree of intelligence. Examples of software agents are software systems external to the collaborative system and workflow processes such as automated business processes within the collaborative system.
An object is a unit of software that often, but not always, corresponds to something in a real-world problem domain. People who extensively use direct-manipulation graphical user interfaces generally tend to blur the distinction between a software object, its graphical manifestation in a user interface, and its real-world referent. When viewed as software units, the shared objects referred to above with respect to a collaborative system may range in complexity from relatively simple passive objects that exhibit only reactive control (e.g, data objects that are stored in data bases), to active objects capable of proactive control and which can initiate interactions with other objects, to autonomous objects that exhibit intelligence by adapting their control mechanisms and behavior. Popular buzzwords for autonomous objects include “agent” and “business object.”
A collaborative system provides object sharing, replication, and distribution; change detection and notification; change collection and reporting; change merging with conflict identification and resolution whenever possible; and propagation of changes and unresolved conflicts to agents. The key issue to be addressed in the design of a collaborative system is providing the collaborating agents with appropriate (not necessarily consistent) views of what is going on in the most efficient way for a particular collaborative situation. Before designing a collaborative system, designers must consider the range of collaborative situations the system is required to handle, and the constraints imposed by development and deployment environments.
Collaborative situations can be distinguished by sometimes-independent features. An example of one such situation is when each agent works with a local copy of an original object that is persistent on some central server. Here, there is no sharing among agents, but synchronization of the local copies with the persistent, original object will be required eventually. Another situation is when each agent works on objects that are independent of objects worked on by other agents. Here, the object sharing supports only inter-agent communication, e.g., to inform what each agent is doing. In yet another example, multiple agents work on the same objects or on objects that are interdependent. Here, object sharing supports not only inter-agent communication but also cooperation. Other situations are as follows: agents are working at different times; agents are working at the same time, but at locations that prohibit communication; agents are working at the same time and in locations that support real or near-real time communication; explicit rules exist for resolving conflicting changes so that resolution of conflicting changes (made by one or more agents) can be automated; only implicit rules exist for resolving conflicts so that conflict resolution cannot be automated; whether the agent population includes both humans and software elements; and the importance of protecting information and restricting access to it.
As an example of a collaborative situation, consider the following. Certain employees of a telecommunications service provider, each with a different role (set of responsibilities), collectively satisfy a customer service order, such as for two phone lines to a residence. Here, object sharing supports inter-agent communication and cooperation. Agents work independently (asynchronously) on some tasks and in concert (synchronously) on others. Some conflict resolution can be automated, while other conflict resolution requires human intervention. The agents include humans and software. Different agents have different access to information based on laws, regulations, agent role, and business considerations.
A number of considerations impact the design of the software to be developed and deployed. Such considerations include the number of developers (vendors) involved. The larger the number, the greater the need for an open architecture and a high degree of programming-language independence. Another consideration is the number of external systems with which the proposed system must interact. This consideration has the same consequences as the number of developers. Yet another consideration is the expected lifespan, which is influenced by economics and technology. To have a life that is both long and successful, a software system must have high evolvability. Further examples include whether it is reasonable for mobile agents to perform their work by using the collaborative system while physically connected to a central server, and the constraints imposed on the choice of client software for mobile and stationary agents. For example, are agents constrained to using only thin clients, like Web browsers.
Open architecture, programming-language independence, and evolvability are critical. Systems with open architectures provide well-defined interfaces that facilitate extension by (metaphorically) plugging in a new software component or swapping one software component for another. Such systems also promote the use of frameworks that allow systems to be configured by assembling and parameterizing components (modern techniques for configuring systems dynamically, i.e., at runtime).
Programming-language independence means that software elements will be able to work together independent of the programming language in which they were written. It allows different vendors to work in different programming languages. By definition, it means that developers can work and think closer to a conceptual level of the application problem and further away from the coding level of the programmed solution. Evolvability encompasses open architectures and programming-language independence and is discussed in more detail below.
For mobile agents, situations sometimes make it difficult or impossible to work while connected (wired or wireless) by mobile devices such as notebook computers. The application requires rapid response but the connections are slow or unreliable. The application is used in locations where physical connection is impossible. In such situations, the objects to be shared must be distributed, i.e., downloaded to the mobile devices.
In contrast, stationary agents usually access shared objects that reside on a central server. The current trend in industry
Habermehl Kyle D.
Hurley William D.
Brooks & Kushman P.C.
Ingberg Todd
Qwest Communications International Inc.
LandOfFree
Collaborative model for software systems with... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Collaborative model for software systems with..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Collaborative model for software systems with... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3253992