Skip to Content

I recently read an interesting Gartner report on Integrated SOA Governance Technology set, part of which was published at a website (,%202007_tcm16-37108.pdf), illustrates the now (in)famous “magic quadrant” describing the offerings from different vendors in the field of Service Oriented Architecture (SOA). The four categories that each of these vendors are evaluated are – Leader, Visionary, Niche Player and Challenger. Albeit very few made it to the leader board, most of them stayed inside the “Visionary” side of the graph. More importantly SAP made the cut for its offering around Enterprise Service Repository (ESR) (BTW! Oracle couldn’t join the party!!!). One of the points that the article makes is “ESR is a misnomer!!!”. Having read that article made me ponder some of the SOA jargons that gets thrown most of the time – registry, repository, UDDI. My focal point of interest lies around the difference between a SOA registry vs. a SOA repository.

When I think about the definition of a registry, I look for metadata contexts around assets i.e a registry stores metadata information of the assets (read services) that one is interested. A repository on the other hand stores the actual asset in question. If I was to draw a simile, a registry would be a “catalog” of items while a repository is the “warehouse” where the items are actually stored for it to be shipped when ordered (read discovered).

So what contents goes into a registry vs. a repository? A registry could be the storage container for service definitions, its associated policy metadata that conforms to the WS-I standards. A service consumer then would be able to discover and bind to a service during runtime. A repository on the other hand could be a store for service artifacts such as models, security rules and policies, and transformational schemas i.e a data store that implements the entire governance model and the interaction mode that it can support.

SAP NetWeaver Enterprise Service Repository (ESR) comes with a set of pre-configured enterprise service definitions that can be simply discovered and consumed to build enterprise applications and/or composite applications in an Enterprise SOA (ESOA) environment. ESR also allows the development community to register custom web services for consumption by applications in a governed environment. What it means is that ESR is just not a repository of enterprise services but is also a registry of services (that can be discovered). Which brings me to my original question: Should ESR be called ESRR?

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

  1. Paul Medaille
    Hello Mahesh

    Interesting blog, but one correction: you say oracle couldn’t make the party, but Oracle acquired BEA, who edgo out SAP slightly according the tragic quadrant; so that technically makes Oracle a player.  As with most things Ellison, of course, they could only become a player by buying a competent player.  I was at Oracle Open World a couple of years back, after Oracle had just completed the acquisitions of PS/JDE and Seibel; at the conference, and IBM guy said to me, “I guess this makes Oracle an 800 pound gorilla.”  “No,” I answered; “Oracle is a 200 pound gorilla with three other 200 pound gorillas on its back.”  So with BEA, one assumes.  Still, it definitely puts Oracle in the game.  But you are correct to the extent that they have nothing like the integrated paltform approach that SAP takes (whether that is an advantage or not, I’ll let others decide).  By the way, the ESR and SR are really separate functionalities, as your excellent analogy of catalog and warehouse suggests.  Still, I don’t put too much stake in what analysts say, as I prefer to think for myself 😉


Leave a Reply