By analysing how and why communication takes place between cooperating persons, we have encountered the business transaction communication pattern. We have seen how instances of this pattern are chained together to form business processes. The understanding that business processes are composed of business transactions enables us to perform the reverse action; the decomposition of business processes into business transactions. Each business transaction identifies one business role, which represents the elementary amount of authority and responsibility to execute the transaction. These business roles are the building blocks for authorisation policies within organisations. Each business role can be viewed as an elementary supply chain and provides a well-defined service. By studying how these services are realised we have encountered the need for additional informational and infrastructural services to enable storage and exchange of information. The decomposition of business processes into business, informational and infrastructural services and the definition of their dependencies provide a solid basis for enterprise information and application architecture. As technology has not played a role in the decomposition of business processes into services, the resulting services are technology-independent. The degree to which services are automated may vary strongly, but this has no influence on the information architecture. When implementing a service, we would recommend hiding both the chosen implementation technology from other interacting services as well as the degree of automation within the service. This approach provides an organisation with the flexibility to change the technology itself as well as the way it is applied in business process implementations.

These are the actions at the various layers. It would be great to use this as a top level categorization for your message exchanges. Today’s approaches conflate all of this together. We don’t want this and merely causes confusion and is not easy to change.

Example conversation - can we canonicalize the way people communicate? Intention (intent) -> Message (content) -> Send Message (form)

Now we move on to a more complicated conversation…

This is a KEY concept. The structuring principles depend entirely on this.

Communication is more than just conveying information. Inform Agree Request Act

The important thing is that the fact is the same in both communicative acts, but the intent is different.

All elementary conversations boil down to a message exchange around one single fact. The intents change. ASK, STATE, REQUEST, ACCEPT, PROMISE

This slide show how elementary communicative acts interleaved and how production acts are surrounded by communicative acts. What is the fact? It is always the final situation/state that is intended. There are actually multiple elementary communications and some of the facts are implied. One physical (production act) can relate to more than one communicative acts (i.e. as with the payment act). It is very important to have a verification that the production act has occurred and this is usually via a stated fact (explicit or implicit).

Explains why the communications are being performed.

Communication take place at various levels to enable communicative acts. Shared Syntax -> Shared Semantics/Understanding -> Shared Interpretation/Context (this last part is why humans are important) Allows co-ordination of actions to get things done.

Business TXs are important for the co-ordination of processes whereas Information exchanges are not. Biz TXs identify roles and activities and are essential for the design/analysis of processes. There is surely a good tie in with this and MS Motion. Business TXs pattern is used when you want someone/something to perform an action / do some work. Information Exchange simply supports/clarifies the Business TX.

Relate this to the Agile Machine architecture and negotiate/agree/perform/verify cycle.

So far we have shown only the success scenarios… but how to handle failures. This is done by having refinement of the Business TX communication flow (interaction). This is the link with Windows Workflow Foundation – we can capture an activity template for this type of communication. Each actor works with his own workflow. So the overall interaction shown actually materializes within a set of related workflows. [See later slides in this deck.]

… thus we have a very strong definition of BUSINESS ROLE = i.e. the person who is able and authorized to perform one particular production action and we discover production actions by finding Business TXs and their associated business role. An individual ROLE can play multiple BUSINESS ROLES.

Workflow services can have parallel conversations with multiple clients over the same contract. Understand how to correlate messages that are sent for the same contract and same operation but need to be handled differently as they are sent by different clients…

The example architecture is modelled after simple AI agents (BDI agents specifically; see Yoav Shoham’s Agent0 work from 1994).

The example architecture is modelled after simple AI agents (BDI agents specifically; see Yoav Shoham’s Agent0 work from 1994).

Service Capsules A Language and Patterns Perspective on Service Design and Implementation Arvindra Sehmi Director, Microsoft Corporation asehmi@microsoft.com Acknowledgement: Gerke Geurts & Savas Parastatidis

ALTERNATIVELY Modeling Robust & Reliable People-to-Machine Business Processes Arvindra Sehmi Director, Microsoft Corporation asehmi@microsoft.com Acknowledgement: Gerke Geurts & Savas Parastatidis

ALTERNATIVELY The Case for Workflow-First Service Design Arvindra Sehmi Director, Microsoft Corporation asehmi@microsoft.com Acknowledgement: Gerke Geurts & Savas Parastatidis

This session is about emerging ideas and concepts. The term Service Capsule is not an official term approved or endorsed by Microsoft. The term Service Capsule is used simply to distinguish them from the commonly understood term Service. Nothing in this talk is guaranteed to be officially supported, approved or endorsed by Microsoft. Caveat Emptor

To Model Robust & Reliable People-to-Machine Business Processes Using Workflow-Based Communication Patterns & Services Business Processes Automation & Design Services and Workflow People-to-People Communication: Basics & Theory Workflow-First Service Design Q&A Objective & Agenda

Business Process Automation Problems

Business Process Financials Warehousing Shipping Customer Order Mgmt Inspector

Financials UI Business Process Automation (1/2) Financials Customer Customer Portal Order Logic Order Data Credit Check Logic Credit Data Customer Data

 Business Process Automation (2/2)    Presentation Business Process Business Information

Business Process Design There’s much more to the design of robust reliable automated (and manual) business processes than having great technology & tools

Business Process – Knowledge Concepts

Three Levels of Business Automation Coordination Interpret Information Exchange Storage (archive) Derivation (transform) Infrastructure Data transfer Data storage Calculations

Business Roles are supported by Informational Roles & Infrastructural Roles

Services and Workflow Modeling services and their message interaction protocols: Some ideas exploring “workflow-backed service contracts” – an essential ingredient for business process automation

A Services Messaging Behaviour A service is characterised by the messages it can send and receive WSDL describes the format of those messages and basic message exchange patterns i.e. request-response The collections of messages sent or received by a service, their format and their relative order sequence or choice represent the messaging behaviour of that service The messaging behaviour can be exposed as metadata – examples SSDL, Abstract BPEL and WS-CL

What’s the Difference? Logic Service Client Logic Service Client 1 2

What’s the Difference? Service contract describes operations Message interaction protocol determined by client Service contract describes interaction protocol and operations Message interaction protocol controlled by service 1 2

A Workflow as a Service Windows Workflow is a great technology for modelling and implementing the behaviour of a process or application We can capture logic through the concept of an activity An activity may represent an incoming or outgoing message We can automatically host such a workflow as a WCF service

Extracting the Messaging Behaviour The messaging behaviour of a Workflow hosted as a service can be extracted automatically by analyzing the workflow The metadata capturing the messaging behaviour can be exposed as a workflow i.e. XOML The XOML file can be used as a skeleton for the implementation of other services / consumers wishing to interact with the hosted service

Workflow as a Service Experimental work with VS2005 (.NET FX 3.0)

People-to-People Communication The Basics

Everyday Conversation Example What is the capital of the Netherlands? I’ll ask Steve… What is the Dutch capital? He asks for the name of the Dutch capital… I think it’s Amsterdam. I’m sure it is, so I’ll state this… It’s Amsterdam

Business Conversation Example I would like a pizza calzone please. Do you want meat sauce on top? No thank you. Ok, That will be €15. Money payment Pizza production There you go, your pizza sir Wonderful! Thank you. Customer Pizza Guy

Fundamental Aspects of Communication Message Form Message Content Message Intent

Message Form Transport Medium Message Syntax Message Grammar Medium: sound waves in air Syntax & Grammar: UK English spoken sentence

Message Content Information – what is in the form, semantics What is the Dutch capital? It’s Amsterdam

Message Intent How should message receiver take the message? I’ll ask Steve… Ask: Provide me with information I’m sure it is, so I’ll state this… State: Accept my information as truth

People-to-People Communication The Theory

Language Action Perspective of Communication Communication is more than message exchange ‘Speaker’ intends to influence behaviour of ‘hearer’ Communicating = Performing communicative acts

Communicative Act Normalised view of message content Performer: Intent: Addressee: Fact: Deadline What is the Dutch capital? It’s Amsterdam Bill: Ask: Steve: Amsterdam is the capital of the Netherlands: ASAP Steve: State: Bill: Amsterdam is the capital of the Netherlands: ASAP

Conversation Sequence of communicative acts between two people with a particular goal All communicative acts in conversation share by definition same fact and deadline Bill: Ask: Steve: Amsterdam is the capital of the Netherlands: ASAP Steve: State: Bill: Amsterdam is the capital of the Netherlands: ASAP

Business Conversation Example I would like a pizza calzone please. Do you want meat sauce on top? No thank you. Ok, That will be €15. Money payment Thanks Pizza production There you go, your pizza sir Wonderful! Thank you. Customer Pizza Guy C pays money P produces pizza C: request: P: C owns pizza <p> P: ask: C: Pizza <p> has sauce C: deny: P: Pizza <p> has sauce P: promise: C: C owns pizza <p> P: request: C: payment <m> made for pizza <p> C: promise: P: payment <m> made for pizza <p> C: state: P: payment <m> made for pizza <p> P: accept: C: payment <m> made for pizza <p> P: state: C: C owns pizza <p> C: accept: P: C owns pizza <p>

Business Conversation Example C pays money P produces pizza C: request: P: C owns pizza <p> P: ask: C: Pizza <p> has sauce C: deny: P: Pizza <p> has sauce P: promise: C: C owns pizza <p> P: request: C: payment <m> made for pizza <p> C: promise: P: payment <m> made for pizza <p> C: state: P: payment <m> made for pizza <p> P: accept: C: payment <m> made for pizza <p> P: state: C: C owns pizza <p> C: accept: P: C owns pizza <p> conversation 2: aim: information to complete request conversation 3: aim: payment commitment conversation 1: aim: pizza production commitment conversation 4: aim: agreement on fulfilment of payment commitment conversation 5: aim: agreement on fulfilment of pizza production commitment

Layers of Communication Coordination Layer Shared social understanding of action that must be performed Social awareness required to understand mutual expectations and act accordingly Informational Layer Shared social understanding requires shared intellectual understanding first Information exchange Infrastructural Layer Shared intellectual understanding requires transmission of signs and shared understanding of these signs Data transfer

Business Communication Patterns Business Transaction Pattern Aim: creation of new production fact Main communicative acts: Request/Promise/State/Accept Information Exchange Pattern Aim: exchange of existing facts/information Main communicative acts: Ask/State or Inform/Confirm

Business Transaction Pattern Result Phase Order Phase Execution Phase 3. Produce 1. Request 5. Accept 2. Promise 4. State Agreement on production action to be performed Agreement on outcome of production action

Execution Phase Order Phase Result Phase Business Transaction Pattern Initiator (Customer) Success Layer Negotiation Layer Failure Layer Request Quit Request Quit Promise Decline Execute State Stop Promise Decline Execute State Stop Accept Reject Accept Reject

Nested Business Transactions Product Sale

Business Transaction Nesting

Business Process – Full Circle! Business process = a structure of causally interconnected business transactions for delivering a particular final product to the environment Each business transaction identifies exactly one business role We can design more robust and reliable business processes by observing the communication pattern semantics

Workflow-First Service Design Available in Visual Studio 2008 (.NET FX 3.5)

Agile Machine Architecture (1/2)

Agile Machine Architecture (2/2)

References G. Geurts and A. Geelhoed, Business Process Decomposition and Service Identification using Communication Patterns, Microsoft Architecture Journal, Issue 1, January 2004. J.R. Searle, Speech Acts, an Essay in the Philosophy of Language, Cambridge University Press, Cambridge MA, 1969. J.L.G. Dietz, P.J.M. Mallens, An Integrated, Business-Oriented Perspective on Facts and Rules, data2knowledge newsletter, January-May 2001. V.E. van Reijswoud, J.L.G. Dietz, DEMO Modeling Handbook Volume 1, Delft University of Technology - Department of Information Systems, Version 2.0, May 1999. SSDL – The SOAP Service Description Language at http://www.ssdl.org. A. Sehmi and B. Schwegler, Service Oriented Modeling for Connected Systems, Microsoft Architecture Journal, for Part 1: Issue 7, January 2006 and for Part 2: Issue 8, April 2006. A. Sehmi and B. Schwegler (2005), “Modeling and Messaging for Connected Systems”, a webcast presenting elements of the paper above can be found here: http://www.ftponline.com/channels/arch/reports/easbarc/2005/video/.

Q&A Questions?