Repositories are a 'force multiplier' for SOA

Repositories are a 'force multiplier' for SOA

Summary: Repositories can help make SOAs a reality, says industry expert.


Everyone's talking about SOA, but who's really got one? We may have Web services by the dozens, but the impetus is on being able to track and manage those services.

That leads us to the whole subject of repositories. In a chat I had earlier in the week with Infravio's Miko Matsumura, he noted that 'repository' may be running the risk of becoming 2006's "most abused word."  Nevertheless, at this stage in the game, we need them. 

In a new ZDNet post, Brent Carlson, vice president of technology and co-founder of LogicLibrary, warns against getting caught up in the excitement around the recent acquisitions in the SOA space (Datapower, Systinet, and Actional) and remember that they're serving markets that haven't quite come into existence yet.

These acquired companies primarily serve the "tail end" of the SOA process, namely a well thought out and executed SOA initiative. To get there, organizations need to get past the ABOS, or A Bunch of Services, stage that they're mired in.  (I've called it JBOWS, or Just a Bunch of Web Services, but I guess Carlson's definition is a little broader.) 

Carlson provides some advice for organizations seeking to move from ABOS/JBOWS to SOA. Namely, to "put in place a combined design-time software development asset (SDA) repository/registry to support the architecture and software development lifecycle (SDLC) governance environments within that SOA." 

The SDA repository can support the service production side, "with links to file-level repositories like SCMs, document management systems, defect tracking tools, requirements management tools, etc. for SDLC work products." Also, the SDA repository can serve "as a registry on the service consumption side, preferably with deep integration into the developer tool of choice these days, the IDE."

Of course, the bits and bytes of repositories and registries are but a tool, and tools only work when properly used. Carlson states that success rests on the level of communication between design teams an the rest of IT.  (I would like to add that the business end users need to be kept informed and involved as well.) 

"The once-a-year IT pow-wow where the EA team rolls out its vision for the next set of strategic initiatives is a highly ineffective way to deliver core IT knowledge. repositories serve as a 'force multiplier' that enables enterprise architects to consistently capture and automatically deliver their knowledge to the larger IT community."

Topic: Software Development

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Will be big if....

    We still have to get back to the crawl phase of SOA and get through it successfully. I think some companies get it especially software vendors, others don't, especially IT shops in companies where software is not the focus of the core business.

    OOP became the big buzz in the 90's but its success was not widespread in the corporate IT world. It was very successful with software vendors, companies that produce software to sell etc. Why did it not reach the widespread success that everyone seems to think SOA is going to in the big corporate IT shop? I think that is the million dollar question for corporate IT.

    Was it lack of repositories, not wanting to share, lack of understanding of more advanced design principals, client pressure? Probably some of all of that but I think any IT shop thinking about SOA should have a good answer for it. Repositories are definitely a good thing but I not convinced how key they are going to be for the early success of SOA at least in the corporate IT space. Kind of nice to have but shouldn't hold you back kind of thing. But if you don't understand abstraction, loose coupling, interface design with reuse in mind, then you are doomed with or without a repository.

    • Mutual dependencies

      Well, I try to avoid thinking in object-orientated terms (because I think the fundamental idea is flawed and not coherently defined), I have tried, but I don't think it is applicable to business systems, I really don't.

      There seems to be this idea that you can have a customer class and an invoice class and that these can somehow exist either independently of each other or interact.

      To take and example: customers and invoices are mutually dependent on each other. Sure, you can have a customer that we haven't raised an invoice for. You can validate in your invoice "class" that the invoice has a customer. However you also have to validate in your customer "class" that you cannot delete a customer who has invoices.

      The fact is that "repositories" already exist. They are called catalog relations (catalog tables in SQL speak). If the validation of the data is put in its proper place (in the database) then the whole need for application specific "services" and all the complexity that goes with them disappears in a puff of smoke.
      • Not sure about that

        Unfortunately or fortunately depending on your viewpoint, service design has a lot to do with some common OOP principals. There are some differences as well but a lot of the same. The big difference at least in my mind is services are loosely coupled and coarse grain versus objects that tend to be tightly coupled and fine grain. But a lot of the same development methodology applies and has to be used to design a reusable interface.

        I don't see repositories in the SOA sense being used the same as repositories as in the catalog tables and "SQL speak". In the SOA world a service can be running anywhere on any platform with any underlying technology providing the meat of the service with only the public interface exposed as a standards based technology. The repositories will be pointers to the service interfaces and contract locations. They will also probably do things like quality of service management, failover of services etc. Database centric view of the world won't work in a truly distributed standards based SOA.

        Not to say you couldn't build out an SOA like that but it would be going against the grain and direction of everybody else.

        • Explain terms please

          1. Loosely coupled.
          2. Tightly coupled.
          3. Course grain.
          4. Fine grain.

          Why not expose the "interface" as a relation? Every possible combination of overloaded arguments is then always available without having to write any further code. Surely far more flexible?

          "Database centric" certainly will do what SOA claims to do in a far simpler and more elegant way than using "services". It is just that most of the vendors haven't got round to implementing the technology yet. The principles of distributed databases are well defined and will do the job.
          • Anything is possible but not the standard

            Course grain - encapsulating more functionality within a single call.
            Fine grain - single call very specific operation

            An example would be the difference between something like getcustomer versus getcustomerstatus or getcustomeraddress.

            Tight coupling and loose coupling have multiple meanings depending on the context. Within the SOA world I would say the ability of the service to operate on its own with no dependencies on other services. This also is related to abstraction and state. You can also look at coupling as it relates to messaging(async versus synchronous), intermediaries and proxies. In other words is my application directly invoking a method on another application ie very point to point and brittle.

            I am not arguing you couldn't implement your own SOA the way you are proposing, but it's not that most vendors "haven't got round to implementing the technology yet". Its most vendors are not going to implement their services that way. It's not the direction the industry is going whether it's right or wrong. Of course that's just my viewpoint, the SOA landscape is still in a very early stage.

            Very good discussion.

  • Reinventing the data dictionary

    Metadata management tools have been needed both for development, management and, in many cases, operation in most computer systems. The idea goes back at least to the cross-reference and data dictionary databases of mainframes, and has existed in some or the other form in any IT system of some complexity.

    SOA is no different to them (besides, any SOA includes a large wealth of metadata from the start: WSDL, XML Schema, etc). To be more than a bunch of web services, at runtime it needs at least of a registry for components to find each other. At development time it needs of a means for developers to document, browse and find services, to subscribe to changes about them, etc. And at management time it needs of means to browse and components, find dependences among them, control them, etc. And another very interesting and less common usage of metadata is for SOA capabilities to be used directly by end users, without IT staff intervention - they need of means to browse not services (which they should not care about), but Domain concepts and features (which may be "implemented" by a number of services). RDBMSs have have a remarkable success in this (reports, BI).

    In many areas, SOA is reinventing the wheel - also in metadata management. However, although usually this reinvention is not good, I think the benefits SOA promises to deliver are worth it.

    (see for more on this)
    • "Repositories" are regressive

      Actually the "data dictionary" of the relational model is far further advanced than the crude approaches advocated by the SOA enthusiasts.

      The relational model is based on a sound mathematical basis. XML Schema is a throw back to hierarchical methods already proved unworkable in the 1970s and has no sound theoretical background. Thus it can only be made to work with a considerable amount of pain, effort and procedural programming. From a business point of view this is pure overhead.

      SOA contains a "wealth" of metadata but it is all represented in a way which makes it impossible to access flexibly.

      Users can "browse" the data dictionary in an RDBMS without IT staff intervention. You just need to select the tables the user has select access to. Simple, elegant and all achieved with a single SQL statement.
  • business governance

    Joe, your comment about business end users needing to be kept informed for an SOA to be successful is right on target. Take a look at my blog entry on the topic of business architecture -- looking forward to your thoughts on the topic...
    • Excellent points...

      Excellent points in Brent's blog, especially #1, SOA is not about building gallactic infrastructures reaching into every part of the enterprise. Start with a smaller, demonstrable project, and show its success. Plus, it may be easier to sell a problem solution (faster invoicing) than actually calling it an "SOA."