The role of BPEL in Business Process Integration
The Business Process Execution Language (BPEL) is a vendor-neutral mechanism for describing the behavior of business processes. Originally created by Microsoft, IBM, and others, the latest version of this technology is currently being standardized by a larger group working through OASIS.
The Value of BPEL
BPEL is focused on describing business processes as interactions among web services. Consider a business process spread across multiple execution environments. In this example, the process runs partially on BizTalk Server 2004 and partially on an integration server from another vendor running on Windows or some other platform. The figure below illustrates how BPEL can be used to describe the interaction between the two implementations.
As the figure shows, a BPEL definition can be used first to formalize the public interactions between the two parties participating in this business process, then to generate a baseline implementation of those interactions. Two implementations are generated in this scenario, one targeting BizTalk Server 2004 and a second targeting the other integration server. Each contains the behavior for the system’s appropriate role in the business process. BizTalk Server 2004 might execute the buying half of the process, for example, while the other integration server executes the selling half. The role of BPEL is to define the web service interactions involved in this process. The focus is on the information exchange that must take place to successfully carry out the process.
This example of a business process split between two integration servers illustrates BPEL’s primary value: facilitating interchange[1] of web services-based business processes. While BPEL doesn’t define a complete business process, it does provide a vendor-neutral way to describe interactions of the process with external web services and complementary processes implemented across multiple systems.
Along with the example just described, there are several other scenarios where BPEL can be useful. They include the following:
n A large organization such as a retailer or manufacturer might wish to specify the process its suppliers must implement to sell to it. This kind of hub-and-spoke arrangement, common in business-to-business (B2B) interactions, can be made easier using BPEL. The large buyer at the hub might use BPEL to describe the business process that its suppliers must implement, then distribute this definition to those suppliers. The BPEL definition precisely specifies the required interactions with the hub organization, and so each supplier can use it as a starting point for implementing its side of the process.
n An organization might wish to implement an internal business process that relies on several existing applications, but allow this process to be deployed on any of several different integration servers. To allow this kind of enterprise application integration (EAI), the organization could define the basics of the process in BPEL, then use that common definition as a starting point for implementing the process on servers from one or more vendors.
n Libraries of best-practice business processes can be created, allowing intellectual property to be captured and reused more effectively. For organizations building a process from scratch, standard BPEL solutions like these can be a useful starting point.
n An industry-specific standards organization could provide BPEL templates to its members to help ensure industry-wide support for agreements on how to conduct electronic business.
Microsoft’s support for BPEL is consistent with the other web services standards efforts in which the company participates. All of these standards, including SOAP, the Web Services Description Language (WSDL), and the various WS-* specifications such as WS-Security, are focused on building a common integration fabric across vendor boundaries. None of them, including BPEL, defines an execution environment for implementing applications that use these standards. Instead, this choice is left up to each vendor. For Microsoft, of course, the execution environment is the .NET Framework.
One way to understand BPEL’s usefulness is to view this business process language in much the same light as WSDL. WSDL is useful because it defines an abstract interface to concrete implementations, exposing only what’s necessary for these implementations to interoperate. One implementation might be built in C# on the .NET Framework, while another might be built in Java on a J2EE-based platform, yet interoperability is possible using WSDL and a standard protocol such as SOAP. Similarly, BPEL is useful because it allows an abstract definition of a business process that can be implemented using the .NET Framework, a J2EE-based platform, or something else. By specifying the web services-based interactions the process requires, BPEL effectively aggregates a business process around multiple WSDL endpoints. It makes interworking possible at the business process level rather than just the level of individual web services.
The Foundations of BPEL’s Value
The value of BPEL is based on two fundamental attributes of the technology. First, because BPEL makes no assumptions about the environment in which a business process will execute the technology is completely platform-neutral. The second fundamental attribute that makes BPEL valuable is the language’s complete focus on process-oriented abstractions. Rather than mix these higher-level concerns with the more detailed constructs found in traditional programming languages such as C# and Java, BPEL allows a clean separation between defining the business process itself and implementing the finer-grained business objects (probably written in C#, Java, or a similar language) that this process invokes.
Once these core attributes are clear, it’s obvious why BPEL does not—and should not—provide language bindings for directly invoking .NET or Java objects. Doing this would destroy BPEL’s value by eliminating both of the attributes just described: the language would no longer be platform-neutral, and it would also no longer allow a clean separation between the higher-level abstractions of process modeling and the low-level details of implementing business objects. In fact, BPEL’s creators deliberately omitted these kinds of implementation-oriented capabilities, focusing instead on coordinating service-level interactions using interchangeable XML. While a BPEL definition can specify a business process’s interactions with services and other processes, it provides only a starting point for fully implementing that process.
The truth is that the name “Business Process Execution Language” is something of a misnomer, since BPEL’s primary value lies more in the interactions it defines than in its execution capabilities. Implementations of business processes depend on capabilities that are specific to a particular execution environment. Because of this, implementing complete business processes in a truly portable way is not one of BPEL’s goals. Even if a vendor claims to provide a “BPEL execution engine”, the reality is that proprietary platform-specific extensions are necessary to support full implementation of business processes. Even process implementations created for these BPEL-based systems are not easily portable to other execution environments.
BPEL in BizTalk Server 2004
With the release of BizTalk Server 2004, Microsoft is the first platform vendor to support BPEL in an integration server product. In this new version, customers can import a standard BPEL definition that defines the public aspects of a business process, then use the full power of the BizTalk Server 2004 execution environment built on the .NET Framework to implement and run that process. Similarly, customers can define the web service interaction aspects of their business process in the product’s Orchestration Designer, using just the features found in the BPEL specification, then export this process to standard BPEL. Microsoft adds no proprietary extensions to BPEL.
Given its role as an interchange technology, BPEL will be far more useful when other vendors also support it. In the short run, the initial adoption of BPEL will be slow until these implementations are completed. Yet because of its broad industry backing, other vendors will support the language in the near future. Once this occurs, BPEL is likely to play an important role in implementing business processes that span multiple execution environments.
[1] The term interchange is more appropriate than interoperability when discussing BPEL. As it’s usually used, interoperability implies a protocol, yet BPEL uses industry standard web services and does not define any new protocols. Instead, BPEL determines what gets sent across the wire by specifying the behavior of a business process, thereby defining the interchange between parts of that process.
The Business Process Execution Language (BPEL) is a vendor-neutral mechanism for describing the behavior of business processes. Originally created by Microsoft, IBM, and others, the latest version of this technology is currently being standardized by a larger group working through OASIS.
The Value of BPEL
BPEL is focused on describing business processes as interactions among web services. Consider a business process spread across multiple execution environments. In this example, the process runs partially on BizTalk Server 2004 and partially on an integration server from another vendor running on Windows or some other platform. The figure below illustrates how BPEL can be used to describe the interaction between the two implementations.
As the figure shows, a BPEL definition can be used first to formalize the public interactions between the two parties participating in this business process, then to generate a baseline implementation of those interactions. Two implementations are generated in this scenario, one targeting BizTalk Server 2004 and a second targeting the other integration server. Each contains the behavior for the system’s appropriate role in the business process. BizTalk Server 2004 might execute the buying half of the process, for example, while the other integration server executes the selling half. The role of BPEL is to define the web service interactions involved in this process. The focus is on the information exchange that must take place to successfully carry out the process.
This example of a business process split between two integration servers illustrates BPEL’s primary value: facilitating interchange[1] of web services-based business processes. While BPEL doesn’t define a complete business process, it does provide a vendor-neutral way to describe interactions of the process with external web services and complementary processes implemented across multiple systems.
Along with the example just described, there are several other scenarios where BPEL can be useful. They include the following:
n A large organization such as a retailer or manufacturer might wish to specify the process its suppliers must implement to sell to it. This kind of hub-and-spoke arrangement, common in business-to-business (B2B) interactions, can be made easier using BPEL. The large buyer at the hub might use BPEL to describe the business process that its suppliers must implement, then distribute this definition to those suppliers. The BPEL definition precisely specifies the required interactions with the hub organization, and so each supplier can use it as a starting point for implementing its side of the process.
n An organization might wish to implement an internal business process that relies on several existing applications, but allow this process to be deployed on any of several different integration servers. To allow this kind of enterprise application integration (EAI), the organization could define the basics of the process in BPEL, then use that common definition as a starting point for implementing the process on servers from one or more vendors.
n Libraries of best-practice business processes can be created, allowing intellectual property to be captured and reused more effectively. For organizations building a process from scratch, standard BPEL solutions like these can be a useful starting point.
n An industry-specific standards organization could provide BPEL templates to its members to help ensure industry-wide support for agreements on how to conduct electronic business.
Microsoft’s support for BPEL is consistent with the other web services standards efforts in which the company participates. All of these standards, including SOAP, the Web Services Description Language (WSDL), and the various WS-* specifications such as WS-Security, are focused on building a common integration fabric across vendor boundaries. None of them, including BPEL, defines an execution environment for implementing applications that use these standards. Instead, this choice is left up to each vendor. For Microsoft, of course, the execution environment is the .NET Framework.
One way to understand BPEL’s usefulness is to view this business process language in much the same light as WSDL. WSDL is useful because it defines an abstract interface to concrete implementations, exposing only what’s necessary for these implementations to interoperate. One implementation might be built in C# on the .NET Framework, while another might be built in Java on a J2EE-based platform, yet interoperability is possible using WSDL and a standard protocol such as SOAP. Similarly, BPEL is useful because it allows an abstract definition of a business process that can be implemented using the .NET Framework, a J2EE-based platform, or something else. By specifying the web services-based interactions the process requires, BPEL effectively aggregates a business process around multiple WSDL endpoints. It makes interworking possible at the business process level rather than just the level of individual web services.
The Foundations of BPEL’s Value
The value of BPEL is based on two fundamental attributes of the technology. First, because BPEL makes no assumptions about the environment in which a business process will execute the technology is completely platform-neutral. The second fundamental attribute that makes BPEL valuable is the language’s complete focus on process-oriented abstractions. Rather than mix these higher-level concerns with the more detailed constructs found in traditional programming languages such as C# and Java, BPEL allows a clean separation between defining the business process itself and implementing the finer-grained business objects (probably written in C#, Java, or a similar language) that this process invokes.
Once these core attributes are clear, it’s obvious why BPEL does not—and should not—provide language bindings for directly invoking .NET or Java objects. Doing this would destroy BPEL’s value by eliminating both of the attributes just described: the language would no longer be platform-neutral, and it would also no longer allow a clean separation between the higher-level abstractions of process modeling and the low-level details of implementing business objects. In fact, BPEL’s creators deliberately omitted these kinds of implementation-oriented capabilities, focusing instead on coordinating service-level interactions using interchangeable XML. While a BPEL definition can specify a business process’s interactions with services and other processes, it provides only a starting point for fully implementing that process.
The truth is that the name “Business Process Execution Language” is something of a misnomer, since BPEL’s primary value lies more in the interactions it defines than in its execution capabilities. Implementations of business processes depend on capabilities that are specific to a particular execution environment. Because of this, implementing complete business processes in a truly portable way is not one of BPEL’s goals. Even if a vendor claims to provide a “BPEL execution engine”, the reality is that proprietary platform-specific extensions are necessary to support full implementation of business processes. Even process implementations created for these BPEL-based systems are not easily portable to other execution environments.
BPEL in BizTalk Server 2004
With the release of BizTalk Server 2004, Microsoft is the first platform vendor to support BPEL in an integration server product. In this new version, customers can import a standard BPEL definition that defines the public aspects of a business process, then use the full power of the BizTalk Server 2004 execution environment built on the .NET Framework to implement and run that process. Similarly, customers can define the web service interaction aspects of their business process in the product’s Orchestration Designer, using just the features found in the BPEL specification, then export this process to standard BPEL. Microsoft adds no proprietary extensions to BPEL.
Given its role as an interchange technology, BPEL will be far more useful when other vendors also support it. In the short run, the initial adoption of BPEL will be slow until these implementations are completed. Yet because of its broad industry backing, other vendors will support the language in the near future. Once this occurs, BPEL is likely to play an important role in implementing business processes that span multiple execution environments.
[1] The term interchange is more appropriate than interoperability when discussing BPEL. As it’s usually used, interoperability implies a protocol, yet BPEL uses industry standard web services and does not define any new protocols. Instead, BPEL determines what gets sent across the wire by specifying the behavior of a business process, thereby defining the interchange between parts of that process.
Comments