Opinari

Subscribe

Why BPEL is Like Bytecode  
# Sunday, May 28, 2006
 
I'm not convinced that BPEL has much of a future as an executable language (see here for why). Still, plenty of people think otherwise, and most of the discussion around BPEL assumes this perspective. Even if you accept this view, however, I'd still argue that the typical take on BPEL is inaccurate.

People tend to think of BPEL as a programming language. The expectation is that a developer writes process logic in BPEL just as she writes object-oriented logic in a language such as Java. But unlike Java and every other mainstream programming language, BPEL is defined using XML. Accordingly, it was designed to be generated by tools, not written directly by developers. Whatever BPEL aficionados believe, masses of developers are never going to work directly in a complex XML-based language.

In fact, as an executable language, BPEL's primary goal is to provide a portable description of logic. Isn't this exactly what Java bytecode strives to do? BPEL focuses on process logic, while bytecode takes on a broader problem space. Yet the two are quite analogous: both are tool-generated languages (bytecode by a Java compiler, BPEL by some graphical process design tool) and both can potentially foster portability.

If BPEL is analogous to Java bytecode, what in the BPEL world is analogous to the Java language itself? The answer must be the thing from which BPEL is produced, i.e., the graphical process description format. Today, different vendors take different approaches to doing this. There is an impending standard, however, in the Business Process Modeling Notation (BPMN). Just as lots of people know Java, lots of people may one day know BPMN. And just as almost nobody except tool vendors works directly in or even thinks much about Java bytecode, the day may come when almost nobody except tool vendors works directly in or thinks much about BPEL.

If you believe that BPEL has a future as an executable language--and again, this is an open question today--viewing BPEL as more analogous to bytecode than to Java gives a clearer view of the role this language plays.

11 comments :: Post a Comment

 

On Defining "Workflow"  
# Saturday, May 20, 2006
 
If you're interested in business process management, and you're not reading every word that Bruce Silver writes, you need to start right now. Bruce is the best independent analyst I know of on BPM technology. Much of his work is available for free, too, including his excellent 2006 BPMS Report.

I read Bruce's recent blog entry on the use of the terms "workflow" and "BPM" with interest. He references a post by Keith Swenson, architect of Fujitsu's BPM product and a long-time participant in the Workflow Management Coalition. Both Bruce and Keith have roots in the traditional workflow world, where the term referred to automating interactions among people. Keith points out that he is heartened by Microsoft's use of the word "workflow" in the forthcoming Windows Workflow Foundation. He also proposes differentiating between workflow, meaning automation focused on human capabilities, and orchestration, meaning automation focused on system capabilities. BPM then becomes the umbrella category for both.

I like this distinction--it makes a lot of sense. Unfortunately, it doesn't match the way Microsoft is using the term "workflow". Windows Workflow Foundation will be used for automating human interactions, as in the workflow support being added to Windows SharePoint Services, Version 3 and Office SharePoint Server 2007. But it will also eventually be used for automating system interactions when it one day provides the orchestration capabilities in BizTalk Server. For Microsoft, the term"workflow" covers both areas.

What Microsoft has begun to do is distinguish between human workflow, as in Windows SharePoint Services, Version 3, and system workflow, as in a future version of BizTalk Server. Windows Workflow Foundation is meant to support both equally well, as well as allowing developers to create applications that span both areas. And because this technology will become a standard part of the Windows operating system, it's fair to expect Microsoft's preferred usage to become dominant in the half of the software world that uses .NET. Whatever one might wish, the naming conventions chosen by the big vendors have a disproportionate impact on the terminology we use.

5 comments :: Post a Comment

 

Introducing InfoCard  
# Monday, May 08, 2006
 
Dealing with identity in a digital world is a challenging problem. There are plenty of different systems used today to define and convey digital identity, and more are sure to be created. With Passport, Microsoft tried to create one identity system that could be used by many different people and organizations. While Passport wasn't a failure--it's used today by lots of people--the main thing Microsoft learned from it seems to be that a single-source model for identity will never suffice. What's needed is a way to use the plethora of existing identity systems in an effective way--an identity metasystem.

Working with others, Microsoft has defined what this metasystem should look like. More important, they've also created software that lets Windows applications fit into this system. Code-named "InfoCard", I'd argue that this technology is among the most interesting things happening in distributed computing today. It's also poised to be one of the most important, since if it's successful, everybody will use it, including your children and your mom. InfoCard also offers a way to reduce the use of passwords on the web and significantly better protection against phishing attacks, two potentially big benefits.

I've written a Microsoft-sponsored white paper, Introducing InfoCard, that provides an introduction to this new approach to digital identity. I believe that anybody who cares about modern computing should take the time to understand what InfoCard is all about--it's that significant. And as always, let me know what you think.

1 comments :: Post a Comment