Registries, Repositories, and Bears, oh my!
Okay, no bears, sorry. I read post from my good friend Jeff Schneider regarding SAP’s Enterprise Service Repository (ESR). He states:
At the core of the SAP SOA story is the Enterprise Service Repository (ESR). It is actually a combination of both registry and repository. The registry is a UDDI 3.0 implementation and has been tested to integrate with other registries such as Systinet. But the bulk of the work is in their repository. Unlike other commercial repositories, the first thing to notice is that SAP’s is pre-populated (full, not empty). It contains gobs of information on global data types, schemas, wsdl’s and similar artifacts relating to the SAP modules.
This now brings registry/repository into the mix of infrastructure products that SAP customers must make decisions regarding adoption and placement. Do they leverage what SAP provides, or do they go with more neutral products from a pure infrastructure provider such as BEA, HP, SOA Software, or SoftwareAG/WebMethods? The interesting thing with this particular space is that it’s not as simple as picking one. Jeff points out that the SAP ESR comes pre-populated with “gobs of information” on assets from the SAP modules. Choose something else, and this metadata goes away.
I hope that this may bring some much needed attention to the metadata integration/federation space. It’s not just a need to integrate across these competing products, but also a need to integrate with other metadata systems such as configuration management databases and development lifecycle solutions (Maven, Rational, Subversion, etc.). I called this Master Metadata Management in a previous post.
Back when Gartner was pushing the concept of the ESB heavily, I remember an opening keynote from Roy Schulte (I think) at a Web Services Summit in late 2005. He was emphasizing that an organization would have many ESBs that would need to interoperate. At this point, I don’t think that need is as critical as the need for our metadata systems to interoperate. You have to expect that as vendors of more vertical/business solutions start to expose their capabilities as services, they are likely to come with their own registry/repository containing their metadata, especially since there’s no standard way to just include this with a distribution and easily import it into a standalone RR. It would be great to see some pressure from the end-user community to start making some of this happen.
4 Responses to “Registries, Repositories, and Bears, oh my!”
Leave a Reply
Hi Todd!
Good stuff, and interesting. I know that SAP ESR is most definitely NOT a hosted thing… but the fact that it comes with content kind of reminds me of the new fangled things like the “Facebook API” or OpenSocial.
The point I guess I’m trying to make is that not only is the value of the thing that you get a real nice way to talk to a system, but on top of it all you get a data set that comes along for the ride.
We’ve seen customers who need both the Software AG Centrasite Registry Repository *and* the SAP ESR, no question… Because of governance issues that straddle non SAP systems. Their technology as part of the overall NetWeaver strategy is a bit lagging also…
But the existence of “pre packaged content” inside of a Registry Repository is definitely a huge thing, and we are increasingly pre loading content into the registry repository product Centrasite in order for it to nestle into specific accounts more nicely.
Miko
Deputy CTO, Software AG webMethods
This has the potential to lead to a real mess. Consider the packaged data warehouse/data mart solutions bundled with applications. They can be an incredibly valuable point solution, but in the enterprise view they can be simply a distraction or an outright BI/DWH derailer.
Assuming Oracle, IBM and others follow suit with similar populated and bundled repositories, will it make life easier, harder or no different? Will it have a positive or negative impact on repository efforts? Who can makes changes? How will changes be affected by application upgrades?
A federated scheme is likely to work best in such a scenario. More complex. Potentially harder to use. But probably the “least unacceptable” solution. 🙂
We’ll probably start to see stories of “repository in a box” and “why build one when you can buy one.” These will be a distraction at least.
My view on the Registry/Repository is that there will be multiple of these within a large Enterprise. For example: The application team that has standardized on SAP shall most propably use the SAP ESR and the eBusiness team would leverage one that is provided the middleware vendor like IBM, BEA or Software AG. and lets not forget the CMDBs of the world that have the operations view.
As some of the common metadata, such as service definitions, service dependencies, etc. will need be synchronized across these repositories, the challange is that no-vendors has adopted a uniform standard for synchronizing these metadata. Each of the registry/repository vendords do have a synchronization engine/process and for now, IT organization may have to develop the module to synchorize the metadata.
Best Practice: Try and stick to one vendor for Registry & Repository 🙂
This is the first time I’ve visited this site and thought I’d get into the mix by asking the following question: I have a client that has implemented Systinet taxonomy and service lifecycle. They are currently planning to implement SAP ESR. Can anyone provide me with a recommendation on a best practice for determining how to align the SAP ESR with Systinet?