Your SlideShare is downloading. ×
[RFC2119]
[RFC2119]
[RFC2119]
[RFC2119]
[RFC2119]
[RFC2119]
[RFC2119]
[RFC2119]
[RFC2119]
[RFC2119]
[RFC2119]
[RFC2119]
[RFC2119]
[RFC2119]
[RFC2119]
[RFC2119]
[RFC2119]
[RFC2119]
[RFC2119]
[RFC2119]
[RFC2119]
[RFC2119]
[RFC2119]
[RFC2119]
[RFC2119]
[RFC2119]
[RFC2119]
[RFC2119]
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

[RFC2119]

345

Published on

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

  • Be the first to like this

No Downloads
Views
Total Views
345
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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 28
  • 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 28
  • 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 28
  • 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 Other Stacks...............................................................................................................................16 124 5.1 SOAP Gap: WS-Addressing ..........................................................................................................16 125 5.1.1 2.1 SOAP Nodes.....................................................................................................................22 126 5.1.2 2.2 SOAP Roles and SOAP Nodes.........................................................................................22 127 # Conformance........................................................................................................................................25 128A. Acknowledgements..............................................................................................................................26 129B. Non-Normative Text.............................................................................................................................27 130C. Revision History...................................................................................................................................28 131 132 10[Document Identifier] 20 January 2009 11Copyright © OASIS® 2009. All Rights Reserved. Page 4 of 28
  • 5. 1331 Introduction 134[All text is normative unless otherwise labeled] 135TBD 1361.1 Terminology 137The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD 138NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described 139in [RFC2119]. 1401.2 Normative References 141 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, 142 http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997. [WS-I Basic Profile] 143 WS-I Basic Profile Version 1.0: "Final Material", available at http://www.ws- 144 i.org/Profiles/BasicProfile-1.0-2004-04-16.html. 145 146 [WSDL 1.1] W3C Note (15 March 2001): "Web Services Description Language (WSDL) 1.1". 147 http://www.w3.org/TR/2001/NOTE-wsdl-20010315. 148 [Reference] [Full reference citation] 1491.3 Non-Normative References 150 [Reference] [Full reference citation] 151 152 153 154 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 156 13[Document Identifier] 20 January 2009 14Copyright © OASIS® 2009. All Rights Reserved. Page 5 of 28
  • 6. 157 16[Document Identifier] 20 January 2009 17Copyright © OASIS® 2009. All Rights Reserved. Page 6 of 28
  • 7. 1582 Web Services Related Gaps 159This section provides example uses cases that cover gaps that are related to web services standards as 160they apply to telecom services. 161 1622.1 Assumed standards Landscape and Architecture 163The figure in this section reflects the current understanding on the relationship between various 164standardization bodies to the work of this TC. 165 166 167 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 168 169 170Editor Note: 171Need to develop a very high level architecture that illustrates how the uses cases will work. The 172architecture should include the role of mediation (proxies for thin and fat clients, mobility and 173other scenarios) 174 175 176 177 19[Document Identifier] 20 January 2009 20Copyright © OASIS® 2009. All Rights Reserved. Page 7 of 28
  • 8. 1782.2 Transaction Endpoints Specification 1792.2.1 Scenario 180The issue presented in this contribution derives from a concrete case, implemented within Telecom 181Italia’s SOA Middleware. 182Telecom Italia is in the process of deploying a SOA infrastructure, of which some of the constituting 183elements are an ESB (Enterprise Service Bus), a BPM (Business Process Manager), some “Service 184Consumers (systems or applications), some “Service Providers” (systems or applications). 185An aspect to be considered is that to satisfy performance criteria it has been decided that the ESB must 186be intrinsically “stateless” (i.e. it must not store any persistence information on destination of incoming 187service requests). 188Moreover, the “number” of ESBs can vary, i.e. there can be interconnetted trunks of different vendors’ 189ESBs. 1902.2.2 Use Case 191The following Use Case describes Telecom Italia’s technical problem. To improve readability the depicted 192use case presents only one instance of ESB, but the possible solution to the problem must satisfy also 193the cases of multiple instances of ESB. 194A Service Consumer (C1 or C2) invokes a Service, implemented as a Web Service (Web Service A). 195Such WSA is achieved as an “itinerary” with the composition of more elementary services, provided by 196Provider P1 and Provider P2. 197The ESB provides intermediary services for final exposition, enrichment and Data reconciliation and 198routing. 199 • Case A: C1 is the originator and final receiver. 200 • Case B: C2 is the originator and final receiver. 201 202 22[Document Identifier] 20 January 2009 23Copyright © OASIS® 2009. All Rights Reserved. Page 8 of 28
  • 9. 203 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 204 Figure 1 Scenario Implementation 205 25[Document Identifier] 20 January 2009 26Copyright © OASIS® 2009. All Rights Reserved. Page 9 of 28
  • 10. 206 207 208 209 Figure 2 Scenario Flow 210 211Use Case Steps: 212Case A 213 • C1 invokes WSA, exposed by ESB. 214 • WSA is executed with the internal composition (transparent to C1) and with intermediary services 215 provided by the ESB. 216 • At the end of the internal interactions, the ESB forwards the response to C1. 217Case B 218 • C2 invokes WSA, exposed by ESB. 219 • WSA is executed with the internal composition (transparent to C2) and with intermediary services 220 provided by the ESB. 221 • At the end of the internal interactions, the ESB forwards the response to C2. 2222.2.3 Possible Gaps 223To Telecom Italia’s knowledge and expertise, in presence of an ESB offering intermediary services, there 224is no formal way to specify the endpoint (e.g. C1 or C2) to which the final result of a “process/transaction" 225(i.e. asynch response) result should be sent. 226 28[Document Identifier] 20 January 2009 29Copyright © OASIS® 2009. All Rights Reserved. Page 10 of 28
  • 11. 2272.2.4 Editor Note: This is a place holder for possible Workaround 228This issue could be solved with the following “workaround” solution, which in any case is not mandatory 229but exploits some “optional” features of WS-Addressing. 230Note: 231This proposal does not require any “persistence” on any intermediary and is fully compliant with WS- 232Addressing specification. 233 234Telecom Italia asks if, apart from the proposed workaround, there is another standard reference solution 235for the highlighted problem. 236 237Should there be no other solution apart from the proposed workaround; TI proposes to extend the WS- 238Addressing specification in order that the “Message Properties” include a new tag (provisionally 239named “Final Destination”) to specify the process/transaction result. 240Moreover the proposal is to make the utilization of this new tag as Mandatory whenever it is 241necessary to specify a “final destination”, i.e. in presence of a non-direct “requester-consumer” 242situation. 243 244 245Proposed Workaround: 246 247 248CASE A: 249 250 1. C1 invokes WS-A and specifies in the replyTo section of the WS-Addressing header the EPR 251 (Endpoint Reference) where it wants to receive the async response (C1). 252 (Example: http://service1.sc.local/response). 253 254 2. The ESB invokes WSB and specifies in the replyTo section of the WS-Addressing header the EPR 255 (Endpoint Reference) where it wants to receive the async response (Example: 256 http://service1.esb.local/response). By doing so it takes the replyTo section received by C1 and 257 embeds it in the referenceParameters section of replyTo. P1 is obliged by WS-Addressing 258 specification to return the referenceParameters in the To section when sending the async response. 259 260 3. P1 returns the async response to the replyTo address (Example: 261 http://service1.esb.local/response) specified by the ESB, together with the referenceParameters 262 section. 263 264 4. The ESB invokes WSC and specifies in the replyTo section of the WS-Addressing header the EPR 265 (Endpoint Reference) where it wants to receive the async response (Example: 266 http://service2.esb.local/response). By doing so it takes the referenceParameters section received 267 by WSB and embeds it in the replyTo section. P2 is obliged by WS-Addressing specification to 268 return the referenceParameters in the To section when sending the async response. 269 270 5. P2 returns the async response to the ESB replyTo address (Example: 271 http://service2.esb.local/response) specified by the ESB, which includes the referenceParameters 272 section. 273 31[Document Identifier] 20 January 2009 32Copyright © OASIS® 2009. All Rights Reserved. Page 11 of 28
  • 12. 274 6. The ESB gets the replyTo info, embedded in the referenceParameters received from P2, to 275 address the async response to C1. 276 277CASE B: 278Same as Case 1 with C2 originator and final destination. 279 280 2812.3 Service Non Functional Properties (NFP) 282 283Editor Note: This section is a place holder for Non Functional Properties. Contributions are encouraged. 284 2852.4 Service Discovery 286Editor Note: This section is a place holder for Discovery. Contributions are encouraged. 287  To discover available services and may be other devices in a network 288  Many techniques for service discovery 289  UDDI for Web services 290  Jini for Java objects 291  Simple Service Discovery Protocol (SSDP) used for Universal plug-and-play (UPnP) 292  DNS Service Discovery (DNS-SD) 293  Bluetooth Service Discovery Protocol (SDP) 294  Service Location Protocol (SLP) 295  How about HTTP Discovery? 2962.5 Service Level Agreements (SLA) 297Editor Note: This is a place Holder for material on SLA 298  Need to differentiate between service SLA and measuring service SLA compliance 299  Services may need to have a service compliance interface (testing to verify claims against SLA) 300  Relationship to service composition 301  W-SLA, service testting and monitoring 302  Relation to Non-functional properties 3032.5.1 Composed services and their part in Web Services Service Level 304 Agreements (WSLA) 305  Need a taxonomy or ontology of service behaviors 306  Need an approach to calculating behaviors of composed services 307 o Service failure is one of many identified behaviors 308 3092.6 Telecom WS SOA Profile 310Editor Note: This is a place Holder for material on Telecom SOA Profile. The main issue here is to 311identify 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 28
  • 13. 312Providers and establishing an interoperability profile to implement them in a composed fashion. 313Contributions are encouraged. Current specifications include: 314  WS Addressing 315  WS reliable messaging 316  WS security 317  SOAP over JMS 318  General improvement of specs with guidelines to avoid proliferation of solutions 319  WS-Policy 320 3212.7 Service Orchestration (BPEL) 322Editor Note: This is a place Holder for material on BPEL. Use cases are encouraged. 323 324 • BPEL originally designed for IT application space 325 • Purpose: integrate long running inter-machine business processes 326 • Evolution to include BPEL4People to provide human time frame interactions rather than machine 327 speed 328 • Current benchmarks show 80 TPS on dual Xeon cpu 329 • Baseline HLR runs 5500 TPS (Telecom One TM1 benchmark) 330 • Basic SIP B2BUA is 10+ network transactions 331There 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 28
  • 14. 3323 Web 2.0 and Telco 2.0 333Editor Note: A possible approach for this section is to take a deep dive into APIs such as Parlay-X, 334JAIN and CCTA and provide analysis of why these approaches have not been as widely accepted 335by the developer community. 336 3373.1 Gaps Related to Parlay-X 338Editor Note: The purpose of this section is to document the Gaps that Parlay-X encountered 339during their development. Defining new Parlay-X services or modifying current ones is out of 340scope. In this regard, contributions are encouraged to illustrate the workaround techniques that 341Parlay-X had to do to enable WS passed Telecom services. 342Contributions are encouraged. 343The definition of new Parlay-X API’s is out of scope for this OASIS working group. 344If during the use case analysis process where Parlay-X API’s are used as part of this work, some 345corrective content or even a new API function is discovered then the current OMA ARC processes 346for submitting corrective content to existing Parlay-X API’s or creating new interfaces should be 347used by member companies. 348 3493.1.1 Parlay-X Part 1 – Common 350The Parlay-X API Part 1 is related to the definition of common types and other constructs used by the 351other Parlay-X API’s. The web services messages are conformant to WS-I Basic Profile for the SOAP, 352XML and HTTP components. The web service security model uses the WS-I Basic Profile for HTTP over 353TLS. 354The WSDL interfaces are defined using the WSDL 1.1 specifications. 355 40[Document Identifier] 20 January 2009 41Copyright © OASIS® 2009. All Rights Reserved. Page 14 of 28
  • 15. 3564 Mobile 357Editor Note: This is a place Holder for material on mobility aspects of the telecom SOA working group. 358 359 43[Document Identifier] 20 January 2009 44Copyright © OASIS® 2009. All Rights Reserved. Page 15 of 28
  • 16. 3605 SOAP Other Stacks 361 3625.1 SOAP Gap: WS-Addressing 363 364This information was submitted by Telecom Italia and accepted as part of the February 10th conference 365call. 366 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 367 368 369Scenario/context: 370The issue presented in this contribution derives from a concrete case, occurred within the context of the 371development of Telecom Italia’s platform for Mobile Virtual Network Operators (MVNOs). 372 373This contribution is related to a possible technical issue within the SOAP 1.2 specification (ref. 374http://www.w3.org/TR/soap12-part1/), in particular on the “SOAP Intermediary” and “Ultimate SOAP 375receiver” concepts. 376 377The specification defines the following (section 1.5.3): 378 379 • 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). 380 381 382In particular it is stated that 46[Document Identifier] 20 January 2009 47Copyright © OASIS® 2009. All Rights Reserved. Page 16 of 28
  • 17. 383 • A SOAP Intermediary processes the header of a SOAP message. 384 • An Ultimate SOAP receiver processes the body of a SOAP message and can not also be a 385 SOAP intermediary for the same SOAP message. 386 387 388The issue presented in the following Use Case illustrates the need to have a SOAP Intermediary which 389must process the body of a SOAP message in addition to its “canonical” role of processing the SOAP 390message header. 391 392The case is included within the activities of deployment of a company-ware SOA infrastructure, of which 393some of the constituting elements are an ESB (Enterprise Service Bus), some “Service Consumers 394(systems or applications), some “Service Providers” (systems or applications), a BPM (Business Process 395Manager), etc. 396 397 398 399 400 401 402Use Case: 403 404A Service Consumer C1 (e.g. a CRM application) invokes a Web Service to execute a transaction within a 405specific business process for the management of Mobile Virtual Network Operators. 406The access point for the Consumer C1 is the ESB, which exposes such Web Service and moreover 407typical functions such as Data Enrichment and Content Based Routing (CBR). 408 409 410 C1 CRM Application 1 ESB 2a 2b Service Service 411 Provider 1 Provider 2 49[Document Identifier] 20 January 2009 50Copyright © OASIS® 2009. All Rights Reserved. Page 17 of 28
  • 18. 412 413 Figure 1 414 415 416Figure 2 contains the SOAP message which is the request formulated by the Service Consumer (e.g. the 417CRM application) to the ESB. 418The request contains 419 • a SOAP Envelope (in black color). This is enclosed for completeness but is not subject of 420 discussion within this contribution; 421 • the SOAP Header, in red color; 422 • the SOAP message Body, in blue (and green) color. 423 424With reference to the SOAP 1.2 specification, the ESB is a “SOAP Node” (ref. Section 1.5). 425 52[Document Identifier] 20 January 2009 53Copyright © OASIS® 2009. All Rights Reserved. Page 18 of 28
  • 19. 426 <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> 427 428 Figure 2: Original message created by the Client (Initial SOAP sender) 429 430The ESB for this use case must process the body of the SOAP message in order to perform 2 operations: 431 1) “Data Enrichment”, 432 The ESB queries a provisioning system to obtain the IMSI of the asset (mobile phone number) in 433 order to add such data to the message: it invokes a Web Service, exposed by that system, which 434 takes in input the ICCD, present in the message, and returns the IMSI. 435 2) CBR (Content Based Routing) 55[Document Identifier] 20 January 2009 56Copyright © OASIS® 2009. All Rights Reserved. Page 19 of 28
  • 20. 436 The ESB decides on the final receiver of the SOAP message on the basis of the content of the 437 “Context” field (in green in Figure 2). 438 Once such tasks are performed, the ESB deletes the “Context” field from the message and 439 subsequently forwards the SOAP message to the selected Service Provider. 440 Note: 441 The Data Enrichment task is executed with the collaboration of other “Service Providers” (different 442 than SP1 or SP2), but it is not a subject to be discussed within this contribution: for this reason details 443 are omitted. 444 445After such tasks are complete, the ESB must forward the SOAP message to the selected Service 446Provider, which is the “real” Ultimate SOAP receiver. The message that must be finally sent to the SP by 447the ESB is the one depicted in Figure 3. 448It is fundamental to state that the Service Provider needs the header present in the SOAP message, e.g. 449because the content of the “business ID” field can not be associated to the body of the SOAP message. 450 451 <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 28
  • 21. 452 Figure 3: Message needed by the Service Provider (Ultimate SOAP receiver) 453 454 455Nevertheless, given the initial definitions (section 1.5.3 of the SOAP Specification), since the ESB needs 456to elaborate the body of the message, it becomes an “Ultimate SOAP receiver” and thus can not be 457simultaneously classified as “SOAP Intermediary”. 458The consequence of this is that the ESB can not forward the header of the SOAP message to the 459selected Service Provider (i.e. to the “real” Ultimate SOAP receiver). 460Thus the message really forwarded by the ESB is depicted in Figure 4. 461 462 463 464 465 466 467 468 469 <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 28
  • 22. 471 Figure 4: message effectively forwarded by the ESB to the appropriate Service Provider 472 473This is a real case faced by Telecom Italia, and to overcome the problem some costly ad-hoc 474developments-customizations were necessary to re-build / reinsert the necessary header within the 475message before the ESB could forward the “complete” message to the final Service Provider. 476 477 478 479Perceived Technical issue: 480 481In the SOAP specification the following is stated. 482------------------- 4835.1.1 2.1 SOAP Nodes 484A SOAP node can be the initial SOAP sender, an ultimate SOAP receiver, or a SOAP intermediary. A 485SOAP node receiving a SOAP message MUST perform processing according to the SOAP processing 486model as described in this section and in the remainder of this specification … etc. 487 4885.1.2 2.2 SOAP Roles and SOAP Nodes 489In processing a SOAP message, a SOAP node is said to act in one or more SOAP roles, each of which is 490identified by a URI known as the SOAP role name. The roles assumed by a node MUST be invariant 491during the processing of an individual SOAP message. This specification deals only with the processing 492of individual SOAP messages. No statement is made regarding the possibility that a given SOAP node 493might or might not act in varying roles when processing more than one SOAP message. 494 495Table 2 defines three role names which have special significance in a SOAP message (see 2.6 496Processing SOAP Messages). 497 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. 498 499In addition to the SOAP role names defined in Table 2, other role names MAY be used as necessary to 500meet the needs of SOAP applications. 501------------------- 502 503 504Due to the fact that the ESB (as a SOAP Node) processes the body of the message, it is classified as 505“ultimateReceiver”. 506 64[Document Identifier] 20 January 2009 65Copyright © OASIS® 2009. All Rights Reserved. Page 22 of 28
  • 23. 507As a consequence, the ESB can not “Forward” the SOAP Header to the appropriate Service Provider (ref. 508Sections 2.7.1 of the SOAP specification) since it has value “ultimateReceiver”. The following table 509depicts the behavior of the ESB being an ultimateReceiver. 510 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 511 512 513 514The case presented shows that a SOAP Intermediary (the ESB), which is clearly not the “ultimate 515receiver” of the SOAP message, is forced to assume the role of “ultimateReceiver” since it processes 516the body of the message. This prevents the ESB to correctly perform it s “proper” intermediary role, since 517“An ultimate SOAP receiver cannot also be a SOAP intermediary for the same SOAP message”. 518 519The perceived technical gap suggested by Telecom Italia is that the SOAP specification should be 520modified in order to enable a SOAP Intermediary node to “forward” the SOAP Header in automatic mode 521(thus without the Header reinsertion) even if such node performs some processing operation over the 522body of the SOAP message. 523Another way of expressing this perceived gap is to state that currently only 3 roles are allowed for a 524SOAP Node (i.e. initial SOAP Sender, SOAP intermediary, SOAP ultimate receiver – section 2.1 of the 525SOAP 1.2 specification), while a probable fourth role enabling the simultaneous body processing and 526header forwarding of a specific SOAP message may be needed. 527 528Should the specification already enable this, Telecom Italia suggests to modify them in order to avoid 529possible ambiguities and misinterpretations. 530 531 532------------ 533 534 535 536 537 538 539 67[Document Identifier] 20 January 2009 68Copyright © OASIS® 2009. All Rights Reserved. Page 23 of 28
  • 24. 540 541 542 70[Document Identifier] 20 January 2009 71Copyright © OASIS® 2009. All Rights Reserved. Page 24 of 28
  • 25. 543 # Conformance 544The last numbered section in the specification must be the Conformance section. Conformance 545Statements/Clauses go here. 73[Document Identifier] 20 January 2009 74Copyright © OASIS® 2009. All Rights Reserved. Page 25 of 28
  • 26. 546A. Acknowledgements 547The following individuals have participated in the creation of this specification and are gratefully 548acknowledged: 549Participants: 550 [Participant Name, Affiliation | Individual Member] 551 [Participant Name, Affiliation | Individual Member] 552 76[Document Identifier] 20 January 2009 77Copyright © OASIS® 2009. All Rights Reserved. Page 26 of 28
  • 27. 553B. Non-Normative Text 79[Document Identifier] 20 January 2009 80Copyright © OASIS® 2009. All Rights Reserved. Page 27 of 28
  • 28. 554C. Revision History 555 Revision Date Editor Changes Made 1.0 Jan 20, 2009 Abbie Barbir Started all sections in the document 556 557 82[Document Identifier] 20 January 2009 83Copyright © OASIS® 2009. All Rights Reserved. Page 28 of 28

×