informa
/
News

Open For Business

Preparing for a complex, event-driven future, leading-edge businesses are pushing the software community to focus application development on a vision of business-driven, integrated processes. The conclusion of our series focuses on key components.

IT and business professionals may also use the process model to run simulations. IT, for example, may check how increasing the transaction load by 20 percent will affect server performance. Business professionals could then check the impact on staffing if the increase occurred. Not only are business processes modeled but also the people and systems related to them, which allows these simulations to take everything into account during calculations.

Life-cycle Steps

This section summarizes the five steps involved in the full process life cycle:

Model. Information workers model business processes. Key issues in modeling are: Does the package possess a modeling scheme that information workers feel comfortable working with? Does it support simulation? Is it synchronized with executable processes? Moving from business-friendly modeling languages (such as SCOR) to operational languages (such as BPEL) more suitable to executable business processes is tough, which makes synchronization between model and executing process quite challenging.

Orchestrate. Here, process models are connected to IT assets, such as Web services and databases, and become executable. Information workers can at times develop simple processes directly: But, generally, this step is where IT takes over development. Remember, though, that the process model serves as a common synchronized piece of documentation. Through the process model, business users retain control and understanding of their business processes. Developers know that they're working with the "correct" specification, as they insert assets directly into the process model.

Another benefit is that orchestration tools that generally use workflow-centric languages, such as BPEL, are better equipped to handle long-running transactions, support parallel workflows, and deftly insert humans into business processes than past technologies. Thus, through orchestration, end-to-end business processes are better automated.

Deploy. This step must support versioning and rollback. As information workers take over from IT developers, deployment will need to become simpler. The smarter, more discrete processes contained in SOA will be easier to version and track, and thus deploy.

Analyze. BAM, as discussed here and in Part II of this article, enables real-time digital dashboards consisting of data from process models and other enterprise systems. BAM can also initiate alerts based on events occurring in the process model. An example would be an order that didn't ship on time to a tier-one customer. Because BAM is contextually aware of the business process through the process model, it provides a powerful source from which to send meaningful alerts.

Improve. In the full process life cycle, this step doesn't stand apart from everything else but is instead the result of an improved software manufacturing process. The effort to improve processes and systems can leverage better analysis, process visibility for both information workers and developers, and simplified means of change. Modeling, orchestration, and visibility are the enablers of continual incremental change.

The Future is Now

SOA and the related methods and technologies described throughout this series of articles have deep roots in a legacy of efforts to improve software development — many of which fell short. The great promise of the current efforts by major vendors (such as BEA, IBM, Microsoft, SAP, Tibco, WebMethods, and a host of other development concerns around the globe) is made real by urgent demand. Businesses, government agencies, and other kinds of organizations desperately need faster, more agile application development that's made more cost-effective through reuse and component growth.

Thanks to the Internet, technology standards are here and are continuing to improve to support SOA. What lies ahead should be a creative and productive period, beneficial to business and IT alike.

More SOA Standards

As I did in a sidebar accompanying Part I of this article, here are some comments about important SOA standards relevant to this concluding part of the article. Whether used together or alone, open industry standards are an essential part of what Web services and SOA can deliver for modern applications.

Transactions have proven difficult for Web services because they require a framework that supports multistep, multiparty, and multimessage operations. Early Web service standards didn't support this framework, and the usual way of ensuring transactions through ACID is also poorly suited for Web services. In a world of long-running, multiparty transactions, you can't hold the entire transaction in limbo until it completes successfully — or roll it back if it doesn't.

WS-Coordination enables a message element — called a coordination context — containing the WS Address information of the coordination service to be appended to all messages participating in the transaction. The coordinator service, a Web service described in Web Services Definition Language (WSDL), provides a mechanism to start or end a task and enable participants to check transaction status or register tasks.

WS-Atomic Transactions enable Web services to provide standard two-phase commit transactional behavior at the service layer. (Enterprises participating in the service may still have to perform compensation or versioning.)

Service Composition Business Process Execution Language (BPEL) has two primary use-case candidates: Design tools and execution engines operate on BPEL, or they operate on proprietary languages that import and export BPEL. The second scenario seems to be the most popular now. Upgrades occurring in the OASIS BPEL specification will dictate the proportion of direct BPEL use versus import and export.

The individual services in BPEL-composed Web services are inserted via their WSDL interfaces. BPEL relies on WSDL for service descriptions and WS-Policy for transactional, security, and other abilities and constraints.

BPEL structure is defined by the link between the BPEL partnerLink and the WSDL port type. BPEL information or instance data is stored in variables that are described by schemas. A BPEL-composed service is a set of choreographed activities — each tied to a variable — that form the process steps and combine to define the behavior of the business process.

- Robert Eisenberg

Resources

Earlier installments online at IntelligentEnterprise.com:

Part I: "The Future Is Now," April 17, 2004

Part II: "Leveraging the Legacy," May 1, 2004