Service provider integration framework

• US 20030208583A1
• Filed: 07/30/2002
• Published: 11/06/2003
• Est. Priority Date: 03/14/2002
• Status: Active Grant

• Current Assignee: SAP SE
• Original Assignee: SAP AG (SAP SE)
• Inventors: Schroeder, Norbert
• Granted Patent: US 7,055,134 B2
• Time in Patent Office: Days
• US Class Current: 709/223
• CPC Class Codes: G06F 9/465 Distributed object oriented systems remote method invocation [RMI] G06F9/548

Abstract

Methods and data processing apparatus, including computer program products, providing and implementing an integration framework for service providers, where a persistent object identifier object is used to provide a general reference to a persistent object of a service provider. A service provider has a service provider client, a service provider backend, and a service provider repository for storing service provider persistent objects. The service provider provides to its objects the services of storage of persistent objects in the service provider repository; visualization of objects in the service provider client, and access to objects in the service provider backend. The framework has a client framework and a backend framework. The client framework communicates directly with the backend framework, and the backend framework performs non-visual operations on the service provider backend.

Claims

1. A data process system, comprising:

means for establishing a class role, a class role being a computer programming construct that assigns to a class occupying the class role a functionality in terms of a set of interfaces, where the class role defines each interface in the set as being either mandatory or optional;

means for determining dynamically a class for the class role at runtime; and

means for instantiating a programming object from the dynamically determined class.

2. The system of claim 1, further comprising:

means by which the class determined dynamically can be accessed from a program at runtime.

3. The system of claim 1, wherein the class role further defines each interface in the set as being either visual or nonvisual.

4. A computer program product, tangibly embodied on a computer-readable medium, comprising instructions operable to:

establish a class role, a class role being a computer programming construct that assigns to a class occupying the class role a functionality in terms of a set of interfaces, where the class role defines each interface in the set as being either mandatory or optional;

determine dynamically a class for the class role at runtime; and

instantiate a programming object from a class determined dynamically for the class role at runtime.

5. The product of claim 4, further comprising instructions to:

access the class determined dynamically from a program at runtime.

6. The product of claim 4, wherein the class role further defines each interface in the set as being either visual or nonvisual.

7. A data processing system, comprising:

a service provider, the service provider comprising a service provider client, a service provider backend, and a service provider repository for storing service provider persistent objects, where the service provider provides to its objects the services of storage of persistent objects in the service provider repository;

visualization of objects in the service provider client, and access to objects in the service provider backend;

a framework comprising a client framework and a backend framework, where the client framework communicates directly with the backend framework, and the backend framework performs non-visual operations on the service provider backend; and

a persistent object identifier (POID) object providing a general reference to a first persistent object of the service provider, the POID including information identifying the service provider and a primary key distinguishing the first persistent object from all other objects of the service provider;

where the framework is operable to use information identifying the service provider to determine which among all the service providers known to the framework is the service provider identified by the POID, and the service provider is operable to use the primary key to obtain the first persistent object.

8. The system of claim 7, wherein:

the POID object is maintained in a persistent form as an Extensible Markup Language (XML) document.

9. The system of claim 7, wherein:

the POID object is a model for a service provider repository object that does not yet exist.

10. The system of claim 7, wherein:

all client platform dependencies of the framework are in the client framework; and

all client platform dependencies of the service provider are in the service provider client.

11. The system of claim 7, wherein:

the framework generates dynamically all object instances of service provider objects.

12. The system of claim 7, wherein:

all objects that are part of the framework are instantiated dynamically by means of a class role, a class role being a computer programming construct that assigns to a class occupying the class role a functionality in terms of a set of interfaces, where the class role defines each interface in the set as being either mandatory or optional.

13. The system of claim 7, wherein the framework is operable to:

coordinate queries and searches over multiple service providers;

register service providers;

arrange requests between different service providers;

provide an object factory with late binding; and

provide an abstract class hierarchy for specialization through service providers.

14. A computer program product, tangibly embodied on a computer-readable medium, comprising instructions operable to:

implement a service provider, the service provider comprising a service provider client, a service provider backend, and a service provider repository for storing service provider persistent objects, where the service provider provides to its objects the services of storage of persistent objects in the service provider repository;

visualization of objects in the service provider client, and access to objects in the service provider backend;

implement a framework comprising a client framework and a backend framework, where the client framework communicates directly with the backend framework, and the backend framework performs non-visual operations on the service provider backend; and

implement a persistent object identifier (POID) object providing a general reference to a first persistent object of the service provider, the POID including information identifying the service provider and a primary key distinguishing the first persistent object from all other objects of the service provider;

where the framework is operable to use information identifying the service provider to determine which among all the service providers known to the framework is the service provider identified by the POID, and the service provider is operable to use the primary key to obtain the first persistent object.

15. The product of claim 14, further comprising instructions to:

maintain the POID object in a persistent form as an Extensible Markup Language (XML) document.

16. The product of claim 14, further comprising instructions to:

implement the POID object as a model for a service provider repository object that does not yet exist.

17. The product of claim 14, further comprising instructions to:

implement all client platform dependencies of the framework in the client framework; and

implement all client platform dependencies of the service provider in the service provider client.

18. The product of claim 14, further comprising instructions to:

generate dynamically by the framework all object instances of service provider objects.

19. The product of claim 14, further comprising instructions to:

instantiate all objects that are part of the framework dynamically by means of a class role, a class role being a computer programming construct that assigns to a class occupying the class role a functionality in terms of a set of interfaces, where the class role defines each interface in the set as being either mandatory or optional.

20. The product of claim 14, further comprising instructions making the framework operable to:

coordinate queries and searches over multiple service providers;

register service providers;

arrange requests between different service providers;

provide an object factory with late binding; and

provide an abstract class hierarchy for specialization through service providers.