Successfully governing an enterprise-class SOA-based system calls for keeping track of a large number of rapidly changing system components. This is the role of the AmberPoint Sphere, the repository used by AmberPoint SOA Management System to collect and track the information required to govern an SOA environment at runtime. The AmberPoint Sphere represents an extensive set of information about SOA components such as services, endpoints and consumers, along with supporting components such as appliances, application servers, service buses, identity management systems and registries.

Reducing manual steps is critical to making SOA environments scaleable and reducing their risk. That's why the AmberPoint Sphere automatically gathers and synchronizes as much of this information as possible through a variety of techniques, such as dynamic discovery, APIs, pre-built integration with third-party systems, and, of course, the actual runtime governance of the system throughout its lifecycle. Additionally, AmberPoint offers user interfaces for directly entering, reviewing, and modifying appropriate parts of the information.

In addition, the repository model is user extensible. AmberPoint users can define new types of data for each of the major components and then reference this information in their service use or their policy definitions used to govern the systems. For example, if the corporation does internal bill back of service use, they may want to add a data element such as TransactionFee for each service. Or, they may look to add a Location field for each service and apply security policies based on service's Location.

Extensive Information

Since comprehensive runtime governance requires a rich, complete set of information at its disposal, the AmberPoint Sphere is defined to handle all sorts of metadata. The complete set of information is too extensive to list completely; however, highlights are provided below.

Services and Endpoints

• Technical – Service name, nickname, container type, transport protocol, software type, date discovered, discovery mechanism, original URL, proxy URL (if applicable), UUID, documentation
• Lifecycle – Phase (development, production, etc), version
• Runtime Status – Alive, alive-since date, under management, management date
• Business Info – Name, email, phone number, web URL, and organization for each of business owner, technical owner support contact, and testing contact

Containers and Appliances
Applicable data from above plus management interface, login information, IP address

Policies

• Technical – Policy name, type, subtype, definition, dynamic assignment criteria, description, version, creator, creation date
• Lifecycle – Disabled/pending/applied, status date, runtime faults
• Runtime Status – Services/endpoints where policy is enforced, # of pending applications
• Business Info – Creator, creation date

Dependencies
Dependency information at the operations, endpoints, and services.

Cross-linking
Throughout the repository, it can reference cross-linked information such as web interfaces, web pages, documentation, and reference materials.

Synchronization
AmberPoint automatically synchronizes services metadata recorded in a registry—as well as the policies associated with those services—with the actual runtime state of your SOA. This exchange of information enables documentation of discrepancies between design and development intentions and runtime realities. For instance, it identifies rogue services and submits them for approval. Ad hoc management policies are brought to the notice of system owners. Administrators can also ensure that consumers are accessing managed service endpoints—endpoints that have been authorized for use.

In particular, the AmberPoint Sphere can synchronize:

• Service metadata (bidirectional)
• Endpoint metadata (bidirectional)
• Policy information (bidirectional)
• Runtime status
• Service scorecard