1 / 33

Electronic Business eXtensible Markup Language - Business Process Specification Schema (ebXML-BPSS)

Electronic Business eXtensible Markup Language - Business Process Specification Schema (ebXML-BPSS). Mike Richmond 11/21/2003. Outline:. Introduction Key Concepts Business Transaction Semantics XML BPSS Example. What is ebXML?.

Roberta
Télécharger la présentation

Electronic Business eXtensible Markup Language - Business Process Specification Schema (ebXML-BPSS)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Outline: • Introduction • Key Concepts • Business Transaction Semantics • 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

  5. 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.

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

  7. 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:

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

  9. 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.

  10. Business Transaction Syntax <BusinessTransaction name="Catalog Request"> <RequestingBusinessActivity name="requestCatalog" <DocumentEnvelope businessDocument="Catalog Request"/> </RequestingBusinessActivity> <RespondingBusinessActivity name="sendCatalog"> <DocumentEnvelope isPositiveResponse="true" businessDocument="Catalog" /> </RespondingBusinessActivity> </BusinessTransaction>

  11. 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>

  12. <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”> </Attachment> </DocumentEnvelope> </RespondingBusinessActivity> </BusinessTransaction>

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

  14. 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 .

  15. 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

  16. <BinaryCollaboration name="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>

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

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

  19. 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.

  20. 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.

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

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

  23. Show diagram on p. 54 => 62

  24. 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.

  25. 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. SecurityAuthorization and document integrity may be enforced through ebXML.

  26. 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.

  27. XML BPSS Example: Document Specifications <?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"/>

  28. Business Transaction Specification <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

  29. Binary Collaboration Specification <!-- 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>

  30. Compound Binary Collaboration <!-- 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>

  31. Multiparty Collaboration (deprecated) <!-- 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>

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

More Related