Business process: understanding BPEL4WS, Part 1

Business process: understanding BPEL4WS, Part 1

Concept of business processes December 2002

The recently released Web service business process execution language (BPEL4WS) specification is a web service standard for integration. You can create different activities that can complete WEB service calls, manipulate data, throw faults or terminate one process, and then connect them, creating complex processes. These activities can nest in structured activities, structural activities define the operating mode of the activities, such as serial or parallelism or depends on certain conditions. The purpose of this series is to let readers have aware of different parts of the BPEL4WS language and teach readers how they create their own complete processes. This article is part of this series, which will lead the reader to create the first simple process. The subsequent section will expand this example in different ways to illustrate and explain the key parts of the BPEL4WS language, including data manipulation, correlation, fault processing, compensation, and various structured activities in BPEL4WS.

Introduction Today, the Web service can communicate with each other through industry specifications, disclose themselves, discovered and called. However, until last week, the user still needs to make a choice from many mutually conflict specification for a business process or an integration, and the user needs this situation between IBM's WSFL and Microsoft's XLANG. . The business process of the Web service (BPEL4WS) is the product of WSFL and XLANG fusion. If you are lucky, it will become the basis of Web service integration standards. BPEL4WS sets of WSFL and XLANG (the former supports graphical processes, the latter supports the structured construction of the process), forming a combination of various types of business processes supporting a variety of types of business processes in a nature. Package. In addition to being a language, BPEL4WS can also be used to describe the interface of business processes - the way to use abstract processes. We will further discuss this issue in future articles. The initial implementation of BPEL4WS is called BPWS4J, IBM also released this initial implementation on AlphaWorks (see Refigu). Users can use this implementation as an experiment when learning and experimenting BPEL4WS. We discussed this article in this article. Basic concepts of BPEL4WS. The concept of BPEL4WS BPEL4WS supports two distinctive use situations:

Implement executable business processes. Describe the abstract abstract flow. This article focuses on the first case; this series will have an article to discuss some abstract flow concepts of BPEL4WS. As the implementation language of the executable process, the role of BPEL4WS is to integrate a set of existing services to define a new web service. Therefore, BPEL4WS is basically a language that implements such an integrated. As with any other Web service, the interface of the integrated service is also described as a collection of WSDL Porttype. Integration (referred to as a process) indicates the cooperation of the overall execution of the service interface and integration. Figure 1 illustrates the above case described by the BPEL4WS process from the outside. Figure 1. The integrated primitives that appear in the BPEL4WS as a BPEL4WS process is mainly experienced by many years of workflow and business process integration, so the positioning of BPEL4WS is a business process integration language. What is the event on the cloud block on the service? Unlike the traditional programming language to implement the WSDL service, each of the portType is not mapped into a separate logic block in BPEL4WS. The entire type of service (ie the portType collection of the service) is implemented by a single BPEL4WS process. Thus, the particular "entry point" corresponding to the external user operated by the calling interface is indicated in the BPEL4WS description. These entry points consumption WSDL operations are incorporated from only an input-ONLY operation or an input-output (input-output). For the latter case, the process must also indicate where the output message is generated. BPEL4WS only uses and supports only WSDL only input operation and input - output (request - response (repane) operation and output (notification) operation and output - input (output-input) - Solicit-response) The operation is neither not supported. The BPEL4WS process is basically a flowchart, similar to a flow chart used to express algorithms. Each step of the process is called an activity. There are some basic activities: call the operation on a web service (), wait a message to respond to the operation of the service interface that is called by someone (), generates the response of the input / output operation (), wait for a while (), copy the data from one place to another (), indicating an error in a place (), termination of the entire service instance (), Or do not do (). These primitive activity can be combined into a more complex algorithm by using any structured activity provided by the language.

The capabilities provided by these structured activities are: Define a set of steps (), use the current "Case-Statement" measures to generate branches (), define a loop () , Perform one of several optional paths (), and indicating that a set of steps should be performed in parallel (). In a set of activities performed in parallel, you can specify the constraints of the execution order by using the link (LINK). BPEL4WS allows you to recursively combine structured activities to express any complex algorithms, which represent the implementation of services. Interact with other things: As a language used to combine a set of services together to form a new service, the BPEL4WS process is called and / or receives to other services and / or receives from the client (users serving in Figure 1) Call composition. The former is done by using activity, the latter is done by using and activity. BPEL4WS puts other service names with process interacts. In this way, the partner or the process is called as a service (called partner), or the service (client partner) that call the flow (client partner). The first type of partner is obvious - the process is undoubtedly to call other services to complete some things. Activity indicates what is the partner to call and which porttypes to call partners. However, please note that the called partner can finally become a client-process call partner to request some kind of service. Subsequently, partners will call operations on the process to provide the desired data. The reason why the process is treated as partners may not be so easy. This is actually two reasons: the first reason is that sometimes the process may need to call one of the operations on the client partner. The main support mechanism for asynchronous interactions is as follows: Action on the client calls to request some kind of service. Once completed, the process will call the operation on the client partner. At this point, there is no significant difference between client partners and called partners. The second reason is that the services provided by the process may be more than one client (using all services or several components that use the service). In addition, these different users who can distinguish between services. For example, a process that represents a loan service system provides a single web service, but only some of them are accessible to customers who apply for loans, and some other parts are accessible by the customer service representative, and ultimately the entire service is only Loan guarantors can access. According to a certain action, the returned behavior may be greatly different from the customer or by the guarantor. In addition, since the partner is used to simulate the client, the process can indicate that some operations can only be called by some clients. Therefore, partners can be divided into the following:

Services are only called by the process. Only call the service service. Alternatively, it is called both the process of calling and calling the flow (which is possible). The first two are called partners and client partners, they are all simple. Consider the relationship between the process first call the service and services during the third case. This means that the service provides (or published) a porttype (PT1), then the process calls the operation of the porttype. At the same time, the process must provide a service from the portType (PT2) that calls the operation. In this way, from the perspective of the process, the flow requires the portType PT1 from the service and provides PortType PT2 to the service. From the perspective of the service, the relationship between the two will receive an opposite conclusion: the service provides the PortType PT1 to the process and requires the Porthpe PT2 from the process. Whether the process first calls the service or the opposite, the relationship between the service and the flow is as described above. The service link type is a third type of partner modeling to lead the service link type. The service link type is not from the perspective of a part of these participants to define the relationship between services and processes, but a third party statement, with this declaration to illustrate two (or more) services The relationship between. The service link type defines a set of roles, where each role indicates a group of portType. Its idea is that when two services interact each other, the service link type is how to interact with these two services - the parties have provided the statement. BPEL4WS defines partners with a service link type. Basically, partners are defined: give partners a name, then specify the name of the service link type, determine what role will serve as a role in this service link type, and determine what role will serve as a partner. For purely called partners and pure client partners, there will be only one role in the service link type, so it only indicates a role when defining partners. Partner names will then be used in , , and to indicate the expected partner. How does the service reference partner work when running? In order to work at runtime, partners must parse into actual Web services. In this way, the partner is actually the end is a type of service reference, and its type information comes from the service link type and role. The BPEL4WS process itself does not specify how a partner is bind to a specific service; people think this is a binding step when deploying or runtime, which must be supported by BPEL4WS. Problem developers need to have errors in the process of handling business processes and resume from errors. BPEL4WS is built into the language in the language via and . BPEL4WS's troubleshooting concept is directly in contact with WSDL's troubleshooting, in fact, the former is based on the latter. In addition, BPEL4WS supports compensating this concept, which is a technique that allows process designers to achieve some compensation actions for certain irreversible actions. For example, it is imagined that there is a travel scheduled process. Once a reservation is confirmed, some explicit operations must be performed to cancel this predetermined. These actions are called the "compensation action" of the original action. BPEL4WS introduces this concept of a role domain, which recursively supports troubleshooting and compensation, and the scope is essentially a fault handling and / or compensation unit. Detailed understanding of compensation and troubleshooting requires an article that will be provided in the future. What is the life cycle of these services? The Web service implemented as a BPEL4WS process has an instance lifecycle model. That is, the clients of these services are always interacting with a particular instance of the service (process).

How do the client creates an instance of the service? Unlike traditional distributed object systems, the BPEL4WS instance is not created by plant mode. In contrast, the example in BPEL4WS is implicitly created when the message is reached. That is, the example is not identified by an explicit "instance ID), but is identified by some keyword fields in the data message. For example, if the process represents an order implementation system, the invoice number may be a "keyword" domain used to identify a particular instance involved in interaction. Thus, if there is no matching instance when the message arrives at the "start" point, then a new instance is automatically created and associated with keyword data in the message. After positioning the appropriate instance, you can only accept messages in the process of non-starting point; that is, in these cases, the message is actually transmitted to a particular instance. In BPEL4WS, find a suitable instance or create a suitable instance (if necessary) is referred to as message correlation (Message Correlation). There will be an article discussed message-dependent future in the future. Endy language We briefly explain the main underlying concept of BPEL4WS in this article. We discussed the BPEL4WS overall, and then discussed partners, faults, compensation, and life cycles. In this series, we intend to discuss various specific aspects of BPEL4WS in detail. [Editor Press] Each period of this column will alternately provide a series of series of concepts behind BPEL4WS and how to implement the series of these concepts from technology. The next phase will introduce the technology implementation. ] Reference information Click on the discussion of the top or bottom of the article on the discussion forum on this article. Download Business Processes for Web Services Java Runtime from AlphaWorks. Read the business process of the web service to execute language specification. Read the following related articles: Business processes and transaction automation and business processes in the Web Services world in Web services.

About the author Sanjiva Weerawarana is a researcher in the Component Systems group of IBM T.J. Watson Research Center. He is one of the authors of the BPEL4WS specification, WSDL specification, and WSFL specification, and one of BPWS4J, Apache SOAP, WSTK, WSDL Toolkit, WSIF, and WSGW developers. He received a Ph.D. in Purdue University. You can contact the author through Sanjiva@us.ibm.com. Francisco Curbera is a researcher in the Component Systems group of IBM T.J. Watson Research Center, and the head of the group. He is one of the authors of BPEL4WS specification, WSDL specification, and WSFL specification, and one of BPWS4J, Apache SOAP, and WSTK. He received a Ph.D. academy of Columbia University. Please contact him via Curbera@us.ibm.com.