Service Life Cycle Management

There are many ways of implementing API Life Cycle Management. Sentinet focuses on the runtime manageability by ensuring that all design-time decisions made are fully enforced and governed during runtime. Using the Graphical User Interface of the Sentinet Administrative Console, Sentinet administrators and developers declaratively express their design-time and runtime intents and decisions, Sentinet's runtime infrastructure remotely executes and enforces these.

The subjects of design-time and runtime manageability are the SOAP services and REST APIs managed by Sentinet. At design-time, services are registered in the Sentinet Repository as the software assets, and their metadata (WSDL or Swagger documents) and associated artifacts and attributes become available for analysis, control, and change management by the Sentinet users. At runtime, Web Services and REST APIs become managed software assets, when they are virtualized and exposed through one or more Sentinet Nodes. These dynamic Virtual Services hosted in the Sentinet Nodes provide non-intrusive enablement and enforcement of security, monitoring, access control, service agreements management, and all other aspects of real SOA and APIs agility and runtime management.

In Sentinet terms, a SOAP service version or a REST API version (virtual or non-virtual) goes through several design-time and runtime states, namely: Draft, Active, Obsolete and Retired. A Sentinet service version is "promoted" when it is moved from the previous state to the next state in its forward-only lifecycle. Once a service reaches the Retired state, it can only be deleted.

Service Life Cycle states
Figure. Service Life Cycle states.

Below is the summary of each state's definition:

  • Draft

    At the Draft stage, a service version registered in the Sentinet Repository can be changed in many ways, and service version's current state is considered incomplete and its configuration can be inconsistent. A service version in Draft state can be virtualized through a virtual service that is also in Draft state, but the virtual service cannot be actively hosted in a Sentinet Node(s) unless virtualized service version and virtual service version are both in Active state. That means that service version in Draft state is not managed at runtime.

  • Active

    A virtual service version can be in Active state only if virtualized service version is also in Active state. Active service versions (virtual or non-virtual) must have endpoints with fully defined and consistent configurations such as transport bindings, policies and endpoint identities. Promoting virtual services to Active state makes them physically hosted on the remote Sentinet Node server(s). Active services' endpoints can be modified (add, remove, change of endpoint address, transport binding, policy, change or update identity) as long as the Active Service version maintains at least one valid endpoint.

  • Obsolete

    Service versions in the Obsolete state remain actively hosted through virtual services. Obsolete services versions are candidates for retirement. They are often used to indicate that they are planned for ongoing replacement by new service versions.

  • Retired

    Retired Services cannot be modified and cannot be actively hosted. A service can be promoted from the Obsolete to the Retired state if it is not virtualized, or if its virtual services are in the Retired state. Retired services exist to maintain the history of services and APIs and their past transactions (message exchanges).

A service in any state can be deleted at any time providing it is not virtualized (i.e. not referenced by other virtual services).