Personal Messaging API for Groupware Integration
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing groupware and personal information management systems are proprietary, making it difficult and expensive for enterprises to integrate their data and information with other applications, leading to inconsistencies and inefficiencies due to overlapping functionalities between systems like Microsoft Exchange and CRM applications.
Innovation Solution
A personal messaging interface is developed as a collection of Java API libraries that facilitates interoperability between applications and collaboration systems like Microsoft Exchange and Lotus Domino, allowing developers to integrate applications without knowing the specific interfaces of these systems, using a schema and provider implementations to connect to various collaboration servers without rewriting code.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If proprietary groupware systems are used, then specific functionality is provided, but integration difficulty increases
Solution Approach 1:
The patent introduces a messaging interface as an intermediary layer between applications and collaboration servers. This interface includes abstract classes and concrete implementations that mediate communication, allowing applications to access groupware functionality without directly interfacing with proprietary systems. The intermediary handles the complexity of integration internally while presenting a simplified interface to developers.
Solution Approach 2:
The messaging interface is designed as a universal solution that works with multiple collaboration server types (Microsoft Exchange, Lotus Domino, etc.) through a common API. The abstract messaging interface defines standard operations that can be implemented by different server-specific providers, enabling one interface to serve multiple functions across different proprietary systems.
2Reliability
If proprietary groupware systems are used, then specific functionality is provided, but integration cost increases
Solution Approach 1:
The messaging interface acts as a cost-effective intermediary that standardizes access to expensive proprietary systems. By providing a unified interface layer, organizations avoid the need to develop and maintain separate integration solutions for each collaboration server, reducing overall integration costs while maintaining access to proprietary functionality.
Solution Approach 2:
The interface allows parameter changes in the form of configurable connection settings and protocol options. Applications can adjust connection parameters to work with different server types without changing core logic, reducing development and maintenance costs associated with multiple specialized integration approaches.
3Adaptability or versatility
If multiple collaboration servers are supported, then interoperability improves, but interface complexity increases
Solution Approach 1:
The messaging interface implements universality by providing a single standardized API that works with multiple collaboration server types. The interface defines common messaging operations that are implemented differently by each server-specific provider, allowing one interface to handle multiple server types without increasing apparent complexity for the application developer.
Solution Approach 2:
The interface is segmented into abstract base classes that define the universal interface and concrete implementation classes that handle server-specific logic. This segmentation separates the simple universal interface from the complex server-specific implementations, allowing high interoperability while hiding interface complexity in the implementation layer.
Data Source
AI summary
A personal messaging application programming interface can be utilized by a developer in order to add groupware functionality to an application. The interface can include various schemas and providers that allow the schemas to connect to a collaboration server which provides the groupware functionality. The schemas can further include item and container classes and can extend other schemas so as to provide functionality that is more specific to the collaboration server. The items and containers can represent various entities on the collaboration server. The providers can use stubs in order to create connections to the collaboration server and can implement the schema hierarchy so as to map the functionality defined by the schema into various core calls on the collaboration server.