Method of generating a services repository using a target services roadmap

• US 7,739,228 B1
• Filed: 12/20/2005
• Issued: 06/15/2010
• Est. Priority Date: 12/20/2005
• Status: Expired due to Fees

• Current Assignee: AT&T Corporation (AT&T, Inc.)
• Original Assignee: AT&T Intellectual Property II LP (AT&T, Inc.)
• Inventors: Erickson, Richard R., Polston, Steven
• Primary Examiner(s): Rones, Charles
• Assistant Examiner(s): Quader, Fazlul
• Application Number:
  US11/275,228
• Time in Patent Office: 1,638 Days
• Field of Search: 707/3
• US Class Current: 707/602
• CPC Class Codes: G06F 2209/462 Lookup
• CPC Class Codes: G06F 9/465 Distributed object oriented systems remote method invocation [RMI] G06F9/548

Abstract

A repository of services, a system for building a repository of services, a method of building a repository of services and various other embodiments associated with the repository are disclosed. The method relates to a method of building a repository of services using a target services roadmap. The method comprises receiving from a user an identification of an implemented service and zero or more target services and mapping the implemented service to the zero or more target services. The target services and/or mapped implemented services are added to the repository.

Claims

1. A computer-implemented method of building a repository of services using a target services roadmap, the method causing a computing device to perform steps comprising:

receiving a target services roadmap for a service oriented architecture (SOA) repository, the target services roadmap comprising an abstractly-described listing of functional services and defining a group of target services yet to be identified and assimilated into the SOA repository, and which are unimplemented, wherein the listing of functional services relate to the definition of implemented services and target services consists of at least one of;

service name, service description, service version, host system, taxonomy, target or implemented service identification, comments, operations including operation name, operation description, operation parameters including parameter name, parameter description, in-or-out-or-in-out type, at least one of required or optional or conditional designation, data domain, URL linkage to data dictionary, middlewares, interface definition documents associated with each middleware, clients, interface agreements associated with each client, contacts, and dependent services;

iteratively, until a SOA repository of services is complete according to the target services roadmap, performing the steps;

receiving a selection from a user via a field in a user interface of an implemented service in a SOA;

mapping the selected service to zero or more target services based on the target service roadmap; and

building the SOA repository of services including the mapped, implemented service.

2. The method of claim 1, wherein the listing of functional services further consists of at least one of:

service phase, operation phase and relation to a target service.

3. The method of claim 1, wherein the taxonomy comprises a domain and a subgroup, optionally an eTOM Vertical, and at least one of Level 1 or Level 2 or Level 3 eTOM Process specification.

4. The method of claim 1 wherein the implemented service goes through phases and different versions comprising development, production and deprecation.

5. The method of claim 1, further comprising:

receiving from a user an edit of one of the implemented service or a target service within the target services roadmap.

6. The method of claim 1, wherein the step of mapping the implemented service to zero or more target services in the target service roadmap further comprises:

mapping the implemented service to zero or more target services based on functional correspondence.

7. The method of claim 6, wherein if a target service or services is specified, then the method further comprises mapping each operation in the implemented service to zero or at most one operation in the target service(s).

8. The method of claim 1, further comprising:

monitoring at least one service at runtime to determine whether a definition associated with the at least one service in the repository of services is accurate.

9. The method of claim 8, further comprising:

monitoring parameters associated with at least one of;

the service, operation clients, versions, middlewares and host systems; and

determining whether there are discrepancies between the monitored parameters and definitions in the repository to find discrepancies.

10. The method of claim 8, further comprising:

monitoring service and operations implemented in arbitrary middlewares by embedding logging callouts in service operation implementations.

11. The method of claim 10, further comprising:

logging callouts supported at different log levels specifying the collection of an increasing amount of management information comprising at least one of;

invocation occurrences, invocation authorization failures, service operation exits and callouts to other identified service operations.

12. The method of claim 11, further comprising:

logging callouts going either directly to a centralized database of management information or going to local disk where the callouts are subsequently processed and delivered to the centralized database of management information.

13. The method of claim 12, further comprising:

logging callouts collecting information on at least one of;

the service and operation IDs invoked, service version, service host system, calling client system, initiating principal behind the calling client system, authorization status, timestamp, type of log record, transaction ID, service exit information, and service and operation IDs called by the invoked service.

14. The method of claim 1, wherein the implemented service and a target service associated with the target roadmap are associated with a dashboard of management information combining data collected at runtime with data stored in the repository to report on at least one of:

service operation characteristics and service-oriented architecture program effectiveness including target services offered by applications and domains, implemented services offered by applications and domains, percent of target services complete and amount of service reuse by service and domains.

15. The method of claim 1, wherein the implemented service and target services associated with the target services roadmap are associated with an arbitrary taxonomy.

16. The method of claim 1, wherein the implemented or target service is defined by specifying at least one of:

the HRID of the person defining the implemented service, a taxonomy domain, a taxonomy subgroup, an optional eTOM taxonomy, a service name, a service description, a version, a host OSS system, a specification of whether the service is a target service or implemented service, a development phase if an implemented service, contacts, comments, one or more operations including operation data parameters, one or more middlewares and associated interface artifacts, clients and interface agreements.

17. The method of claim 16, wherein, when defined, globally unique service and operation IDs are assigned for target services and/or the implemented service.

18. The method of claim 16, further comprising presenting options to the user to edit any of the entered information associated with the implemented service and target services.

19. The method of claim 16, wherein at least one of the listed parameters provides a drop-down menu to the user for further selection of features associated with the parameter, and at least one of the listed parameters provides a pop-up screen to lookup information linked from other systems of record.

20. The method of claim 1, further comprising validating received information from the user for the implemented service.

21. The method of claim 1, further comprising:

for both target services and the implemented service, validating a form associated with receiving from the user information associated with either a target service or the implemented service.

22. The method of claim 1, wherein the method further comprises:

determining whether the implemented service name has the same name as a target service within the same part domain and subgroup taxonomy.

23. The method of claim 22, wherein if the implemented service name has a similar name as the target service within the domain and subgroup taxonomy, then confirming with the user that the implemented service is an instantiation of the same named target service.

24. The method of claim 23, wherein the mapping of the implemented service to zero or more target services is performed upon user confirmation.

25. The method of claim 16, wherein the following list of parameters associated with the implemented service are optional parameters:

comments, additional contacts and dependencies.

26. The method of claim 25, wherein the following additional list of parameters associated with the implemented service is optional:

operations, middlewares and clients.

27. The method of claim 16, wherein receiving a definition of the domain parameter further comprises requiring the user to select one value from an arbitrary list of values, which includes the following taxonomy of domains:

billing and account management, capacity management, data access, decision support, ebonding, servicing, finance, infrastructure, network and element management, other, recording management, sales and marketing, service assurance, service delivery and workcenter architecture.

28. The method of claim 16, wherein receiving a definition of the taxonomy of subgroup parameters further comprises requiring the user to select at least one value from an arbitrary list of value specific to each domain, which includes the following list:

billing and account management domain subgroups, capacity management domain subgroups, data access domain subgroups, decision support domain subgroups, ebonding domain subgroups, servicing domain subgroups, finance domain subgroups, infrastructure domain subgroups, network and element management domain subgroups, recording management domain subgroups, sales and marketing domain subgroups, service assurance domain subgroups, service delivery domain subgroups and workcenter architecture domain subgroups.

29. The method of claim 17, wherein the list of domains and subgroups are changed by accessing an admin screen, enabling edit, addition and deletion of domain and subgroup names.

30. The method of claim 1, further comprising:

engaging in a dialog with the user to obtain input associated with the listing of functional services.

31. The method of claim 1, wherein the repository is a service-oriented architecture repository.

32. The method of claim 1, further comprising:

adding the target service or mapped implemented service to the repository.

33. The method of claim 31, wherein the service-oriented architecture repository places services within a taxonomy of domains and subgroups, and the method further supports the build-out of the target services roadmap by:

enabling new feature and product architectures and solution designs to view, specify and build out the service oriented target services in parallel; and

mapping each implemented service back to the target service roadmap upon completion of feature development.

34. The method of claim 31, wherein once implemented services have been defined, the implemented services are viewed and specified for reuse on new feature and product solutions.

35. The method of claim 16, wherein at least one of the listed parameters provides a pop-up screen that enables selection of standard data objects organized by a data taxonomy.