|
Tuning Up the Orchestra
With its BizTalk e-business server, Microsoft gained early experience in composing business process from XML Web services
Interview by Stuart J. Johnston and Dan Ruby
Among the XML technologies that Microsoft has championed is business process orchestration based on Web services. The company's premier orchestration product, BizTalk Server, first debuted nearly two years ago. XML & Web Services Magazine Contributing Editor Stuart J. Johnston and Editorial Director Dan Ruby recently chatted with David Kiker, Microsoft's general manager for e-business servers, about his views on orchestration and how it fits into the company's vision of .Net and the future of Web services. Dave Wascha, BizTalk Server lead product manager, also participated.
XML & Web Services Magazine: What's the big problem that the industry is solving with orchestration and business process automation?
Kiker: The role of process orchestration has been undervalued by the computer industry as a whole. We have done a great job for business people in terms of data. But for someone who needs to monitor their business processto understand deeply how they process loans, for examplewe have a very long way to go.
I believe that business process is just as important as business data, and that at some point in the future there are going to be applications on people's desktops that are as common as Excel that allow people to deeply understand business process in the same way that they can deeply understand the data.
We are working very hard to get a standardization of basic business-processing principles that will allow you to describe not only the data exchanged in an ordering process, but also describing the ordering process itself.
XML & Web Services Magazine: Processes are made up of a series of discrete steps. If each step functions properly, why is it difficult to tie them together?
Kiker: Orchestration is really about composing long-running transactions using messaging protocols of various kinds but increasingly focusing on Web services. Long-running transactions involve business activities that cannot be managed using the traditional two-phase commit process. These kinds of processes may occur inside one company or between companies.
Picture a transaction with an online bookstore. Traditionally, if you wanted to roll back a transaction at the end, because it reached some error condition, you would simply undo it. But with this kind of long-running business transaction between partners, you can't just roll back the transaction. What if you ordered a book and it was delivered to you, but it's the wrong book? You can't just undo that. You have to get a return authorization number, and you have to be able to have your credit card credited back. In many ways, the compensations for the error conditions are as elaborate, or in some cases more elaborate, than the initial transaction.
There are a lot of issues that come up when you're doing this. For example, there's correlation. How do you map back the various activities: issuing a credit-card authorization, getting a return authorization number, making sure that when the book got into the warehouse that it was actually credited against your original transaction?
Finally, there's a big element about managing it, so that a simple business-monitoring application can provide the status of the transaction, what needs to be done next, and any interventions that are needed.
Back to top
|