WO2008037788A2

WO2008037788A2 - Service metadata management in service-oriented architecture

Info

Publication number: WO2008037788A2
Application number: PCT/EP2007/060297
Authority: WO
Inventors: John Colgrave; Raymond Walter Ellis
Original assignee: International Business Machines Corporation
Priority date: 2006-09-29
Filing date: 2007-09-28
Publication date: 2008-04-03
Also published as: GB0619248D0

Description

SERVICE METADATA MANAGEMENT IN SERVICE-ORIENTED

ARCHITECTURE

This invention relates to service definition management in a service-oriented architecture.

BACKGROUND

Service-oriented architecture (SOA) offers the promise of business agility and resilience through reuse, loose coupling, flexibility, interoperability, integration and governance. These are realized by separating service descriptions from their implementations, and using this descriptive metadata across the service life cycle. Standards-based service metadata artefacts, such as Web Service Definition Language (WSDL), XML schema, policy or Service Component Architecture (SCA) documents, capture the technical details of what a service can do, how it can be invoked, or what it expects other services to do. Semantic annotations and other metadata can be associated with these artefacts to offer insight to potential users of the service on how and when it can be used, and what purposes it serves.

Service metadata is used by analysts, architects, and developers during a Development Phase of the SOA life cycle to locate services to reuse and to evaluate the impact of changes to service configurations. Service metadata is used by deployers in a Change and Release Phase and by administrators in a Runtime Integration Phase. It is used in the Operation Phase of the life cycle to support policy enforcement required by Service Level Agreements (SLAs) and to present a more comprehensive view of the managed service environment.

When service metadata for a particular service is stored in single file it is relatively easy to use for all users. Similarly if the service metadata for a particular is stored in a small set of files in a known small structure then the user simply learns the files and structure. The problem comes with when service metadata is stored in a large number of files having a large and unknown structure - this arises due to the number of types of users wanting to use, edit, modify and add to the service metadata in ways particular to their function.

SUMMARY OF INVENTION According to a first aspect of the present invention there is provided a method of managing service metadata in a service repository comprising: parsing two or more service metadata files in file directory structure to populate a two or more linked service metadata object models.

Preferably each service metadata object model is populated according to a schema associated with that service metadata object model.

This solution allows easy use of the service data regardless of the number of service metadata files and structure that is used. It allows a given set of users to create a unique set service metadata files and structures but isolates the files and structures from the other types ofuser.

A problem with creating a logical model of the service metadata is that the resources needed to store and process are at least doubled. If each different version of the service metadata is stored then the resource needed is even more.

It is advantageous to store only new versions of those service metadata objects models effected by one or more changes to service metadata files. Typically a set of changes will be made by one set of users and will effect only one service metadata object. This minimizes the resources used to stored new logical versions of the service when changes are made.

In the preferred embodiment the service metadata object models correspond to the four main phases in the service life cycle, comprising: development; change and release; runtime integration; and operation. Each service metadata object has a corresponding schema defining the metadata object.

The development schema comprises: model; build; and assemble namespaces.

The change and release schema comprises: test and deploy namespaces.

The runtime integration schema comprises: mediate and bind namespaces. The operation schema comprises: manage namespaces.

There is a problem searching more than one logical model because normal querying processes will return the results of the first search only.

Advantageously the service metadata manager searches each of the logical models combining all the separate results; the combined results are returned as a single search result.

According to a second aspect of the invention there is provided a system for managing service metadata in a service repository comprising: a parsing engine for parsing two or more service metadata files in file directory structure to populate a two or more linked service metadata object models.

According to a third aspect of the invention there is provided a computer program product for managing service metadata in a service repository, the computer program product when loaded into a compute causing the computer to execte the following steps: parsing two or more service metadata files in file directory structure to populate a two or more linked service metadata object models.

According to a fourth aspect of the invention there is provided a service for managing service metadata in a service repository comprising: parsing two or more service metadata files in file directory structure to populate a two or more linked service metadata object models.

DESCRIPTION OF DRAWINGS

Embodiments of the invention will now be described, by means of example only, with reference to the accompanying drawings in which:

Figure 1 is a schematic of the preferred embodiment showing the phases in a service life cycle; Figure 2 is a schematic of the service registry and repository including the service metadata manager; and

Figure 3 a schematic of a metadata method according to the preferred embodiment of the present invention; and

Figure 4 is a schematic of a query method according to a preferred embodiment of the present embodiment.

DESCRIPTION OF THE EMBODIMENTS

IBM® WebSphere® Service Registry and Repository is the master metadata repository for service interaction endpoint descriptions. A broad definition of "service" applies here. This includes traditional Web services that implement WSDL interfaces with SOAP/HTTP bindings as well as a broad range of SOA services that can be described using WSDL, XSD and policy decorations, but might use a range of protocols and be implemented according to a variety of programming models.

Figure 1 illustrates SOA life cycle phases: Service Development; Change and Release Management; Runtime Integration and Operation. As the integration point for service metadata, WebSphere Service Registry and Repository establishes a central point for finding and managing service metadata acquired from a number of sources, including service application deployments and other service metadata and endpoint registries and repositories, such as Universal Description, Discovery, and Integration (UDDI). It is where service metadata that is scattered across an enterprise is brought together to provide a single, comprehensive description of a service. Once this happens, visibility is controlled, versions are managed, proposed changes are analyzed and communicated, usage is monitored and other parts of the SOA foundation can access service metadata with the confidence that they have found the copy of record.

WebSphere Service Registry and Repository does not manage all service metadata, and it does not manage service metadata across the whole SOA life cycle. It focuses on a minimalist set of metadata that describes: capabilities; requirements; and the semantics of deployed service endpoints. It interacts and federates with other metadata stores that play a role in managing the overall life cycle of a service.

The preferred embodiment of the invention is service registry and repository 10 as shown in

Figure 2. The service registry and repository 10 comprises a service metadata manager 12; object model repository 14; service metadata file directory 16; schema repository 18; meta data method 300; and query method 400.

Schema repository comprises: development schema 20; change and release schema 22; runtime integration schema 24 and operation schema 26.

The development schema 20 comprises: model; build; and assemble namespaces. The change and release schema 22 comprises: test and deploy namespaces. The runtime integration schema 24 comprises: mediate and bind namespaces. The operation schema 26 comprises: manage namespaces.

The metadata management method 300 comprises the following steps:

In step the 302, the service metadata manager 12 parses the service metadata files in the directory 16 and populates a metadata object model according to an associated schema (one of the development schema 20; the change and release schema 22; the runtime integration schema 24 and the operation schema 26).

Step 304 repeats the previous step for all the metadata object models (only four in the preferred embodiment.)

Step 306 saves only the changed metadata object in the object model repository 14.

Step 308 links the latest versions of the metadata objects and associates them with the latest version of the service. Each service version retains the links to the relevant metadata objects. The metadata query method 400 comprises:

In step 402, the first metadata model in a service version is searched using a query expression and the search results received.

In step 404, the previous step is repeated for all metadata models for that service version.

In step 406, the search results for all the metadata models are combined and returned as a single search result.

Example

Examples of the use of the preferred embodiment are now described with reference to the main phases.

During the Service Development phase of the business service life cycle, WebSphere Service Registry and Repository is used to locate the copies of record of candidate service interaction endpoints or mediating intermediaries as well as policies governing the interactions.

In all SOA life cycle stages, WebSphere Service Registry and Repository is complemented by repositories that specialize in managing SOA artefacts. For example, a development artefact management system such as Rational® Clearcase takes care of service and composite application building blocks such as source code, service interface declarations, software architecture models or business process models that are under construction. A

Reusable Assets Manager and Asset Repository manage bundles of artefacts describing assets according to the Reusable Asset Specification (RAS) standard. It implements governance processes controlling the promotion of artefacts to assets and the approval process associated with that.

WebSphere Service Registry and Repository complements those repositories and federates the data they manage; for example, for a given WSDL service declaration, it can have a reference to a reusable asset declaration that WebSphere Service Registry and Repository users can follow to find more information about intended usage and function of that service, or Reusable Asset managers can use to analyze usage of the asset (for example, how many deployed services are based on it).

During Service Development, Business analysts, solution architects, and developers create service metadata and make use of existing service metadata as they perform their specific tasks. They use development artefact management systems to take care of your intermediate work products and contribute to the definition of reusable assets that are hosted by a RAS manager. Business analysts, solution architects, and developers use WebSphere Service

Registry and Repository to explore the set of already deployed services as building blocks for the new things they are building, and they produce service metadata that end up in WebSphere Service Registry and Repository once the underlying service makes it out of development into a deployed state (test, staging, and production). Their interest in and contribution to WebSphere Service Registry and Repository content differs according to their specific tasks.

Analysts model a new business processes and browse WebSphere Service Registry and Repository to better understand the existing environment. As an analyst, you are less interested in IT-level technical details of services like their WSDL interfaces, than in a business view on service capabilities established by WebSphere Service Registry and Repository via semantic annotation of the underlying IT-level artefacts. Analysts may work with the asset manager to define and apply classification systems used to describe business semantics of services.

Solution architects use the Service Registry and Repository to find existing services you can use as building blocks for assembly of new composite services. As a solution architect, you can also use service descriptions you find in WebSphere Service Registry and Repository to populate the set of building blocks analysts use when modelling new business processes, abstracting the IT specifics into process modelling artefacts. Component developers build new service components and can browse in WebSphere Service Registry and Repository to find services you can invoke as part of your implementation or to scope queries against WebSphere Service Registry and Repository that you might want to use as part of your service implementation. Component developers can use WebSphere Service Registry and Repository to analyse the impact an envisioned change on a service might have on other services.

Integration developers assemble solutions from new or existing components. As an integration developer, you use WebSphere Service Registry and Repository to find building blocks that you can bind references in your composite applications to. Integration developers model the mediations necessary to facilitate interactions between service interaction endpoints, for example, using WebSphere Service Registry and Repository lookup to select a service endpoint to be used in a dynamic routing scenario. In coordination with the asset manager role integration developers also can discover existing service endpoints and publish them in WebSphere Service Registry and Repository.

Deploy and Runtime Integration Phases

WebSphere Service Registry and Repository provides the system of record for metadata describing service interaction endpoints. It is populated with metadata as part of SOA solution deployment or via discovery of existing endpoints; and it is used by SOA run times as well as Deployer and administrator roles when detailed information about service endpoints is required to drive operations of the deployed composite applications.

Once the development team has finished their work and testing is complete, Deployers further augment the service metadata, providing binding information for service endpoints used in composite applications and managing deployment of the metadata from the development environment to the staging or production Service Registry and Repository as part of the service deployment process. Governance over the service metadata takes place, as metadata is promoted from test to staging to production environments that may have separate

WebSphere Service Registry and Repository installations. In the production environment, Service Registry and Repository is made available to a broader audience and shared. It is available to the runtime systems and those user roles that are responsible for the management of the IT systems.

Here again, new service metadata, or more often a change in existing service metadata, can be discovered in other service endpoint registries and repositories, published in WebSphere

Service Registry and Repository, and can be used as input for the application configuration and binding tasks performed by the Deployers and Solution Administrators. Discovered service metadata is usually incomplete and not yet suitable for broader visibility and consumption. Deployers work with asset managers to ensure the metadata is augmented with the necessary semantics, permissions and scoping constraints.

Automation of service metadata publication during service application deployment integrates the management of service metadata with the overall SOA management and governance processes in a first class way.

Component developers and integration developers. Execution time interactions with the Service Registry and Repository can be implemented in a service endpoint by a component developer or by a mediating intermediary that acts on behalf of the service requester or the provider and is configured by an integration developer. Dynamic endpoint selection is a key use case that involves querying the Service Registry and Repository for the service provider or a set of candidate service providers, and binding to the endpoint that is the best choice.

Another use case is dynamic retrieval and enforcement of the policies that are in effect for a service interaction in the areas of logging, filtering, data transformation, or routing. WebSphere Service Registry and Repository stores the policy definitions as well as information about which service interaction endpoints they apply to; policy enforcement points can be configured using that information and can be update when WebSphere Service Registry and Repository-managed metadata changes.

SOA run time elements will often maintain configuration information beyond the minimalist set of service metadata managed by WebSphere Service Registry and Repository; they will cache WebSphere Service Registry and Repository managed metadata and relate it to the additional configuration information they maintain.

Development Phase

Solution administrators use WebSphere Service Registry and Repository content to better understand the solution artefacts they are administering, and in the future may be able to dynamically affect changes in the configuration of deployed applications by updating WebSphere Service Registry and Repository content (for example, replacing documents describing endpoint selection rules or applicable policies). Clearly those types of administrator-driven updates must be controlled and that's achieved using WebSphere Service Registry and Repository governance support for the artefacts in question which controls visibility of artefacts as well as who can perform which actions on specific governed entities.

Management phase

Operational management and resilience within the SOA is enhanced by sharing the service metadata that exists in the Service Registry and Repository with operational data stores, allowing management and monitoring dashboards to present a more comprehensive view of the managed service environment. Summary information about service performance can be fed back into WebSphere Service Registry and Repository and used by the execution environment to affect the selection of the best-fit provider.

As in the other life cycle facets, WebSphere Service Registry and Repository only manages a minimalist set of service metadata and federates with repositories specializing on managing information about services in this life cycle stage. For example a Configuration Management Database (CMDB) like ITSM Change and Configuration Management Database will acquire and manage detailed information about the environment and topology in which service endpoints execute. Service management products like IBM's ITSM suite will use and update that information and drive governance of processes that provision and configure the underlying infrastructure. WebSphere Service Registry and Repository and CMDB federation enables WebSphere Service Registry and Repository users to drill down into information about environment and runtime status of a service while CMDB exploiters can obtained detailed descriptions of shape and semantics of service endpoints from WebSphere Service Registry and Repository. Service monitoring and management products like ITCAM for SOA provide instrumentation of service interactions that allow monitoring of service interactions and service endpoint behaviour. Summary information about service behaviour can be pushed into WebSphere Service Registry and Repository to decorate service endpoint metadata with execution statistics. In the future service management products can use WebSphere Service Registry and Repository managed policy information to configure policy enforcement points that implement the SLAs users want to enforce in service interactions.

In the operator user role category, the incident analyst investigates unexpected incidents when they occur in the IT system and manages service endpoints. You consult the metadata and summary statistics about service endpoints found in the Service Registry and Repository to understand the behaviour of the IT systems and to assess the impact of an underlying failure. The business operations manager analyses performance of SOA applications from a business value perspective and uses metadata provided from WebSphere Service Registry and Repository to understand application semantics and to compare expected with observed behaviour of those applications.

It will be clear to one skilled in the art that the method of the present invention may suitably be embodied in a logic apparatus comprising logic means to perform the steps of the method, and that such logic means may comprise hardware components or firmware components.

It will be appreciated that the method described above may also suitably be carried out fully or partially in software running on one or more processors (not shown), and that the software may be provided as a computer program element carried on any suitable data carrier (also not shown) such as a magnetic or optical computer disc. The channels for the transmission of data likewise may include storage media of all descriptions as well as signal carrying media, such as wired or wireless signal media. It will be equally clear to one skilled in the art that the logic arrangement of the present invention may suitably be embodied in a logic apparatus comprising logic means to perform the steps of the method, and that such logic means may comprise components such as logic gates in, for example, a programmable logic array. Such a logic arrangement may further be embodied in enabling means for temporarily or permanently establishing logical structures in such an array using, for example, a virtual hardware descriptor language, which may be stored using fixed or transmittable carrier media.

The present invention may suitably be embodied as a computer program product for use with a computer system. Such an implementation may comprise a series of computer readable instructions either fixed on a tangible medium, such as a computer readable medium, for example, diskette, CD-ROM, ROM, or hard disk, or transmittable to a computer system, via a modem or other interface device, over either a tangible medium, including but not limited to optical or analogue communications lines, or intangibly using wireless techniques, including but not limited to microwave, infrared or other transmission techniques. The series of computer readable instructions embodies all or part of the functionality previously described herein.

Those skilled in the art will appreciate that such computer readable instructions can be written in a number of programming languages for use with many computer architectures or operating systems. Further, such instructions may be stored using any memory technology, present or future, including but not limited to, semiconductor, magnetic, or optical, or transmitted using any communications technology, present or future, including but not limited to optical, infrared, or microwave. It is contemplated that such a computer program product may be distributed as a removable medium with accompanying printed or electronic documentation, for example, shrink-wrapped software, pre-loaded with a computer system, for example, on a system ROM or fixed disk, or distributed from a server or electronic bulletin board over a network, for example, the Internet or World Wide Web.

It will be further appreciated that embodiments of the present invention may be provided in the form of a service deployed on behalf of a customer to offer service on demand. It will also be appreciated that various further modifications to the preferred embodiment described above will be apparent to a person of ordinary skill in the art.

The scope of the present disclosure includes any novel feature or combination of features disclosed herein. The applicant hereby gives notice that new claims may be formulated to such features or combination of features during prosecution of this application or of any such further applications derived there from. In particular, with reference to the appended claims, features from dependent claims may be combined with those of the independent claims and features from respective independent claims may be combined in any appropriate manner and not merely in the specific combinations enumerated in the claims.

In summary, there is described a method, system, computer program and service for managing service metadata in a service repository comprising: parsing two or more service metadata files in file directory structure to populate a two or more linked service metadata object models. Each service metadata object model is populated according to a schema associated with that service metadata object model. Only new versions of those service metadata objects models effected by one or more changes to service metadata files are stored. The service metadata object models correspond to the four main phases in the service life cycle, comprising: development; change and release; runtime integration; and operation.

Claims

1. A method of managing service metadata in a service repository comprising: parsing one or more service metadata files containing existing metadata to populate a service metadata object model; and attaching additional metadata to the service metadata object model wherein the relationships between the existing metadata and the additional metadata is persisted.

2. A method according to claim 1 wherein each service metadata object model is populated according to a schema associated with that service metadata object model.

3. A method according to claim 1 or 2 wherein only new versions of those service metadata objects models effected by one or more changes to service metadata files are stored.

4. A method according to any of claims 1 to 3 wherein the service metadata object models correspond to the four main phases in the service life cycle, comprising: development; change and release; runtime integration; and operation.

5. A method according to any of claims 1 to 4 further comprising searching each of the logical models and combining all the separate results; the combined results are returned as a single search result.

6. A system for managing service metadata in a service repository comprising: a parsing engine for parsing one or more service metadata files to populate a service metadata object model; and an editor for attaching additional metadata to the service metadata object model wherein the relationships between the existing metadata and the additional metadata is persisted.

7. A system according to claim 6 wherein each service metadata object model is populated according to a schema associated with that service metadata object model.

8. A system according to claim 6 or 7 wherein only new versions of those service metadata objects models effected by one or more changes to service metadata files are stored.

9. A system according to any of claims 6, 7 or 8 wherein the service metadata object models correspond to the four main phases in the service life cycle, comprising: development; change and release; runtime integration; and operation.

10. A system according to any of claims 6 to 9 further comprising a search engine for searching each of the logical models and combining all the separate results; the combined results are returned as a single search

11. A computer program product for managing service metadata in a service repository, the computer program product when loaded into a compute causing the computer to execute the following steps: parsing one or more service metadata files to populate a service metadata object model; and attaching additional metadata to the service metadata object model wherein the relationships between the existing metadata and the additional metadata is persisted.

12. A computer program product according to claim 11 wherein each service metadata object model is populated according to a schema associated with that service metadata object model.

13. A computer program product according to claim 11 or 12 wherein only new versions of those service metadata objects models effected by one or more changes to service metadata files are stored.

14. A computer program product according to any of claims 11 to 13 wherein the service metadata object models correspond to the four main phases in the service life cycle, comprising: development; change and release; runtime integration; and operation.

15. A computer program product according to any of claims 11 to 14 further comprising searching each of the logical models and combining all the separate results; the combined results are returned as a single search result.

16. A service for managing service metadata in a service repository comprising: parsing one or more service metadata files to populate a service metadata object models; and attaching additional metadata to the service metadata object model wherein the relationships between the existing metadata and the additional metadata is persisted.

17. A service according to claim 16 wherein each service metadata object model is populated according to a schema associated with that service metadata object model.

18. A service according to claim 16 or 17 wherein only new versions of those service metadata objects models effected by one or more changes to service metadata files are stored.

19. A service according to any of claims 16 to 18 wherein the service metadata object models correspond to the four main phases in the service life cycle, comprising: development; change and release; runtime integration; and operation.

20. A service according to any of claims 16 to 19 further comprising searching each of the logical models and combining all the separate results; the combined results are returned as a single search result.