1. Implementing a Basic ebXML Capability From: Chapter 10, ebXML Concepts and Application, by Brian Gibb and Suresh Damodaran, Wiley, 2003

2. Basic ebXML Capability2 Goal Understanding the SOAP protocol and its current limitations Understanding the ebXML Message Specification Implementing the ebXML Message Specification

3. Basic ebXML Capability3 Basic SOAP Messaging A SOAP 1.1-based message containing the PurchaseOrder element might look like …

4. <SOAP:Encelope xmlns:SOAP=http://schemas.xmlsoap.org/soap/envelope xmlns=“http://www.smallco.org/order” xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance”> SterlingVommerce SmallCo Purchase Order bbc006751 Small Co Enterprise 123456789-0456 John Adams 214-340-1234 … …

5. Basic ebXML Capability5 What is missing? Interoperability –Based on shared semantics of message structure n partners, n schemas for MessageHeader –Based on shared semantics of exchanged documents With SOAP, it is only is possible to interpret XML documents, while EDI, for example, is industry-accepted as well. –SOAP toolkit interoperability Security Reliable messaging Error processing –In SOAP 1.1, Fault element represents errors in SOAP structure and semantics. However, in real-world B2B communication, error handling must cover a much wider scope with richer semantics. Contracts

6. Basic ebXML Capability6 ebXML Messaging Solution ebMS v. 2 defines the structure of message exchanged between two ebXML Message Service Handler (MSH). A message may include business document — payloads — enclosed in a message envelope. Such payloads can include –A standard EDI transaction, –XML-based business document, binary file, or –A service request.

7. Basic ebXML Capability7 ebXML Messaging Solution ebXML Application ebXML MSH Communication Protocol Handler (HTTP, SMTP, …) BSI Binding ebXML Application ebXML MSH Communication Protocol Handler (HTTP, SMTP, …) BSI Binding

8. Basic ebXML Capability8 Implementing ebXML Messaging Take a comprehensive look at how to implement an ebXML MSH based on ebMS.

9. Basic ebXML Capability9 Synchronous and asynchronous communications Synchronous communication: An entity A communicates with entity B synchronously over a communication channel if A requires a response back from B, and A does not initiate another communication to B using the same communication channel before it receives that response. Asynchronous communication: When A communicates with B asynchronously, A does not always require a response back from B. Irrespective of whether A requires a response or not, A may initiate another communication to B.

10. Basic ebXML Capability10 Synchronous and asynchronous communications In an ebXML message, the need for a synchronous response is specified using a SynReply element in the Header of envelop. Note: This element should not be used to override the value of synReplyMode in the CPA.

11. The collaborative messaging problem Initiating Service Initiating MSH Responding MSH Responding Service Asynchronous Acknowledgement and Response to Initiating MSH 1 Request BSI Internet 2 Request Message 4 Request 3 Acknowledgement 5 6 Response 7 Response Message 8 Response 9 Acknowledgement 10 Acknowledgement

12. Basic ebXML Capability12 The collaborative messaging problem Acknowledgement messages serve two purposes: –Assurance that a message reached its destination and –Non-repudiation.

13. The collaborative messaging problem Initiating Service Initiating MSH Responding MSH Responding Service Synchronous Acknowledgement and Response 1 Request BSI Internet 2 Request Message 4 Response 3 Service Request 5 Acknowledgement 6 7 Acknowledgement & Response Message 8 Response 9 Acknowledgement

14. The ebXML message structure Communication Protocol Envelope (HTTP, SMTP, etc.) SOAP 1.1 with Attachments MIME envelope MIME Part MIME Part(s) Attachment(s) SOAP: Envelope SOAP: Header SOAP-ENV: Body eb:MessageHeader eb:ErrorList eb:Acknowledgement eb:SyncReply eb:etc. eb:Manifest eb:etc.

15. Basic ebXML Capability15 MIME packaging MIMI (Multipurpose Internet Mail Extensions) –devised in 1982 –A packaging mechanism specifically to work with SMTP –capable of sending not just text but images and binary data RFC 2822 defines the MIME syntax pertaining to US-ASCII characters, whereas the series RFCs 2045, 2046, 2047, 2048 and 2049 define the syntax for values outside this range that can be used for emailing images, binary data, etc. These extensions allowed different types of Content-Type MIME headers.

16. MIME packaged message MIME-Version: 1.0 Content-Type: multipart/related start=“ebxml-envelope@stercomm.com”;type=“text/xml”; boundary=“taos.csg.stercomm.com::60faa2:ed4afadebc:-7da3” -- taos.csg.stercomm.com::60faa2:ed4afadebc:-7da3 Content-ID: Content-Transfer-Encoding:8bit Content-Type:text/xml;charset=utf-8 … Payload -- taos.csg.stercomm.com::60faa2:ed4afadebc:-7da3 Content-ID: Content-Transfer-Encoding:8bit Content-Type:application/edi-x12 ST~850~Transfer BEG~00~AB~Purchase Order Number~Release Number~20000329~Contract … SE~23~Transacti -- taos.csg.stercomm.com::60faa2:ed4afadebc:-7da3

17. Basic ebXML Capability17 MIME packaging A SOAP Message package can be constructed per SOAP with Attachments specification in the following manner: 1.The primary SOAP 1.1 message must be carried in the root body part of the multipart/related MIME structure. Because the type parameter of the multipart/related Content-Type is the same as the root body part, the type parameter is text/xml. 2.All referenced MIME body parts must contain either a Content- ID MIME header, as defined in RFC 2045, or a Content- Location MIME header, as defined in RFC 2557.

18. Basic ebXML Capability18 Communication protocol envelope POST /webservices/ebxml/message-header HTTP/1.1 Host: www.sterlingcommerce.com Content-Type: multipart/related; start=“ebxml-envelope@stercomm.com”; type=“text/xml”; boundary=“taos.csg.stercomm.com::60faa2:ed4afadebc:-7da3” SOAPAction: ebXML Content-Length=6178 -- taos.csg.stercomm.com::60faa2:ed4afadebc:-7da3 HTTP Envelope

19. Basic ebXML Capability19 Communication protocol envelope Packaging a MIME message for a specific communication protocol is not only a matter of adding a few HTTP or SMTP header only. –HTTP is 8 bit clean; SMTP is 7-bit representation. Thus the Content-Transfer-Encoding MIME header of a payload may be different. –MIMI header works well with SMTP. However, HTTP 1.1 is not in full compliance with MIME. –HTTP can support synchronous and asynchronous message exchanges; whereas SMTP is inherently asynchronous.

20. Basic ebXML Capability20 Collaboration protocol agreement The communication between MSHs happens under the context of an agreement between MSHs. Every ebXML message has a required CPAId element in the eb:MessageHeader, which is a unique identifier points to the CPA. ebXML Application ebXML MSH Communication Protocol Handler (HTTP, SMTP, …) BSI Binding ebXML Application ebXML MSH Communication Protocol Handler (HTTP, SMTP, …) BSI Binding CPACPA

21. Basic ebXML Capability21 Collaboration protocol agreement It is useful to keep at least the following types of information in a CPA. ( continued … ) –The From and To information for the MSHs. SterlingCommerce http://www.sterlingcommerce.com/roles/Buyer xyzcommerce http://www.xyzcommerce.com/roles/Seller xyz-verification http://ebxml.xyzcommerce.com:4080/exchange/xyz

22. Basic ebXML Capability22 Collaboration protocol agreement –Service and Action information at each MSH. <action name=“Send” syn-reply-mode=“signalsAndResponse” non-repudiation-of-receipt=“true” retry-count=“3” retry-interval=“1800” duplicateElimination=“true”/>

23. Basic ebXML Capability23 Basic processing model The MSH gets to the Active state when it sends or receives a message. When the MSH is in an Active state, it consists of two concurrent states: Send and Receive. –The reason for this concurrency: an MSH may receive or send messages at the same time.

24. Basic ebXML Capability24 Concurrent send and receive Basic processing model The SOPA message is validated and identified. The message is further processed.

25. The Active on Message State Concurrent delivery of message and sending Acknowledgement

26. The Receive Processing State

27. Basic ebXML Capability27 The Receive Processing State MIMI Unpack state –Validate the headers Content-Type exists and is multipart/related for the MIME message Type is text/xml … –A validMIME event is triggered, after unpacked successfully. Prevalidation state –The following items are checked Message conforms to the SOAP 1.1 structure. CPAId refers to a valid CPA. Service and Action element contents are not null.

28. Basic ebXML Capability28 The Receive Processing State Map Conversation Context state –(Now it’s safe to read the MessageHeader element.) –Binding the context to a received message Pick CPA Slice state –Take a slice of CPA that corresponds to the contents of Service element, its type attribute, and the Action element of the incoming message. Validate state –Ensure that the incoming message is structurally sound and can be processed further by performing a number of checks. (Partial list) Exact one SOAP header Message not expired The Content-ID in eb:Manifest matches the Content-ID from the MIME.

29. The Prepare Send Message State

30. Basic ebXML Capability30 The Send Message State

31. Basic ebXML Capability31 The Send Message State

32. Typical Deployment View

33. Basic ebXML Capability33 Reliable Messaging Reliable Messaging Problem can be split into two sub-problems –Lost messages and –Duplicate messages

34. Initiating Service Initiating MSH Responding MSH Responding Service 1 Request BSI Internet 2 Request Message Lost message  Lost!

35. Initiating Service Initiating MSH Responding MSH Responding Service 1 Request BSI Internet 2 Request Message 4 Request 3 Acknowledgement Lost Acknowledgement  Lost!

36. Basic ebXML Capability36 Solution to the Lost-Message Problem Resend a lost message or Acknowledgement. –A resend of a message is done after a retry interval (Specified as RetryInterval element in ebMS). –The CPA can specify the number of times such a resend should happen (with the Retries element in ebMS). –To prevent an infinite series of resending by an MSH, a time limit is specified for all such resend. It does not prevent duplicate messages or acknowledgements from piling up at the Sending or Receiving MSHs.

37. Basic ebXML Capability37 Solution to the Duplicate Messages Problem Duplicate messages must be eliminated by specifying the DuplicateElimination element. When a message has DuplicateElimination element in it, the receiving MSH performs duplicate elimination. The ebMS allows for duplicate elimination only at the receiving end, and not at intermediaries.

38. Basic ebXML Capability38 Duplicate Elimination Initiating Service Initiating MSH Responding MSH Responding Service Request Message Response Message Retry Interval Duplicate Elimination Message duplicate elimination

39. Basic ebXML Capability39 Duplicate Elimination Initiating Service Initiating MSH Responding MSH Responding Service Message 1 Acknowledgement 1 Retry Interval Duplicate Elimination Acknowledgement duplicate elimination Message 1 Retry Interval

40. Basic ebXML Capability40 Enhancements to Basic Processing Reliable sending of message

41. Basic ebXML Capability41 Enhancements to Basic Processing Reliable receiving processing

42. Basic ebXML Capability42 Message Ordering The Receiving Service may require that messages be delivered in the order in which they are sent from the Sending Service. –A prerequisite for message ordering is that reliable messaging be carried out with a once-and-only-once scheme. –In addition, a SequenceNumber is inserted in an ebXML message. –The SequenceNumber is unique within a ConversationID. –In the Receiving Processing state, messages with linearly increasing sequence numbers are delivered to the Receiving Service. –When an out-of-sequence message is received, it is stored in an out-of-sequence message buffer. –The maximum size of this buffer is implementation-dependent. –When this buffer is full, the Sending MSH is notified of a DeliveryFailure error.

43. Basic ebXML Capability43 Secure Messaging A major requirement on security in the context of ebXML messaging is that the countermeasure technologies and infrastructures for securing must be interoperable between MSHs. Basic security notions –Authentication, –Authorization, –Confidentiality, –Integrity, and –Nonrepudiation. Two aspects of security in the context of ebXML messaging –Communication security –Persistent security

44. Basic ebXML Capability44 Trust Infrastructure A prerequisite to communication and persistence of security information is the establishment and management of the required trust infrastructure. Digital certificate in X505 v3 format are quite popular. Public key/private key concept

45. Basic ebXML Capability45 Trust Infrastructure The trust infrastructure is established and managed in various ways. Some of the variations are due to the reasons listed here and are impediments to interoperability of MSHs: –Multiple ways to generate public/private key pairs. –Many trust authorities. –Many trust models –Various ways to enforce trust. –Certificates are processes by libraries created by different vendors at each end of MSHs.

46. Basic ebXML Capability46 Trust Infrastructure Because private keys are the authors of trust, they must be safeguarded. Certificates are used to secure –the communication protocol layer (e.g., SSL/TLS), –sign/verify digital signatures, and to –Encrypt/decrypt messages. It is more secure to use different certificates for these activities.

47. Basic ebXML Capability47 Signing The ebXML supports signing ebXML messages, as specified in the XML Signature Specification. In the ebXML context, the signature is used for multiple purposes. –Verifying integrity of ebXML message envelope and payload(s) –Providing signed acknowledgement –Providing nonrepudiation of acknowledgement –Authenticating the sender of a message

48. Basic ebXML Capability48 Signature Generation and Verification The exact methods of creating and verifying signatures are described in the ebXML and XML Signature Specification. Some of the tasks involved in creating a signature for a ebXML message: –Creating digests for the SOAP:Envelope and each payload –Insert the digests calculated for each payload and SOAP:Envelope –Canonicalize the ds:SignedInfo that now has all the ds:Reference element and respective ds:DigestValue elements with values

49. … … cTG3yp)n+Smr09uz4mM8auHjilY= KTrPeHp0ftATWidWxBbzwfhTrSg= …clTkDL0gPw … An example of signature

50. Basic ebXML Capability50 Signature Generation and Verification Note that signing the envelope ensures that any change in the content of SOAP:Envelope or any of the payload can be detected. However, payloads are not signed individually, and the ebMS does not specify how individual payloads may be signed. After you create a payload signature, you can embed it in the payload or send separately as another payload with the original payloads.

51. Basic ebXML Capability51 Signature Generation and Verification Signing individual payloads can be useful in the following circumstances: –The sender of the payload is not the creator or the “source” of the payload, and therefore, it may be useful to sign the payload separately so that the creator of each payload can be identified. –The receiver does not want to store the SOAP:Envelope to which the payload is attached. –The receiving MSH is not the end user of all payloads.

52. Basic ebXML Capability52 Encryption You can use encryption to provide confidentiality while –the ebXML message is in transit from one MSH to another or while –the ebXML message is in persistent storage. The encryption during transmission can be provided by TLS or IPSEC. The ebXML does not suggest a standard way to apply persistent encryption in the current version. However, ebMS suggests that when XML encryption becomes a recommended standard of W3C, ebMS may provide appropriate recommendations. Alternatively, S/MIME v3, S/MIME v2 may be used for rncrypting the MIME message.

53. Basic ebXML Capability53 Error Processing Error reporting between one MSH to another MSH uses the ErrorList element or a SOPA fault message. When an ErrorList element is present in a message, the RefToMessageId element in the message contains the message to which the ErrorList element is referring. The ErrorList element consists of one or more Error element. An Error element has three attributes: –ErrorCode : describes the cause; –Severity with two values: Error or warning ; and –A location where the error has happened.

54. Basic ebXML Capability54 Error Processing Types of errors: –MIME structure errors –SOAP structure errors –Errors in structure and contents of ebXML namespace qualified SOAP Extension elements –Errors encountered during reliable messaging –Errors encountered during security processing

55. Basic ebXML Capability55 Error processing while sending message

56. Basic ebXML Capability56 Error processing while receiving message

57. Basic ebXML Capability57 ErrorList construction

58. Tree of states

59. Basic ebXML Capability59 Mixing Business-Action Message and Signals The ebMS allows “piggy-backing” one or more Acknowledgement with a request or response. –An Acknowledgement element is optional in SOAP:Header and has a required RefeToMEssageId element. Error messages, however, can not be piggybacked, because an ErrorList element refers to the error(s) that correspond to the message identified by RefToMessageId element in eb:MessageHeader.

60. Basic ebXML Capability60 Huge Messages In the first round of ebMS, Drummond sponsored interoperability testing. –ebXML message with payloads up to 10MB were tested successfully by participants. The main issue with huge message is the buffer space required at the various processing stages.

61. Basic ebXML Capability61 Multiple Hops and Intermediaries When the message can be passed through one or more intermediaries nodes capable of processing SOAP messages, the message is said to multihop. SOAP 1.1 specifies an actor attribute for element SOAP:Header to indicate the recipient of that header. –The ebMS defines two URIs. –SOAP:Actor=urn:oasis:names:tc:ebxml-msg:actor:nextMSH refers to another MSH –SOAP:Actor=urn:oasis:names:tc:ebxml-msg:actor:toPartyMSH refers to the MSH that is to be the eventual destination of the message as identified in the message itself.

62. Basic ebXML Capability62 Implementation Discussions

63. Basic ebXML Capability63

64. Basic ebXML Capability64

65. Basic ebXML Capability65