Руководство Пользователя для Cisco Cisco Process Orchestrator 3.0
1-4
Cisco Process Orchestrator User Guide
OL-30196-01
Chapter 1 Understanding Service-Oriented Orchestration and the Cisco Process Orchestrator
Understanding Service-Oriented Orchestration
•
Relationships allow modeling of topologies of lower level services assembled to offer higher-level
services; that is, relationships allow lower-level objects to be bound together to achieve a larger
whole. Automation can navigate from a higher-level object, such as a service, to lower-level objects
against which they can perform automation.
services; that is, relationships allow lower-level objects to be bound together to achieve a larger
whole. Automation can navigate from a higher-level object, such as a service, to lower-level objects
against which they can perform automation.
–
Relationships allow you to navigate from one object to another in a workflow.
–
Target types define the property that models the relationship.
–
Target instances provide the link to a specific instance.
–
Relationships support inheritance.
–
Relationships can be set in the northbound web service like any property.
•
Processes provide actions that can be executed against targets. Process Orchestrator allows you to
view a target to see what actions are possible, or what automation is being done against those targets.
view a target to see what actions are possible, or what automation is being done against those targets.
The target types that a process can accept define the services on which a process can act.
•
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
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