In this task, the asset is made visible to a target audience that goes beyond the Repository. As part of the normal
asset review activities, the asset may transition to the state of Approved. It is then visible to the Asset
Consumers with the appropriate access control.
However, here you are interested in making the asset visible to other target audiences. This task will largely
take place as certain asset types, such as Service Interfaces, are published into service registries.
In this case the Service Interface likely has several key artifacts such as the WSDL, and XSDs. At this point, the
approved Service Interface asset is selected and the target service registry is identified. The contents of the Service
Interface (or whatever asset type it may be) asset are published to the service registry.
This can affect the state of the asset in the Repository by transitioning to something such as "published".
Publishing the asset introduces some issues around classification and security. The classification of the asset in the
Repository may not map directly to the classification that is available in the target repository or registry.
Another consideration is security and access control. In some cases the access control between the two systems may be
dissimilar. It is critical that one Repository does not betray the access control specified in another repository.
A development-time repository is focused on the governance of assets to aid the development organization. The runtime
service registry is focused on the governance of services into and out of production environments.
When publishing an asset to another repository or registry, the administrators will also need to deal with duplicated
data and how to handle updates and new versions. It is also necessary to consider which system is the source of record for
the asset or some portion of the asset. |