1、 ATIS-0300079 TML TRANSPORT PROFILE SPECIFICATION The Alliance for Telecommunication Industry Solutions (ATIS) is a technical planning and standards development organization that is committed to rapidly developing and promoting technical and operations standards for the communications and related in
2、formation technologies industry worldwide using a pragmatic, flexible and open approach. Over 1,100 participants from more than 350 communications companies are active in ATIS 23 industry committees and its Incubator Solutions Program. NOTE - The users attention is called to the possibility that com
3、pliance with this standard may require use of an invention covered by patent rights. By publication of this standard, no position is taken with respect to whether use of an invention covered by patent rights will be required, and if any such use is required no position is taken regarding the validit
4、y of this claim or any patent rights in connection therewith. ATIS-0300079, tML Transport Profile Is an ATIS Standard developed by the ATIS Telecom Management and Operations Committee (TMOC). Published by Alliance for Telecommunications Industry Solutions 1200 G Street, NW, Suite 500 Washington, DC
5、20005 Copyright 2007 by Alliance for Telecommunications Industry Solutions All rights reserved. No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission of the publisher. For information contact ATIS at 202.628.63
6、80. ATIS is online at . Printed in the United States of America. ATIS-0300079 Specification on TML TRANSPORT PROFILE Secretariat Alliance for Telecommunications Industry Solutions Approved March 16, 2006 Abstract This document recommends a Transport Profile Specification to support the telecommunica
7、tions Markup Language (tML) Framework. The intent is to facilitate the interchange of tML formatted business transactions among telecommunication companies. An implementation infrastructure is specified to allow companies to conduct e-business with trading partners. This document is intended as a re
8、ference to assist in implementing applications based on tML schemas. This focus is on incorporating simple object access protocol (SOAP) messaging over hyper-text transfer protocol secure sockets (HTTP/S) into a companys interconnection infrastructure to exchange messages. ATIS-0300079 ii FOREWORD T
9、he Alliance for Telecommunication Industry Solutions (ATIS) serves the public through improved understanding between carriers, customers, and manufacturers. The Telecom Management and Operations Committee (TMOC) - formerly T1M1 -develops operations, administration, maintenance and provisioning stand
10、ards, and other documentation related to Operations Support System (OSS) and Network Element (NE) functions and interfaces for communications networks - with an emphasis on standards development related to U.S.A. communication networks in coordination with the development of international standards.
11、 Suggestions for improvement of this document are welcome. They should be sent to the Alliance for Telecommunications Industry Solutions, TMOC Secretariat, 1200 G Street NW, Suite 500, Washington, DC 20005. M. Fargano, TMOC Chair R. Roman, TMOC Vice-Chair C. Underkoffler, ATIS Chief Editor S. Edward
12、s, TMOC Technical Editor S. Reynolds, TMOC Technical Editor Organization Represented Name of Representative Alcatel USA Inc. Ken Biholar Atahan Tuzel (Alt.) AT it needs to integrate using existing middleware into an enterprises current infrastructure rather than replace pieces. Moreover, not all asp
13、ects of WS are appropriate for secured transactions. An example is discovery services using UDDI. The interactive nature of service requests necessitate that trading partners negotiate a priori with each other on how they will communicate. The terms agreed to can include service level agreements and
14、 the actual message contracts to be exchanged. While it is useful for the service description to be published and exchanged, it is unlikely that a new partner will discover the service in a public directory and use it without prior contact with the service provider. Data security, Quality of Service
15、 (QoS), and message orchestration are overarching issues that need to be considered for every external facing interface. It is desirable to consolidate these functions for the various business applications because it facilitates the ability to apply corporate policies and changes for all application
16、s. Having an infrastructure to handle these consistently across the different entry points and the various business applications would 7 ATIS-0300079 enable these functions to be leveraged regardless of the message payload. Web Services security extensions is another area where the technology is not
17、 mature enough for commercial application. This necessitates that current infrastructure must be leveraged. The following sections will detail the use of SOAP messaging and how it relates to different transport modes and business flows. 4 TML MESSAGING USING SOAP SOAP over HTTP(S) will be used to ex
18、change tML documents between telecom trading partners. A SOAP message consists of a SOAP envelope that encloses two data structures: the SOAP header and the SOAP body, and information about the namespaces used to define them. As shown in the following diagram, the SOAP header section will contain th
19、e tML Header, and optionally contain a Security Header, and other extensible Header components. The SOAP body contains a standard tML request or response document. Figure 4 - SOAP Envelope The tML Header conveys processing or control information about the request or response document contained in th
20、e SOAP body. For example, the processing or control information enables the transport application to perform the following tasks: Identify the sender of the SOAP Message. Track the status of the request or response document. Specify the interaction modes between the sender and receiver transport app
21、lication. 8 ATIS-0300079 9 The Security Header provides information for trading partners to exchange security related information, including digital certificates, digital signature, tokens, etc. The details of the security header will be defined in clause 7 of this document. The header section is ex
22、tensible and based on pair-wise trading partner agreements. Additional SOAP Header components can be added to support other tML transaction requirements, such as routing, transaction, and QoS, etc. The body contains a standard tML request or response document. The tML request or response document is
23、 defined by the business applications. For example, the tML schema of an ASR request or response document can be found in UOM-ASR Volume III. 4.1 tML Header Component The tML header will provide service control information about the SOAP request or response. It will include the following information
24、: From (required) indicates where the request originates, such as Company Name or Company Code. Company Code could be Exchange Carrier Code (ECC) or Access Carrier Name Abbreviated (ACNA). Up to 64 alphanumeric characters are allowed. The first 10 characters of this field is a part of the TransportI
25、D. To (required field) will be used to indicate the identity of the destination service provider. The identity could be, for example, Company Code or Company Name. Up to 64 alphanumeric characters are allowed. The first 10 characters of this field is a part of the TransportID. SendTimestamp (require
26、d field) represents the timestamp stating when the request/response/acknowledgement has been sent, up to milliseconds. The length of this field is 30 characters. It is required as a part of the TransportID. TransportID (required) will be used to uniquely identify the message being transferred at the
27、 transport level. It is a Log File ID entry to assist help desk personnel to track the SOAP Message. The originator is responsible for the uniqueness of the TransportID. Up to 64 alphanumeric characters are allowed. Below is a suggested format of this field: FROM field (first 10 characters) TO field
28、 (first 10 characters) Send Timestamp field (30 characters) NOTE - Time zone information is specified in this format see tML Header Schema Definition. Unique number generated by originator (14 characters) CorrelationID (see Figure 5 for usage) will be used to correlate a particular request or respon
29、se with the acknowledgement. It is also used to specify the result to be retrieved. Up to 64 alphanumeric characters are allowed. TrackID (see Figure 5 for usage) will be used to correlate multiple messages for a particular business transaction lifecycle, including requests, responses, and acknowled
30、gements. Up to 64 alphanumeric characters are allowed. ATIS-0300079 10 ApplicationType (required) will be used to indicate which transaction the request/response is for. This is a descriptive field intended for informational purposes. Up to 32 alphanumeric characters are allowed. ApplicationVersion
31、(optional) may be used to indicate which version of the application the transaction request/response is for. It is recommended that application version numbers be specific and include company specific naming with dot version levels when appropriate. This is a descriptive field intended for informati
32、onal purposes. Up to 32 alphanumeric characters are allowed. RetryCount (required) will provide the number of times the SOAP Message was resent. The original attempt should have a value of zero. This field is an integer. The following table shows how tML Header fields can be used in different scenar
33、ios: NOTE “Conditional” field use depends on specific business usage. Transaction Scenarios TransportID CorrelationID TrackID Request Required Optional Optional Synchronous Request/Response mode Response Required Conditional Conditional Request Required Required Conditional Asynchronous Request/Resp
34、onse mode Response Required Required Conditional One Way Notification Mode Request Required Optional Optional Figure 5 - Field Usage Table ATIS-0300079 4.2 tML Header Schema Definition Figure 6 - tML Header Schema Definition 4.3 Sample tML Header The following is a sample tML header. TransportID is
35、used to uniquely identify each message over the wire. CorrelationID is used to correlate the request/response and acknowledgement for a particular order transaction. The telecom services provider must process tML header. 11 ATIS-0300079 Figure 7 - Sample tML Header When the trading partner receives
36、the Header above, it will respond with the following tML Header section in the acknowledgement. Figure 8 - Sample tML Header (Acknowledgement to Figure 7) The following is a sample tML header for a new order transaction using synchronous request/response mode. TransportID is used to uniquely identif
37、y each message over the wire. The telecom services provider must process the tML header. Figure 9 - Sample tML Header with synchronous request/response mode 12 ATIS-0300079 5 INTERACTION OPERATIONAL MODES 5.1 General Telecom Interaction Modes The diagram below is the conceptual e-business model betw
38、een two telecom business partners. The telecom service providers extend their applications to their external trading partners through well-defined XML documents which are based upon industry guidelines. The document is described using tML, telecom XML standard for Trouble administration, Pre-Order,
39、Service Order, etc. Figure 10 - Conceptual E-Business Model The implementation of a tML transport profile by Telecom partners will need to support one of the transport modes defined in 5.3. In this transport profile document, Telecom partners will be referred to as either Telecom service requesters
40、and/or Telecom service providers. The interaction mode(s) selected is dependent on the process flows of the particular business application. 5.2 Interaction modes implemented in SOAP/HTTP(S) 5.2.1 WSDL SOAP messages, when used to carry tML service requests and responses, must conform to the WSDL des
41、cription. Telecom Service Providers should furnish WSDL descriptions defining the application services they are providing. Besides specifying the message descriptions for a particular service, WSDL descriptions also define the protocol and network address access points for each service. To ensure pr
42、oper message routing, it is recommended that schemas defined in a WSDL be named in a manner to support application versioning plus company specific naming with dot version levels when appropriate. 13 ATIS-0300079 14 5.2.2 SOAP Faults There are many cases when a web service provider must send an erro
43、r back to the requester instead of the expected result. A SOAP Fault can be used in place of any expected web service response during message transactions in any of the tML Interaction Modes. For example, a service that requires two fields (such as a street address and state) would return a SOAP fau
44、lt message if either of those fields were missing. Note that the failure in this example is not a business edit failure but rather a failure to properly invoke and process the service. 5.2.3 SOAP Messaging Transaction Flow The following describes the basic transaction flow for any SOAP service used
45、in the tML Transport definition: The service requester creates a SOAP message with a payload containing a request for service in the form of a tML document. The service requester sends the SOAP message to the service providers SOAP processor using HTTP(S). The service provider receives the SOAP mess
46、age, and attempts to validate the XML message against the required schema1. If the service provider is able to process the request, the expected response message is generated normally. If the service provider is not able to process the request, a SOAP Fault message is generated to be used as the res
47、ponse. If the service provider successfully receives the request but a business error occurs during normal processing of the SOAP message, a response message will be returned which contains the details of the business error. The business responses from the service provider are returned to the SOAP p
48、rocessor, again using the SOAP protocol, and this message is returned to the originating service requester via the same HTTP(S) socket connection. 5.3 Application Interaction There are two types of application interaction modes defined in the tML Transport: “Request/Response” and “Notification”. The
49、 interactions described are typical application behaviors used to send and process request transactions and are generally described in process flows. The “Request/Response” type is used to allow one business partner (the requester) to request that the other partner (the provider) performs some sort of action. As the name “Request/Response” implies, there is eventually a result generated by this action that the provider sends back to the requester. 1Schema validation can be performed outside the transport layer. ATIS-0300079 At a h
