There are a number of questions all wrapped up in this single question, so I'm going to piece them apart.
The first question has to do with security in a cloud computing scenario. Whether it's a service repository, transactional data, customer reference information, or anything else, this is one of the first concerns raised in any cloud computing discussion. In my opinion, this has less to do with any actual security deficiency from cloud computing providers and more to do with the fear associated with giving control over your information to an external provider. So, in terms of protecting your data, you need to look at the hosting model from the provider and ask detailed questions on how that data is protected. For example, is it a multi-tenant environment or not? If so, how are the boundaries between each tenant's data maintained? What control do you have over naming conventions to prevent people familiar with one tenant's structures from accessing your information? Again, these questions are not specific to hosting a service repository in the cloud, they are questions that should be asked for hosting any application or information repository in the cloud.
The next question is getting the cloud-based repository populated. This is going to be a bit more challenging, mainly because there isn't a well-adopted standard for interaction with a repository. While most vendors in the space have provided UDDI support, this is more about interacting with a registry rather than a repository. Indeed, when IBM first announced WebSphere Service Registry and Repository, they stated that a new standard for interacting with registries and repositories was needed. Older repository products such as Oracle's Enterprise Repository have always had proprietary APIs for interaction (in addition to UDDI), while more recent products from WSO2 and MuleSoft, have embraced a REST-based interface for repository elements. So, it is reasonably safe to say that the ease of initial population is going to be an area that providers can differentiate themselves, and not something that can be generally classified.
Once you've populated your repository, there's now a question of maintaining it. This is probably the least controversial area, as most repositories today utilize a Web-based interface, so there's no reason why a software as a service (SaaS) offering can't provide a similar interface. If there is a need for automated publishing, the problem is the exact same as with the initial populated repository, only dealing with smaller data sets. Again, given the lack of standards for interacting with repositories, this will be an area of differentiation for the vendors involved.
The final question, and probably the most important one, is whether or not there are even viable options in the cloud today. Frankly, if there are, they're not widely known, and that's not surprising. The biggest challenge that repository tools have faced, even prior to SOA, is finding the proper integration with the rest of the IT ecosystem. As a result, many of these repositories were tied to some other product. Web service registries and repositories were tied to ESBs or Service Gateways. ITIL Service Catalogs, configuration management databases (CMDBs) and configuration management systems (CMSs) were tied to service desk products. Business process repositories were tied to BPM suites. Business application suites from SAP or Oracle have repositories of business functions, objects, and more at their heart. Unfortunately, a market for a true enterprise repository that spans all of these spaces is still in its infancy. As a result, cloud-based repositories fall into a similar category. Service-now.com has a Service Catalog as part of their cloud-based IT Service Management offering. Lombardi's Blueprint offering for cloud-based BPM includes a repository for process related assets. Again, the repository is tied to the usage scenario.
The takeaway from all of this is that ultimately a repository is just a container for data. To make good decisions on your repository, you need a clear idea on how that repository information will be used. Will it be solely for human consumption as a portfolio management tool, or will you require more sophisticated interactions through automated interfaces for service discovery, publishing, reporting, and more? If it's the latter, I think the larger problem is not going to be security, it's going to be finding a provider that not only has a robust set of programmatic interfaces, but also one that has out of the box integration with cloud-based service providers as well as the traditional in-house application providers and middleware vendors.
This was first published in January 2010