6 The Asset Lifecycle

This chapter describes the asset lifecycle stages, including service definition, implementation and configuration, testing, staging and production, and monitoring and management.

This chapter contains the following sections:

6.1 Overview

After assets are harvested and made visible to stakeholders, the next step is inserting governance into the asset lifecycle process. Figure 6-1 illustrates the asset lifecycle process.

  1. First, a capability needed by multiple work groups is defined.

  2. The capability is funded and a project is initiated to implement it.

  3. The implementation is promoted to pre-production environments, which might include staging and testing.

  4. Finally, the implementation is promoted to the production environment, where performance can be monitored and behavior enforced. Oracle Enterprise Repository's automated workflows facilitate this process.

Figure 6-1 Asset Lifecycle Process

This image is described in surrounding text.
Description of "Figure 6-1 Asset Lifecycle Process"

6.2 Asset Lifecycle

This section describes Governance in each asset lifecycle phase. This section contains the following topics:

6.2.1 Service Definition

When a needed capability is recognized, the Enterprise Repository can make it visible. Capabilities may come from architects working on target architecture or business analysts identifying common business requirements. After these capabilities are visible in the enterprise repository, they can be evaluated and prioritized according to a common business or ROI model. Next, these capabilities can be categorized into stages such as proposed (identified and vetted), planned (in progress in an active project), and released (fully implemented).

You can make a capability visible through the Enterprise Repository in these ways:

  • Quick Submission

  • Advanced Submission

Information and a workbook are available to help you justify and prioritize your capabilities and asset investments:

6.2.2 Implementation and Configuration

As capabilities are planned, projects implement them. SOA Suite developers working in JDeveloper can see and reuse enterprise repository services to complete their projects. Service Bus developers working in Eclipse can see and reuse enterprise repository services to complete their projects. Developers can also submit their completed implementations directly to the Enterprise Repository. The Enterprise repository also supports VS .Net development.

6.2.3 Testing, Staging, and Production

After an implementation has been harvested to Oracle Enterprise Repository, the repository's workflows process it according to established governance rules and practices. Oracle Enterprise Repository comes with several preconfigured, customizable workflows.

For more information about Oracle Enterprise Repository's workflows and how to customize them, see "Configuring Oracle Enterprise Repository Workflow" in Oracle Fusion Middleware Configuration Guide for Oracle Enterprise Repository.

As an implementation moves through the lifecycle, from testing, through staging, and into production, Oracle Enterprise Repository harvests and makes visible the endpoints for each environment. The Harvester is incorporated into the Ant or WLST deployment script.

For information about harvesting endpoints from the runtime environment using deployment scripts, see "Configuring and Using Automated Harvesting in Design-time and Runtime Environments" in Oracle Fusion Middleware Configuration Guide for Oracle Enterprise Repository.

Using the Exchange Utility, Oracle Enterprise Repository can optionally promote the services and harvested endpoints to a Service Registry in each lifecycle environment. Runtime tooling, such as OSB and SOA Suite, can dynamically discover changes to services in the registry. OSB subscribes to the Service Registry's publish/subscribe API, therefore OSB is automatically notified when a change occurs. Alternatively, SOA Suite caches the WSDL and endpoint locations and the UDDI service key at design time. If the WSDL or endpoints become invalid, SOA Suite uses the service key to dynamically discover and update them. Both OER and OSR honor the unique key for each service. Applications can access services by their keys instead of their endpoints, which may change throughout the lifecycle.

6.2.4 Consumer Provisioning and Contract Management

Some organizations may not want to automatically expose their production service endpoints to all consumers. Consumers may first be required to negotiate a service level agreement with the service provider. Oracle Enterprise Repository can facilitate this negotiation process.

6.2.5 Monitoring and Management

Both service providers and service consumers need to understand how a service is performing in the runtime environment. Oracle Enterprise Repository 11g can import a summary of runtime service performance metrics from Enterprise Manager SOA Management Pack Plus.

For information on configuring interoperability between Oracle Enterprise Repository and Oracle Enterprise Manager SOA Management Pack Enterprise Edition, see Oracle Fusion Middleware Configuration Guide for Oracle Enterprise Repository.

Some third-party tools can publish runtime metrics to Oracle Service Registry. Bidirectional synchronization between Oracle Enterprise Repository and Oracle Service Registry moves runtime metrics from the registry to the repository.

Note that Oracle Enterprise Manager SOA Management Pack Enterprise Edition provides runtime metrics directly to the Enterprise Repository.

For additional information about promoting metrics from Oracle Service Registry to Oracle Enterprise Repository, see "Metric Publishing" in Oracle Fusion Middleware Integration Guide for Oracle Enterprise Repository.