When you are doing inductive conclusion, you have to take care of representative set of examples you want to generalise. A part of the example analysis is a research of why the examples exist - are they here because something work in that way or somebody use the things in particular way. Plus, it would be nice to know if the examples really contribute into the picture.
We read the repositories by eyes because we still cannot properly automate the procedure we apply when reading. Here should be a big deal of semantic analysis (not just matching things) to model what we find when reading the repository. For now, it is very theoretical buy-in to a dynamic discovery and binding, especially for the business services where we affect the RWE and business functionality directly, because we cannot provide proper discovery (binding is easier). - Michael ________________________________ From: Steve Jones <[EMAIL PROTECTED]> To: [email protected] Sent: Thursday, December 4, 2008 2:51:00 PM Subject: Re: [service-orientated-architecture] Fowler on Registries In 2008 its a "bold" statement to say that dynamic discovery and binding isn't an idea you "particularly" buy into. I think most people thought it was bollocks in about 2001. Almost every decent registry product I've seen has been oriented around people usage, its the only way to go. Its a nice reference and they did some nice stuff but it really is what most people have been doing for the last 5+ years. Steve 2008/12/4 Gervas Douglas <gervas.douglas@ gmail.com>: > <<One of the features of the new world of services that SOA-gushers > promoted was the notion of registries. Often this was described in > terms of automated systems that would allow systems to automatically > look up useful services in a registry and bind and consume those > services all by themselves. > > Well computers may look clever occasionally, but I didn't particularly > buy that idea. While there might the be odd edge case for automated > service lookup, I reckon twenty-two times out of twenty it'll be a > human programmer who is doing the looking up. > > I was chatting recently to my colleague Erik Dörnenburg about a > project he did with Halvard Skogsrud to build a service registry that > was designed for humans to use and maintain. The organization was > already using ServiceCustodians to manage the development on the > project, so the registry needed to work in that context. This led to > the following principles: > > * People develop and use services, so orient it around people > (sorry UDDI, thank you for playing). > * Don't expect people to enter stuff to keep it up to date, people > are busy enough as it is. > * Make it easy for people to read and contribute. > > The heart of the registry is a wiki that allows people to easily enter > information on a particular service. Not just the builders of the > service, but also people who've used it. After all users' opinions are > often more useful than providers (I'm guessing product review sites > get more traffic than the vendors' sites). > > A wiki makes it easy for people to describe the service, but that > relies on people having time to contribute. A wiki helps make that > easy as you can just click and go, but there's still time involved. So > they backed up the human entry with some useful information gathered > automatically. > > * A tool that interrogates the source code control systems and > displays who has committed to a service, when, and how much. This > helps human readers find out who are the other humans who they should > talk to. Someone who did most of the commits, even if a while ago, > probably knows a lot about the core design and purpose of the service. > People who made a few recent commits might know more about the recent > usage and quirks. > * RSS feeds from CI servers and source code control systems. > * Task and bug information from issue tracking systems. > * Traffic data from the message bus indicating how much the > service is used, and when. Also the message bus gives some clues about > the consumers of the service. > * Interceptors in the EJB container that captured consumer > application names - again to get a sense of who is consuming the > service. These were on the consumer side to capture consumer > application names, and on the service to get a sense of the usage > patterns. > * Information from the Ivy dependencies. > > Much of this functionality was inspired by ohloh.net, in particular > this view. > > The point of a registry like this is that it does a lot of automated > work to get information, but presents it in a way that expects a human > reader. Furthermore it understands that the most important questions > the human reader has are about the humans who have worked on the > project: who are they, when did they work on this, who should I email, > and where do I go for a really good caipirinha?> > > > You can read this blog at: > > http://martinfowler .com/bliki/ > > Gervas > >
