As we observed in the previous chapters, when the amount of the <invoke> activities increases, the amount of variables and partner links that requires to handle the runtime status of those <invoke> activities also grows. In synchronous invocations, each <invoke> activity has to have two variables in order to hold input and output of the external web service invocation. Additionally, it may need to keep another variable to maintain fault data. So, it is inevitable that the number of activities in a business process grows when the complexity of business process logic grows. As a consequence, a developer has to spend more time on implementing and verifying the business logic.

Hence, it is advantageous to have some structural activities that encapsulate the blocks keep this complexity to a minimum level. The <scope> activity enables us organize the WS-BPEL 2.0 process into hierarchical organized parts. In other words, a <scope> activity can maintain a set of local data (for example, variables and partner links) and handlers (for example, fault handlers and compensation handles) so that only visible to the activities resides within the scope. We explain how to use the <scope> activity to organize a WS-BPEL 2.0 process.

As with most of the programming languages such as Java and C#, BPEL also has the concept of defining scopes, which defines restrictions to resources, manipulated during the program execution. In Java, we can define a variable with different access levels named as local, instance, and static. A local variable can be only accessible within a Java method block. So, it cannot be accessed outside of the particular method block. In other words, variables defined in a Java method block are not visible to the world outside of that method block. On the other hand, any Java object can access the static variable.

Likewise, WS-BPEL 2.0 provides the <scope> activity, which enables to define different contexts within a BPEL process definition. Within the <scope> activity, you can define variables, partner links, correlation sets, fault handlers, and so on, that are only visible to the activities defined within the particular scope. This means those resources that are local to the <scope> activity affect the behavior of the activities defined within the particular <scope> activity. In more general terms, we can say that the <scope> activity provides behavioral contexts for activities defined within the <scope> activity. In the previous chapter, we talked about inline fault handlers, which is a very useful example of the <scope> activity.

In this chapter, we refine the main example mentioned in Chapter 5, Interaction Patterns in BPEL (asynchronous invocations) such that the partner links, variables, correlation sets, and fault handlers related to each service invocation are encapsulated within child scopes. So, it brings more readability to the process. And in the second phase of the chapter (from the Time for action – the fault and termination handlers section), we explain more important use cases such as inline fault handling, termination handling, and so on.

Let's reuse the example, named Book_Warehousing_Process, which we introduced in Chapter 5, Interaction Patterns in BPEL:

Workflow of the book warehousing process

If you take a look at the BPEL source code, you may realize that all the <variable> and <partnerLink> activities are defined at the top level of the <process> definition. We call this the global level, as once the <variable> and <partnerLink> activities are defined, they are visible to all the activities defined within the BPEL process. So, they can be referred anywhere. However, at some point we may wish to restrict the scope of access to those resources. As an example, we may need to restrict access of variables on to an <invoke> activity, which is the only activity used in the mentioned variables. In such a case, we need to define a <scope> activity and enclose that <invoke> activity.

Keeping this in mind, if we take a look at the preceding sample workflow, it has several external service invocations. They are listed here:

In this exercise, we only consider the scoping of two <invoke> activities. These activities are Query_BookStore_A and Query_BookStore_B and those are executed within a <flow> activity, as shown in the following screenshot:

So by examining those two <invoke> activities, we can realize that these two <invoke> activities share the same partner link (QueryServicePartnerLink) and the input variable (Query_BookStore_serach_InputVariable), but use different output variables. The <invoke> activity named Query_BookStore_A uses Query_BookStore_A_serach_OutputVariable and the other <invoke> activity named Query_BookStore_B uses Query_BookStore_B_serach_OutputVariable, as shown in the following code:

<flow name="Flow1">
    <sequence name="Sequence">
        <invoke name="Query_BookStore_A"
            partnerLink="QueryServicePartnerLink"
            portType="ns1:search_port_type" operation="search"
            inputVariable="Query_BookStore_search_InputVariable"
            outputVariable="Query_BookStore_A_search_OutputVariable"
            bpelx:invokeAsDetail="no"/>
    </sequence>
    <sequence name="Sequence1">
        <invoke name="Query_BookStore_B"
            partnerLink="QueryServicePartnerLink"
            portType="ns1:search_port_type" operation="search"
            inputVariable="Query_BookStore_search_InputVariable"
            outputVariable="Query_BookStore_B_search_OutputVariable"
            bpelx:invokeAsDetail="no"/>
    </sequence>
</flow>

So, what we can do is restrict the access of variables such as Query_BookStore_A_serach_OutputVariable and Query_BookStore_B_serach_OutputVariable only to the <invoke> activity that refers the particular resource. In the same way, we can restrict the access of variable Query_BookStore_serach_InputVariable and the partner link QueryServicePartnerLink only to the two <invoke> activities given the condition that these resources are only utilized within those two <invoke> activities.