Cisco Cisco Process Orchestrator 3.0 User Guide
1-8
Cisco Process Orchestrator User Guide
OL-30196-01
Chapter 1 Understanding Service-Oriented Orchestration and the Cisco Process Orchestrator
Service Definition Examples
topology nodes fit within some network, with each tier separated by firewalls, and these nodes require
specific firewall configuration, so the application topology has relationships to a network topology. All
of this combines to form the service topology.
specific firewall configuration, so the application topology has relationships to a network topology. All
of this combines to form the service topology.
In a Platform as a Service solution, the customer must enable not only provisioning but ongoing
operations and eventually deprovisioning of services or applications, as opposed to IaaS where
individual virtual machines are provisioned. The leap involves treating a service or a collection of virtual
machines and their networks as a package. Applications or other services are provisioned and configured
on these VMs and networks. It involves an ordering experience that allows customers to deploy and use
those services.
operations and eventually deprovisioning of services or applications, as opposed to IaaS where
individual virtual machines are provisioned. The leap involves treating a service or a collection of virtual
machines and their networks as a package. Applications or other services are provisioned and configured
on these VMs and networks. It involves an ordering experience that allows customers to deploy and use
those services.
To this end, there is a need to define service or application blueprints so they can model their services
and make them orderable and support provisioning, operations, and de-provisioning of those services.
These blueprints capture what the customer needs to deploy some application. Customers want to receive
these blueprints from Cisco, or possibly from partners or a community. They also need to be able to build
these blueprints themselves and move them from development to test to production.
and make them orderable and support provisioning, operations, and de-provisioning of those services.
These blueprints capture what the customer needs to deploy some application. Customers want to receive
these blueprints from Cisco, or possibly from partners or a community. They also need to be able to build
these blueprints themselves and move them from development to test to production.
Service-Oriented Orchestration allows one to define, package, ship, and receive these models, as well as
to create instances of the service from that model. In this way, the company can drive a standardized
deployment of the service across development, test, and production systems. For example, a target type
could be created for a web server, while the specific web server target is an instance created from that
web server target type. This might have a relationship to the Linux server that hosts the web server.
to create instances of the service from that model. In this way, the company can drive a standardized
deployment of the service across development, test, and production systems. For example, a target type
could be created for a web server, while the specific web server target is an instance created from that
web server target type. This might have a relationship to the Linux server that hosts the web server.
A level 1 help desk operator might not know or care what specific database or LDAP instance supports
the customer support service, or what UCS blade actually runs a certain instance of the web server. They
want to do things against the customer support service. Say they want to authorize a new user to access
the customer support service and provision whatever they need. They would generally run an add-user
process, acting on the customer support service.
the customer support service, or what UCS blade actually runs a certain instance of the web server. They
want to do things against the customer support service. Say they want to authorize a new user to access
the customer support service and provision whatever they need. They would generally run an add-user
process, acting on the customer support service.
A Build process that acts on the customer support service is responsible for provisioning of the whole
of the service. This process might call the Build process for each target type in the topology, building
the service up an element at a time. This process might use files, like an OVF for a server, to stand up
the specific service element, or might invoke a tool such as Puppet or Chef.
of the service. This process might call the Build process for each target type in the topology, building
the service up an element at a time. This process might use files, like an OVF for a server, to stand up
the specific service element, or might invoke a tool such as Puppet or Chef.
Other examples of processes that act on the service or its elements are things like site disaster recovery,
that may need to make changes to many parts of the customer support distributed application to move it
to another site. These processes need to act on the customer support service as a whole, but leverage the
topology and relationships to traverse to other actions, possibly calling similar processes that act on
those elements. For example, a request to back up the overall service might invoke a backup of each
server in the topology as well as the database.
that may need to make changes to many parts of the customer support distributed application to move it
to another site. These processes need to act on the customer support service as a whole, but leverage the
topology and relationships to traverse to other actions, possibly calling similar processes that act on
those elements. For example, a request to back up the overall service might invoke a backup of each
server in the topology as well as the database.
Through Service-Oriented Orchestration, processes can act on the customer support service. As
necessary, the process can traverse relationships to lower level infrastructure and tool elements on which
it takes action. For example, a process that queries capacity might traverse to the database target, and
perform Process Orchestrator activities against that database.
necessary, the process can traverse relationships to lower level infrastructure and tool elements on which
it takes action. For example, a process that queries capacity might traverse to the database target, and
perform Process Orchestrator activities against that database.
A Cisco TelePresence Service
A TelePresence system has a number of components that automation can act on through SSH, SNMP, or
a web service. Prior to Process Orchestrator 3.0, to act on a service, one was required to browse through
all of the processes, filter by category or automation pack (see
a web service. Prior to Process Orchestrator 3.0, to act on a service, one was required to browse through
all of the processes, filter by category or automation pack (see
a process and specify the terminal, SNMP, or web service target. One had to understand the underlying
implementation to know what target to provide.
implementation to know what target to provide.