Preparing to Implement a Business Process (Composition)

Determining how to implement a business process is one of the keys to successful application programming. The primary concerns during the implementation phase of business processes revolve around performance, flexibility, and granularity of the business process:

Keep the business process implementation flexible: Business processes are a competitive advantage to businesses, and they often change as economic and competitive forces change. The application a business uses can either facilitate the business or hinder it. Using a business process modeling technique along with a metadata language is the goal of business processes. Implemented the right way, modeling can become the tool of the business rather than a tool of a programmer, allowing the business analyst to alter the flow of a business process at a moment's notice. Until standards are settled and modeling and metadata are as versatile as programming languages, this paradigm will be a tough sell to application implementers.

Different parts of a business process may have different performance requirements, so make sure you understand performance to a relatively granular level: An example of a business process with different performance characteristics is an order-to-fulfillment scenario. Consider a Web-based application: The user wants to determine if their order processed , but determining when the order ships is ofless concern to the user. In effect, only the first portion of the business process needs to be performance sensitive, though the entire business process must scale.

Use standardized business process definitions and interfaces as often as possible: Over time, standard business process definitions will govern a large percentage of business application implementations . This change will occur in specific industries and ripple into others. Using an existing tModel containing a WSDL file to jump start your own business process will significantly reduce your effort in analysis and design, leaving only the internal system design and implementation.

Isolate business activities that span computer systems, architectures, and companies: The business activity is a convenient location to place logic that must leverage other Web Services to reach out of the application implementation. For example, the order-to-fulfillment scenario must communicate with a shipping process. Treating this unit of work as a business activity, you can isolate how you communicate with the shipper and the logic used to deal with the shipping. Later, you can replace the business activity with a few lines of code in the primary business process implementation.

Avoid exposing the internal object model to the business process interface: There are two primary reasons for avoiding the exposure of your internal object model. The first is to protect potential clients of your Web Service from complexity. The second is to protect you from limiting the application's capabilities by exposing too much of your implementation outside of the core tasks for your process. The business process can be a place where you isolate the underlying implementation from the client experience. By exposing too much of the underlying application model, you lose your ability to change the underlying model because of the effects the change would have on your external interface. Finally, remember that your client may not be using an object-oriented language. If you expose a robust object-model to your client, there is no guarantee that they will be able to consume it from an architecture that does not support objects. Further, the potential client of your Web Service may not understand the object-semantics that you attempt to force onto them.