Re: Roch on SOA Registry Repository Tool Integration
- I have been doing a lot of work on this subject of late, and published several new reports http://cbdi.wikispaces.com/Service+Asset+Management
The challenge I have found with products WSRR and others is that out of the box, their meta model of asset types and relationships is relatively small. It is focused more on the cataloguing of operational services and a few associated assets and relationships (e.g. where consumed), whereas we see the bigger challenge as being the full life-cycle aspects. What about knowing what services are planned for example, and what their current status is? Or where is the more detailed service specification for the service, not just the WSDL? or the business models that were used to identify/derive the services in the first place?
Fortunately, these products are extensible, so it is not hard to start supporting and recording this data in the registry/repository. However, you need to start by modeling the meta model of what you intend to record (rather than allowin it to get extended in an unplanned way). And we don't expect every organization to want to have to do that from scratch. The CBDI-SAE meta model and the SOA deliverables we have identified in SAE are a good starting point for that, and this is one of the things I have been researching and providing guidance on how to implement our model and approach in tools like WSRR.
--- In email@example.com, Gervas Douglas <gervas.douglas@...> wrote:
> You can find the following blog at:
> <<If the SOA Registry/Repository is the center of the SOA world, how
> does change management databases, source code management, and asset
> management fit into the picture?
> The integration of SOA Registry/Repository can solve one of the big
> problems with SOA registry/repository namely populating relevant data
> about the state of the services. A repository/registry is only as good
> as the data recorded about SOA.
> By providing hooks into the development environment, change management
> system and testing tools you can automatically pull metadata about
> services and populate a customized and standardized taxonomy within the
> repository. This allows IT to carry out their tasks as usual and have
> the repository automatically populated in a consistent manner. For
> example, if a developer consumes a service from within an integrated
> development environment (IDE) that usage is noted in the repository and
> can be reported for impact analysis.
> Predefined registration workflows and policies enforce SOA governance
> compliance and can be customized to your process and tools. For example,
> a workflow and policy can prevent service deployment until after service
> testing. This is where the interoperability framework also comes into
> play - integrating tools such as the IDE, test tools and change
> management software with the repository.
> The predefined workflows, policies and taxonomy based on best practices
> will save implementation time and ensure that you have a good baseline
> for capturing the metadata about services that you need for proper SOA
> The IBM developerWorks article, IBM SOA Registries and Repositories
> Portfolio Overview
> outlines how their SOA registry/repository, asset management, change
> management database works together to manage services and change. The
> products are IBM specific but the outline of the product roles can apply
> to any toolset.
> Registry Integration