These notes were prepared for the course ELG 5389 "Electronic commerce technologies".

3. Commerce workflow models

3.1. UML and other notations

• Consider the example of the processing of a loan request (at a bank) (see example in the document [Activity Nets ] )
• The system development process: requirements, design (architectural, system decomposition, performance), implementation
• The basic models in UML
• Use cases
• Class and Instant diagrams (object classes, relationships; example configurations involving object instances)
• Sequence/collaboration diagrams (possible order of message exchanges or method invocations)
• State diagrams (dynamic behavior of an object instance)
• Activity diagram (higher level of abstraction (suitable for requirements specification, deals with issues of use cases, sequence of actions and components/actors involved)
• DMR's workflow language (see examples shown in [ Activity Nets ]) and so-called Use Case Maps (UCM)  << work on standardization is going on in the ITU. The relation of UCM concepts to UML are discussed here (paper presented at the conference UML 2000)  >>
• The basic concepts for workflow modeling are
• Activity
• Actors, Resources (including databases that may be updated)
• Exchanged objects: input/output (e.g. invoice, sold product)

3.2. Workflows for e-commerce

• [Treese] chapter 6
• Role = Actor
• Roles in e-commerce
• basic CtoB ([Treese] Fig. 6.3)
• shared transaction server for CtoB, as proposed by OBI ([Treese] Fig. 6.4)
• BtoB ([Treese] Fig. 6.8)
• Using Activity diagrams (or Activity Nets) for describing the above workflows (note: the notations in Treese's figures are very informal and without any meaning). See example workflow description corresponding to Fig. 6.8 and the same figure with indication where the activities are performed (blue at buyer side, red at seller side) and a figure showing more details of the "order approval" activity representing what is meant (I think) by Fig. 6.8 of Treese.

3.3. Distribution of functions and communication protocols

• Distribution of functions is an important step in architectural design
• Consider the example of [Treese] Figure 6.8
• draw Activity Net
• consider a straightforward distribution strategy
• consider function distribution as implied by Figure 6.8 (this requires a refinement of the approval process activity)
• Communication protocols define aspects which guarantee compatibility for interworking between different system components
• What information is exchanged (datatypes, object classes, range of allowed attribute values, etc.) ?
• How is this information encoded for transmission between the different components ?
• In which order are the information messages to be exchanged between the different components ? Note: This aspect often implies a specific behavior of each protocol entity (which performs the protocol on behalf of the respective system component), which may be defined in terms of an state diagram (possibly written in UML)
• What underlying communication protocols are used to transmit this encoded information reliably and securely between the different components ?

3.4. History of EDI - Electronic Data Interchange

• Traditional EDI, players, message elements, message transmission format (see [Minoli] Section 2.2)
• Adaptation to the Internet context (see [Minoli] Section 2.3)  << see also IETF working group http://www.ietf.org/html.charters/OLD/ediint-charter.html    >>

3.5. Tools for workflow modeling

•  For an overview of Workflow, see Workflow: An Introduction << see also the Workflow Management Coalition at http://www.wfmc.org  and related research/publications >>
• Goal (ideal): define process using some workflow definition language; obtain automatically support for the part of the process that is to be automated (support provided by a "workflow management system"). See figure on page 21 in  "Workflow: An Introduction"
• Issues of compatibility between different workflow automation tools; see figure on page 31 in "Workflow: An Introduction"
• XPDL defined by by the Workflow Managmenet Coalition (see Section 8 for examples)

3.6. Business Process Execution Language (BPEL)

BPEL is an XML-based language for "orchestrating" Web Services, that is, to write a program that defines some local processing and interaction with other Web Services. It has an WSDL interface that defines the service that is provided by the BPEL program.

Transaction processing:

• short-term transactions (the classical transactions with ACID properties)
• long-term transactions, involving normally several short-term transactions and possibly compensation actions if certain short-time transactions must be "undone".

BPEL is for long-term transactions. For an overview, see Wikipedia. The control flow primitives are like in Activity Diagrams. A BPEL process represents a centralized process (running as a Web Service) that communicates with other Web Services according to the local control flow defined within the BPEL process.

Going from Activity Diagrams to PBEL: see http://www-128.ibm.com/developerworks/webservices/library/ws-uml2bpel/

Another example is discussed in https://blueprints.dev.java.net/bpcatalog/ee5/soa/BP1_DesignDetails.html

A good overview can be found with SUN: http://developers.sun.com/prodtech/javatools/jsenterprise/nb_enterprise_pack/reference/techart/bpel.html

The definition of PBEL is here.