What should an SOA repository look like?

It's becoming clear that a repository is an essential component in a successful SOA. What's less clear is what a successful SOA repository actually looks like. Is it just an expanded registry, or something else? I've been asking SOA vendors for their views over the past couple of months. The range of replies I've had is illuminating.

Early adopters more or less stumbled upon the need for a repository, without at first realizing just how crucial it was going to be. Recognition of the role of the repository went through three phases:

1. Denial. Originally, it was thought that a registry, based on the UDDI standard, would be sufficient: Services would just use the registry to seek out matching resources at runtime and consume them automagically. But this early vision failed to take into account issues like contracts, shared meaning, reputation and trust.

2. Awareness. As enterprises began to build SOAs that linked services from different domains, it became obvious there was a need for some kind of system of record that developers could consult at design time. This would have to provide more information than a barebones UDDI registry was equipped for, and indeed taking into account the need to include documentation and other supporting material, it became evident that the directory-like registry model didn't go far enough. There needed to be some kind of document store with its own defined processes, in other words, a repository.

3. Acceptance. The more one started to think about what one could do with a repository, the more obvious it became how necessary it was to have one. Not just at design time, but also through deployment, runtime, and on to change time — those moments when a live service needs to adjust to changing circumstances.

The extent to which the debate has moved on through this process was summed up for me when Cape Clear's CEO Annrai O'Toole posed me this question when we met in London in late November: "How should a repository work? Like a database, or like a wiki?"

What's happened is that we've moved from a starting point when it was assumed that all the negotiation would be done by machines, application-to-aplication, to arrive at the conclusion that in fact it's going to have to be done by people, working in collaboration. Instead of looking like a soulless library or asset register, the repository suddenly takes on more of the aspect of a coffee shop, filled with back-and-forth conversation — replete with social context, to use today's lingo.

So began my mission to find out what other SOA specialists thought the repository should be like. I realized that Bill Portelli, CEO of CollabNet, which quite a few large-scale SOA adopters are using to manage development, had already put it succinctly in an earlier conversation: "SOA is really a community development problem." I'd also talked with Flashline's CEO Charles Stack about the company's launch of an SOA governance platform (I'll finally get around to posting that interview in the next few days, now that I've got onto this topic). He summed up the repository's role with the image of a "parts catalog." But it was evident that Flashline's SOA parts catalog takes a very Internet-savvy approach: "We’ve designed our application as a central point from which to popularize reuse," he told me. It lets developers see which assets get used the most, who are the most prolific consumers, and which are the most popular services.

When SOA testing tools vendor Mindreef launched its SOA collaboration platform, Coral, last month, it seemed to me to be positioning the repository as a kind of virtual demo room, where would-be consumers can put services through their paces and check out whether they'll meet requirements. Company president and CTO Frank Grossman pointed out that the context in which the information is presented is more important than where it is actually stored: "Coral is more a tool to front-ennd the registry and repository — the various components might be held in various places."

Early this month, I put the question to Thomas Erickson, Systinet's CEO, in the midst of finding out about his company's acquisition by Mercury. "A little bit like Google or Amazon," he told me, but with the caveat that customers should have the flexibility to choose what works best for them: "Give people basic capabilities they can extend and let them decide how they can extend their specific model." A couple of days later, Frank Martinez, Blue Titan's CEO, called in during a visit to the UK. He said simply, "It should be just like using a browser."

Then yesterday, I saw Marc Benioff demonstrate Salesforce.com's AppExchange platform (link to video) and all those ideas suddenly snapped into place. Of course, AppExchange is a showcase for on-demand applications, so it's not exactly the same thing, and it targets end users rather than professional developers or business analysts. But its primary aim is to maximize reuse, and to that end it incorporates RSS feeds that update users on changes to applications or new additions to categories, it presents popularity metrics, it allows users to post reviews and comments, and of course it's searchable in a variety of ways. AppExchange is an excellent example of what an SOA repository should look like.

posted by Phil Wainewright 10:32 AM (GMT) | comments | link