A Glance at Orchestration for Modern Enterprise
Enterprise Integration is one of the core services that UltraVista provides. The area of the Enterprise Orchestration plays a big role in our business portfolio. Before diving in, let’s take a look at the Enterprise Architecture stack and the orchestration layer.
In essence, the Enterprise Orchestration is the management of the interdependencies among departments with the aim of ensuring that individual organizations collaborate in a coherent and consistent way to provide an integrated response to Enterprise Architecture and customers. Orchestration for modern IT represents a comprehensive and holistic approach to defining, building, orchestrating, managing and reporting on intelligent workflows that work with third-party tools and operational processes. When properly understood and correctly used, orchestration helps IT accelerate the business. It puts more power in the hands of users, connecting them with elastic resources. It gives control to IT staff members, helping speed problem resolution. It drives standardization and increases service availability, keeping employees productive. Orchestration gives IT more time to focus on helping move the business ahead, by making complex procedures easy to repeat while reducing the possibility of human errors. IT organizations that take advantage of orchestration are able to improve efficiency and service quality while reducing operational costs; since it helps less-skilled IT staffers implement complex activities that span networks, servers, storage, applications, and databases.
The Enterprise Orchestration is set of intertwined processes and it combines Business Processes Integration, Business Process Management and Business Process Modelling. The orchestration processes excels in identifying the right information, receiving the right information at the right place, visualizing updated information in real time, reflecting the actual state of the enterprise operation (including environmental changes such as new customer demands, new technology, new legislation or new philosophies of the society at large), coordinating business processes, organizing and adapting the enterprise.
Orchestration and SOA
The big part of the Enterprise Orchestration relies on SOA. Service Oriented Architecture (SOA) is an approach to developing enterprise systems by loosely coupling interoperable services - small units of software that perform discrete tasks when called upon - from separate systems across different business domains. SOA offers mode departments a way to develop new business services by reusing components from existing programs within the enterprise rather than writing functionally redundant code from scratch and developing new infrastructures to support them. With SOA, functionalities are expressed as a collection of services rather than a single application, marking a fundamental shift in how developers approach enterprise architecture design.
A crucial aspect of SOA is service orchestration. It is well known fact that enterprise systems and integration projects designed according to SOA principles depend on successful service orchestration. Finding a platform with enhanced service orchestration capabilities, then, is a high priority for enterprises looking to build their systems according to SOA. In a truly service oriented architecture, new applications are created by new orchestrations of existing services - not by writing new code.
Similar to an organizational work flow, service orchestration is the coordination and arrangement of multiple services exposed as a single aggregate service. Developers utilize service orchestration to support the automation of business processes by loosely coupling services across different applications and enterprises and creating "second-generation," composite applications. In other words, service orchestration is the combination of service interactions to create higher-level business services.
Service orchestration works through the exchange of messages in the domain layer of enterprise applications. Since individual services are not programmed to communicate with other services, messages must be exchanged according to a predetermined business logic and execution order so that the composite service or application can run as it is demanded by the end-user. This is usually accomplished through enterprise application integration (EAI), which enables data integration, and the use of a central messaging engine such as an enterprise service bus (ESB), which routes, transforms and enriches messages.
Related to service orchestration is service choreography. Though both are employed to create composite services and applications in service oriented architectures, it it is worth pointing out the differences. A service choreography model works without a central messaging engine or orchestrator while a service orchestration model relies on a central controller to couple services. In the former, the participating services each know the business logic and sequence and timing of message exchanges. In the latter, the participating services don't know that they are being orchestrated as part of a higher-level service; only the central controller knows the business logic and messaging sequence.
Choreography versus OrchestrationChoreography and orchestration, in an SOA context, pertain to the use of processes that span multiple participants, with message traffic moving in all directions according to a complex set of rules. Choreography and orchestration are attempts to coordinate or control all of this activity. They attack the problem by putting rigour on how message exchanges are represented, and by organizing the overall process using the right set of control flow patterns. Use cases in this area can be inter-organizational (for example, B2B commerce involving buyer, seller, and wholesaler), or intra-organizational if the organization is large enough and the participants act as separate organizations (for example, bank account processes spanning the front office, the back office, and the fraud department).
- The coordination of component processes is centrally managed by a known coordinator
- Web services can be incorporated without their being aware that they are taking part in a larger business process
- Alternative scenarios can be put in place in case faults occur.
By convention, choreography describes the global protocol governing how individual participants interact with one another. Each participant has its own process, but choreography is a master process that acts as a kind of traffic cop. Significantly, the choreography process does not actually run. It is not a central broker in the live message exchange, but merely a message exchange protocol. If the participants follow the protocol, the live exchange will run as smoothly as if there were a central broker.
Enterprise Orchestration requires new roles and responsibilities:
- Supporting search and selection
- Assessment of needs
- Service discovery and finding
- Service request: translating needs into sub-service requests
- Communicating service request to involved parties
- Monitoring progress: ensuring that lead-times are met
- Enterprise Architecture and Orchestration/li>
- Collecting response and integrating them into a single answer
- Creating and disseminating (integrated) information about the services
- Advertising and creation awareness for services
- Reducing service request and delivery costs
- Progress monitoring and tracking and tracing
- Balancing and integrating conflicting interests between customer service levels and efficiency
- Ensuring an efficient and effective service delivery.
To make a real-world sense of the above high-stake words, let’s take a look at a typical customer service example that UltraVista finds to be a “no-brainer” example for the orchestration. At its simplest, customer approaches the organization requesting something (goods, document, permit, insurance, etc…) and upon processing request, the organization responds by providing what was requested.
As it can be seen from the illustration, without orchestration:
- Customers have to interact with all enterprise departments
- Organizations are not used to collaborating with each other
- Limited incentives for cooperation Enterprise Architecture and Orchestration
- The decision authority and responsibility for service provisioning is dispersed
- No commonly shared goals, objectives and values
- Opposing rules and regulations, multiple or conflicting answers could be provided to customer
- To easy the integration pain, customer interactions can be facilitated by a portal.
Orchestration streamlines the process, enables efficiency and optimization, focusing on additional layer, instead of re-engineering the network, so at the end customers get a single answer.
Building a Business Process
The orchestration utilizes BPEL for definition of processes. Business Process Execution Language for Web Services (BPEL or BPEL4WS) is a language used for the definition and execution of business processes using Web services. BPEL enables the top-down realization of Service Oriented Architecture (SOA) through composition, orchestration, and coordination of Web services. BPEL provides a relatively easy and straightforward way to compose several Web services into new composite services called business processes.
A BPEL process specifies the exact order in which participating Web services should be invoked, either sequentially or in parallel. With BPEL, you can express conditional behaviors. For example, an invocation of a Web service can depend on the value of a previous invocation. You can also construct loops, declare variables, copy and assign values, define fault handlers, and so on. By combining all these constructs, you can define complex business processes in an algorithmic manner. In fact, because business processes are essentially graphs of activities, it might be useful to express them using Unified Modelling Language (UML) activity diagrams.
In a typical scenario, the BPEL business process receives a request. To fulfill it, the process invokes the involved Web services and then responds to the original caller. Because the BPEL process communicates with other Web services, it relies heavily on the WSDL description of the Web services invoked by the composite Web service.
Let's take an example. A BPEL process consists of steps; each step is called an "activity." BPEL supports primitive as well as structure activities. Primitive activities represent basic constructs and are used for common tasks, such as the following:
- Invoking other Web services
- Waiting for the client to invoke the business process by sending a message, using (receiving a request)
- Generating a response for synchronous operations
- Manipulating data variables
- Indicating faults and exceptions
- Waiting for some time
- Terminating the entire process.
We can then combine these and other primitive activities to define complex algorithms that specify exactly the steps of business processes. To combine primitive activities, BPEL supports several structure activities. The most important are:
- Sequence ( ), which allows us definition of a set of activities that will be invoked in an ordered sequence
- Flow ( ) for defining a set of activities that will be invoked in parallel
- Case-switch construct ( ) for implementing branches
- While ( ) for defining loops
- The ability to select one of several alternative paths
- Each BPEL process will also define partner links, and declare variables.
To understand how business processes are described with BPEL, we will define an oversimplified business process for employee travel arrangements: The client invokes the business process, specifying the name of the employee, the destination, the departure date, and the return date. The BPEL business process first checks the employee travel status, assuming that a Web service exists through which such checks can be made. Then the BPEL process will check the price for the flight ticket with two airlines: American Airlines and Delta Airlines. Again assume that both airline companies provide a Web service through which such checks can be made. Finally, the BPEL process will select the lower price and return the travel plan to the client.
Then, we will build an asynchronous BPEL process. We will assume that the Web service for checking the employee travel status is synchronous. This is reasonable because such data can be obtained immediately and returned to the caller. To acquire the plane ticket prices we use asynchronous invocations. Again, this is a reasonable approach, because it might take a little longer to confirm the plane travel schedule. We assume that both airlines offer a Web service and that both Web services are identical (i.e. provide equal port types and operations) to simplify our example.
In real-world scenarios, we will usually not have the choice about the Web services but will have to use whatever services are provided by partners infrastructure. If we have the luxury of designing the Web services and BPEL process at the same time, we would want to consider which interface is better. Usually we'll use asynchronous services for long-lasting operations and synchronous services for operations that return a result in a relatively short time. If we use asynchronous Web services, the BPEL process is usually asynchronous as well.
When we define a business process in BPEL, we essentially define a new Web service that is a composite of existing services. The interface of the new BPEL composite Web service uses a set of port types through which it provides operations like any other Web service. To invoke a business process described in BPEL, we have to invoke the resulting composite Web service. Figure below shows a schematic view of our process.