WO2013147780A1

WO2013147780A1 - A conceptual services implementation platform

Info

Publication number: WO2013147780A1
Application number: PCT/US2012/031046
Authority: WO
Inventors: Joe Robert Hill; Steven H. MARNEY; Michael K. Smith; Sumit Bandyopadhyay
Original assignee: Hewlett-Packard Development Company, L.P.
Priority date: 2012-03-29
Filing date: 2012-03-29
Publication date: 2013-10-03
Also published as: EP2831751A1; US20140344782A1; CN104081381A; US9589037B2; EP2831751A4; CN104081381B

Abstract

The present disclosure generally relates to computing methods and applications. A service platform includes standard functionalities that can be used in different applications, such as composite applications. The service platform includes a database that stores application specific information, which is mapped to the standard functionalities. To use these functionalities, different applications initialize relevant parts of the database and uses predefined standards to access these functionalities.

Description

A CONCEPTUAL SERVICES IMPLEMENTATION PLATFORM

BACKGROUND

[0001] The present disclosure generally relates to computing methods and applications.

[0002] With the advent of the computer and network technologies, more and more software tools and applications become available to provide solutions to individuals and business entities. Often, programmers build software applications by combining existing software solutions and functions, usually for the reasons of cost saving. As an example, an application that is formed by combining multiple existing service implementations can be loosely referred to as a composite application. This type of application can be referred to by other names as well. Usually, a composite application comprises functionalities from more than one source and a logic portion that governs how these functionalities are used and interact with one another.

BRIEF DESCRIPTION OF THE DRAWINGS

[0003] Figure 1 is a simplified diagram illustrating a conceptual services implementation platform (CSIP) within the context of a composite application platform.

[0004] Figure 2 is a simplified diagram illustrating entities and their relationships for service implementation and dependency support system (SIDSS).

[0005] Figure 3 is a simplified sequence diagram for Message Transformation operation Create From SI (Service Implementation).

[0006] Figure 4 is a simplified sequence diagram for Message Transformation operation Create To SI.

[0007] Figure 5 is a simplified sequence diagram for Message Transformation operation Read SI.

[0008] Figure 6 is a simplified diagram illustrating an enterprise integration patterns representation for Message Transformation Read SI.

[0009] Figure 7 is a simplified sequence diagram for Message Transformation operation Update or Delete From SI. [0010] Figure 8 is a simplified sequence diagram for Message Transformation operation Update or Delete From SI.

[0011] Figure 9 is a simplified sequence diagram for Service Facade operation oNew.

[0012] Figure 10 is a simplified sequence diagram for Service Facade operation oChange.

[0013] Figure 11 is a simplified sequence diagram for the Service Facade operation oRemove.

[0014] Figures 12A and 12B are simplified sequence diagrams for Service Facade operations oGet and uGet.

[0015] Figures 13A-D are simplified sequence diagrams for oGet and uGet usage patterns.

[0016] Figure 14 is a simplified sequence diagram for Service Integration operation uNew.

[0017] Figure 15 is a simplified sequence diagram for Service Integration operation uChange.

[0018] Figure 16 is a simplified sequence diagram for Service Integration operation uRemove.

[0019] Figure 17 is a simplified diagram illustrating a human resources conceptual services design.

[0020] Figure 18 is a simplified diagram illustrating a computer system that can be used to implement a CSIP system.

DETAILED DESCRIPTION

[0021] The present disclosure generally relates to computing methods and applications. A service platform includes standard operations that can be used to implement composite applications. The service platform includes a database that stores information on conceptual services and service implementations; each conceptual service can have a plurality of service implementations. The service platform automatically sends standard operation service requests to appropriate service implementations; the appropriate service implementation for a request may be determined by the customer who is making the request. Some service requests trigger additional requests, which the platform handles automatically.

[0022] Existing technologies are often inadequate for various reasons. Typically, for composite applications, existing solutions typically provide design patterns and generic integration platforms. Problems with these solutions include: (i) they enable developers to create solutions that do not conform to the best patterns (e.g., lack of abstract canonical service interfaces and over-reliance on point-to-point integration); (ii) they do not follow the principles of model driven architecture, but instead require developers to construct platform- specific implementation code for each platform separately; (iii) they require system engineers to create domain solutions, instead of enabling domain experts to specify domain designs that are directly executable; (iv) the existing published design patterns are at a much finer grained level than is needed, in other words, they are elementary building blocks rather than high- level meta-patterns that are needed for multi-tenant, configurable, composite services; and (v) these other solutions do not address the traceability issues from the business context to the conceptual services to the logical designs to the physical technologies to the executable code.

[0023] Typically, composite applications are built by combining functionalities from multiple applications, services, and/or sources. By using functionalities that are already available, it is possible to build composite applications faster than starting from scratch. However, the complexity of composite applications, especially when delivered as multi- tenant configurable services, creates obstacles to success at every stage of the lifecycle: conception, design, development, deployment, operation, and continuous release. Some of this complexity is inherent to the problem being solved, but much of it is artificially introduced by failing to treat composite applications as the new solution type they are.

[0024] In general, composite applications are complex. They combine cross-functional, role-based user experiences, case- and message-based workflows, interoperable canonical business services (each delivered via multiple optional service implementations), multi-tenant customer configurations, together with security, logging, monitoring, self-service sales, metering, billing, etc. Each of these components is a challenge in itself, but is still much simpler than their combination. Further, composite applications often require formal traceability from the business context to the conceptual services to the logical designs to the physical technologies to the executable code, which are not dealt with coherently by existing application methodologies.

[0025] These challenges have resulted in multiple failures in development projects, customer contracts, and service line offerings and portfolios. The difficulties negatively affect code quality, time to market, development and maintenance costs, and agile rapid release. In addition, the avoidable complexities often cause software engineers to forget to follow good design principles based on model driven architecture, including standardized domain-independent platform architectures and platform-independent portable domain designs.

[0026] It is to be appreciated that, in contrast, by focusing on the specific problems associated with composite applications and by leveraging our Role-based Domain

Architecture (RDA) methodology and tools, we have developed a design methodology that reduces the avoidable complexity in these solutions. As described in the present disclosure, we have defined a domain-independent composite application platform, appropriate RDA meta-models for capturing platform-independent domain models, and the code- and configuration-generating drivers that make executable designs a reality for composite applications. The present disclosure describes a portion of the platform that provides managing multiple implementations of conceptual services and their dependencies. It is to be appreciated the methods and systems described in the present disclosure are comparable to that of a relational database management system, which can be combined with a database design tool for composite, service-oriented, message-based, event-driven, multi-tenant, as-a- service software, the resulting designs being used to generate configuration files and patterned code that is deployable on the runtime platform. The methods and systems described in the present disclosure focus on one sub-problem of this big picture, the problem of managing multiple implementations for conceptual services and their dependencies within a configurable and multi-tenant environment.

[0027] Figure 1 is a simplified diagram illustrating a conceptual services implementation platform (CSIP) within the context of a composite application platform. This diagram is merely an example, which should not unduly limit the scope of the claims herein. One of ordinary skill in the art would recognize other variations, modifications, and alternatives. The CSIP 100 comprises the following service components ("SI" stands for "Service Implementation" and prefixes "o-" and "u-" indicate "owning" and "using" services, respectively): Service Fa ade 105, Service Integration 106, Message Broker 107, Message Transformation 108, SIDSS 1 10, and SI API 11 1. Depending on the implementations, these service components can be modified, replaced, and/or combined. It is to be understood that the service components may be referred to using other terms. As an example, the CSIP 100 can be implemented using one or more computer systems and/or a service orientated architecture. Various components of the CSIP 100 can be implemented as software modules stored on computer readable mediums and executed by processors. Depending on the application, one or more components of the CSIP 100 may be added, removed, modified, and/or replaced. [0028] To use the CSIP 100, a user interfaces with the service facade 105 of the CSIP 100. As shown in Figure 1, the REST API services 104 depends on the Service Facade 105, which provides standard functions that REST API Services 104 can access. The REST API Services 104 provides an interface for the UI Composite Client 102 and the Service

Implementation 103. For example, UI Composite Client 102 can be a composite application that uses multiple standard operations provided by the CSIP 100, and to access these operations, the composite application uses the REST API services 104 which interact with the Service Fagade 105.

[0029] The Service Integration and Dependency Support System (SIDSS) 1 10 performs various operations and owns fundamental objects (a) Services, Fundamental Object

Schemas, Service Dependencies 1 12; (b) Service Implementations, SI Object Schemas, Schema Transformations 1 13; (c) Customers and their SI Picks 1 14; (d) Customer Object Instances and their Mappings 115. The SIDSS 1 10 exposes these fundamental objects through standard CRUD (Create, Retrieve, Update, Delete) operations.

[0030] The Message Broker 107 owns fundamental object Customer Object Instances in Queues. In addition, the Message Broker 107 exposes operators oPublish and uSubscribe.

[0031] The Message Transformation 108, as shown, exposes operations Create from SI, Create To SI, Read SI, Update or Delete From SI, and Update or Delete To SI. These operations are described below and illustrated in Figures 3-8.

[0032] The Service Fa ade 105 exposes operations oNew, oChange, oRemove, oGet, and uGet. In addition, the Service Facade 105 interfaces with the REST API Services 104. For example, upon receiving a service request from the REST API Services 104, the Service Facade 105 executes the appropriate CSIP operations to satisfy the service request.

[0033] The Service Integration 106 exposes operations uNew, uChange, and uRemove.

[0034] The components of the CSIP 100 work with and depend on one another. These services have the following dependencies as illustrated in Figure 1 :

Service Facade 105 depends on (a) SIDSS 110; (b) Message Broker 107: oPublish; and (c) Message Transformation 108.

Service Integration 106 depends on (a) SIDSS 110; (b) Message Broker 107:

uSubscribe; and (c) Message Transformation 108.

Message Broker 107 depends on SIDSS 110. Message Transformation 108 depends on (a) SIDSS 110 and (b) (called) Service Implementation 11 1.

[0035] For example, to access and use the CSIP 100, a composite application UI Composite Client 102 or (calling) Service Implementation 103 depends on REST API Services 104, which depends on Service Facade 105. And to access the (called) Service Implementation 111, the composite application interacts with the CSIP 100 through REST API Services 104, which depends on Service Facade 105, which depends on Service Transformation 108, which depends on Service Implementation 11 1.

[0036] As can be seen from Figure 1 and the description above, many components of the CSIP 100 depend on the SIDSS 110. It is to be appreciated that the SIDSS 1 10 provides dependency supports that allow functionalities of CSID 100 components to operate with one another and provide services to composite applications.

[0037] Figure 2 is a simplified diagram illustrating entities and their relationships for the Service Implementation and Dependency Support System (SIDSS). This diagram is merely an example, which should not unduly limit the scope of the claims herein. One of ordinary skill in the art would recognize other variations, modifications, and alternatives. The SIDSS 200 uses SIDSS tables to store the data needed by SIDSS to perform its responsibilities to support various components of the CSIP, including Service Fa ade, Service Integration, Message Broker, and Message Transformation. The SIDSS 200 provides standard CRUD (Create, Retrieve, Update, Delete) operations for each of the tables in the diagram. As an example, the SIDSS 200 can be implemented using one or more network database systems or servers to store the SIDSS tables. For example, each of these tables can be implemented as a database or a record entry at a database.

[0038] The SIDSS database 200 includes domain information 210, service implementation information 220, customer information 230, and operational information 240. Domain information 210 includes Domain table 211, Service table 212, FundamentalObjectSchema table 213, and ServiceUsesFundamentalObject table 214. Service implementation information 220 includes Servicelmplementation table 221 ,

ServicelmplementationObjectSchema table 222, and SchemaTransformation table 223. Customer information 230 includes Customer table 231 and CustomerServiceConfiguration table 232. Operational information 240 includes FundamentalObjectlnstance table 241, ServicelmplementationObjectlnstance table 242, and ObjectlnstanceMapping table 243. [0039] The business data in the domain is represented as a set of fundamental objects stored in the FundamentalObjectSchema table 213, each of which is owned by one of the services in Service table 212. These fundamental object schemas are listed in

FundamentalObjectSchema table 213, which identifies the OwningService for each object. A fundamental object owned by one service may be used by other services, each of which is referred to as a UsingService. ServiceUsesFundamentalObject table 214 stores this information (i.e., relationships between services and various fundamental objects that they use). As an example, the structure of a fundamental object is represented as an XML Schema Design (XSD) which is stored in the FundamentalObjectXSD attribute of

FundamentalObjectSchema table 213. Instances of a fundamental object are represented as XML documents stored in the FundamentalObjectlnstanceXML attribute of

FundamentalObjectlnstance table 241. These XML documents conform to the corresponding FundamentalObj ectXSD .

[0040] The Servicelmplementation table 221 stores information on the service

implementations that implement the (conceptual) services. A Service Implementation (SI) that implements an OwningService is the system of record for the instances of fundamental objects owned by that OwningService.

[0041] The Customer table 231 stores information on the customers of the services. The CustomerServiceConfiguration table 232 stores the configuration details for each customer; this table has a row for each (Service, Customer) pair, in which ServicelmplementationID identifies the Servicelmplementation that this customer has picked to implement this Service. Rows are inserted into these tables whenever a new customer is introduced. The

CustomerServiceConfiguration table 232 provides links between services stored in the Service table 212 and implementations of services stored in the Servicelmplementation table 221. When the user (or the composite application of the user) needs to use a service provided by the CSIP and sends a service request, the SIDSS 200 refers to various tables to determine which services to use and how these services are implemented.

[0042] The service implementation information tables 220 on the right parallel the domain information tables 210 on the left. For example, alignment between the Service

Implementation Objects and the corresponding Fundamental Objects is made explicit in the SchemaTransformation table 223 in the middle. For example, the SchemaTransformation table 223 stores the XSLT files needed to translate between corresponding

FundamentalObjectlnstanceXML and ServicelmplementationObjectlnstanceXML documents. These transformations may also include data domain mappings (e.g., "Texas" in one representation might be "TX" in another; truncation and padding functions; etc.).

[0043] New rows are inserted into the Servicelmplementation table 221,

ServicelmplementationObjectSchema table 222, and SchemaTransformation table 223 whenever a new service implementation is introduced. The new service implementation can be a part of the CSIP functionalities and/or introduced by a customer.

[0044] Operation tables 240 include FundamentalObjectlnstance table 241,

ServicelmplementationObjectlnstance table 242, and the ObjectlnstanceMappmg table 243. Object mappings between FundamentalObjectlnstance table 241 and

ServicelmplmentationObjectlnstance table 242 are stored in the ObjectlnstanceMappmg table 243.

[0045] New rows are inserted into the FundamentalObjectlnstance table 241,

ServicelmplementationObjectlnstance table 242, and ObjectlnstanceMappmg table 243 when new instances occur in the execution of the composite application.

[0046] It is to be understood that while the tables illustrated in Figure 2 are referred to with specific names, other names can be used as well. Depending on the application, one or more tables in Figure 2 can be added, removed, renamed, modified, replaced, and/or combined.

[0047] Now referring back to Figure 1. As shown in Figure 1 , the CSIP 100 includes Message Broker 107, which is a component responsible for standard publish-subscribe operations.

[0048] Figures 3-8 are sequence diagrams for operations performed by Message

Transformation 108. Among other things, these figures provide details of Message

Transformation operations and their dependencies on SIDSS 110 and Service Implementation 111. While operations illustrated in Figures 3-8 are referred to with specific terms, it is to be understood that these operations and their variations can be referred to using other terms, and they should not unduly limit the claims.

[0049] Figure 3 is a simplified sequence diagram for Message Transformation operation Create From SI. This diagram is merely an example, which should not unduly limit the scope of the claims herein. One of ordinary skill in the art would recognize other variations, modifications, and alternatives. For example, one or more processes performed in Figure 3 can be added, removed, modified, replaced, rearranged, repeated, and/or overlapped. As shown in Figure 3, the operation Message Transformation: Create From SI includes three steps: (i) routing flow, which obtains the ServicelmplementationID information from the CustomerServiceConfiguration table (e.g., element 232 in Figure2) for this Customer and Service from the SIDSS; (ii) schema validation, which obtains

ServicelmplementationObjectXSD information from the SIDSS and uses it to check the ServicelmplementationObjectlnstanceXML document; and (iii) transformation flow, which obtains and applies FromServicelmplementationXSLT from the SIDSS to form the corresponding FundamentalObjectlnstanceXML document.

[0050] Figure 4 is a simplified sequence diagram for Message Transformation operation Create To SI. This diagram is merely an example, which should not unduly limit the scope of the claims herein. One of ordinary skill in the art would recognize other variations, modifications, and alternatives. For example, one or more processes performed in Figure 4 can be added, removed, modified, replaced, rearranged, repeated, and/or overlapped. As shown in Figure 4, the operation Message Transformation: Create To SI has five steps: (i) routing flow from the SIDSS; (ii) schema validation, which gets FundamentalObjectXSD from the SIDSS and uses it to check the FundamentalObjectlnstanceXML document; (iii) transformation flow, which obtains and applies ToServicelmplementationXSLT to form the corresponding ServicelmplementationObjectlnstanceXML document; (iv) adaptor flow, which obtains and applies ServicelmplementationProtocolAdaptor; and (v) Service

Implementation API call, which creates the new instance in the Service Implementation (e.g., SI API 11 1 in Figure 1).

[0051] Figure 5 is a simplified sequence diagram for Message Transformation operation Read SI. This diagram is merely an example, which should not unduly limit the scope of the claims herein. One of ordinary skill in the art would recognize other variations,

modifications, and alternatives. For example, one or more processes performed in Figure 5 can be added, removed, modified, replaced, rearranged, repeated, and/or overlapped. As shown in Figure 5, to provide a service implementation, certain information is obtained from the SIDSS and processed, based on which service is processed by the service implementation component of the CSIP.

[0052] Figure 6 is a simplified diagram illustrating the Message Transformation Read SI operation using enterprise integration patterns. This diagram is merely an example, which should not unduly limit the scope of the claims herein. One of ordinary skill in the art would recognize other variations, modifications, and alternatives. For example, one or more processes or modules can be added, removed, modified, replaced, rearranged, repeated, and/or overlapped. As shown in Figure 6, a request is provided in standard protocol. After processed by various modules of the CSIP as a part of the "Request Spoke", the Service Implementation module performs the requested service, and the "Response Spoke" provides a response in Standard Protocol. It is to be appreciated that the CSIP modules are standard modules that provide functionalities that can be used by composite applications. To use these modules and functionalities, a user does not have to make customized modules for the composite application; instead, the user simply uses standard inputs to use these modules. In contrast, existing methods typically require users to customize these modules before utilizing them in a composite application, thereby often causing integration problems.

[0053] Figures 7 and 8 are simplified sequence diagrams for operations performed by the Message Transformation component 108 of the CSIP 100. Figure 7 is a simplified sequence diagram for Message Transformation operation Update or Delete From SI. This diagram is merely an example, which should not unduly limit the scope of the claims herein. One of ordinary skill in the art would recognize other variations, modifications, and alternatives. For example, one or more processes performed in Figure 7 can be added, removed, modified, replaced, rearranged, repeated, and/or overlapped. As shown in Figure 7, update or delete from SI functions are performed in conjunction with the SIDSS.

[0054] Figure 8 is a simplified sequence diagram for Message Transformation operation Update or Delete To SI. This diagram is merely an example, which should not unduly limit the scope of the claims herein. One of ordinary skill in the art would recognize other variations, modifications, and alternatives. For example, one or more processes performed in Figure 8 can be added, removed, modified, replaced, rearranged, repeated, and/or overlapped. As shown in Figure 8, update or delete to SI functions are performed in conjunction with the SIDSS and the service implementation component. For example, after needed information is obtained from the SIDSS, the service implementation is carried out by the service implementation component.

[0055] Figures 9-12 are sequence diagrams for the operations performed by the Service Fa ade 105 component of the CSIP 100. While operations illustrated in Figures 9-12 are referred to with specific terms, it is to be understood that these operations and their variations can be referred to using other terms, and they should not unduly limit the claims. Figure 9 is a simplified sequence diagram for Service Facade operation oNew. This diagram is merely an example, which should not unduly limit the scope of the claims herein. One of ordinary skill in the art would recognize other variations, modifications, and alternatives. For example, one or more processes performed in Figure 9 can be added, removed, modified, replaced, rearranged, repeated, and/or overlapped. As shown in Figure 9, the oNew operation is performed with Message Transformation 108, SIDSS 110, and Message Broker 107 components of the CSIP 100. Among others, the Message Broker 107 performs an oPublish of the new fundamental object instance.

[0056] Figure 10 is a simplified sequence diagram for Service Facade operation oChange. This diagram is merely an example, which should not unduly limit the scope of the claims herein. One of ordinary skill in the art would recognize other variations, modifications, and alternatives. For example, one or more processes performed in Figure 10 can be added, removed, modified, replaced, rearranged, repeated, and/or overlapped. As shown in Figure 10, the oChange operation is performed with the Message Transformation 108, the SIDSS 110, and the Message Broker 107 components of the CSIP 100. Among others, the Message Broker 107 performs an oPublish of the change to the fundamental object instance.

[0057] Figure 11 is a simplified sequence diagram for Service Facade operation oRemove. This diagram is merely an example, which should not unduly limit the scope of the claims herein. One of ordinary skill in the art would recognize other variations, modifications, and alternatives. For example, one or more processes performed in Figure 1 1 can be added, removed, modified, replaced, rearranged, repeated, and/or overlapped. As shown in

Figurel 1 , the oRemove operation is performed with Message Transformation 108, SIDSS 110, and Message Broker 107 components of the CSIP 100. Among others, the Message Broker 107 performs an oPublish of the remove of the fundamental object instance.

[0058] Figures 12A and 12B are simplified sequence diagrams for Service Fagade operations oGet and uGet. These diagrams merely provide an example, which should not unduly limit the scope of the claims herein. One of ordinary skill in the art would recognize other variations, modifications, and alternatives. As shown in Figure 12A, the oGet function is performed by the Message Transformation 108 component of the CSIP 100. Figure 12B shows that the uGet function is performed by the Message Transformation 108 component of the CSIP 100.

[0059] Figures 13A-D are simplified sequence diagrams for usage patterns for operations oGet and uGet. This diagram is merely an example, which should not unduly limit the scope of the claims herein. One of ordinary skill in the art would recognize other variations, modifications, and alternatives. As an example, in Figure 13 A, to use oGet function, request of OwningService goes to OwningService's system of record (e.g., stored in the SDISS 200 in Figure 2). [0060] Figures 14-16 are sequence diagrams for operations performed by the Service Integration 106 component of the CSIP 100: uNew, uChange, and u emove. While operations illustrated in Figures 14-16 are referred to with specific terms, it is to be understood that these operations and their variations can be referred to using other terms, and they should not unduly limit the claims. To perform operations of the Service Integration 106 component, these three steps are performed: (i) uSubscribe to the Message Broker 107 fundamental object queue; (ii) call the relevant Message Transformation 108 operator; and (iii) make the appropriate updates to the SIDSS 110 database.

[0061] Figure 14 is a simplified sequence diagram for Service Integration operation uNew. This diagram is merely an example, which should not unduly limit the scope of the claims herein. One of ordinary skill in the art would recognize other variations, modifications, and alternatives. For example, one or more processes performed in Figure 14 can be added, removed, modified, replaced, rearranged, repeated, and/or overlapped. As an example, the process starts with a new fundamental object (FO) instance, which calls for the uNew operation of the Service Integration 106. The uNew operation calls for Create To SI operation of the Message Transformation 108. Since a new FO is to be created, the relevant database tables of the SIDSS are updated.

[0062] Figure 15 is a simplified sequence diagram for Service Integration operation uChange. This diagram is merely an example, which should not unduly limit the scope of the claims herein. One of ordinary skill in the art would recognize other variations,

modifications, and alternatives. For example, one or more processes performed in Figure 15 can be added, removed, modified, replaced, rearranged, repeated, and/or overlapped. As an example, the process starts with a change to a FO instance, which calls for the uChange operation of the Service Integration 106. The uChange operation calls for the Update or Delete To SI operation of the Message Transformation 108. Since an existing FO is to be changed, the relevant database tables (e.g., FundamentalObjectlnstance and/or

ServicelmplementationObjectlnstance) of the SIDSS are updated.

[0063] Figure 16 is a simplified sequence diagram for Service Integration operation uRemove. This diagram is merely an example, which should not unduly limit the scope of the claims herein. One of ordinary skill in the art would recognize other variations, modifications, and alternatives. For example, one or more processes performed in Figure 16 can be added, removed, modified, replaced, rearranged, repeated, and/or overlapped. As an example, the process starts with a remove FO instance, which calls for the uRemove operation of the Service Integration 106. The uRemove operation calls for the Update or Delete To SI operation of the Message Transformation 108. Since an existing FO is to be removed, the relevant database tables (e.g., FundamentalObjectlnstance and/or

ServicelmplementationObjectlnstance) of the SIDSS are updated.

[0064] The CSIP described in the present disclosure simplifies multi-tenant composite applications by standardizing the architecture, design patterns, and executable platform for service implementation and integration. This standard platform reduces risk, improves quality, shortens time-to-market, and lowers development and maintenance costs. The CSIP 100 is not just a set of design patterns; rather it is a platform that implements the design patterns. It is analogous to a relational database management system for service

implementation and integration.

[0065] Additionally, the CSIP provides executable designs possible for service

implementation and integration. This encourages domain design experiments with quick cycle times to improve such solutions. Use of the system can occur in four stages: (a) each domain design; (b) each service implementation; (c) each customer setup; and (d) customer instances that occur during runtime. Automating these makes it much easier to create and run multi-tenant composite applications. This is analogous to database design tools (e.g., ERWin) for service implementation and integration. For example, given two composite applications both use a function provided by the CSIP, neither application needs a specialized or customized version of that function, as the function is a standard CSIP function; to utilize this function for different uses, the SIDSS is configured accordingly. The composite applications have different information stored at the SIDSS, and the information stored at the SIDSS dictates how this function behaves when used by these two different applications.

[0066] Moreover, the CSIP provides the basis for solving the traceability problem for composite applications. It explicitly ties the executable code and configurations for service implementation and integration to the business context, conceptual services, logical design, and physical technologies. It makes executable designs possible.

[0067] Figure 17 is a simplified diagram illustrating a human resources conceptual services design. This diagram is merely an example, which should not unduly limit the scope of the claims herein. One of ordinary skill in the art would recognize other variations,

modifications, and alternatives. The human resources (HR) conceptual services design provides an example of using a CSIP. A composite application for HR domain 1700 comprises three services: Workforce Administration (WFA) 1704, Payroll Administration (PAY) 1701 , and Health & Welfare Benefits (HWB) 1707. The Service WFA 1704 owns fundamental objects Employee Demographics 1705 and Org Structures 1706. The service PAY owns fundamental objects Bank Accounts 1702 and Deposit Allocations 1703. The service HWB 1707 owns fundamental objects Options 1708 and Enrollment Selections 1709. The services PAY 1701 and HWB 1707 both depend on the WFA 1704: Retrieve. The PAY 1701 also depends on the HWB 1707: Retrieve. For example, the domain model also includes the FundamentalObjectSchemas.

[0068] Once the HR domain 1700 is set up, then service implementations for each of the services are listed. For example, SAP and/or Oracle applications can be used to implement the WFA 1704 and the PAY 1701. Automatic Data Processing as-a-service offerings can be used to implement PAY 1701. Towers Perrin and Hewitt implementations can be used for the HWB 1707. These are examples of popular HR service implementations that can be incorporated within the service ecosystem. It is to be understood these services can be implemented using other types of applications as well. Other users or entities might also have their own service implementations for these services. Finally, individual customers might have custom implementations or contracts with other third-party providers for one or more of WFA, PAY, and HWB.

[0069] For each of these service implementations, the ServicelmplementationObjects, their ServicelmplementationObjectSchemas, and the XSLT mappings between these schemas and the FundamentalObjectSchemas need be specified. For example, when implementing these services, relevant information is entered into the SIDSS database. Given the list of service implementations, each customer identifies their picks for the implementation of each of the services. New service messages for the various customers are automatically routed to the appropriate service implementations of the CSIP, and these messages are automatically processed appropriately. As described above, a user or customer simply identifies the implementation of service functionalities in order to use the CSIP functionalities, as opposed to redefining or customizing these services as commonly used in existing techniques. The parameters and behaviors of the components of the CSIP are standardized, thereby freeing the customer or user from having to create them from scratch for each solution.

[0070] Use of the CSIP is illustrated in the following two use cases. The operators are defined above. An arrow (->) indicates an initiating event arising from a source external to the CSIP.

[0071] To create a new employee, the following steps are performed: Create Employee Capture new Employee information (i.e., EmployeeName, EmployeeAddress)

- WFA oNew EmployeelD = new Employee(EmployeeName,

EmployeeAddress)

includes WFA oPublish Employee(EmployeeID, EmployeeName,

EmployeeAddress)

PAY uSubscribe to uNew Employee(EmployeeID, EmployeeName,

EmployeeAddress)

HWB uSubscribe to uNew Employee(EmployeeID, EmployeeName,

EmployeeAddress)

[0072] For example, to create the new employee information, which includes name and address, the external source (e.g., end user) initiates the oNew operation by the WFA, which invokes the oPublish operation by the WFA. To use the oNew operation, the WFA access the oNew operation of the Service Facade component of the CSIP. The oPublish operation is processed by the Message Broker of the CSIP. The PAY and HWB services need access to the new employee information, and to do that they utilize the uSubscribe operation of the Message Broker component and the uNew operation of the Service Integration component.

[0073] To provide another example, the following steps are performed to update information for an existing employee:

Update Employee Address

Capture updated EmployeeAddress

- WFA oChange Employee(EmployeeID, updated EmployeeAddress)

includes WFA oPublish Employee(EmployeeID, updated

EmployeeAddress)

PAY uSubscribe to uChange Employee(EmployeeID, updated

EmployeeAddress)

Create "New Account and/or Change Deposit Allocation " case

Employee is presented with option to add new Account and/or Change Allocation

Capture new Account and/or new Allocation from the Employee -> PAY oNew AccountID = Account(AccountName, BankID,

AccountRoutingNumber)

-> PAY oChange updated list of Allocation(EmployeeID, AccountID, DepositPercent)

HWB uSubscribe to uChange Employee(EmployeeID, updated

EmployeeAddress)

Create "Update Enrollment Selections" case (e.g., with 30 day timer)

Present Employee updated EligibilityOptions implied by updated Employ e A ddress

Capture updated EnrollmentSelections from the Employee

- HWB oChange updated list of EnrollmentSelections(EmployeeID, OptionID)

Includes HWB oPublish updated list of EnrollmentSelections(EmployeeID, OptionID) PAY uSubscribe to uChange updated list of EnrollmentSelections(EmployeeID, OptionID)

PAY updates Employee's payroll deductions to reflect updated

Enrollments elections

[0074] It is to be appreciated that the CSIP system described in the present disclosure may be implemented using various types of systems. Figure 18 is a simplified diagram illustrating a computer system that can be used to implement a CSIP system. This diagram is merely an example, which should not unduly limit the scope of the claims herein. One of ordinary skill in the art would recognize other variations, modifications, and alternatives. For example, the computer system in Figure 18 comprises a computer readable medium (e.g., hard disk, solid state memory, optical drive, etc.) that stores program instructions that can be executed by processors to perform various functions of the CSIP system and SIDSS databases. It is to be appreciated that CSIP systems can be implemented using a network computing device, including but not limited to SOA systems. There can be other embodiments as well.

[0075] While the above is a full description of the specific embodiments, various modifications, alternative constructions and equivalents may be used. Therefore, the above description and illustrations should not be taken as limiting the scope of the present invention which is defined by the appended claims.

Claims

WHAT IS CLAIMED IS:

1. A method of providing one or more operations, the method comprising: providing a database having a computer readable medium;

storing a set of domain information at the computer readable medium, the domain information comprising domain parameters for conceptual service information, fundamental objects information, and service dependency information;

storing a set of service implementation information, the service implementation information comprising service implementation parameters for representations of the fundamental objects and service implementation information for the fundamental objects, the service implementation information being associated with operations executable by a processing module;

storing a first set of customer configuration information;

initializing the domain parameters and the service implementation parameters based on at least the set of customer configuration information;

storing a set of operational information;

receiving a first service request for an operation related to a first fundamental object;

processing the first service request to determine a first service implementation; determining a first parameter for performing the first service implementation; and performing the first service implementation using a set of operations associated with the first service implementation.

2. The method of claim 1 further comprising transforming the first parameter to a representation of a fundamental object.

3. The method of claim 1 wherein the domain information comprises a database table for conceptual services.

4. The method of claim 1 further comprising performing a service update operation.

5. The method of claim 1 further comprising a database for storing the customer configuration information, domain information, and service implementation information.

6. The method of claim 1 wherein a plurality of representations of a fundamental object corresponds to a first representation of the fundamental object.

7. The method of claim 1 further comprising a database storing dependencies between the representations of the fundamental objects and the fundamental objects.

8. The method of claim 1 further comprising executing a plurality of operations associated with the first service implementation.

9. The method of claim 1 wherein a set of operational information corresponds to the fundamental objects.

10. The method of claim 9 wherein the set of operational information comprises fundamental object instances, service implementation object instances, and mappings between them.

11. The method of claim 1 further comprising associating the first set of customer information to the conceptual services.

12. A method for implementing and integrating conceptual services, the method comprising:

providing a service facade module;

providing a message broker module;

providing a service integration module;

providing a message transformation module;

providing a service implementation and dependency support system (SIDSS) module, the SIDSS module providing a database, a create operation, a read operation, an update operation, and a delete operation, the SIDSS module comprising a domain table, a service table, a fundamental object schema table, a service uses fundamental object table, a service

implementation table, a service implementation object schema table, a schema transformation table, a customer table, a customer service configuration table, a fundamental object instance table, a service implementation object instance table, and an object instance mapping table; initializing at least the domain, service, fundamental object schema, service uses fundamental object, service implementation, service implementation object schema, schema transformation, customer, and customer service configuration tables;

receiving a first service fa ade operation request from a customer comprising at least a first canonical parameter;

processing the first service facade operation request to determine a first service implementation associated with the first service fa ade operation request using at least the customer service configuration table; and

determining a first service implementation parameter for performing the first service facade operation request using at least the schema transformation table, the first service implementation parameter being associated with the first service implementation and the first canonical parameter; and performing the first service implementation with the first service implementation parameter.

13. The claim of claim 12 wherein:

the service facade module provides an oNew operation, an oGet operation, an oChange operation, an oRemove operation, and an uGet operation;

the message broker module provides an oPublish operation and an uSubscribe operation;

the service integration module provides an uNew operation, an uChange operation, and an uRemove operation; and

the message transformation module provides a Create From SI operation, a Create To SI operation, a Read SI operation, an Update or Delete From SI operation, and an Update or Delete To SI operation.

14. The method of claim 12, wherein the SIDSS modules comprise a database.

15. An apparatus of providing one or more operations, the method comprising:

a processing module;

a computer readable medium comprising: codes for storing a first set of customer configuration information at the computer readable medium;

codes for storing a set of domain information in the computer readable medium, the domain information comprising parameters for conceptual service information, fundamental objects information, and service dependency information;

codes for initializing the parameters based at least on the set of customer configuration information;

codes for storing a set of service implementation information, the service implementation information comprising representations of the fundamental objects and service implementation information for the fundamental objects, the service

implementation information being associated with operations executable by a processing module;

codes for storing a set of operational information;

codes for receiving a first service request for an operation related to a first fundamental object;

codes for processing the first service request to determine a first service implementation;

codes for determining a first parameter for performing the first service implementation; and

codes for performing the first service implementation using a set of operations associated with the first service implementation.