I'm going to take my usual middle-of-the-road stance and argue that
any human-facing registry/repository needs a way to support both the
known and the unknown. The beauty of a google-style search is that
it doesn't constrain the query. We can't possibly predict all
questions someone has in mind when they try to use the registry/
repository, although we can certainly predict some as Anne has done
here. It's also very important to have appropriate identity tracked
on all queries into the registry/repository so we can begin to
understand the roles that the users had when searching the system and
the goals they were trying to achieve. Tweaks can then continue to
be made up front to present the information without searching. A lot
of Anne's questions are things that shouldn't even require a search.
If I'm a service manager, I should log into the system and
immediately see a list of all services I manage, with the ability to
see details via a single click. Early on, however, appropriate
matching of roles/goals to activities in the product will be a
relative unknown.
This brings up an interesting aspect of these systems. A ways back,
I posted a blog entry after listening to a podcast about the inherent
advantage that companies like Salesforce and Amazon have in meeting
customer expectations. It's because they're able to view that entire
clickstream, perform analysis on it, and better understand how the
customers are using their systems. The typical registry/repository
is deployed inside the firewall, so the major vendors don't have the
ability to receive this data and improve the product as a result.
They have to rely on customer feedback and advisory boards, and I
doubt any users come with clickstream in hand to those discussions.
There's a bit of irony in that these registry/repositories can also
be the "clickstream store" for all run-time service interactions,
exactly the data that the enterprise should be looking at to better
understand how services are being used, beyond just the dependencies
that can be determined at the time the solution is constructed. It's
great that we know that Application A uses Service B. What we can't
know in advance is that 80% of Application A's invocations to Service
B uses data related to companies mentioned in the Wall Street Journal
that day, etc.
-tb
http://www.biske.com/blog
On Feb 12, 2007, at 8:22 AM, Anne Thomas Manes wrote:
Steve,
All registries maintain ownership information. That's a pretty
basic type of relationship, and it's built into the core UDDI data
model. I'm more interested in:
- which services meet or exceed this surety level?
- which services meet or exceed this SLA?
- which types contain customer information?
- which services use the corp-namespace:customer type?
- which services contain customer information?
- which artifacts don't comply with corporate policies (or this
specific set of policies)?
- which applications rely on this service?
- which services rely on this service?
- what system resources does this service rely on?
- which services are not currently being audited?
A repository should support these types of queries. And it should
do so using a Google style search tool. If it doesn't, it's not
much use. Most of the repository products support this type of
query. Systinet's search facility is the most powerful of the
systems I've looked at, and it permits you to search based on any
information in any or all artifacts in the respository. (The power
of XQuery and its ability to do the equivalent of "joins" really
comes through.) IBM also has a pretty powerful search facility, but
since the underlying system is based on XPath, it doesn't have the
ability to do a cross-artifact join (it's searching only in
individual artifacts; it can't do "joins"). Infravio's search
facility is based on SQL, so queries must resolve down to values
associated with individual table elements -- as a result the free-
form search is more constrained. (It indexes artifacts and captures
lots of info from the artifacts, but the search facility is much
less powerful than IBM or Systinet.)
Anne
On 2/11/07, Steve Jones <[EMAIL PROTECTED]> wrote:
I'm not disagreeing that these are important elements, and for me
more "runtime" or technical. Relationships can be done in free
form (they are just links afterall) and Google is pretty good at
that, hell you could even argue dependencies could be tracked that
way (but I won't). What I'm saying is that there are two problems,
one is how to get anyone, whether technical or not, to find
services for them to be used, the other is the technical governance
that needs to be done. The most important of these jobs is the
former as without it you can't get to the later.
Now the former is, as I think I've mentioned, one of the few places
that I've actually seen real benefits to "Semantic" web (namely the
semantic extensions to MediaWiki) as then you can query based on
the intentions of relationships "Give me all services that Bob
owns". If registries could adopt that form of style then it would
make them more people friendly for discovery.
On 10/02/07, Anne Thomas Manes < [EMAIL PROTECTED]> wrote:
Google certainly wins for human discovery, but what about
relationships, dependancy tracking, impact analysis, lifecycle
management, change control, and other governance capabilities?
Anne
On 2/10/07, Steve Jones <[EMAIL PROTECTED]> wrote:
[snip]
> XQuery is what gives the repository a powerful search capability.
REST is what enables users to more readily exploit the search
capability. I think Systinet did a pretty good job putting love
into its UI. Its competitors have a long way to go. (Systinet still
has a lot of stuff to do to enhance its product, and it really
needs to fix its performance problems, but its just way beyond with
the other folks have done.)
>
Anne, I'm not convinced that XQuery is a very effectively search tool
for a repository except for technical navigation. Its reliant on
knowledge of the XML structure and is based on traversal, thus loose
associations tend to be lost.
Registry for runtime and technical discovery, Google for humand
discovery makes more sense to me.
> Anne
>
> ps. And no -- I have no personal stake in HP or Systinet. I've
just completed a pretty thorough analysis of the leading products,
and I was astonished by the differences.
>
>
> On 2/10/07, Paul Downey <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> >
> >
> >
> >
> > On 9 Feb 2007, at 12:32, Anne Thomas Manes wrote:
> >
> > > Yes -- open content model, automatic detection of relationships,
> > > hyperlinks, REST architecture, excellent search. This is what
> > > differentiates Systinet's repository from the other players. It
> > > doesn't have a built-in wiki capability, although it does have a
> > > free-form description field for all artifacts. And the content
> > > model is extensible, so you could add/extend the description or
> > > comments field to allow folks to add more information.
> >
> > I periodically get to attend meetings where someone has a vision
> > which involves a single registry/repository to rule them all.
> > There follows a list of all the great metadata which this
> > single truth will "own".
> >
> > Usually a can't hear what they're saying due to the sound
> > of "Darth Vader's Theme" trumpeting in my lugholes.
> > Empire building.. Empire building ..
> >
> > Beyond the obvious political motivations for a central registry,
> > I just don't like the outcome. Flickr, Google, Amazon, etc all
put more
> > love into their developer web pages. It's no coincidence they're
> > adopted more widely by developers that services shoved into
> > a UDDI at the edge of the known universe.
> >
> > Web sites rock. Spreadsheets suck.
> >
> > Paul
> > --
> > http://blog.whatfettle.com
> >
> >
>
>
