Working with Registration Entries
The RegistryEntry class provides the data the Team Foundation tool requires to provide services in a Team Foundation domain. The fields in registry entries describe the important attributes of tools. This enables them to work together.
RegistryEntry Class
Team Foundation supports loose coupling so that the tools can communicate with minimum assumptions on their behavior. This is especially important because a Team Foundation domain can contain different types of tools. This includes tools that will be available only in the future and tools from a third-party company which do not yet exist. The tools can be written in managed or unmanaged code. They can be written in any programming language. They can support SOAP or not. They might not even support an HTTP interface. The only common denominator that is assumed about a tool is that it supports network calls and can be located on the network through an identifying string.
RegistryEntry Fields
The RegistryEntry class has the following fields.
Tool Type
Each Team Foundation tool has a type. The type corresponds to the name of the tool product. An example is "Team Build." This name is unique to the tool. The type the tool chooses must be communicated to all the other tools. This ensures they can locate the tool using the type information. This field is not optional.
ChangeType
Use RegistrationEntry as a value object. Among other things, you can use it for updating the Team Foundation Registration information. ChangeType is an enumeration that determines the kind of change to be performed on this entry. The default value is NoChange. The other possible values are Add, Delete and Change. This field is not optional.
Service Interfaces
Each tool must specify the Web Services it provides through a Service Interface. A ServiceInterface is a name/URL pair. As an example in a particular Team Foundation domain, Team Foundation provides the ServiceInterface <IRegistrationService, http://bx-iis/bisserver/registration.asmx>. If a tool named "A" must use a service provided by the tool named "B," it must first get the Registration Entry by using the type of the tool "B." Then it must get the specific service by using the ServiceInterface name. This assumes that tool A already has knowledge about the tool type and the names of the services it provides. Team Foundation itself does not attach any implicit semantics to one or more of these interfaces except for IBISEnablement interface and ToolDefaultArtifactAspServer. The ToolDefaultArtifactAspServer contains the base URL to which the Team Foundation Generic ASP page will route the artifact URI display requests. To make this possible, tool B must document this information. It should provide these values as constants in its interface. Tool A and tool B cannot communicate if this information is not mutually agreed upon. In the most common case, this also assumes that tool A creates the proxy to call the service that tool B provides. It instantiates its URL property using the URL provided in the RegistrationEntry. In some rare cases, the URL field can be instantiated by other network location identifiers such as a connection string for a database. The Service Interfaces array can be empty, if the tool does not provide any services.
RegistrationExtendedAttributes
RegistrationExtendedAttributes are name, value pairs to contain tool specific information. No semantic assumptions are made about these properties. It is the tool’s responsibility to define their semantics in their documentation so that they can be used by other tools. The Registration Extended Attributes array can be empty if the tool does not provide any.
EventTypes
A tool can support Events. An EventType is a name, schema pair. The Notification Specification Event type array can be empty if the tool does not provide any.
ArtifactTypes
A tool in the Team Foundation domain also must provide the types of artifacts it provides to the other Team Foundation tools. This is necessary for the Linking Service to follow the forward and backward links. An artifact type contains the name of the artifact type and a list of artifact types that these kinds of artifacts can point to through specified types of links. Because there is a one-to-many relationship between the source artifact type and the destination artifact types, we introduce the concept of a "OutboundLink." An Artifact Type contains a list of OutboundLinks. Each OutboundLink implicitly has this Artifact Type as its source. Each OutboundLink contains the name of the link type. Additionally, it contains the target tool name (that is <Tool Type>) and name of the destination Artifact Type. Artifact type array can be empty if the tool does not provide any.