Welcome!

Microservices Expo Authors: Liz McMillan, Pat Romanski, Carmen Gonzalez, Elizabeth White, Jason Bloomberg

Related Topics: Government Cloud, Java IoT, Microservices Expo, Open Source Cloud

Government Cloud: Article

Showcasing the Key Design Principles of SOA

A Case Study: Orchestrating Services Using Open Source BPEL

SOA & WOA Magazine on Ulitzer

WS-BPEL 2.0 is the dominant specification to standardize orchestration logic and process automation between Web services. The BPEL model is used to assemble a set of discrete, essentially disparate, services into an end-to-end process flow to transform the existing stateless and uncorrelated Web service infrastructure into cohesive, process-centric applications based on a service-oriented architecture.

Under this model, new applications are developed "on-the-fly" by wiring together external "partner" services that leverage existing enterprise assets. JBoss's jBPM product is an open source platform for BPEL as well as other graph-based execution languages and provides the runtime infrastructure: interpretion, extraction/WSDL document publishing, flow execution, analytics, transactional and persistence support for the deployed service composition model. A use case example demonstrates a simplified process domain comprising of a composite service that consists of two partner relationships: JAX-RPC synchronous and asynchronous service endpoints, respectively.

Web services represent the building blocks of a service-oriented architecture and use a loosely coupled, interoperable, reusable and discoverable model to allow for flexible integration of heterogeneous systems in a variety of domains: business-to-consumer, business-to-business and enterprise application integration.

With the maturity of the JCP specifications (popularly JAX-RPC, JAX-WS and JAX-RS) and various reference implementations and tools supporting the individual technology stacks (WS-* or REST), it is relatively easy to create single service endpoints [1] (or as in the case of REST, Web resources [2]), each encapsulating a unique functionality and have it invoked by one or more clients. However, for more complex systems that require coordinating between multiple services, for example, system integration efforts connecting home-grown legacy systems to ERP and other enterprise systems for fulfillment of a unique business goal require more than just the ability to conduct simple interactions by using standard protocols and the stateless WSDL-supported model of request-response or uncorrelated one-way interactions. What is required is a way for applications and business processes to integrate their complex interactions by using a standard process integration model. The real promise of SOA is not realized by building and consuming disparate services alone but by defining clear cohesive services that wholly describe their interactions that are then capable of being reused, through composition, in a variety of process-based services. Therefore, what you really need in such cases is a way to conveniently express the flow in business semantics, something that sufficiently abstracts away the individual services within a process context, executed on the server; and ultimately exposes a WSDL that can then be called on by a Web service client. In the world of SOA this is called an orchestration and often executed using BPEL, or Business Process Execution Language [3].

About BPEL
WS-BPEL 2.0, the latest underlying OASIS standard around which most current BPEL implementations are based, leverages Web services as the model for process decomposition and defines an XML-based "model and a grammar for describing the behavior of a business process based on interactions between the process and its partners. The interaction with each partner occurs through Web service interfaces" [4]. In essence, WS-BPEL defines how interactions with these partners are orchestrated (coordinated) to achieve a business goal.

A deployed BPEL application represents a new and complex composite service that is composed of basic services and the various interactions/message exchanges between them. BPEL defines an executable language for specifying interactions with these basic Web services that support some of the commonly used features of a WS-* process language construct: XML and WSDL typed variables, property-based message correlations, expressions and queries using XPath, transformations using XSLT, fault/event handlers along with structured logic constructs and flow directives and support for robust workflow features such as parallel execution, flow sequencing and chaining

Common representations are in an XML-formatted document with a .bpel extension that conforms to the WS-BPEL standard and executes within the BPEL engine environment, which provides the interpretion, execution, analytics, transactional support, and persistence store for the deployed model service composition. The interactions with the external entities are abstract in the sense that the dependence is on port type operations and message definitions represented via XML schemas, thereby abstracting business logic into flow directives, which encourages high cohesion and loose coupling between the service implementations.

About jBPM-BPEL
JBoss/RedHat's jBPM is an open source platform for graph-based execution languages [5]. Its pluggable architecture makes it possible to support different workflow languages (mainly jPDL and BPEL) that can be modeled as some kind of abstract flow directive. jPDL (Java Process Definition Language) is jBPM's native workflow language and is similar to BPEL in as much as it was created to model and assemble a discrete set of processes into an end-to-end process flow. This is where the similarity ends, with the main difference being that in jPDL the variable context for the process data is made up of Java POJOs whereas BPEL processes use XML constructs. BPEL is the focus of this article so I'll not delve further on the differences between the two process technology stacks. However, it's worthwhile to note that BPEL is more widely adopted and supported. The main reason being, most business processes involve frequent interactions with heterogeneous systems and partners with interoperability/platform independence being essential. Factor in XML as the populist (efficient, manipulable, interoperable and developer-friendly) message exchange mechanism along with QoS demands for an increasingly wired world and now you know why.

jBPM is built upon a persistence model with Hibernate as its default object-relational mapping solution [6]. This means that installation of the jBPM-BPEL software involves deploying an enterprise archive (.EAR) component (containing required libraries and configuration files) along with configuring a Data Source (pointing to a jBPM database) within the application server. Once successfully deployed, the jBPM-BPEL runtime is ready to extract new process definitions, create process service endpoints, publish WSDL contracts and orchestrate the composite service all of whose state is persisted within the jBPM database.

An Example Process Domain
Figure 1 shows a highly simplified Process domain comprising of a composite service that consists of two partner services: a POJO synchronous service endpoint represented by Forms and a POJO asynchronous endpoint represented by Imaging. In actuality, the partners represent our internal Forms Management and Imaging systems, respectively, whose interactions can be captured in a BPEL workflow and deployed to a jBPM-BPEL runtime engine to collectively work in rendering PDF documents that are then archived away as image files.

The Forms system consists of a JAX-RPC document-style POJO endpoint implemented by JBoss's very own JAX-RPC SOAP stack, the JBossWS framework. The Service Endpoint Interface (SEI) and implementation bean for this service are shown in Listing 1. (Listings 1 - 10 can be downloaded here.) JAX-RPC endpoints leverage the slightly older J2EE 1.4 programming model, which requires packaging of a number of deployable descriptors for the Web service [7] (newer specifications like JAX-WS does away with most descriptors by providing all endpoint associated metadata via annotations [8] that perform compile/runtime dependency injections, thereby greatly simplying the development model). However, WS-BPEL is not supported by JAX-WS, therefore we are limited to using JAX-RPC endpoints for our external service implementations for use by the BPEL composite process.

A number of deployment descriptors need to be created prior to packaging this endpoint and bean implementation (see Listing 1); the webservices.xml descriptor that identifies the deployment of a Web service endpoint, the abstract service WSDL contract and the jaxrpc-mapping.xml descriptor that maps the WSDL document schema elements to Java classes. JBossWS comes with a handy wstools utility that creates all the aforementioned artifacts either from the command line or at build time. The POJO endpoint is packaged as a Web application in a WAR file and is deployed as a servlet accessible via a URL pattern. Once the services are packaged this way and deployed to a JBossWS compliant application server, they are then visible via the Web service console at http://<machine>:8080/jbossws/services.

The Imaging system upon receiving the PDF rendered form (represented as binary stream data) will initiate the image archival process (internal details of which are best left out as they are beyond the scope of this article), an asynchronous component, which finally returns a response consisting of an image index and a system message on a JMS message queue. Other than this, development and packaging of the Imaging service endpoint (ImagingPT) is very similar to what was done earlier for the FormsPT SEI and Service implementation.

Once the partner or external system endpoints have been developed and deployed, we need to let jBPM-BPEL know about its existence. This is typically done through the Partner Sevices Catalog available under the jBPM-BPEL console (http://<machine>:8080/jbpm-bpel/partners.jsp) (refer to Table 1).

A process scenario would have the central orchestrating service call the Forms system with a set of parameters (form design number, form field data etc.) to render a pre-populated PDF form. Next, it would send the PDF form (represented as a byte array data) to the Imaging system to initiate the image archival process. The imaging system responds asynchronously on a JMS queue with the image index and a system message that is then picked up by a MessageDrivenBean (deployed along with the Imaging endpoint) listening on the same queue, which calls back into the orchestrating service, triggered upon receipt of the javax.jms.Message. The service then bundles all the return values into an invoice which is sent back to the calling client of the process.

BPEL Process Development Methodology
There are two main options for designing a business process: Top-Down or Bottom-Up [9]. Both methods lend themselves to a design approach using a visual BPEL process designer of which there are quite a few open source options.

The Top-Down approach is as its name suggests. Essentially, you model all the intermediary (partner) components that make up the composite service. This may involve interviewing business stakeholders and analysts to come up with the ideal service parameter definitions and return values. You basically would want to view the services and compositions from the invoker's point of view, which would necessitate keeping the service granularity at the appropriate level of abstraction. Once done, you can start adding technical details to the process such as port types, schemas, partner links, variables, scopes, sequences, conditional logic, error handling and other task activities to build out an orchestration of the composite service. This design method suits those enterprises that need to develop new partner services and processes from scratch and is what we used.

Alternately, using a Bottom-Up method involves using pre-existing services and the WSDL documents available within your environment to create out the orchestrated business processes wherin you would add the technical details to the process exactly the same way as in the Top-Down approach.

Creating the BPEL Process Definition Document
The BPEL process definition document models the entire workflow in XML, which upon deployment is interpreted and translated by the jBPM-BPEL runtime engine to provide the runtime infrastructure as a centralized orchestrating composite service with its own endpoint and service WSDL contract. This section goes over the basic structure and content of the BPEL document for the example process domain as illustrated in Figure 1.

a. Creating Partner Links and Defining Related Port Types
The <process> element is the root element of all BPEL process definition documents. It declares all the namespaces used within the process (including that of itself) and imports the namespaces for all external or partner services. The namespace declaration is http://docs.oasis-open.org/wsbpel/2.0/process/executable, which is the standard root namespace for all BPEL 2.0 processes. The <import> element is used to declare a dependancy on either an XML schema or the WSDL contract of an external or partner service that must exist in the same relative path (attribute "location") as the central process document and qualify all imported definitions with the namespace attribute. In our example described earlier, the process imports a WSDL file that defines the partner links that it uses and is available in the same directory as the BPEL file along with two other separate WSDL files, for the previously deployed Forms and Imaging endpoints (refer to Listing 2 - a section of the BPEL process document).

Partner links are made available within a BPEL document by adding the namespace of "xmlns:plnk=http://docs.oasis-open.org/wsbpel/2.0/plnktype" and can be thought of as analogous to business partners; they define the different external entities that are consulted during the execution of the business process and define the relationship between the Web services involved in the process fulfillment. The partner link represents an interaction between the central orchestrating service and the external service by indicating the port types used in the relationship (see Listing 3) and is characterized by a partner link type that defines the roles played by each of the services in the context of the conversation. Each partner link type defines essentially two roles: myRole, which indicates the role of the process itself in the relationship, and partnerRole, which indicates the role of the partner. The process document snippet in Listing 2 defines three partner link types (one for the orchestrating service workflowLT and one each for the external services that are invoked formsLT and imagingLT) described by their respective port types in the process WSDL document as shown in Listing 3. Note that the port types, which are an abstraction of the service endpoint interface (SEI) (frm:FormsPT and img:ImagingPT, respectively), are defined in the Forms and Imaging service WSDL definition files that were imported previously into the process context. Therefore, the formsLT partner link type is a conversational relationship, initiated by the process, with the Forms SEI that is defined by port type frm:FormsPT. The workflowLT is initiated by an external client that calls the process whose conversation involves the SEI for the process (defined as pos:workflowPT within the context of the process WSDL definition and shown in Listing 4). The imagingLT has two roles: one that is initiated by the process calling into the Imaging endpoint SEI that is defined by the port type img:ImagingPT and the other is a callback into the process initiated by the asynchronous Imaging service. How that callback exactly occurs is detailed in a later section. It's important to point out that upon deployment of this BPEL process document, each myRole definition on the partner link results in publication of as many port types all served by the same central composite service. Please refer to Listing 5 for a snippet of the composite service's WSDL document created by jBPM-BPEL upon deployment and available under http://<machine>:8080/jbossws/services.

More Stories By Rizwan Ahmed

Rizwan Ahmed is an IT Systems Architect and author. He has about 10 years of experience in the public and private sector architecting technology, systems and security solutions. He holds Bachelor's and Master's degrees from the Indian Institute of Technology and the Florida State University, respectively. Passionate about open source as contributor and evangelist, he is also a frequent speaker at Java user groups, conferences and sponsored workshops. He holds the Sun Certified Java Programmer, Certified Information Systems Security Professional (CISSP), Certified Secure Software Lifecycle Professional (CSSLP) and the Project Management Professional (PMP) credentials. He lives with his wife and two kids in Columbia, SC.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Microservices Articles
Modern software design has fundamentally changed how we manage applications, causing many to turn to containers as the new virtual machine for resource management. As container adoption grows beyond stateless applications to stateful workloads, the need for persistent storage is foundational - something customers routinely cite as a top pain point. In his session at @DevOpsSummit at 21st Cloud Expo, Bill Borsari, Head of Systems Engineering at Datera, explored how organizations can reap the bene...
"NetApp's vision is how we help organizations manage data - delivering the right data in the right place, in the right time, to the people who need it, and doing it agnostic to what the platform is," explained Josh Atwell, Developer Advocate for NetApp, in this SYS-CON.tv interview at 20th Cloud Expo, held June 6-8, 2017, at the Javits Center in New York City, NY.
The Jevons Paradox suggests that when technological advances increase efficiency of a resource, it results in an overall increase in consumption. Writing on the increased use of coal as a result of technological improvements, 19th-century economist William Stanley Jevons found that these improvements led to the development of new ways to utilize coal. In his session at 19th Cloud Expo, Mark Thiele, Chief Strategy Officer for Apcera, compared the Jevons Paradox to modern-day enterprise IT, examin...
In his session at 20th Cloud Expo, Mike Johnston, an infrastructure engineer at Supergiant.io, discussed how to use Kubernetes to set up a SaaS infrastructure for your business. Mike Johnston is an infrastructure engineer at Supergiant.io with over 12 years of experience designing, deploying, and maintaining server and workstation infrastructure at all scales. He has experience with brick and mortar data centers as well as cloud providers like Digital Ocean, Amazon Web Services, and Rackspace. H...
Skeuomorphism usually means retaining existing design cues in something new that doesn’t actually need them. However, the concept of skeuomorphism can be thought of as relating more broadly to applying existing patterns to new technologies that, in fact, cry out for new approaches. In his session at DevOps Summit, Gordon Haff, Senior Cloud Strategy Marketing and Evangelism Manager at Red Hat, will discuss why containers should be paired with new architectural practices such as microservices ra...
In his session at 20th Cloud Expo, Scott Davis, CTO of Embotics, discussed how automation can provide the dynamic management required to cost-effectively deliver microservices and container solutions at scale. He also discussed how flexible automation is the key to effectively bridging and seamlessly coordinating both IT and developer needs for component orchestration across disparate clouds – an increasingly important requirement at today’s multi-cloud enterprise.
The Software Defined Data Center (SDDC), which enables organizations to seamlessly run in a hybrid cloud model (public + private cloud), is here to stay. IDC estimates that the software-defined networking market will be valued at $3.7 billion by 2016. Security is a key component and benefit of the SDDC, and offers an opportunity to build security 'from the ground up' and weave it into the environment from day one. In his session at 16th Cloud Expo, Reuven Harrison, CTO and Co-Founder of Tufin, ...
DevOps is often described as a combination of technology and culture. Without both, DevOps isn't complete. However, applying the culture to outdated technology is a recipe for disaster; as response times grow and connections between teams are delayed by technology, the culture will die. A Nutanix Enterprise Cloud has many benefits that provide the needed base for a true DevOps paradigm. In their Day 3 Keynote at 20th Cloud Expo, Chris Brown, a Solutions Marketing Manager at Nutanix, and Mark Lav...
Many organizations are now looking to DevOps maturity models to gauge their DevOps adoption and compare their maturity to their peers. However, as enterprise organizations rush to adopt DevOps, moving past experimentation to embrace it at scale, they are in danger of falling into the trap that they have fallen into time and time again. Unfortunately, we've seen this movie before, and we know how it ends: badly.
TCP (Transmission Control Protocol) is a common and reliable transmission protocol on the Internet. TCP was introduced in the 70s by Stanford University for US Defense to establish connectivity between distributed systems to maintain a backup of defense information. At the time, TCP was introduced to communicate amongst a selected set of devices for a smaller dataset over shorter distances. As the Internet evolved, however, the number of applications and users, and the types of data accessed and...