[RFC2119]

712 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
712
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

[RFC2119]

  1. 1. 1 2Telecom SOA Use Cases and Gap 3Analysis Version 1.0 4OASIS TC Committee Draft 520 January 2009 6Editor Note: The URL’s will be fixed in the next revision of the document. 7 8Specification URIs: 9This Version: 10 http://docs.oasis-open.org/[tc-short-name]/ [additional path/filename].html 11 http://docs.oasis-open.org/[tc-short-name]/ [additional path/filename].doc 12 http://docs.oasis-open.org/[tc-short-name]/ [additional path/filename].pdf 13Previous Version: 14 http://docs.oasis-open.org/[tc-short-name]/ [additional path/filename].html 15 http://docs.oasis-open.org/[tc-short-name]/ [additional path/filename].doc 16 http://docs.oasis-open.org/[tc-short-name]/ [additional path/filename].pdf 17Latest Version: 18 http://docs.oasis-open.org/[tc-short-name]/ [additional path/filename].html 19 http://docs.oasis-open.org/[tc-short-name]/ [additional path/filename].doc 20 http://docs.oasis-open.org/[tc-short-name]/ [additional path/filename].pdf 21Technical Committee: 22OASIS SOA for Telecom (SOA-TEL) Technical Committee 23 24Chair(s): 25 MIke Giordano, giordano@avaya.com, Chair 26 John Storrie, storrie@nortel.com, Chair 27 28Editor(s): 29 Abbie Barbir, abbieb@nortel.com 30 31Related work: 32 This specification replaces or supercedes: 33 • Not Applicable 34 This specification is related to: 35 • Not Applicable 36 37Declared XML Namespace(s): 38 Not Applicable 1[Document Identifier] 20 January 2009 2Copyright © OASIS® 2009. All Rights Reserved. Page 1 of 39
  2. 2. 39Abstract: 40 TBD 41Status: 42 This document was last revised or approved by the OASIS SOA for Telecom (SOA-Tel) TC on 43 the above date. The level of approval is also listed above. Check the “Latest Version” or “Latest 44 Approved Version” location noted above for possible later revisions of this document. 45 Technical Committee members should send comments on this specification to the Technical 46 Committee’s email list. Others should send comments to the Technical Committee by using the 47 “Send A Comment” button on the Technical Committee’s web page at http://www.oasis-open.org/ 48 committees/ soa-tel/. 49 For information on whether any patents have been disclosed that may be essential to 50 implementing this specification, and any offers of patent licensing terms, please refer to the 51 Intellectual Property Rights section of the Technical Committee web page (http://www.oasis- 52 open.org/committees soa-tel/ipr.php. 53 The non-normative errata page for this specification is located at http://www.oasis- 54 open.org/committees/ soa-tel/. 4[Document Identifier] 20 January 2009 5Copyright © OASIS® 2009. All Rights Reserved. Page 2 of 39
  3. 3. 55Notices 56Copyright © OASIS® 2009. All Rights Reserved. 57All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual 58Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website. 59This document and translations of it may be copied and furnished to others, and derivative works that 60comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, 61and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice 62and this section are included on all such copies and derivative works. However, this document itself may 63not be modified in any way, including by removing the copyright notice or references to OASIS, except as 64needed for the purpose of developing any document or deliverable produced by an OASIS Technical 65Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must 66be followed) or as required to translate it into languages other than English. 67The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors 68or assigns. 69This document and the information contained herein is provided on an "AS IS" basis and OASIS 70DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 71WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 72OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 73PARTICULAR PURPOSE. 74OASIS requests that any OASIS Party or any other party that believes it has patent claims that would 75necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, 76to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to 77such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that 78produced this specification. 79OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of 80any patent claims that would necessarily be infringed by implementations of this specification by a patent 81holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR 82Mode of the OASIS Technical Committee that produced this specification. OASIS may include such 83claims on its website, but disclaims any obligation to do so. 84OASIS takes no position regarding the validity or scope of any intellectual property or other rights that 85might be claimed to pertain to the implementation or use of the technology described in this document or 86the extent to which any license under such rights might or might not be available; neither does it represent 87that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to 88rights in any document or deliverable produced by an OASIS Technical Committee can be found on the 89OASIS website. Copies of claims of rights made available for publication and any assurances of licenses 90to be made available, or the result of an attempt made to obtain a general license or permission for the 91use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS 92Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any 93information or list of intellectual property rights will at any time be complete, or that any claims in such list 94are, in fact, Essential Claims. 95The names "OASIS", [insert specific trademarked names and abbreviations here] are trademarks of 96OASIS, the owner and developer of this specification, and should be used only to refer to the organization 97and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, 98while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis- 99open.org/who/trademark.php for above guidance. 100 7[Document Identifier] 20 January 2009 8Copyright © OASIS® 2009. All Rights Reserved. Page 3 of 39
  4. 4. 101Table of Contents 1021 Introduction..............................................................................................................................................5 103 1.1 Terminology......................................................................................................................................5 104 1.2 Normative References......................................................................................................................5 105 1.3 Non-Normative References..............................................................................................................5 1062 Web Services Related Gaps....................................................................................................................7 107 2.1 Assumed standards Landscape and Architecture............................................................................7 108 2.2 Transaction Endpoints Specification.................................................................................................8 109 2.2.1 Scenario....................................................................................................................................8 110 2.2.2 Use Case..................................................................................................................................8 111 2.2.3 Possible Gaps.........................................................................................................................10 112 2.2.4 Editor Note: This is a place holder for possible Workaround...................................................11 113 2.3 Service Non Functional Properties (NFP).......................................................................................12 114 2.4 Service Discovery...........................................................................................................................12 115 2.5 Service Level Agreements (SLA)....................................................................................................12 116 2.5.1 Composed services and their part in Web Services Service Level Agreements (WSLA)........12 117 2.6 Telecom WS SOA Profile...............................................................................................................12 118 2.7 Service Orchestration (BPEL).........................................................................................................13 1193 Web 2.0 and Telco 2.0...........................................................................................................................14 120 3.1 Gaps Related to Parlay-X...............................................................................................................14 121 3.1.1 Parlay-X Part 1 – Common......................................................................................................14 1224 Mobile ...................................................................................................................................................15 1235 SOAP Header PropagationOther Stacks...............................................................................................16 124 5.1 SOAP Gap: SOAP Header Propagation.........................................................................................16 125 5.1.1 2.1 SOAP Nodes.....................................................................................................................22 126 5.1.2 2.2 SOAP Roles and SOAP Nodes.........................................................................................22 1276 WS-Security...........................................................................................................................................25 1287 WS-Notification......................................................................................................................................30 129 # Conformance........................................................................................................................................36 130A. Acknowledgements..............................................................................................................................37 131B. Non-Normative Text.............................................................................................................................38 132C. Revision History...................................................................................................................................39 133 134 10[Document Identifier] 20 January 2009 11Copyright © OASIS® 2009. All Rights Reserved. Page 4 of 39
  5. 5. 1351 Introduction 136[All text is normative unless otherwise labeled] 137TBD 1381.1 Terminology 139The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD 140NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described 141in [RFC2119]. 1421.2 Normative References 143 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, 144 http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997. [WS-I Basic Profile] 145 WS-I Basic Profile Version 1.0: "Final Material", available at http://www.ws- 146 i.org/Profiles/BasicProfile-1.0-2004-04-16.html. 147 148 [WSDL 1.1] W3C Note (15 March 2001): "Web Services Description Language (WSDL) 1.1". 149 http://www.w3.org/TR/2001/NOTE-wsdl-20010315. 150 [Reference] [Full reference citation] 1511.3 Non-Normative References 152 [Reference] [Full reference citation] 153 154 155 156 NOTE: The proper format for a citation to an OASIS Technical Committee’s work (whether Normative or Non-Normative) is: OASIS Stage (Committee Draft 01, Committee Draft 02, Committee Specification 01, etc. or Standard) Title (italicized or in quotation marks) Approval Date (Month YYYY) URI of the actual Authoritative Specification (namespace is not acceptable as the content changes over time) For example: EDXL-HAVE OASIS Standard, “Emergency Data Exchange Language (EDXL) Hospital AVailability Exchange (HAVE) Version 1.0”, November 2008. http://docs.oasis-open.org/emergency/edxl-have/os/emergency_edxl_have-1.0-spec- os.doc 158 13[Document Identifier] 20 January 2009 14Copyright © OASIS® 2009. All Rights Reserved. Page 5 of 39
  6. 6. 159 16[Document Identifier] 20 January 2009 17Copyright © OASIS® 2009. All Rights Reserved. Page 6 of 39
  7. 7. 1602 Web Services Related Gaps 161This section provides example uses cases that cover gaps that are related to web services standards as 162they apply to telecom services. 163 1642.1 Assumed standards Landscape and Architecture 165The figure in this section reflects the current understanding on the relationship between various 166standardization bodies to the work of this TC. 167 168 169 Market-driven interoperability profiles Framework Telecom Management SOA Profile (SDF) Bod Model Driven Event Driven Identity Management y Mobile Device SOA Profile Architecture Architecture Architecture IEEE Life Cycle Mgmt OASIS Telecom SOA Profile (Gap?) Non-functional Policy NGN SOA Framework SID Models OMG properties … TMF Securi … … BEPL WS-* ty OMA Parlay - X IT? … Transport Abstraction / Enablers ITU-T Gap 170 171 172Editor Note: 173Need to develop a very high level architecture that illustrates how the uses cases will work. The 174architecture should include the role of mediation (proxies for thin and fat clients, mobility and 175other scenarios) 176 177 178 179 19[Document Identifier] 20 January 2009 20Copyright © OASIS® 2009. All Rights Reserved. Page 7 of 39
  8. 8. 1802.2 Transaction Endpoints Specification 1812.2.1 Scenario 182The issue presented in this contribution derives from a concrete case, implemented within Telecom 183Italia’s SOA Middleware. 184Telecom Italia is in the process of deploying a SOA infrastructure, of which some of the constituting 185elements are an ESB (Enterprise Service Bus), a BPM (Business Process Manager), some “Service 186Consumers (systems or applications), some “Service Providers” (systems or applications). 187An aspect to be considered is that to satisfy performance criteria it has been decided that the ESB must 188be intrinsically “stateless” (i.e. it must not store any persistence information on destination of incoming 189service requests). 190Moreover, the “number” of ESBs can vary, i.e. there can be interconnetted trunks of different vendors’ 191ESBs. 1922.2.2 Use Case 193The following Use Case describes Telecom Italia’s technical problem. To improve readability the depicted 194use case presents only one instance of ESB, but the possible solution to the problem must satisfy also 195the cases of multiple instances of ESB. 196A Service Consumer (C1 or C2) invokes a Service, implemented as a Web Service (Web Service A). 197Such WSA is achieved as an “itinerary” with the composition of more elementary services, provided by 198Provider P1 and Provider P2. 199The ESB provides intermediary services for final exposition, enrichment and Data reconciliation and 200routing. 201 • Case A: C1 is the originator and final receiver. 202 • Case B: C2 is the originator and final receiver. 203 204 22[Document Identifier] 20 January 2009 23Copyright © OASIS® 2009. All Rights Reserved. Page 8 of 39
  9. 9. 205 c2 c1 6a 1b 1a 6b 5 WS A WS C resp ESB WS B WS C WS B resp 2 4 3 Provider P1 Provider P2 206 Figure 1 Scenario Implementation 207 25[Document Identifier] 20 January 2009 26Copyright © OASIS® 2009. All Rights Reserved. Page 9 of 39
  10. 10. 208 209 210 211 Figure 2 Scenario Flow 212 213Use Case Steps: 214Case A 215 • C1 invokes WSA, exposed by ESB. 216 • WSA is executed with the internal composition (transparent to C1) and with intermediary services 217 provided by the ESB. 218 • At the end of the internal interactions, the ESB forwards the response to C1. 219Case B 220 • C2 invokes WSA, exposed by ESB. 221 • WSA is executed with the internal composition (transparent to C2) and with intermediary services 222 provided by the ESB. 223 • At the end of the internal interactions, the ESB forwards the response to C2. 2242.2.3 Possible Gaps 225To Telecom Italia’s knowledge and expertise, in presence of an ESB offering intermediary services, there 226is no formal way to specify the endpoint (e.g. C1 or C2) to which the final result of a “process/transaction" 227(i.e. asynch response) result should be sent. 228 28[Document Identifier] 20 January 2009 29Copyright © OASIS® 2009. All Rights Reserved. Page 10 of 39
  11. 11. 2292.2.4 Editor Note: This is a place holder for possible Workaround 230This issue could be solved with the following “workaround” solution, which in any case is not mandatory 231but exploits some “optional” features of WS-Addressing. 232Note: 233This proposal does not require any “persistence” on any intermediary and is fully compliant with WS- 234Addressing specification. 235 236Telecom Italia asks if, apart from the proposed workaround, there is another standard reference solution 237for the highlighted problem. 238 239Should there be no other solution apart from the proposed workaround; TI proposes to extend the WS- 240Addressing specification in order that the “Message Properties” include a new tag (provisionally 241named “Final Destination”) to specify the process/transaction result. 242Moreover the proposal is to make the utilization of this new tag as Mandatory whenever it is 243necessary to specify a “final destination”, i.e. in presence of a non-direct “requester-consumer” 244situation. 245 246 247Proposed Workaround: 248 249 250CASE A: 251 252 1. C1 invokes WS-A and specifies in the replyTo section of the WS-Addressing header the EPR 253 (Endpoint Reference) where it wants to receive the async response (C1). 254 (Example: http://service1.sc.local/response). 255 256 2. The ESB invokes WSB and specifies in the replyTo section of the WS-Addressing header the EPR 257 (Endpoint Reference) where it wants to receive the async response (Example: 258 http://service1.esb.local/response). By doing so it takes the replyTo section received by C1 and 259 embeds it in the referenceParameters section of replyTo. P1 is obliged by WS-Addressing 260 specification to return the referenceParameters in the To section when sending the async response. 261 262 3. P1 returns the async response to the replyTo address (Example: 263 http://service1.esb.local/response) specified by the ESB, together with the referenceParameters 264 section. 265 266 4. The ESB invokes WSC and specifies in the replyTo section of the WS-Addressing header the EPR 267 (Endpoint Reference) where it wants to receive the async response (Example: 268 http://service2.esb.local/response). By doing so it takes the referenceParameters section received 269 by WSB and embeds it in the replyTo section. P2 is obliged by WS-Addressing specification to 270 return the referenceParameters in the To section when sending the async response. 271 272 5. P2 returns the async response to the ESB replyTo address (Example: 273 http://service2.esb.local/response) specified by the ESB, which includes the referenceParameters 274 section. 275 31[Document Identifier] 20 January 2009 32Copyright © OASIS® 2009. All Rights Reserved. Page 11 of 39
  12. 12. 276 6. The ESB gets the replyTo info, embedded in the referenceParameters received from P2, to 277 address the async response to C1. 278 279CASE B: 280Same as Case 1 with C2 originator and final destination. 281 282 2832.3 Service Non Functional Properties (NFP) 284 285Editor Note: This section is a place holder for Non Functional Properties. Contributions are encouraged. 286 2872.4 Service Discovery 288Editor Note: This section is a place holder for Discovery. Contributions are encouraged. 289  To discover available services and may be other devices in a network 290  Many techniques for service discovery 291  UDDI for Web services 292  Jini for Java objects 293  Simple Service Discovery Protocol (SSDP) used for Universal plug-and-play (UPnP) 294  DNS Service Discovery (DNS-SD) 295  Bluetooth Service Discovery Protocol (SDP) 296  Service Location Protocol (SLP) 297  How about HTTP Discovery? 2982.5 Service Level Agreements (SLA) 299Editor Note: This is a place Holder for material on SLA 300  Need to differentiate between service SLA and measuring service SLA compliance 301  Services may need to have a service compliance interface (testing to verify claims against SLA) 302  Relationship to service composition 303  W-SLA, service testting and monitoring 304  Relation to Non-functional properties 3052.5.1 Composed services and their part in Web Services Service Level 306 Agreements (WSLA) 307  Need a taxonomy or ontology of service behaviors 308  Need an approach to calculating behaviors of composed services 309 o Service failure is one of many identified behaviors 310 3112.6 Telecom WS SOA Profile 312Editor Note: This is a place Holder for material on Telecom SOA Profile. The main issue here is to 313identify the minimum number of WS specifications that need to be supported by Telecom 34[Document Identifier] 20 January 2009 35Copyright © OASIS® 2009. All Rights Reserved. Page 12 of 39
  13. 13. 314Providers and establishing an interoperability profile to implement them in a composed fashion. 315Contributions are encouraged. Current specifications include: 316  WS Addressing 317  WS reliable messaging 318  WS security 319  SOAP over JMS 320  General improvement of specs with guidelines to avoid proliferation of solutions 321  WS-Policy 322 3232.7 Service Orchestration (BPEL) 324Editor Note: This is a place Holder for material on BPEL. Use cases are encouraged. 325 326 • BPEL originally designed for IT application space 327 • Purpose: integrate long running inter-machine business processes 328 • Evolution to include BPEL4People to provide human time frame interactions rather than machine 329 speed 330 • Current benchmarks show 80 TPS on dual Xeon cpu 331 • Baseline HLR runs 5500 TPS (Telecom One TM1 benchmark) 332 • Basic SIP B2BUA is 10+ network transactions 333There is a need for speed. Do we need a real time BPEL for Telecom. 37[Document Identifier] 20 January 2009 38Copyright © OASIS® 2009. All Rights Reserved. Page 13 of 39
  14. 14. 3343 Web 2.0 and Telco 2.0 335Editor Note: A possible approach for this section is to take a deep dive into APIs such as Parlay-X, 336JAIN and CCTA and provide analysis of why these approaches have not been as widely accepted 337by the developer community. 338 3393.1 Gaps Related to Parlay-X 340Editor Note: The purpose of this section is to document the Gaps that Parlay-X encountered 341during their development. Defining new Parlay-X services or modifying current ones is out of 342scope. In this regard, contributions are encouraged to illustrate the workaround techniques that 343Parlay-X had to do to enable WS passed Telecom services. 344Contributions are encouraged. 345The definition of new Parlay-X API’s is out of scope for this OASIS working group. 346If during the use case analysis process where Parlay-X API’s are used as part of this work, some 347corrective content or even a new API function is discovered then the current OMA ARC processes 348for submitting corrective content to existing Parlay-X API’s or creating new interfaces should be 349used by member companies. 350 3513.1.1 Parlay-X Part 1 – Common 352The Parlay-X API Part 1 is related to the definition of common types and other constructs used by the 353other Parlay-X API’s. The web services messages are conformant to WS-I Basic Profile for the SOAP, 354XML and HTTP components. The web service security model uses the WS-I Basic Profile for HTTP over 355TLS. 356The WSDL interfaces are defined using the WSDL 1.1 specifications. 357 40[Document Identifier] 20 January 2009 41Copyright © OASIS® 2009. All Rights Reserved. Page 14 of 39
  15. 15. 3584 Mobile 359Editor Note: This is a place Holder for material on mobility aspects of the telecom SOA working group. 360 361 43[Document Identifier] 20 January 2009 44Copyright © OASIS® 2009. All Rights Reserved. Page 15 of 39
  16. 16. 3625 SOAP Header PropagationOther Stacks 363 3645.1 SOAP Gap: SOAP Header Propagation 365 366This information was submitted by Telecom Italia and accepted as part of the February 10th conference 367call. 368 Title SOAP Header Propagation Source Telecom Italia Contact Enrico Ronco (enrico.ronco@telecomitalia.it) Authors Federico Rossini, Luca Galeani, Enrico Ronco Date Feb. 10, 2009 Revision 0 369 370 371Scenario/context: 372The issue presented in this contribution derives from a concrete case, occurred within the context of the 373development of Telecom Italia’s platform for Mobile Virtual Network Operators (MVNOs). 374 375This contribution is related to a possible technical issue within the SOAP 1.2 specification (ref. 376http://www.w3.org/TR/soap12-part1/), in particular on the “SOAP Intermediary” and “Ultimate SOAP 377receiver” concepts. 378 379The specification defines the following (section 1.5.3): 380 381 • Initial SOAP sender – The SOAP sender that originates a SOAP message at the starting point of a SOAP message path. • SOAP intermediary – A SOAP intermediary is both a SOAP receiver and a SOAP sender and is targetable from within a SOAP message. It processes the SOAP header blocks targeted at it and acts to forward a SOAP message towards an ultimate SOAP receiver. • Ultimate SOAP receiver – The SOAP receiver that is a final destination of a SOAP message. It is responsible for processing the contents of the SOAP body and any SOAP header blocks targeted at it. In some circumstances, a SOAP message might not reach an ultimate SOAP receiver, for example because of a problem at a SOAP intermediary. An ultimate SOAP receiver cannot also be a SOAP intermediary for the same SOAP message (see 2. SOAP Processing Model). 382 383 384In particular it is stated that 46[Document Identifier] 20 January 2009 47Copyright © OASIS® 2009. All Rights Reserved. Page 16 of 39
  17. 17. 385 • A SOAP Intermediary processes the header of a SOAP message. 386 • An Ultimate SOAP receiver processes the body of a SOAP message and can not also be a 387 SOAP intermediary for the same SOAP message. 388 389 390The issue presented in the following Use Case illustrates the need to have a SOAP Intermediary which 391must process the body of a SOAP message in addition to its “canonical” role of processing the SOAP 392message header. 393 394The case is included within the activities of deployment of a company-ware SOA infrastructure, of which 395some of the constituting elements are an ESB (Enterprise Service Bus), some “Service Consumers 396(systems or applications), some “Service Providers” (systems or applications), a BPM (Business Process 397Manager), etc. 398 399 400 401 402 403 404Use Case: 405 406A Service Consumer C1 (e.g. a CRM application) invokes a Web Service to execute a transaction within a 407specific business process for the management of Mobile Virtual Network Operators. 408The access point for the Consumer C1 is the ESB, which exposes such Web Service and moreover 409typical functions such as Data Enrichment and Content Based Routing (CBR). 410 411 412 C1 CRM Application 1 ESB 2a 2b Service Service 413 Provider 1 Provider 2 49[Document Identifier] 20 January 2009 50Copyright © OASIS® 2009. All Rights Reserved. Page 17 of 39
  18. 18. 414 415 Figure 1 416 417 418Figure 2 contains the SOAP message which is the request formulated by the Service Consumer (e.g. the 419CRM application) to the ESB. 420The request contains 421 • a SOAP Envelope (in black color). This is enclosed for completeness but is not subject of 422 discussion within this contribution; 423 • the SOAP Header, in red color; 424 • the SOAP message Body, in blue (and green) color. 425 426With reference to the SOAP 1.2 specification, the ESB is a “SOAP Node” (ref. Section 1.5). 427 52[Document Identifier] 20 January 2009 53Copyright © OASIS® 2009. All Rights Reserved. Page 18 of 39
  19. 19. 428 <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP- ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema- instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:m0="http://telecomitalia.it/BSS/MVNO/NetProvisioningCustomTypes"> <SOAP-ENV:Header> <m:Header xmlns:m="http://telecomitalia.it/BSS/MVNO/NetProvisioningHeaderTypes"> <m:sourceSystem>String</m:sourceSystem> <m:businessID>String</m:businessID> </m:Header> </SOAP-ENV:Header> <SOAP-ENV:Body> <m:ActivateLineMessage xmlns:m="http://telecomitalia.it/BSS/MVNO/NetProvisioning"> <m:Command> <m0:description>String</m0:description> </m:Command> <m:MobilePhoneAccount> <m0:telephoneNumber>String</m0:telephoneNumber> <m0:ManagedOn> <m0:ICCID>String</m0:ICCID> </m0:ManagedOn> </m:MobilePhoneAccount> <m:NetworkProfile> <m0:ID>String</m0:ID> <m0:TDS>String</m0:TDS> </m:NetworkProfile> <m:Context> <m0:value>String</m0:value> </m:Context> </m:ActivateLineMessage> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 429 430 Figure 2: Original message created by the Client (Initial SOAP sender) 431 432The ESB for this use case must process the body of the SOAP message in order to perform 2 operations: 433 1) “Data Enrichment”, 434 The ESB queries a provisioning system to obtain the IMSI of the asset (mobile phone number) in 435 order to add such data to the message: it invokes a Web Service, exposed by that system, which 436 takes in input the ICCD, present in the message, and returns the IMSI. 437 2) CBR (Content Based Routing) 55[Document Identifier] 20 January 2009 56Copyright © OASIS® 2009. All Rights Reserved. Page 19 of 39
  20. 20. 438 The ESB decides on the final receiver of the SOAP message on the basis of the content of the 439 “Context” field (in green in Figure 2). 440 Once such tasks are performed, the ESB deletes the “Context” field from the message and 441 subsequently forwards the SOAP message to the selected Service Provider. 442 Note: 443 The Data Enrichment task is executed with the collaboration of other “Service Providers” (different 444 than SP1 or SP2), but it is not a subject to be discussed within this contribution: for this reason details 445 are omitted. 446 447After such tasks are complete, the ESB must forward the SOAP message to the selected Service 448Provider, which is the “real” Ultimate SOAP receiver. The message that must be finally sent to the SP by 449the ESB is the one depicted in Figure 3. 450It is fundamental to state that the Service Provider needs the header present in the SOAP message, e.g. 451because the content of the “business ID” field can not be associated to the body of the SOAP message. 452 453 <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP- ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema- instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:m0="http://telecomitalia.it/BSS/MVNO/NetProvisioningCustomTypes"> <SOAP-ENV:Header> <m:Header xmlns:m="http://telecomitalia.it/BSS/MVNO/NetProvisioningHeaderTypes"> <m:sourceSystem>String</m:sourceSystem> <m:businessID>String</m:businessID> </m:Header> </SOAP-ENV:Header> <SOAP-ENV:Body> <m:ActivateLineMessage xmlns:m="http://telecomitalia.it/BSS/MVNO/NetProvisioning"> <m:Command> <m0:description>String</m0:description> </m:Command> <m:MobilePhoneAccount> <m0:telephoneNumber>String</m0:telephoneNumber> <m0:ManagedOn> <m0:ICCID>String</m0:ICCID> <m0:IMSI>String</m0:IMSI> </m0:ManagedOn> </m:MobilePhoneAccount> <m:NetworkProfile> <m0:ID>String</m0:ID> <m0:TDS>String</m0:TDS> </m:NetworkProfile> </m:ActivateLineMessage> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 58[Document Identifier] 20 January 2009 59Copyright © OASIS® 2009. All Rights Reserved. Page 20 of 39
  21. 21. 454 Figure 3: Message needed by the Service Provider (Ultimate SOAP receiver) 455 456 457Nevertheless, given the initial definitions (section 1.5.3 of the SOAP Specification), since the ESB needs 458to elaborate the body of the message, it becomes an “Ultimate SOAP receiver” and thus can not be 459simultaneously classified as “SOAP Intermediary”. 460The consequence of this is that the ESB can not forward the header of the SOAP message to the 461selected Service Provider (i.e. to the “real” Ultimate SOAP receiver). 462Thus the message really forwarded by the ESB is depicted in Figure 4. 463 464 465 466 467 468 469 470 471 <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP- ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema- instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:m0="http://telecomitalia.it/BSS/MVNO/NetProvisioningCustomTypes"> <SOAP-ENV:Body> <m:ActivateLineMessage xmlns:m="http://telecomitalia.it/BSS/MVNO/NetProvisioning"> <m:Command> <m0:description>String</m0:description> </m:Command> <m:MobilePhoneAccount> <m0:telephoneNumber>String</m0:telephoneNumber> <m0:ManagedOn> <m0:ICCID>String</m0:ICCID> <m0:IMSI>String</m0:IMSI> </m0:ManagedOn> </m:MobilePhoneAccount> <m:NetworkProfile> <m0:ID>String</m0:ID> <m0:TDS>String</m0:TDS> </m:NetworkProfile> </m:ActivateLineMessage> </SOAP-ENV:Body> </SOAP-ENV:Envelope> 61[Document Identifier] 20 January 2009 62Copyright © OASIS® 2009. All Rights Reserved. Page 21 of 39
  22. 22. 473 Figure 4: message effectively forwarded by the ESB to the appropriate Service Provider 474 475This is a real case faced by Telecom Italia, and to overcome the problem some costly ad-hoc 476developments-customizations were necessary to re-build / reinsert the necessary header within the 477message before the ESB could forward the “complete” message to the final Service Provider. 478 479 480 481Perceived Technical issue: 482 483In the SOAP specification the following is stated. 484------------------- 4855.1.1 2.1 SOAP Nodes 486A SOAP node can be the initial SOAP sender, an ultimate SOAP receiver, or a SOAP intermediary. A 487SOAP node receiving a SOAP message MUST perform processing according to the SOAP processing 488model as described in this section and in the remainder of this specification … etc. 489 4905.1.2 2.2 SOAP Roles and SOAP Nodes 491In processing a SOAP message, a SOAP node is said to act in one or more SOAP roles, each of which is 492identified by a URI known as the SOAP role name. The roles assumed by a node MUST be invariant 493during the processing of an individual SOAP message. This specification deals only with the processing 494of individual SOAP messages. No statement is made regarding the possibility that a given SOAP node 495might or might not act in varying roles when processing more than one SOAP message. 496 497Table 2 defines three role names which have special significance in a SOAP message (see 2.6 498Processing SOAP Messages). 499 Table 2: SOAP Roles defined by this specification Short-name Name Description Each SOAP intermediary and the next "http://www.w3.org/2003/05/soap- ultimate SOAP receiver MUST act in envelope/role/next" this role. none "http://www.w3.org/2003/05/soap- SOAP nodes MUST NOT act in this envelope/role/none" role. ultimateReceiver "http://www.w3.org/2003/05/soap- The ultimate receiver MUST act in envelope/role/ultimateReceiver" this role. 500 501In addition to the SOAP role names defined in Table 2, other role names MAY be used as necessary to 502meet the needs of SOAP applications. 503------------------- 504 505 506Due to the fact that the ESB (as a SOAP Node) processes the body of the message, it is classified as 507“ultimateReceiver”. 508 64[Document Identifier] 20 January 2009 65Copyright © OASIS® 2009. All Rights Reserved. Page 22 of 39
  23. 23. 509As a consequence, the ESB can not “Forward” the SOAP Header to the appropriate Service Provider (ref. 510Sections 2.7.1 of the SOAP specification) since it has value “ultimateReceiver”. The following table 511depicts the behavior of the ESB being an ultimateReceiver. 512 Role Header block Short-name Assumed Understood & Processed Forwarded Yes No, unless reinserted next Yes No No, unless relay ="true" Yes No, unless reinserted Yes user-defined No No, unless relay ="true" No n/a Yes Yes n/a ultimateReceiver Yes No n/a none No n/a Yes 513 514 515 516The case presented shows that a SOAP Intermediary (the ESB), which is clearly not the “ultimate 517receiver” of the SOAP message, is forced to assume the role of “ultimateReceiver” since it processes 518the body of the message. This prevents the ESB to correctly perform it s “proper” intermediary role, since 519“An ultimate SOAP receiver cannot also be a SOAP intermediary for the same SOAP message”. 520 521The perceived technical gap suggested by Telecom Italia is that the SOAP specification should be 522modified in order to enable a SOAP Intermediary node to “forward” the SOAP Header in automatic mode 523(thus without the Header reinsertion) even if such node performs some processing operation over the 524body of the SOAP message. 525Another way of expressing this perceived gap is to state that currently only 3 roles are allowed for a 526SOAP Node (i.e. initial SOAP Sender, SOAP intermediary, SOAP ultimate receiver – section 2.1 of the 527SOAP 1.2 specification), while a probable fourth role enabling the simultaneous body processing and 528header forwarding of a specific SOAP message may be needed. 529 530Should the specification already enable this, Telecom Italia suggests to modify them in order to avoid 531possible ambiguities and misinterpretations. 532 533 534------------ 535 536 537 538 539 540 541 67[Document Identifier] 20 January 2009 68Copyright © OASIS® 2009. All Rights Reserved. Page 23 of 39
  24. 24. 542 543 544 545 70[Document Identifier] 20 January 2009 71Copyright © OASIS® 2009. All Rights Reserved. Page 24 of 39
  25. 25. 5466 WS-Security Title SAML Token Correlation Source Telecom Italia Contact Enrico Ronco (enrico.ronco@telecomitalia.it) Authors Federico Rossini, Maria Jose Mollo, Marco Cavalieri, Enrico Ronco Date Feb. 24, 2009 Revision 0 547 548 549Scenario/context: 550 551The context from which this contribution originates is that of sales and post-sales of telecommunications 552services, in particular the activation and provisioning of ADSL service to residential customers. 553The business process under analysis is complex and necessitates to be orchestrated by a BPM 554(Business Process Management) application. 555Such process is a “long-running” type process: in fact one of its tasks requires a human intervention 556within the central office, which can be executed within hours (or days). 557 558This implies that the process must be handled in a different mode from the “security management” 559perspective. 560 561This contribution addresses potential issues within the OASIS Web Services Security specification, 562OASIS Standard Specification, 1 February 2006, 563(http://www.oasis-open.org/specs/index.php#wssv1.0, ref. WS-Security). 564 565Use Case: 566 567A consumer, e.g. a CRM application invokes a service to execute a specific business process, the 568activation of ADSL services for a residential customer. 569 570The BPM application gets in charge of the orchestration/execution of such processes. 571 572Given the fact that the process is “long-running”, the BPM shall, at a given point, suspend the 573orchestration/execution of the process until it will receive a specific “activity closure” event from a back 574office system once the appropriate technician will have terminated his manual tasks. 575 576The following schema (Figure 1) depicts a simplified transaction diagram, while Figure 2 provides a 577pictorial representation of the Use Case. 73[Document Identifier] 20 January 2009 74Copyright © OASIS® 2009. All Rights Reserved. Page 25 of 39
  26. 26. 578 579 580 CRM BPM Delivery Order request In delivery X hours/days Delivery response Order response 581 Figure 2: Simplified transaction diagram 582 583 76[Document Identifier] 20 January 2009 77Copyright © OASIS® 2009. All Rights Reserved. Page 26 of 39
  27. 27. CRM Delivery system Application Token IAM Issuer BPM token1 Token Issuer SEP1 Token2 selling request 1 SEP2 BPM 2 selling response token1 token1 Generic system Generic system Delivery system 584 585 586 Figure 2: Represented use case 587 588 589Use Case steps. 590 591• The CRM sends an ADSL activation request. 592• The consumer (CRM) provides its credentials to a Token Issuer and requires the generation of a 593 security token, “token1”. The token is associated to the initial message and has limited duration, since 594 extending it would mean to have a weaker security policy. 595• The Security Enforcement Point, interacting with the policy decision point (IAM) (Identity Access 596 Manager), applies the authentication and authorization policies. 597• The BPM orchestrates the process interacting with the various services exposed by the involved 598 systems within the company SOA infrastructure. All interactions are executed with the “token1” as 599 security token. 600• When appropriate, the BPM invokes a service exposed by a Delivery system to obtain a physical 601 configuration within the central office. At this stage the BPM suspends the execution of the business 602 process (the duration of the task may require hours or days), awaiting for the reception of a specific 603 “activity closure” event. 604• The Delivery System activates the technical configuration task. 605• A human intervention is performed within the central office. 79[Document Identifier] 20 January 2009 80Copyright © OASIS® 2009. All Rights Reserved. Page 27 of 39
  28. 28. 606• Once this task is terminated, the technician reports the “activity closure” on the Delivery system, 607 which generates the “activity closure” event for the BPM. 608• The BPM resumes the suspended process, invoking the “next step” in the ADSL activation process. 609• If the security token “token1”is expired, the BPM requests the Token Issuer to generate a new 610 security token, “token2”, since the previous is not valid any more. 611• The remaining portion of the process is executed utilizing the new security token, “token2”. 612 613 614Perceived Technical issue: 615 616In the described scenario the issue is related to which credentials (capabilities) must be utilized to 617generate the security token “token2”. 618The BPM is responsible for the orchestration/execution of the process, and is the entity which is entitled 619to request the generation of the new security token “token2”, which is of course different from “token1”. 620This is a weakening factor for the “security architecture”, since an element of the middleware 621infrastructure (the BPM) would need to request the generation of security tokens which are not 622“correlated” (or “directly coupled”) to the real entity which requires the initiation of the business process 623(i.e. the CRM application, thus the CRM sales representative) and to the business process itself. It is a 624requirement for the Telecom Operator to reduce such potential security threats. 625 626It should be possible for the BPM to request the Token Issuer to generate a new token “associated” to the 627“token1” in order for the BPM itself to be authorized, once security checks are validated by the IAM, to 628invoke all pending services within the second part of the process because it is guaranteed that such 629invocations are “really” part of a “security authorized” business process. 630 631The OASIS WS-Sec specification, in Section 7, row 824, states that mechanisms for referencing security 632tokens are defined. 633 634In row 870 the following is stated: 635 636-------- 637 870 /wsse:SecurityTokenReference/@wsse:Usage 638 871 This optional attribute is used to type the usage of the 639 872 <wsse:SecurityTokenReference>. Usages are specified using URIs and multiple 640 873 usages MAY be specified using XML list semantics. No usages are defined by this 641 874 specification. 642-------- 643 644Thus, form a syntactical perspective, the specification enables the “correlation” of a security token to 645another one, but it does not prescribe how such correlation should be formalized. 646 647Moreover, within non-normative Appendix D “SecurityTokenReference Model”, specific examples of 648security token referencing are provided, with emphasis of the “signature referencing”. 649Within this appendix, Row 2413 to 2432 do provide an example of “non-signature references”, but the 650specification states that 651 82[Document Identifier] 20 January 2009 83Copyright © OASIS® 2009. All Rights Reserved. Page 28 of 39
  29. 29. 652 2430 This may be an expensive task and in the 653 2431 general case impossible as there is no way to know the "schema location" for a specific 654 2432 namespace URI. 655 656 657In conclusion, the lack of normative guidelines on how to address this problem, is perceived as a strong 658issue for a Telecom Operator because the “correlation” problem must anyhow be solved, but adopted 659solutions result to inevitably be proprietary, costly, non-standard, vendor/platform dependent 660customizations. 661 85[Document Identifier] 20 January 2009 86Copyright © OASIS® 2009. All Rights Reserved. Page 29 of 39
  30. 30. 6627 WS-Notification Title Event-Driven Service interoperability in Telecom Source Telecom Italia Contact Enrico Ronco (enrico.ronco@telecomitalia.it) Authors Vincenzo Amorino, Luca Galeani, Enrico Ronco (TI), Tommaso Pernice (HP) Date Feb. 24, 2009 Revision 0 663 664 665Scenario/context: 666Event-Driven Architectures are extremely important in environments, like Telecoms, where it is necessary 667to handle massive network events that have a business value to registered subscribers. 668Often these solutions rely on proprietary protocols that work against the implementation of SOA 669principles. 670There’s a strong technical and business need for a Notify/Subscribe protocol which could be widely 671adopted and used by Vendors and Telecom Operators. Moreover the protocol should support the 672presence of intermediaries between the Subscriber and the Notifier. 673In the following, 2 use cases are presented, one related to a lack of acceptance of an existing standard by 674the vendor community, and one on a specific technical issue on existing standards. 675 676Specifications addressed within this contribution are: 677OASIS Web Services Base Notification 1.3 (WS-BaseNotification), OASIS Standard, 1 October 2006, 678http://docs.oasis-open.org/wsn/wsn-ws_base_notification-1.3-spec-os.htm 679W3C Web Services Addressing 1.0 – Core W3C Recommendation 9 May 2006, http:// 680www.w3.org/TR/2006/REC-ws-addr-core-20060509 681 682Use Case A: 683The following Use Case describes a technical problem which is common for a Telecom Operator. 684 685 686An Application wants to be notified when a specific “Large Account Mobile Number” receives an SMS with 687a specific keyword in the message content. 688 689 690Use Case Steps: 88[Document Identifier] 20 January 2009 89Copyright © OASIS® 2009. All Rights Reserved. Page 30 of 39
  31. 31. 691 1. The Application informs the Provider that it wants to be notified when the specified Large Account 692 Number “33536821686” receives an SMS containing the word “poll”. 693 694 2. The Provider notifies the Application when an incoming event from the underlying network 695 responds to the Subscribing criteria. 696 697 3. The Application informs the Provider that it does not want to be notified anymore when the 698 specified Large Account Number “33536821686” receives an SMS containing the word “poll”. 699 700 701 Figure 1 702 703 704 705 706 707Perceived technical issue: 708Currently a commonly used interoperable standard does not exist to address “Notify/Subscribe message 709exchanges”. 710The last approved specification, OASIS WS-Notification (ref. http://http://docs.oasis-open.org/wsn/wsn- 711ws_base_notification-1.3-spec-os.htm, October 2006), has been very poorly adopted by the vendors 712community and consequently has no interoperability value. 713The need is that such specification gets endorsed/adopted by the vendor community in order for it to add 714value in this specific context. 715 91[Document Identifier] 20 January 2009 92Copyright © OASIS® 2009. All Rights Reserved. Page 31 of 39
  32. 32. 716Such lack is perceived as a strong market gap with negative impacts for both Telecom Operators and 717Third Parties involved in the development of new services: 7181) Operators are limited in their business development since they must rely on costly proprietary 719 solutions and customizations implemented by vendors; 7202) Third Parties, who are typically involved in developing new services for their customers, can not fully 721 exploit in their services development the open network infrastructures provided by Telco Operators. 722 723 94[Document Identifier] 20 January 2009 95Copyright © OASIS® 2009. All Rights Reserved. Page 32 of 39
  33. 33. 724Use Case B: 725The following Use Case describes a second technical problem which is common for Telecom Operators. 726 727An Application must be notified when a specific “Large Account Mobile Number” receives an SMS with a 728specific keyword in the message content. There are one or more intermediaries between the Application 729and the Provider. 730 731Use Case Steps: 732 1. The Application informs the Intermediary that it wants to be notified when the specified Large 733 Account Number “33536821686” receives an SMS containing the word “poll”. 734 735 2. The Intermediary sends the subscription request to the Provider. 736 737 3. The Provider notifies the Intermediary when an incoming event from the underlying network 738 responds to the Subscribing criteria. 739 740 4. The Intermediary sends the notification to the Application. 741 742 5. The Application informs the Intermediary that it does not want to be notified anymore when the 743 specified Large Account Number “33536821686” receives an SMS containing the word “poll”. 744 745 6. The Intermediary sends the “unsubscribe” request to the Provider. 746 747 748 97[Document Identifier] 20 January 2009 98Copyright © OASIS® 2009. All Rights Reserved. Page 33 of 39
  34. 34. 749 750 751 Figure 2 752 753 754Perceived Technical issue: 755The last approved specification to support Notify/Subscribe patterns, WS-Notification (ref. 756http://docs.oasis-open.org/wsn/wsn-ws_base_notification-1.3-spec-os.htm, October 2006), relies on W3C 757WS-Addressing (http://www.w3.org/TR/2006/REC-ws-addr-core-20060509) for the asynchronous delivery 758of notifications, which means that there is no formal way for the Provider to specify the endpoint to which 759the Notification should be sent. 760As an example, in the case illustrated above there is no standard way for the Provider to indicate the 761original Application as destination of the notification, due to the presence of intermediary (ies) in the path. 762 763The issue on WS-A impacts thus also the WS-N specification. Refer to Telecom Italia’s contribution 764“Transaction Endpoints Specification”, presented to the OASIS SOA-TEL TC on Jan 14, 2009 for the 765technical issues with the WS-A specification. 766 “in presence of intermediary, there is no formal way to specify the endpoint to which the final 767 result of a “process/transaction" (i.e. asynch. response) result should be sent.” (extract from TI 768 contribution). 769 770 771The technical problem here exposed prevents Telecom Operators to develop standardized solutions for 772the management of “multiple notify/subscribe patterns”, and forces to rely on costly customizations and 773proprietary solutions. 774 775 100[Document Identifier] 20 January 2009 101Copyright © OASIS® 2009. All Rights Reserved. Page 34 of 39
  35. 35. 776 103[Document Identifier] 20 January 2009 104Copyright © OASIS® 2009. All Rights Reserved. Page 35 of 39
  36. 36. 777 # Conformance 778The last numbered section in the specification must be the Conformance section. Conformance 779Statements/Clauses go here. 106[Document Identifier] 20 January 2009 107Copyright © OASIS® 2009. All Rights Reserved. Page 36 of 39
  37. 37. 780A. Acknowledgements 781The following individuals have participated in the creation of this specification and are gratefully 782acknowledged: 783Participants: 784 [Participant Name, Affiliation | Individual Member] 785 [Participant Name, Affiliation | Individual Member] 786 109[Document Identifier] 20 January 2009 110Copyright © OASIS® 2009. All Rights Reserved. Page 37 of 39
  38. 38. 787B. Non-Normative Text 112[Document Identifier] 20 January 2009 113Copyright © OASIS® 2009. All Rights Reserved. Page 38 of 39
  39. 39. 788C. Revision History 789 Revision Date Editor Changes Made 1.0 Jan 20, 2009 Abbie Barbir Started all sections in the document 790 791 115[Document Identifier] 20 January 2009 116Copyright © OASIS® 2009. All Rights Reserved. Page 39 of 39

×