Cisco Cisco Process Orchestrator 3.1 User Guide
1-4
Cisco Process Orchestrator 3.1 User Guide
Chapter 1 Introduction
Understanding Service-Oriented Orchestration
•
Targets and target types have events. These can be internal process events or the open Advanced
Message Queuing Protocol (AMQP) protocol. Triggering processes in response to patterns in
underlying processes provides policy.
Message Queuing Protocol (AMQP) protocol. Triggering processes in response to patterns in
underlying processes provides policy.
•
Extensible by services, partners, customers. The content, not the platform, defines service
models. The platform is open to model any IT service topology within automation content. For
example, some types, actions, properties, etc. may come from the packaged product, some from
team 1, some from team 2, some from a partner, and some from a customer. Using this capability
you can assemble a complex solution from parts. Each author controls the version control and
lifecycle of the elements they deliver so they can deliver upgrades.
models. The platform is open to model any IT service topology within automation content. For
example, some types, actions, properties, etc. may come from the packaged product, some from
team 1, some from team 2, some from a partner, and some from a customer. Using this capability
you can assemble a complex solution from parts. Each author controls the version control and
lifecycle of the elements they deliver so they can deliver upgrades.
•
A consistent API, even if elements come from different authors. Users and automation pack authors
(see
(see
) can control which target types are published to the NorthBound Web
Service (NBWS; see the Northbound Web Services Guide). For published objects, Process
Orchestrator exposes the type uniquely in the NBWS. As content teams, services, partners, or
customers extend types, these APIs are maintained to provide a consistent format for APIs across
all types of objects. However, each type of object is uniquely supported.
Orchestrator exposes the type uniquely in the NBWS. As content teams, services, partners, or
customers extend types, these APIs are maintained to provide a consistent format for APIs across
all types of objects. However, each type of object is uniquely supported.
•
Authors can also configure which properties are exposed in the NBWS as optional parameters in the
per-type WSDL.
per-type WSDL.
Aligned to IT Standards
While Service-Oriented Automation is open, allowing any model, it aligns to IT best practices such as
the IT Infrastructure Library (ITIL). ITIL prescribes a configuration management database (CMDB) as
a central tenet which allows high level services to be decomposed into their supporting lower level
services and ultimately to the lower level systems and devices. In ITIL, each element in the model is
called a Configuration Item since it is a unit of configuration. This provides a mapping of how lower
level elements support business services. Service-Oriented Orchestration allows automation to be driven
through a model of current and desired IT services, aware of their relationships and interdependencies.
In this aspect, the principles of service modeling are substantially the same as modeling services within
ITIL and CMDBs.
the IT Infrastructure Library (ITIL). ITIL prescribes a configuration management database (CMDB) as
a central tenet which allows high level services to be decomposed into their supporting lower level
services and ultimately to the lower level systems and devices. In ITIL, each element in the model is
called a Configuration Item since it is a unit of configuration. This provides a mapping of how lower
level elements support business services. Service-Oriented Orchestration allows automation to be driven
through a model of current and desired IT services, aware of their relationships and interdependencies.
In this aspect, the principles of service modeling are substantially the same as modeling services within
ITIL and CMDBs.
However, the implementation bypasses many of the negatives and weight of typical CMDB
implementations. Process Orchestrator can integrate with a CMDB if it is there. Targets provide a natural
synchronization point to exchange data with a CMDB, and target events allow that synchronization to
be externalized from other processes. However, Service-Oriented Orchestration does not require a
CMDB; one does not have to have a CMDB to enable orchestration to function. Often orchestration
needs a reduced model vs. what is in the CMDB, and it is therefore much easier to keep the smaller data
set current. For example, resource management can be more efficient when externalized. Moreover, a
CMDB typically represents actual elements and not potential elements, and since orchestration is often
responsible for provisioning, the orchestrator may have data prior to its life in the CMDB, which it might
write to the CMDB as it is instantiated. Even if Process Orchestrator service models leverage data in
CMDBs, performance is improved by keeping this data in Process Orchestrator target properties to
optimize queries. Process Orchestrator allows a local representation of only those services that relate to
what you want to automate, so that the implementation is right-sized and lighter than complete CMDBs.
Updates are more real time and targeted to the need of automation. A conceptual alignment to ITIL and
CMDB principles creates the flexibility to right size the implementation and unify with CMDBs when
needed.
implementations. Process Orchestrator can integrate with a CMDB if it is there. Targets provide a natural
synchronization point to exchange data with a CMDB, and target events allow that synchronization to
be externalized from other processes. However, Service-Oriented Orchestration does not require a
CMDB; one does not have to have a CMDB to enable orchestration to function. Often orchestration
needs a reduced model vs. what is in the CMDB, and it is therefore much easier to keep the smaller data
set current. For example, resource management can be more efficient when externalized. Moreover, a
CMDB typically represents actual elements and not potential elements, and since orchestration is often
responsible for provisioning, the orchestrator may have data prior to its life in the CMDB, which it might
write to the CMDB as it is instantiated. Even if Process Orchestrator service models leverage data in
CMDBs, performance is improved by keeping this data in Process Orchestrator target properties to
optimize queries. Process Orchestrator allows a local representation of only those services that relate to
what you want to automate, so that the implementation is right-sized and lighter than complete CMDBs.
Updates are more real time and targeted to the need of automation. A conceptual alignment to ITIL and
CMDB principles creates the flexibility to right size the implementation and unify with CMDBs when
needed.
Also, ITIL prescribes key process records such as alerts, incidents, and change requests that drive the IT
operations process. Process Orchestrator provides a native representation for these concepts. This allows
content to be abstracted from how these concepts are provided in a company. For example, content that
detects an IT incident does not have to encode the specific service desk used by a particular customer.
operations process. Process Orchestrator provides a native representation for these concepts. This allows
content to be abstracted from how these concepts are provided in a company. For example, content that
detects an IT incident does not have to encode the specific service desk used by a particular customer.