ASR UOM-Ordering Transport Architecture

1. ASR UOM-Ordering Transport Architecture Proposed Asynchronous Request/Response Model

2. About the Presenters • Programmers of Qwest’s ASR Gateway and QORA GUI. • Business clients and testers

3. Scope • TML Asynchronous Request/Response “handshaking” • Brief discussion about ASR validation web service

4. Not In Scope • Pre-order inquiries • ASOG rules

5. TML Transport Diagram • Taken from the industry TML Transport document. • Triangles added to show location of web services. • Left column represents requesters, a.k.a. customers. • Right column represents providers, in this case Qwest.

6. OverallPicturefromTMOC(TCIF)

7. SequenceDiagram #1

8. SequenceDiagram #2

9. SOAP Concepts • Envelope • Headers • Body • Fault

10. SOAP Message Structure <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:t1m1="http://tml.t1m1.org/tML.Transport.xsd"> <SOAP-ENV:Header> <t1m1:tMLHeader xmlns="http://tml.t1m1.org/tML.Transport.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://tml.t1m1.org/tML.Transport.xsd"> <TransportID>TELE1QWEST2005-12-11T09:30:47.097-05:001</TransportID> <CorrelationID>RRR.112345</CorrelationID> <TrackID>AA</TrackID> <ApplicationType>RequestAcknowledgement</ApplicationType> <From>TELE1</From> <To>QWEST</To> <SendTimestamp>2005-12-11T09:30:47.097-05:00</SendTimestamp> <RetryCount>0</RetryCount> </t1m1:tMLHeader> </SOAP-ENV:Header> <SOAP-ENV:Body> <t1m1:ResultAcknowledgement> <t1m1:ResultID>RRR.112345</t1m1:ResultID> </t1m1:ResultAcknowledgement> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

11. TML Headers - Example <tMLHeader xmlns="http://tml.t1m1.org/tML.Transport.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://tml.t1m1.org/tML.Transport.xsd"> <TransportID>String</TransportID> <CorrelationID>String</CorrelationID> <TrackID>String</TrackID> <ApplicationType>String</ApplicationType> <From>String</From> <To>String</To> <SendTimestamp>2001-12-17T09:30:47-05:00</SendTimestamp> <RetryCount>0</RetryCount> </tMLHeader>

12. TML Headers • IDs • Other fields (ApplicationType, From, To, SendTimestamp, RetryCount) will be contained in persisted message but will have no other effects, since Qwest will likely allow most calls to be repeated.

13. Web Service Descriptions • High level overview of the web services used in the transport protocol.

14. Common Behaviors • Architecture is Asynchronous SOAP. • Each “block” is Synchronous. • Descriptions to follow are from the point of view of “Telecom Service Provider.” • Will probably use client-side two-way SSL for each communication channel. • Try to avoid message level signing.

15. Request Listener • Receives ASR in TML format. • Does XSD validation. • Writes content to database. • Returns SOAP fault on any failure. • If no errors, returns TML OK message.

16. Request Listener – Example OK Response <?xml version="1.0" encoding="UTF-8"?> <OK xmlns="http://tml.t1m1.org/tML.Transport.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://tml.t1m1.org/tML.Transport.xsd"/>

17. Request Listener (client) • Sends Request Ack (not the same as an ASR functional acknowledgement) to the customer. • Customer may optionally XSD-check our message. • Customer returns TML OK message. • On receipt of OK, we begin processing. • If customer doesn’t ack in a reasonable time, need to alarm, delete or take other action.

18. Request Listener (client) Acknowledgement Message – Example Request <?xml version="1.0" encoding="UTF-8"?> <RequestAcknowledgement xmlns="http://tml.t1m1.org/tML.Transport.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://tml.t1m1.org/tML.Transport.xsd"> <Acknowledgement>1<!-- true --></Acknowledgement> <Reason>String</Reason><!-- optional --> </RequestAcknowledgement>

19. Result Sender (client) • A single attempt to send a result (Gateway Response, ASR Functional Ack, FOC, Error Clarification) to the customer web service. • Customer responds with a TML OK. • Customer Acks the receipt of this result by calling Result Ack Listener.

20. Results Ready Sender (client) • Periodically we call the customer web service and provide a list of result IDs that have not been Acked. • Need to alarm or perhaps send the customer an e-mail if results aren’t acked in a timely way. • This list could theoretically be quite long. May need to provided a truncated list (perhaps 100) and flag the fact that the list is partial.

21. Results Ready Sender – Example Request <?xml version="1.0" encoding="UTF-8"?> <ResultWaitingNotification xmlns="http://tml.t1m1.org/tML.Transport.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://tml.t1m1.org/tML.Transport.xsd"> <Result> <ResultID>AAA.112233</ResultID> </Result> <Result> <ResultID>BBB.332211</ResultID> </Result> </ResultWaitingNotification>

22. Result Retrieval Listener • Customer provides an ID, and retrieves one result.

23. Result Retrieval Listener – Example Request <?xml version="1.0" encoding="UTF-8"?> <GetResult xmlns="http://tml.t1m1.org/tML.Transport.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://tml.t1m1.org/tML.Transport.xsd"> <ResultID>RRR.1112345</ResultID> </GetResult>

24. Result Ack Listener • Customer calls with the ID of the result they retrieved with Result Retrieval Listener. • They are provided with TML OK message if there are no errors. • The ID will no longer show up when the customer pulls or we push the list of IDs that are ready.

25. Result Ack Listener – Example Request <ResultAcknowledgement xmlns="http://tml.t1m1.org/tML.Transport.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://tml.t1m1.org/tML.Transport.xsd"> <ResultID>RRR.112345</ResultID> </ResultAcknowledgement>

26. Pro’s To Using TML Transport Protocol • Complies with industry guidelines. • More reliable than other approaches. • Closest solution to “real-time” as is possible, contingent on speed of provider down-stream systems.

27. Con’s to Using TML Transport Protocol • Bringing in a new partner may require formal software release process, depending on local rules. • Client-side certificate “library” must be maintained. • Testing, discovery and URL management. • Strict adherence to protocols is required. Otherwise, separate pair-wise “modules” will need to be developed.

28. Con’s to Using TML Transport Protocol, cont. • Customers need to create three new web services in order to interact with Qwest.

29. Alternate All-Pull Model • Additional proposed Qwest web services that allow implementation of the protocol without the need of customer-side web services.

30. Pro’s To Using All-Pull Protocol • Customer does not need to maintain any web services. • Provider does not need to keep client-side certs up to date. • This approach can safely co-exist with standard UOM ordering protocol.

31. Con’s To Using All-Pull Protocol • “Pull” components are not standard(although Qwest is looking for feedback on introducing this on an industry level). • Provider will need to build functionality to allow quick configuration to support new partners. • There could be a delay for a requester to get their results (up to the pull frequency).

32. Overall Picture including all “pulls”

33. SequenceDiagram #3

34. Alt. Request Listener • Customer would call this listener with the same ID of their ASR. We respond with “OK message” if we had already received their message, or “Not OK message” if we don’t have their message. • If we send the “Not OK message,” the customer should resend their message. • If customer doesn’t ack in a reasonable time, need to alarm, delete or take other action.

35. Alt. Result Ready List • Allows customer to pull a list of result IDs. • Still analyzing what to do for long result lists.

36. Alt. Result Ready List – Example Response <?xml version="1.0" encoding="UTF-8"?> <ResultWaitingNotification xmlns="http://tml.t1m1.org/tML.Transport.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://tml.t1m1.org/tML.Transport.xsd"> <Result> <ResultID>AAA.112233</ResultID> </Result> <Result> <ResultID>BBB.332211</ResultID> </Result> </ResultWaitingNotification>

37. Features under consideration • Synchronous ASR validation service. • An optional “partial” tag may be present, which disables form-flow, and other selected rules.

38. Other Thoughts • Questions/discussion?

39. Appendix

40. ID Descriptions • TransportID uniquely identifies each message, e.g., for Help Desk reference only. • CorrelationID is used for acknowledging. That is, when a message is acknowledged, the CorrelationID is what ties the acknowledgement to the original message. It is also the ID that is provided when retrieving a result. • TrackID stays constant for various messages for an ASR. The TrackID can also be considered the “serial number” for the ASR itself.

41. ID Flow Summary • TransportID changes with each message, and is different between Request and Response. • CorrelationID and TrackID are echoed in Response for all WS. • A new TrackID is created when the Response is cross-ASR.

42. ID Detailed Flow