Summary

This chapter covered the third, and final, primary Web Service construct used in the case study. The business process is an abstraction of complex business logic that consists of one or more business activities, the logic and path in which the activities run, and the path that data takes through the business process. UDDI hosts the business process interface as a tModel. Clients and application builders who want to implement the business process retrieve the WSDL interface definition from UDDI and build language-specific interfaces to use for implementing the business process or accessing an existing implementation of the business process.

This chapter also discussed the ability to represent business processes in metadata through languages such as BPEL. This technique has advantages over specific programming languages because of its innate ability to prevent users from leveraging constructs available in a particular language and the metadata language's ability to limit the programming environment to only those constructs that are useful to a business process programmer. You can use BPEL in three ways: The first is as a representation of a business process model, the second is as a directly executable business process language in a container that interprets and runs the business process, the third is as a metadata representation from which you generate a business process implementation in a specific language, such as Java.

Additionally, the chapter introduced a simple example of a business process implementation and how to construct it from an existing WSDL file, located in UDDI. The business process in this chapter is synchronous, and no logic is required to determine the order or processing of the business activities. As business processes become more complex, several business activities execute at the same time, and some business activities may not execute at all. Further, the data that feeds a particular business activity may follow its own path and decisions within the business process.

With the business process pattern under your belt, you have completed the three primary constructs used in the case study. From here, you will enhance the constructs with some well-known and some not-so-well-known design patterns. For example, client applications often leverage event mechanisms to determine when a particular business process completes, especially when the business process is a long-running business process that you execute asynchronously. The next chapter explores a pattern to create an asynchronous business process, and after that you spend time discussing event patterns.