Legal claims defining the scope of protection. Each claim is shown in both the original legal language and a plain English translation.
1. A method comprising: receiving, by a service requestor proxy system (SRPS), a service/vendor mapping data store including information indicative of: (i) an identity of a first service-oriented architecture (SOA) service that is provided by a first vendor, and (ii) an identity of a second (SOA) service that is provided by a second vendor; receiving a first SOA service request, from a first client device, over a communication network and by the SRPS, with the first service request being a request for performance of the first SOA service; determining, by the SRPS, that the first vendor performs the first SOA service based upon the service/vendor mapping data store; responsive to the determination that the first vendor performs the first SOA service, sending, by the SRPS, over the communication network and to a first vendor SOA performance system, a second SOA service request that requests performance of the first SOA service as a proxy on behalf of the first client device; receiving a third SOA service request, from a second client device, over the communication network and by the SRPS, with the third SOA service request being a request for performance of the second SOA service; determining, by the SRPS, that the second vendor performs the second SOA service based upon the service/vendor mapping data store; and responsive to the determination that the second vendor performs the second SOA service, sending, by the SRPS, over the communication network and to a second vendor SOA performance system, a fourth SOA request that requests performance of the second SOA service as a proxy on behalf of the second client device.
This invention relates to a system for managing service-oriented architecture (SOA) requests in a distributed computing environment. The problem addressed is the need for a centralized proxy system to efficiently route service requests from client devices to the appropriate vendor systems based on predefined mappings. The system includes a service requestor proxy system (SRPS) that maintains a service/vendor mapping data store. This data store contains information linking specific SOA services to the vendors that provide them, such as associating a first SOA service with a first vendor and a second SOA service with a second vendor. When the SRPS receives a service request from a client device, it consults the mapping data store to identify the vendor responsible for the requested service. For example, upon receiving a request for the first SOA service from a first client device, the SRPS determines the first vendor is the provider and forwards the request to the first vendor's SOA performance system as a proxy. Similarly, a request for the second SOA service from a second client device is routed to the second vendor's system. This approach ensures that service requests are directed to the correct vendor systems without requiring clients to know the specific vendor details, simplifying service consumption and improving scalability.
2. The method of claim 1 wherein: the first client device is controlled by a first enterprise entity; the second client device is controlled by the first enterprise entity; the SRPS is controlled by a second enterprise entity; the first vendor SOA performance system is controlled by a third enterprise entity; and the second vendor SOA performance system is controlled by a fourth enterprise entity.
This invention relates to a system for monitoring and analyzing the performance of service-oriented architecture (SOA) environments across multiple enterprise entities. The system addresses the challenge of tracking and evaluating SOA performance metrics in distributed environments where different components are managed by separate organizations. The method involves collecting performance data from multiple client devices and vendor SOA performance systems. The first client device and the second client device are both controlled by a single enterprise entity, ensuring centralized management of these endpoints. A service request processing system (SRPS) is managed by a second enterprise entity, handling service requests and responses between the client devices and external systems. Two vendor SOA performance systems are involved, each controlled by distinct enterprise entities, providing specialized performance monitoring and analysis capabilities. The system aggregates performance data from these disparate sources, allowing for comprehensive analysis of SOA operations. By integrating data from multiple enterprise-controlled components, the system enables cross-organizational performance tracking, identifying bottlenecks, and optimizing service delivery. The distributed architecture ensures that each enterprise retains control over its respective components while contributing to a unified performance monitoring framework. This approach enhances visibility into SOA performance across enterprise boundaries, improving efficiency and reliability in service-oriented environments.
3. The method of claim 1 wherein: the first client device is controlled by a first enterprise entity; the second client device is controlled by the first enterprise entity; the SRPS is controlled by the first enterprise entity; the first vendor SOA performance system is controlled by a second enterprise entity; and the second vendor SOA performance system is controlled by a third enterprise entity.
This invention relates to a system for monitoring and analyzing the performance of service-oriented architecture (SOA) environments across multiple enterprise entities. The system addresses the challenge of tracking performance metrics in distributed SOA environments where different components are managed by different organizations, leading to fragmented visibility and inefficiencies in troubleshooting. The system includes a shared reporting and performance system (SRPS) that aggregates performance data from multiple vendor SOA performance systems. Each vendor system monitors the performance of SOA components controlled by different enterprise entities. The SRPS collects and processes this data to provide a unified view of SOA performance across the entire distributed environment. The system ensures that performance metrics from client devices and other SOA components, regardless of their controlling enterprise, are integrated into a single reporting framework. The invention enables enterprises to monitor cross-enterprise SOA performance by centralizing data from multiple vendor systems. This allows for improved visibility, faster issue resolution, and better coordination between different enterprise entities involved in the SOA ecosystem. The system is particularly useful in scenarios where SOA components are managed by separate organizations, ensuring that performance data is consolidated and accessible to all relevant stakeholders.
4. The method of claim 1 wherein: the first client device is controlled by a first enterprise entity; the second client device is controlled by a second enterprise entity; the SRPS is controlled by a third enterprise entity; the first vendor SOA performance system is controlled by a fourth enterprise entity; and the second vendor SOA performance system is controlled by a fifth enterprise entity.
This invention relates to a system for monitoring and analyzing the performance of service-oriented architecture (SOA) environments across multiple enterprise entities. The system addresses the challenge of tracking performance metrics in distributed SOA environments where different components are managed by separate organizations, leading to fragmented visibility and inefficiencies in troubleshooting. The system includes a shared repository performance system (SRPS) that collects performance data from multiple vendor SOA performance systems. Each vendor system monitors specific SOA components, such as web services or application servers, and generates performance metrics like response times, throughput, and error rates. The SRPS aggregates this data, allowing enterprises to correlate performance issues across different systems and vendors. The method involves a first client device controlled by a first enterprise entity, which interacts with a second client device controlled by a second enterprise entity. The SRPS, managed by a third enterprise entity, receives performance data from a first vendor SOA performance system (controlled by a fourth enterprise entity) and a second vendor SOA performance system (controlled by a fifth enterprise entity). The SRPS processes this data to provide a unified view of SOA performance, enabling cross-enterprise collaboration in identifying and resolving performance bottlenecks. This approach ensures that performance data from disparate systems is centralized, improving visibility and reducing the time required to diagnose and address SOA-related issues. The system is particularly useful in multi-vendor, multi-enterprise environments where SOA components are distributed across different administrative domains.
5. The method of claim 1 further comprising: responsive to receipt of the second SOA service request, performing, by the first vendor SOA service performance system, the first SOA service on behalf of the first client device; and responsive to receipt of the fourth SOA service request, performing, by the second vendor SOA service performance system, the second SOA service on behalf of the second client device.
In the domain of service-oriented architecture (SOA) systems, this invention addresses the challenge of efficiently managing and performing SOA services across multiple vendor systems. The invention involves a distributed SOA service performance system where multiple vendor systems handle service requests from different client devices. The system includes at least two vendor SOA service performance systems, each capable of performing distinct SOA services. A first vendor system receives a second SOA service request from a first client device and performs a first SOA service on behalf of that client. Similarly, a second vendor system receives a fourth SOA service request from a second client device and performs a second SOA service on behalf of that client. The system ensures that each vendor system processes the appropriate service request for its designated client, enabling scalable and distributed service execution. This approach improves service reliability and performance by leveraging specialized vendor systems for different SOA services, reducing bottlenecks and enhancing overall system efficiency. The invention is particularly useful in environments where multiple clients require different SOA services, and vendor systems must dynamically handle requests without centralized coordination.
6. The method of claim 5 wherein: the performance of the first SOA service is carried out in a serviceless manner; and the performance of the second SOA service is carried out in a serviceless manner.
This invention relates to service-oriented architecture (SOA) systems, specifically addressing the challenge of executing SOA services in a stateless, or "serviceless," manner to improve scalability, reliability, and resource efficiency. Traditional SOA services often rely on persistent state management, which can introduce bottlenecks, increase complexity, and limit scalability. The invention describes a method where both a first and a second SOA service operate without maintaining internal state between invocations. This stateless approach ensures that each service request is processed independently, eliminating dependencies on prior interactions and reducing the risk of state-related failures. By decoupling service execution from persistent state management, the system achieves higher availability, easier horizontal scaling, and simplified fault isolation. The serviceless execution model allows services to be dynamically instantiated, executed, and terminated as needed, optimizing resource utilization. This method is particularly useful in cloud-native environments where stateless services align with modern microservices architectures and serverless computing paradigms. The invention enhances SOA systems by enabling more resilient, scalable, and efficient service interactions while maintaining the flexibility and modularity inherent in SOA designs.
7. A method comprising: receiving, by a service requestor proxy system (SRPS), a service/vendor mapping data store including information indicative of: (i) an identity of a first service-oriented architecture (SOA) service that is directly requested using a first communication protocol, and (ii) an identity of a second (SOA) service that is provided by a second communication protocol; receiving a first SOA service request, from a first client device, over a communication network and by the SRPS, with the first SOA service request being formed and formatted according to a generic communication protocol, with the first service request being a request for performance of the first SOA service, and with the generic communication protocol being different from the first communication protocol; determining, by the SRPS, that the first SOA service is to be directly requested in the first communication protocol based upon the service/vendor mapping data store; converting, by the SRPS, the first SOA service request from the generic communication protocol to a second SOA service request for performance of the first SOA service, with the second SOA service being formed and formatted according to the first communication protocol; sending, by the SRPS, over the communication network and to a first SOA performance system, the second SOA service request formed and formatted according to the first communication protocol; receiving a third SOA service request, from a second client device, over a communication network and by the SRPS, with the third SOA service request being formed and formatted according to the generic communication protocol, with the third SOA service request being a request for performance of the second SOA service, and with the generic communication protocol being different from the second communication protocol; determining, by the SRPS, that the third SOA service is to be directly requested in the second communication protocol based upon the service/vendor mapping data store; converting, by the SRPS, the third SOA service request from the generic communication protocol to a fourth SOA service request for performance of the second SOA service, with the fourth SOA service being formed and formatted according to the second communication protocol; and sending, by the SRPS, over the communication network and to a second SOA performance system, the fourth SOA service request formed and formatted according to the second communication protocol.
This invention relates to a system for bridging communication protocols in a service-oriented architecture (SOA) environment. The problem addressed is the incompatibility between different communication protocols used by various SOA services, which complicates direct client interactions. The solution involves a service requestor proxy system (SRPS) that acts as an intermediary, translating requests between a generic protocol used by clients and the specific protocols required by different SOA services. The SRPS maintains a service/vendor mapping data store that associates each SOA service with its required communication protocol. When a client device sends a service request in the generic protocol, the SRPS consults the mapping data store to determine the correct protocol for the requested service. The SRPS then converts the request from the generic protocol to the appropriate protocol and forwards it to the corresponding SOA performance system. This process is repeated for multiple services, allowing clients to interact with diverse SOA services without needing to handle protocol-specific formatting. The system ensures seamless communication by dynamically translating requests between protocols, thereby simplifying client interactions and improving interoperability in heterogeneous SOA environments.
8. The method of claim 7 wherein the second SOA performance system is the same as the first SOA performance system.
This invention relates to service-oriented architecture (SOA) performance monitoring and optimization. The problem addressed is the need to efficiently evaluate and improve the performance of SOA systems, which involve multiple interconnected services. The solution involves a method for analyzing and enhancing the performance of an SOA system by comparing its performance metrics against those of another SOA system. The method includes collecting performance data from the first SOA system, such as response times, throughput, and resource utilization. This data is then compared with performance data from a second SOA system, which may be a different instance or configuration of the same SOA system. The comparison identifies performance discrepancies, inefficiencies, or bottlenecks. Based on this analysis, adjustments are made to the first SOA system to improve its performance, such as optimizing service configurations, load balancing, or resource allocation. The method ensures that the second SOA system serves as a benchmark or reference for performance optimization, allowing for iterative improvements. The invention is particularly useful in environments where multiple SOA systems operate, enabling cross-system performance tuning and standardization.
9. The method of claim 7 wherein the second SOA performance system is different than the first SOA performance system.
This invention relates to service-oriented architecture (SOA) performance monitoring, addressing the challenge of evaluating and comparing performance across different SOA systems. The method involves using a first SOA performance system to measure performance metrics of a service-oriented architecture, such as response times, throughput, or resource utilization. A second SOA performance system, distinct from the first, is then used to measure the same or similar metrics. The results from both systems are compared to identify discrepancies, validate performance data, or assess the effectiveness of different monitoring approaches. The method may include analyzing the differences between the two systems' outputs to determine which system provides more accurate or reliable performance measurements. This comparison can help optimize SOA performance monitoring by identifying the strengths and weaknesses of each system, ensuring more robust and reliable performance assessments. The approach is particularly useful in environments where multiple performance monitoring tools or frameworks are deployed, allowing for cross-verification and improved decision-making in SOA management.
10. The method of claim 7 wherein the second client device is the same as the first client device.
A system and method for managing data synchronization between client devices in a distributed computing environment addresses the challenge of ensuring consistent and efficient data updates across multiple devices. The invention involves a synchronization process where a first client device initiates a data update request to a server, which then propagates the update to a second client device. The method ensures that the second client device receives and applies the update in a manner that maintains data consistency. In one embodiment, the second client device is the same as the first client device, meaning the synchronization process may involve a single device updating its own data in a coordinated manner, such as when a device recovers from a failure or reconnects after a disconnection. The system may use timestamps, version numbers, or other metadata to track changes and resolve conflicts. The method may also include error handling mechanisms to ensure updates are applied correctly, even if the second client device is temporarily unavailable. This approach improves reliability and consistency in distributed data management, particularly in scenarios where devices may operate intermittently or offline.
11. The method of claim 7 wherein the second client device is different than the first client device.
A system and method for managing data access across multiple client devices addresses the challenge of securely and efficiently sharing data between different devices in a networked environment. The invention enables a first client device to request access to data stored on a second client device, where the second client device is distinct from the first. The system verifies the identity of the first client device and checks whether it has the necessary permissions to access the requested data. If authorized, the system retrieves the data from the second client device and transmits it to the first client device. The method ensures secure data transfer by encrypting the data during transmission and validating the integrity of the data before and after transfer. The system also logs access attempts and data transfers for auditing purposes. This approach allows users to access data from different devices while maintaining security and control over data sharing. The invention is particularly useful in environments where multiple devices need to share data securely, such as in enterprise networks or collaborative workspaces.
12. The method of claim 7 further comprising: responsive to receipt of the second SOA service request, performing, by the first vendor SOA service performance system, the first SOA service on behalf of the first client device; and responsive to receipt of the fourth SOA service request, performing, by the second vendor SOA service performance system, the second SOA service on behalf of the second client device.
In the domain of service-oriented architecture (SOA) systems, this invention addresses the challenge of efficiently managing and performing SOA services across multiple vendor systems. The invention involves a distributed SOA service performance system where multiple vendor systems handle service requests from different client devices. The system includes at least two vendor SOA service performance systems, each capable of performing distinct SOA services. When a first client device sends a second SOA service request, the first vendor system performs a first SOA service on behalf of the client. Similarly, when a second client device sends a fourth SOA service request, the second vendor system performs a second SOA service for that client. The system ensures that each vendor system processes requests independently, allowing for scalable and modular service execution. This approach enhances flexibility and reliability by distributing service responsibilities across multiple vendors, reducing bottlenecks and improving overall system performance. The invention is particularly useful in environments where multiple clients require different SOA services, and vendors must efficiently manage and execute these services without central coordination.
13. The method of claim 12 wherein: the performance of the first SOA service is carried out in a serviceless manner; and the performance of the second SOA service is carried out in a serviceless manner.
This invention relates to service-oriented architecture (SOA) systems, specifically addressing the challenge of executing SOA services in a stateless, scalable, and resource-efficient manner. Traditional SOA services often rely on persistent service instances, leading to inefficiencies in resource utilization and scalability. The invention introduces a method for performing SOA services in a "serviceless" manner, eliminating the need for dedicated service instances. The method involves executing a first SOA service and a second SOA service, both operating without maintaining persistent state or dedicated service instances. Instead, each service is invoked dynamically, leveraging stateless execution environments. This approach allows for on-demand processing, reducing overhead and improving scalability. The serviceless execution ensures that resources are allocated only when needed, optimizing system performance and reducing costs associated with idle service instances. By decoupling service execution from persistent infrastructure, the invention enables seamless integration with modern cloud-native architectures, such as serverless computing models. The serviceless SOA services can be triggered by events, scheduled tasks, or API calls, providing flexibility in deployment and operation. This method enhances efficiency, scalability, and adaptability in SOA-based systems, making it suitable for dynamic and high-demand environments.
14. A method comprising: receiving, by a service requestor proxy system (SRPS), a service/vendor mapping data store including information indicative of: (i) an identity of a first service-oriented architecture (SOA) service that is directly requested from a first vendor using a first communication protocol, and (ii) an identity of a second (SOA) service that is provided by a second vendor a second communication protocol; receiving a first SOA service request, from a first client device, over a communication network and by the SRPS, with the first SOA service request being formed and formatted according to a generic communication protocol, with the first service request being a request for performance of the first SOA service, and with the generic communication protocol being different from the first communication protocol; determining, by the SRPS, that the first SOA service is to be directly requested in the first communication protocol based upon the service/vendor mapping data store; determining, by the SRPS, that the first vendor performs the first SOA service based upon the service/vendor mapping data store; converting, by the SRPS, the first SOA service request from the generic communication protocol to a second SOA service request for performance of the first SOA service, with the second SOA service being formed and formatted according to the first communication protocol; responsive to the determination that the first vendor performs the first SOA service, sending, by the SRPS, over the communication network and to a first SOA performance system, the second SOA service request formed and formatted according to the first communication protocol; receiving a third SOA service request, from a second client device, over a communication network and by the SRPS, with the third SOA service request being formed and formatted according to the generic communication protocol, with the third SOA service request being a request for performance of the second SOA service, and with the generic communication protocol being different from the second communication protocol; determining, by the SRPS, that the third SOA service is to be directly requested in the second communication protocol based upon the service/vendor mapping data store; converting, by the SRPS, the third SOA service request from the generic communication protocol to a fourth SOA service request for performance of the second SOA service, with the fourth SOA service being formed and formatted according to the second communication protocol; determining, by the SRPS, that the second vendor performs the second SOA service based upon the service/vendor mapping data store; and responsive to the determination that the second vendor performs the second SOA service, sending, by the SRPS, over the communication network and to a second SOA performance system, the fourth SOA service request formed and formatted according to the second communication protocol.
This invention relates to a service requestor proxy system (SRPS) that facilitates communication between client devices and service-oriented architecture (SOA) services provided by different vendors using different communication protocols. The system addresses the challenge of integrating multiple SOA services from various vendors, each requiring distinct protocols, into a unified framework that clients can access using a generic communication protocol. The SRPS maintains a service/vendor mapping data store that associates each SOA service with its corresponding vendor and the specific communication protocol required to interact with that vendor. When a client device submits a service request in the generic protocol, the SRPS consults the mapping data store to identify the appropriate vendor and protocol for the requested service. The system then converts the client's request from the generic protocol to the vendor-specific protocol and forwards it to the vendor's SOA performance system. For example, if a client requests a first SOA service, the SRPS determines the vendor and protocol for that service, converts the request accordingly, and sends it to the vendor. Similarly, if another client requests a second SOA service from a different vendor, the SRPS performs the same conversion and routing process. This approach ensures seamless interoperability between clients and diverse SOA services, abstracting the complexity of vendor-specific protocols behind a unified interface. The system dynamically adapts to different vendors and protocols, enabling efficient service integration without requiring clients to handle protocol-specific details.
15. The method of claim 14 further comprising: responsive to receipt of the second SOA service request, performing, by the first vendor SOA service performance system, the first SOA service on behalf of the first client device; and responsive to receipt of the fourth SOA service request, performing, by the second vendor SOA service performance system, the second SOA service on behalf of the second client device.
This invention relates to a system for managing service-oriented architecture (SOA) services across multiple vendors. The problem addressed is the need for efficient and secure delegation of SOA service requests between different vendor systems while ensuring proper authentication and authorization. The system includes a first vendor SOA service performance system and a second vendor SOA service performance system, each capable of performing specific SOA services. A first client device sends a first SOA service request to the first vendor system, which authenticates the request and performs the requested service. The first vendor system then generates a second SOA service request, which is sent to the second vendor system. The second vendor system authenticates this request and performs the corresponding service. Similarly, a second client device sends a third SOA service request to the second vendor system, which authenticates and processes it. The second vendor system then generates a fourth SOA service request, which is sent to the first vendor system for authentication and service execution. The system ensures that each vendor system only performs services for which it is authorized, with proper authentication and authorization checks at each step. This approach allows for distributed SOA service execution while maintaining security and operational integrity across multiple vendor systems. The invention enables seamless delegation of service requests between vendors, improving efficiency and scalability in SOA environments.
16. The method of claim 15 wherein: the performance of the first SOA service is carried out in a serviceless manner; and the performance of the second SOA service is carried out in a serviceless manner.
This invention relates to service-oriented architecture (SOA) systems, specifically addressing the challenge of executing SOA services in a stateless, or "serviceless," manner to improve scalability, reliability, and resource efficiency. Traditional SOA services often rely on persistent state management, which can introduce bottlenecks, complexity, and dependencies that hinder performance and flexibility. The invention provides a method for performing SOA services without maintaining state between invocations, ensuring that each service instance operates independently and can be dynamically scaled or replaced without disrupting the system. The method involves executing a first SOA service and a second SOA service, both in a serviceless manner. In this context, "serviceless" means that neither service retains any state between executions, relying instead on stateless protocols and self-contained request-response interactions. This approach eliminates the need for centralized state management, reducing latency and improving fault tolerance. The services may interact with other components, such as databases or external APIs, but do so in a way that does not depend on persistent session data. The invention may also include additional features, such as dynamic service discovery, load balancing, or event-driven triggers, to further enhance system adaptability. By decoupling services from stateful dependencies, the invention enables more resilient, scalable, and maintainable SOA implementations.
Unknown
June 2, 2020
Browse 5M+ US patents with plain-English claim translations and AI-generated analysis.