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

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

  • View
    216

  • Download
    2

Embed Size (px)

Citation preview

Electronic Business Electronic Business eXtensible Markup Language -eXtensible Markup Language -Business Process Specification Business Process Specification

Schema (ebXML-BPSS)Schema (ebXML-BPSS)

Mike Richmond

11/21/2003

Outline:Outline:

1. Introduction

2. Key Concepts

3. Business Transaction Semantics

4. XML BPSS Example

What is ebXML?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.

Why ebXML?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

ebXML and the W.S. Standards Stack

Data

Type

Service

Behavior

Message

BPEL

Web Service Standards

ebX

ML

WSDL

SOAP

XML Schema

XML

Courtesy of Prof. Bultan’s presentation slides

ebXML runsparellel to the Web Services stack

ebXML and W. S.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 IDANetworks 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.

Diagram: Diagram: Key conceptsKey concepts

- ebXML BPSS v1.10 p.9

Requestor

Responder

Key Concepts: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

Key Concepts II: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.

Business TransactionsBusiness 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.

Business Transaction SyntaxBusiness Transaction Syntax

<BusinessTransaction name="Catalog Request"><RequestingBusinessActivity name="requestCatalog"

<DocumentEnvelope businessDocument="Catalog Request"/>

</RequestingBusinessActivity> <RespondingBusinessActivity name="sendCatalog">

<DocumentEnvelope isPositiveResponse="true"businessDocument="Catalog" />

</RespondingBusinessActivity></BusinessTransaction>

A More Detailed version: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"/>

</RequestingBusinessActivity>

<RespondingBusinessActivityname="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”>

</Attachment> </DocumentEnvelope>

</RespondingBusinessActivity> </BusinessTransaction>

Message Flow in a Business Message Flow in a Business TransactionTransaction

Signals indicate the current state of the transaction.

RequestingActivity

RespondingActivity

Request

Response

receiptAcknowledgement Signal

receiptAcknowledgement Signal

AcceptanceAcknowledgement Signal

AcceptanceAcknowledgement Signal

Business Document FlowBusiness 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 .

Binary CollaborationsBinary 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

<BinaryCollaborationname="Firm Order" nameID="122A38D93" initiatingRoleIDREF=”122A38DA3” timeToPerform="P1D"> <Role name="buyer" nameID="122A38DA3"/> <Role name="seller" nameID="122A38DA5"/> <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"/>

</BinaryCollaboration>

ChoreographyChoreography

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 <<abstract>> business state.

How BPSS fits into the ebXML How BPSS fits into the ebXML FrameworkFramework

- ebXML BPSS v1.10 p.14

Business Transaction Business Transaction SemanticsSemantics

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.

TimeoutsTimeouts

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.

Business Service Interface Business Service Interface (BSI)(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

States of the Business States of the Business Transaction ProtocolTransaction Protocol

- ebXML v1.1 Figure 16 p.43

From message flow in a business transaction diagram

RequestingActivity

Protocol Failure

Protocol Success

Busn.Success

Busn.Failure

Success Failure

Show diagram on p. 54 => 62Show diagram on p. 54 => 62

NonrepudiationNonrepudiation

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.

SecuritySecurityAuthorization and document integrity may be enforced Authorization and document integrity may be enforced

through ebXML.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.

ReliabilityReliability

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.

XML BPSS Example: XML BPSS Example: Document Document SpecificationsSpecifications

<?xml version="1.0" encoding="UTF-8"?> <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"> <!-- Business Documents --> <BusinessDocument name="CatalogRequest“specificationLocation="http://www.xyx.com/CatalogReq.xsd"/> <BusinessDocument name="Catalog" specificationLocation="http://www.xyx.com/Catalog.xsd"/> <BusinessDocument name="Purchase Order" specificationLocation="http://www.xyx.com/PO.xsd"/> <BusinessDocument name="PO Acknowledgement"

specificationLocation="http://www.xyx.com/POAck.xsd"/> <BusinessDocument name="Credit Request" specificationLocation="http://www.xyx.com/CreditReq.xsd"/> <BusinessDocument name="Credit Confirm" specificationLocation="http://www.xyx.com/CreditCon.xsd"/> <BusinessDocument name="ASN" specificationLocation="http://www.xyx.com/CatalogASN.xsd"/> <BusinessDocument name="CreditAdvice"

specificationLocation="http://www.xyx.com/CreditAdvice.xsd"/> <BusinessDocument name="DebitAdvice" specificationLocation="http://www.xyx.com/DebitAdvice.xsd"/> <BusinessDocument name="Invoice" specificationLocation="http://www.xyx.com/Invoice.xsd"/> <BusinessDocument name="Payment" specificationLocation="http://www.xyx.com/Payment.xsd"/> <BusinessDocument name="Inventory Report Request"

specificationLocation="http://www.xyx.com/InvReq.xsd"/> <BusinessDocument name="Inventory Report" specificationLocation="http://www.xyx.com/InvRep.xsd"/>

Business Transaction Business Transaction SpecificationSpecification

<Package name="Ordering"><!-- Here are some of the Business Transactions needed -->

<BusinessTransaction name="Catalog Request"> <RequestingBusinessActivity name="RequestCatalog">

<DocumentEnvelope businessDocument="Catalog Request"/> </RequestingBusinessActivity> <RespondingBusinessActivity name="SendCatalog">

<DocumentEnvelope isPositiveResponse="true" businessDocument="Catalog"/> </RespondingBusinessActivity>

</BusinessTransaction> <BusinessTransaction name="Create Order">

<RequestingBusinessActivity name="SendOrder" isNonRepudiationRequired="true" timeToAcknowledgeReceipt="P2D" timeToAcknowledgeAcceptance="P3D"> <DocumentEnvelope businessDocument="Purchase Order"/>

</RequestingBusinessActivity> <RespondingBusinessActivity name="SendPOAcknowledgement"

isNonRepudiationRequired="true" timeToAcknowledgeReceipt="P5D"> <DocumentEnvelope isPositiveResponse="true" businessDocument="PO Acknowledgement"/>

</RespondingBusinessActivity> </BusinessTransaction>

…… all documents have associated transaction specifications

Binary Collaboration Binary Collaboration SpecificationSpecification

<!-- Now one of the Binary Collaborations -->

<BinaryCollaboration name="Request Catalog" initiatingRoleID="1122B1">

<Role name="requestor" nameID="1122B1"/>

<Role name="provider" nameID="2211A1"/>

<Start toBusinessState="Catalog Request"/>

<BusinessTransactionActivity name="Catalog Request" businessTransaction="Catalog Request"

fromRole="requestor" toRole="provider"/>

<Success fromBusinessState="Catalog Request" conditionGuard="Success"/>

<Failure fromBusinessState="Catalog Request" conditionGuard="Failure"/>

</BinaryCollaboration>

Compound Binary Compound Binary CollaborationCollaboration

<!-- A compound Binary Collaboration for illustration purposes--><BinaryCollaboration name="Credit Charge" initiatingRoleID="8132B1">

<Role name="charger" nameID="8132B1"/> <Role name="credit service" nameID="8122B1"/> <Role name=“payor" nameID="7122B1"/><Start toBusinessState="Credit Inquiry"/> <CollaborationActivity name="Credit Inquiry" binaryCollaboration="Credit Inquiry"

fromRole="charger" toRole="credit service"/> <CollaborationActivity name="Credit Payment" binaryCollaboration="Credit Payment"

fromRole="charger" toRole="payor"/> <Success fromBusinessState="Credit Payment" conditionGuard="Success"/> <Failure fromBusinessState="Credit Payment" conditionGuard="Failure"/> <Transition fromBusinessState="Credit Inquiry" toBusinessState="Credit Payment"/>

</BinaryCollaboration>

<!-- First the overall MultiParty Collaboration --><MultiPartyCollaboration name="DropShip">

<BusinessPartnerRole name="Customer"> <Performs role="requestor" roleIDREF="1122B1"/> <Performs role="buyer" roleIDREF="1122B2"/> <Transition fromBusinessState="Catalog Request" toBusinessState="Create Order"/>

</BusinessPartnerRole> <BusinessPartnerRole name="Retailer">

<Performs role="provider" roleIDREF="2211A1"/> <Performs role="seller" roleIDREF="1122B3"/> <Performs role="creditor" roleIDREF="9122B1"/> <Performs role="buyer" roleIDREF="1122B2"/> <Performs role="payee" roleIDREF="6122B1"/> <Performs role="payor" roleIDREF="7122B1"/> <Performs role="requestor" roleIDREF="1122B1"/> <Transition fromBusinessState="Create Order" toBusinessState="Check Credit"/> <Transition fromBusinessState="Check Credit" toBusinessState="Credit Payment"/>

</BusinessPartnerRole> <BusinessPartnerRole name="DropShip Vendor">

<Performs role="seller" roleIDREF="1122B3"/> <Performs role="payee" roleIDREF="6122B1"/> <Performs role="provider" roleIDREF="2211A1"/>

</BusinessPartnerRole> <BusinessPartnerRole name="Credit Authority">

<Performs role="credit service" roleIDREF="8122B1"/> <Performs role="payor" roleIDREF="7122B1"/>

</BusinessPartnerRole> </MultiPartyCollaboration>

Multiparty Collaboration(deprecated)

Sources:Sources:

EbXML committee:

www.ebxml.orgOasis:

www.oasis-open.orgUN/CEFACT:

www.unece.org/cefact