Service development lifecycle phase

Classifications associated with service metadata can be used to indicate the lifecycle state of the service.

Business analysts, solution architects, component developers and integration developers create service metadata and use existing service metadata as they perform their specific tasks. For more information about these user roles see the Related link.

These users use development artifact management systems to take care of their intermediate work products and contribute to the definition of reusable assets hosted by a RAS manager. They use WSRR to explore the set of already deployed services as building blocks for the new things they are building. They produce service metadata that is published to WSRR when the underlying service is considered ready for being shared in a governed way. Classifications associated with service metadata can be used to indicate the lifecycle state of the service (for example: under construction, in test, ready for production). They can also use WSRR to understand the effect that changes they intend to make on existing services will have on other service building blocks.

In addition to the common tasks carried out by the four main user roles, each has its own set of tasks:

• Business analysts model new business processes and can browse WSRR to better understand the existing environment. Analysts are less interested in IT-level technical details of services such as their WSDL interfaces, than in a business view of service functions established by WSRR using semantic annotation of the underlying IT-level artifacts. They might work with the asset manager to define and apply classifier systems used to describe business semantics of services. And they might create WSRR entries representing business-level concepts such as main applications and processes that will later be refined by architects and developers into IT-level artifacts.
• Solution architects use WSRR to find existing services they can use as building blocks for assembly of new composite services; they might also use service descriptions they find in WSRR to populate the set of building blocks analysts use when modelling new business processes, abstracting the IT specifics into process modelling artifacts. They can publish service metadata that describe interfaces of to-be-deployed services that will be realized by component developers and integration developers.
• Component developers build new service components and can browse WSRR to find services they can invoke as part of their implementation, or to scope queries in WSRR that they want to use as part of their service implementation. They can use WSRR to analyze the effect an envisioned change on a service might have on other services; and they can publish service interfaces and other service metadata to WSRR that must be put under governance control.
• Integration developers assemble solutions from new or existing components. They use WSRR to find building blocks to which they can bind references in their composite applications; and they model the mediations necessary to facilitate interactions between service interaction endpoints; for example, using WSRR lookup to select a service endpoint to be used in a dynamic routing scenario. In coordination with the asset manager role they also can discover existing service endpoints (for example, external service offered by a business partner) and publish relevant service metadata in WSRR.

During the service development lifecycle phase, the key tasks are publishing, and discover and reuse. These tasks are described in the following subtopics: