1. Electronic Business eXtensible Markup Language - Business Process Specification Schema (ebXML-BPSS) Mike Richmond 11/21/2003

2. Outline: 1. Introduction 2. Key Concepts 3. Business Transaction Semantics 4. XML BPSS Example

3. What is ebXML? A set of specifications that enhance e-business activities by allowing business process collaborations between 2 or more parties. Started in 1999 as a joint effort between UN/CEFACT and Oasis – Oasis – A global consortium that works to develop and implement e-business standards. – UN/CEFACT – United Nations Center for Trade Facilitation and Electronic Business Goal: create specifications to allow worldwide platform independent business transactions.

4. Why ebXML? Needed a way to unify a variety of existing XML specifications. Electronic Data Interchange (EDI) is no longer seen as a viable method of conducting e-business. – Current specification for e-business transactions – Drawbacks: High startup costs Inconsistent formats Implementation limited to large organizations ebXML’s Benefits: – Common message structure enables worldwide communication – Provided free of charge – Scales well to any organization size

6. ebXML and W. S. "Web Services and ebXML are not competing frameworks. They can be viewed as serving two different B2B models and will continue to be used in parallel.“ - From the Business-to-Business Frameworks for IDA Networks study published in September 2003 by the European Commission's IDA (Interchange of Data between Administrations) [obtained from www.ebxml.org] ebXML defines new ways to use the existing standards: – SOAP – ebXML Messaging Services use SOAP message headers and http protocols. – UDDI – the ebXML Registry mimics and works as a sub- directory of the UDDI registry. – WSDL – ebXML BPSS and CPP give it the functionality of WSDL plus error handling and failure scenarios.

7. Diagram: Key concepts - ebXML BPSS v1.10 p.9 Requestor Responder

8. Key Concepts: Business Transactions: – “an atomic unit of work in a trading arrangement between two business partners.” - ebXML BPSS v1.10 – Consists of 2 Roles: Requestor – the initiator of the transaction. Responder – a response is necessary for a “legal” transaction to take place. – Ex: request catalog, send purchase order… Binary Collaboration: – A set of business transactions between business partners. – 2 Types: Binary – Either a business transaction or another Binary collaboration (allows for recursion). Multi – bundled binary collaborations - deprecated in ebXML BPSS v1.1 – Ex: step 1 = request catalog, step 2 = send catalog

9. Key Concepts II: Document Flows: – Defines the nature of a business transaction. – 2 Types: One-way = notification Two-way = conversation (allows for contractual agreements) Choreography: – Specifies which transaction should be executing at any given time. – Describes the ordering and transitions between transactions and recursive collaboration instances.

10. Business Transactions An event where one or two document flows happen between the receiving and responding Business Activities. Business Activities should not be thought of as “buyer” or “seller” roles, but kept vague. Example Business Transaction: – A “Cancel Purchase Order” request may be sent out by either role in the business transaction. Acknowledgements (Business signals) are used to control the content and usage of business transactions.

11. Business Transaction Syntax <RequestingBusinessActivity name="requestCatalog" <DocumentEnvelope businessDocument="Catalog Request"/> <DocumentEnvelope isPositiveResponse="true" businessDocument="Catalog" />

12. A More Detailed version: <BusinessTransaction name="Check Credit" nameID="122A3DD33" isGuaranteedDeliveryRequired="true"> <RequestingBusinessActivity name="checkCredit" nameID="122A3E833" isAuthorizationRequired="true" isIntelligibleCheckRequired="true" isNonRepudiationReceiptRequired="true" isNonRepudiationRequired="true" timeToAcknowledgeAcceptance=" PT30S" timeToAcknowledgeReceipt=" PT10S"> <DocumentEnvelope isAuthenticated="persistent" isConfidential="persistent" isTamperDetectable="persistent" businessDocument=" Credit Request" businessDocumentIDREF="122A3F613C"/>

13. <RespondingBusinessActivity name="confirmCredit" nameID="122A3E863" isAuthorizationRequired="true" isIntelligibleCheckRequired="true" isNonRepudiationReceiptRequired="true" isNonRepudiationRequired="true" timeToAcknowledgeReceipt="PT10S"> <DocumentEnvelope isPositiveResponse="false" isAuthenticated="persistent" isConfidential="persistent" isTamperDetectable="persistent" businessDocument="Credit Denied" businessDocumentIDREF="122A3F8E3"/> <DocumentEnvelope isPositiveResponse="true" isAuthenticated="persistent" isConfidential="persistent" isTamperDetectable="persistent" businessDocument="Credit Approved" businessDocumentIDREF="122A3F6C3"> <Attachment name=”Credit Report” mimeType=”XML” businessDocument=”Credit Rating” businessDocumentIDREF="122A3F8E4" isConfidential=”none” isTamperDetectable=”none” isAuthenticated=”none”>

14. Message Flow in a Business Transaction Signals indicate the current state of the transaction. Requesting Activity Responding Activity Request Response receiptAcknowledgement Signal AcceptanceAcknowledgement Signal

15. Business Document Flow Conceptually modeled as the passing of Document Envelopes between the request and response ends of a business transaction. Document envelopes carry only one primary business document, but may have any number of possible documents specified. Example: A purchase order request is sent to a vendor (envelope from requestor) and the vendor replies with one of three predefined document envelopes: acceptance, denial, or partial acceptance.

16. Binary Collaborations Defined to be between 2 roles: the initiator and the responder. Two types: – Business transaction activity – Collaboration activity – a binary collaboration executed within another binary collaboration. isInnerCollaboration : boolean value that specifies whether the activity may be executed by itself or only within another collaboration. Allows greater flexibility in defining how collaborations take place. Collaboration Protocol Agreements (CPA) govern how they take place

17. <BinaryCollaboration name="Firm Order" nameID="122A38D93" initiatingRoleIDREF=”122A38DA3” timeToPerform="P1D"> <Start toBusinessState=”Place Order” toBusinessStateIDREF=”122A39C23” /> <BusinessTransactionActivity name="Place Order" nameID="122A39C23" businessTransaction="Create Order" businessTransactionIDREF="122A3DD33" fromRole="buyer“ fromRoleIDREF="122A38DA3" toRole="seller“toRoleIDREF="122A38DA5" isConcurrent="true" isLegallyBinding="false" timeToPerform="P2H"/> <Failure fromBusinessState="Place Order" fromBusinessStateIDREF="122A39C23" conditionGuard="AnyProtocolFailure"/> <Success fromBusinessState="Place Order" fromBusinessStateIDREF="122A39C23" conditionGuard="BusinessSuccess | BusinessFailure"/>

18. Choreography Purpose: “to specify which Business Transaction Activity and/or Collaboration Activity should happen at any point in time.” - ebXML BPSS v1.10 How: keeping track of the current business state and any transitions between business states. Transitions are used to created the nested activities mentioned earlier. Business State examples: start, completion, fork, join, decision, business transaction activity, business collaboration activity. In the UML model, all the examples are generalizations of the > business state.

19. How BPSS fits into the ebXML Framework - ebXML BPSS v1.10 p.14

20. Business Transaction Semantics Transactions are set up to provide*: – Predictability – Roles, time bounds of signal passing, and determination of success or failure are all clearly defined. – Nonrepudiation – Security – Reliability *Assuming reliable message passing and request/response acknowledgements are used.

21. Timeouts Timers are used to govern how long roles should wait when engaging in transactions. Timeout values are specified within the business transaction XML forms using timetoAcknowledgeAcceptance and timetoAchnowledgeReceipt tags. Values take the form: – P1H – one hour – P30S – 30 seconds “All timers start when the initial requesting business document is sent.” - ebXML BPSS v1.10 – Problem: initial document transport latency will cause the timers to start at different times.

22. Business Service Interface (BSI) Responsibilities: 1. Detect start of transactions 2. Detect transfer of control within transactions 3. Detect successful transaction completion 4. Detect unsuccessful transactions 1. Timeouts 2. Exceptions to protocol rules 3. Handle negative receipt/authorization signals

23. States of the Business Transaction Protocol - ebXML v1.1 Figure 16 p.43 From message flow in a business transaction diagram Requesting Activity Protocol Failure Protocol Success Busn. Success Busn. Failure SuccessFailure

24. Show diagram on p. 54 => 62

25. Nonrepudiation Receipt acknowledgement ensures that both parties involved can legally enforce the agreement (the legally binding aspect of it has been deprecated). Takes two forms: – 1: (unenforceable) Each party (requestor/responder) is asked to save copies of all documents and envelopes involved in a transaction. – 2: (enforceable) The isNonRepudiationOfReceiptRequired parameter is used in every message to make sure the receiver (either the requestor or responder) acknowledges the message. A lack of response from the receiver will make the transaction null.

26. Security Authorization and document integrity may be enforced through ebXML. Authorization – Activated when the following parameter is included in a document. – isAuthorizationRequired – Receiving side of the activity must authorize the document by comparing it to a previously supplied set of values (by sender). – Deprecated in version ebXML BPSS v1.1 Document – Uses 3 messages with null, transient, or persistent values: isConfidential isTamperDetectable isAuthenticated – Transient – security provided through the communication channel; tests ensure that it was not tampered with during transfer. – Persistent – ensures the information remains confidential through the use of encryption.

27. Reliability Documents and signals can be trusted to reach their destinations. Parameter isGuaranteedDeliveryRequired forces the responding party to choose a communication channel where there is a delivery guarantee. Instructs the CPP and CPA on the level of service required for this transaction.

28. XML BPSS Example: Document Specifications <ProcessSpecification name="Simple" version="1.1" nameID="Simple-2434134" xmlns="http://www.untmg.org/downloads/General/approved/BPSS-v1pt10.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.untmg.org/downloads/General/approved/BPSS-v1pt10.xsd C:\projects\bpss\bpss_1.1\ebBPSS1.08b.xsd"> <BusinessDocument name="PO Acknowledgement" specificationLocation="http://www.xyx.com/POAck.xsd"/> <BusinessDocument name="CreditAdvice" specificationLocation="http://www.xyx.com/CreditAdvice.xsd"/> <BusinessDocument name="Inventory Report Request" specificationLocation="http://www.xyx.com/InvReq.xsd"/>

29. Business Transaction Specification <RequestingBusinessActivity name="SendOrder" isNonRepudiationRequired="true" timeToAcknowledgeReceipt="P2D" timeToAcknowledgeAcceptance="P3D"> <RespondingBusinessActivity name="SendPOAcknowledgement" isNonRepudiationRequired="true" timeToAcknowledgeReceipt="P5D"> <DocumentEnvelope isPositiveResponse="true" businessDocument="PO Acknowledgement"/> …… all documents have associated transaction specifications

30. Binary Collaboration Specification <BusinessTransactionActivity name="Catalog Request" businessTransaction="Catalog Request" fromRole="requestor" toRole="provider"/>

31. Compound Binary Collaboration <CollaborationActivity name="Credit Inquiry" binaryCollaboration="Credit Inquiry" fromRole="charger" toRole="credit service"/> <CollaborationActivity name="Credit Payment" binaryCollaboration="Credit Payment" fromRole="charger" toRole="payor"/>

32. Multiparty Collaboration (deprecated)

33. Sources: EbXML committee: www.ebxml.org Oasis: www.oasis-open.org UN/CEFACT: www.unece.org/cefact