David Chappell presented a barn-storming presentation based on the idea that the future is services, that services will be called by business processes and that we need to look for a platform that will manage business processes.  He argues, convincingly that we can't expect App Servers to perform this role.  The answer comes with Business Process Platforms.  Here he positions BizTalk 2004 as the answer and goes so far as to claim that it will be the major product at future TechEd's and that getting close to business processes (through BizTalk) could be a key part of keeping your job as a developer since business processes are much harder to outsource than simple services.  You can also read David's whitepaper on BizTalk 2004.

Application Evolution
There are four waves of applications: Mainframe, client/server, multi-teir and now service oriented.  They share the idea that there is a database at the back end, but the key with services, it that they are designed with the idea they can be consumed by other applications, not just humans.  The reason why we can have services today is that we have web services  - an agreement on soap and other specs - amongst all of the vendors.  It's a huge change that we are at the start of - 4th generation.

Soap is like TCP for applications.  It took years between the start of TCP and its ubiquity: the same will happen with SOAP and web services.  It may be five years away.

To think of SOA as just about soap is folly - the reality is that going forward we will see some apps exposing their services via SOAP, but we will also see other diverse ways.  Not all apps will be SOAP.

Who calls services?
SOA talks a lot about how to build about how to define and build services and miss the point of 'who is going to call these services?'

David proposes three groups: UI (portal, asp, jsp, win forms etc), other services (we will have composite services) and business process (some central business process platform that will manage relationships between services).

The need for a Business Process Platform
Where should we build these business processes?  Is it in an app server such as J2EE container?  No, an app server all by itself is not the right place to build service-oriented service.

We are seeing a new kind of platform designed to support business processes.  In other architecture shifts we've seen new platforms - mainframe to client services produced RAD tools, the shift to tiered apps produced App Servers, and now with services we need to support business processes that drives services.

Requirements of a Business Process Platform
What do we need from a business process platform? Something that manages communications with other applications, business process implementation, scalability, modifiable business rules, process monitoring, tools for working with trading partners, cross-app authenticaiton, human interaction with business processes.

Rules change much faster than processes change - so separate out the rules from the processes.

Business Processes: Your job may depend on them
Business processes are more immune from outsourcing than the services.  So as developers we have to start caring more about business processes.  In five years time we'll need to be closer to the business or move to Bangalore.

BizTalk: A Business Process Platform
David mentioned that he had previously avoided BizTalk because he thought integration was messy, boring and 'on the side'.  However, he thinks it will move to the centre of application development.  If you believe in the move to service orientation then you have to believe that business processes that drive those processes are fundamental, therefore BizTalk will be the centre of it all.  It is about to go mainstream as the service-oriented world becomes a reality.

It's not about B2B and EAI.  These are just subsets of the larger space of business processes. 

BizTalk Engine
This is built fundamentally built around the concept of a message.  It doesn't mean only asynch, you can use RPC, but what is processed here is messages.  The incoming message comes in and is processed by a receive adapter - software that knows how to talk to a service or application (there are lots).  Here is the difference between AppServers.  AppServers just support SOAP, but not the diversity of communication technologies.

The message is processed by a receive pipeline.  It does many things, including converting it to XML. The message then comes into a MessageBox (a SQL Server database) that other engine parts subscribed to (e.g. show me all messages from this organisation).  An orchestration (the BizTalk term for a business process) retrieves the message.  It may publish a response to the MessageBox, then back through a send pipeline and a send adaptor.

BizTalk Adapters
Microsoft provides adaptors for MQSeries, SOAP and SAP.  You can make your own or buy them.

Tools
Platforms need tools.  You can build your own adaptors in the Microsoft.BizTalk.Adapter.Framework namespace (notice, a namespace, demonstrating it is a .NET application).  There's also a pipeline designer, biztalk editor (used to create XSD schemas) and a mapper (mappings and xslt transformations between schemas).

Some customers are simply happy with the mapper.

Process implementation with BizTalk Orchestration
Orchestrations compile into .NET assemblies.  It has simple shapes like if-then-else statements, loop, send, receive and parallel actions.  The process logic is simple and doesn't require a high-powered language (e.g. you don't need C# or VB.NET).  Using a graphical language is a decision that Microsoft and many others have done.

Another advantage of a graphical language is that you can use it to communicate with people that understand the business domain.

This visual language can also be authored in Viso for use by Business Analysts.  This is something that will grow over time.

Orchestrations are another reason for preferring Business Process Platforms over AppServers (which implement processes through lower level code rather than graphical representations).

State
Business processes involve people, so state may need to be maintained for a very long period of time.  So we can't use in-memory.  The Business Process platform needs to manage it.  BizTalk does this by storing state automatically and reloading it if needed.

Scope
Business processes involve transactions over long periods of time.  So BizTalk avoids locks (services shouldn't let others take locks on their data), it uses long running transactions that use compensation.  Biztalk uses scopes to manage transactions that can be atomic or long-running.

Correlation
If I send two purchase orders to a service (ERP app), how can I get the correct invoice response from the service?  You can't use request response synchronous calls because the real world doesn't work that way.  So you put in a GUID in the message, but how would this work if you can't alter the response from the service?  You could match on particular fields.  This is what BizTalk does - you define fields that should be used to match responses. 

Scalability Support
BizTalk host instances enable request to be automatically load balanced across orchestrations and MessageBoxes.

Modifiable Business Rules with the Business Rules Engine
Rules change more rapidly than processes - it makes sense to separate them.  If you are building a business process in BizTalk then you can bake process and rules together in an orchestration.  However, if your process has volatile rules, you can build the process as an orchestration and put the rules in a set of rules defined by the rules engine.  This is worth doing so that you can change and redeploy the rules easier than deploying the orchestration.

BizTalk provides a business rule composer that allows business rules to be expressed in a more natural way.  You define terms (sort of like creating an object model) and then the business process rules (like script glues object models into an app).

Process Monitoring with Health and Activity Tracking
There are two levels of monitoring: technical  and business level.  The Health and Activity monitoring tool (HAT) shows the technical side.  The business level if Business Activity Monitoring (BAM) that shows real-time information about running processes (as separate from Business Intelligence data, which is not real time). BAM is based on views on a tracking application.  Business people can use Excel to do this, developers have interfaces they can use.

The Goal: Business Process Management
There's no agreement yet on what a Business Process platform should have, but we are getting a picture.  It has to communicate with other apps, scale out, support business process implementations, workflow with human beings, modifiable business rules and process monitoring.  BizTalk 2004 is Microsoft's implementation of this.

Why is SOA more well known that BPM (Business Process Management)?  Names are confusing in this case, but there's a change coming to the way we build software.  It implies more than SOAP, it requires service for building business processes.  Biztalk is a founation for building, managing and monitoring business process, in the world today and the service oriented world to come.