Basic Registry Requirements

Lets do this didactically and start with the obvious basics. Now I am about to answer a question that I am going to write about in more depth later...but go with me on this...Lets start with a system of operationally separate components, lets further assume that this system of functional...the functionality of this system is expected to grow over time. Now I am also going to assume that this is a big system...but I am not going to tell you the actual size of the system because that depends upon how I measure big. My measure of big is different if there are tone or two guys working it or if there are 250 belly buttons working it. The problem just gets exponentially bigger the more BBs I add, since I am a big believer in my corollary to the Second Law of Thermodynamics (Stupid will fill the volume it is given). And (not to offend anyone , gosh forbid anyone be offended) for each bb i have, there is another ass hole (Famous Quote: "They're all Ass Holes, Sir!" Name the movie and win a prize...and no you can't Google it. Anyway for each BB I have here I have one AH doing his own thing, AND that (coupled with a few other things) is exactly the goal of what a Services Registry is to do. I know, they can still do their own thing, but we are going to assemble a complete systems engineering profile in this blog, it just so happens that we are starting soomewhere in the middle since the Services Registry is the problem of the day. Yeah that's what systems engineering is all about...by the way...its not about installing FRD on a EDW platform using HTG-R4...that's something else,,,that's not even solving the problem.I do not need a PHD to tell me I forgot to move the configure files over to the xyz directory. If you're a PHD, start solving problems, stop being a technician.

OK what are the basic functions of a Services Registry?

Register a Service	Name of Service using naming convention
	Functional description
	Reference to Service (Where is the 411 on this service)
	Calling protocol(see below)
	Contact info (including Organization)
	Public/Private
	SLA
	Metadata

Discover	By Name
	By Key
	By Organization
	By protocol(see below)
	By Contact info
	By Public or Private
	SLA
	By metadata name space

there are optional functions that my services registry can have, some I was very excited about in the beginning and have now cooled to...like real time discovery) but other real functions that Registries can have are OK Real time discovery, Self Registering services, and of course Federation. In a latter blog, I will provide you with a very good argument why Federation is overblown as a capability. But this is enough for now.