Telecom SOA Use Case and Gap v3

1
2Telecom SOA Use Cases and Gap

3Analysis Version 1.0
4OASIS TC Committee Draft

520 January 2009
6Editor Note: The URLs 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:
17Latest Version:
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
39Abstract:
40 TBD
1[Document Identifier] 20 January 2009

2Copyright OASIS 2009. All Rights Reserved. Page 1 of 21
41Status:
42 This document was last revised or approved by the OASIS SOA for Telecom (SOA-Tel) TC on the
43 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 Committees email list. Others should send comments to the Technical Committee by using the
47 Send A Comment button on the Technical Committees web page at http://www.oasis-
48 open.org/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/.

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 be
66followed) 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

101Table of Contents
1021 Introduction......................................................................................................................................... 6
103 1.1 Terminology....................................................................................................................................... 6
104 1.2 Normative References....................................................................................................................... 6
105 1.3 Non-Normative References............................................................................................................... 6
1062 Web Services Related Gaps............................................................................................................... 8
107 2.1 Assumed standards Landscape and Architecture..............................................................................8
108 2.2 Transaction Endpoints Specification.................................................................................................. 9
109 2.2.1 Scenario..................................................................................................................................... 9
110 2.2.2 Use Case................................................................................................................................... 9
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................................................................................................................. 13
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 Other Stacks..................................................................................................................................... 16
124# Conformance.......................................................................................................................................... 17
125A. Acknowledgements........................................................................................................................... 18
126B. Non-Normative Text.......................................................................................................................... 19
127C. Revision History................................................................................................................................ 20
1281 Introduction......................................................................................................................................... 5
129 1.1 Terminology....................................................................................................................................... 5
130 1.2 Normative References....................................................................................................................... 5
131 1.3 Non-Normative References............................................................................................................... 5
1322 Web Services Related Gaps............................................................................................................... 6
133 2.1 Assumed standards Landscape and Architecture..............................................................................6
134 2.2 Transaction Endpoints Specification.................................................................................................. 7
135 2.2.1 Scenario..................................................................................................................................... 7
136 2.2.2 Use Case................................................................................................................................... 7
137 2.2.3 Possible Gaps............................................................................................................................ 8
138 2.2.4 Editor Note: This is a place holder for possible Workaround......................................................9
139 2.3 Service Non Functional Properties (NFP)........................................................................................ 10
140 2.4 Service Discovery............................................................................................................................ 10
141 2.5 Service Level Agreements (SLA)..................................................................................................... 10
142 2.5.1 Composed services and their part in Web Services Service Level Agreements (WSLA) .........10
143 2.6 Telecom WS SOA Profile................................................................................................................. 11

144 2.7 Service Orchestration (BPEL).......................................................................................................... 11
1453 Web 2.0 and Telco 2.0....................................................................................................................... 12
146 3.1 Gaps Related to Parlay-X................................................................................................................ 12
1474 Other Stacks..................................................................................................................................... 13
148# Conformance.......................................................................................................................................... 14
149A. Acknowledgements........................................................................................................................... 15
150B. Non-Normative Text.......................................................................................................................... 16
151C. Revision History................................................................................................................................ 17
152
153

1541 Introduction
155[All text is normative unless otherwise labeled]
156TBD
1571.1 Terminology
158The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD
159NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described
160in [RFC2119].
1611.2 Normative References

162 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels,
163 http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997.
[WS-I Basic Profile]
164 WS-I Basic Profile Version 1.0: "Final Material", available at http://www.ws-
165 i.org/Profiles/BasicProfile-1.0-2004-04-16.html.
166
167 [WSDL 1.1] W3C Note (15 March 2001): "Web Services Description Language (WSDL) 1.1".
168 http://www.w3.org/TR/2001/NOTE-wsdl-20010315.
169 [Reference] [Full reference citation]
1701.3 Non-Normative References

171 [Reference] [Full reference citation]
172
173
174
175
NOTE: The proper format for a citation to an OASIS Technical Committees 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
177
178

1792 Web Services Related Gaps
180This section provides example uses cases that cover gaps that are related to web services standards as
181they apply to telecom services.
182
1832.1 Assumed standards Landscape and Architecture

184The figure in this section reflects the current understanding on the relationship between various
185standardization bodies to the work of this TC.
186
187
188
Telecom
Telecom Management
Management SOA
SOA Profile
Profile (SDF)
(SDF)
Market-driven
Mobile
Mobile Device
Device SOA
SOA Profile
Profile interoperability
profiles
Telecom
Telecom SOA
SOA Profile
Profile (Gap?)
(Gap?)
NGN
NGN SOA
SOA Framework
Framework Framework
Bod
Model
Model Driven
Driven Event
Event Driven
Driven y
Management
Architecture IEEE
Identity Management
Architecture
Architecture Architecture
Architecture
OASIS
Mgmt
Non-functional
Cycle Mgmt
Non-functional
SID
SID Models
OMG
properties
properties
TMF

Life Cycle
Securi
Securi
ty

BEPL
BEPL WS-* OMA
Identity
ty
Policy
Policy
Abstraction / ITU-T
Life
Parlay
Parlay -- X
X IT?
IT? Transport
Transport
Enablers
Gap
189
190
191Editor Note:
192Need to develop a very high level architecture that illustrates how the uses cases will work. The
193architecture should include the role of mediation (proxies for thin and fat clients, mobility and
194other scenarios)
195
196
197
198

1992.2 Transaction Endpoints Specification
2002.2.1 Scenario
201The issue presented in this contribution derives from a concrete case, implemented within Telecom Italias
202SOA Middleware.
203Telecom Italia is in the process of deploying a SOA infrastructure, of which some of the constituting
204elements are an ESB (Enterprise Service Bus), a BPM (Business Process Manager), some Service
205Consumers (systems or applications), some Service Providers (systems or applications).
206An aspect to be considered is that to satisfy performance criteria it has been decided that the ESB must
207be intrinsically stateless (i.e. it must not store any persistence information on destination of incoming
208service requests).
209Moreover, the number of ESBs can vary, i.e. there can be interconnetted trunks of different vendors
210ESBs.
2112.2.2 Use Case

212The following Use Case describes Telecom Italias technical problem. To improve readability the depicted
213use case presents only one instance of ESB, but the possible solution to the problem must satisfy also
214the cases of multiple instances of ESB.
215A Service Consumer (C1 or C2) invokes a Service, implemented as a Web Service (Web Service A).
216Such WSA is achieved as an itinerary with the composition of more elementary services, provided by
217Provider P1 and Provider P2.
218The ESB provides intermediary services for final exposition, enrichment and Data reconciliation and
219routing.
220 Case A: C1 is the originator and final receiver.
221 Case B: C2 is the originator and final receiver.
222
223

224
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
225 Figure 1 Scenario Implementation

226

227
228
229
230 Figure 2 Scenario Flow
231
232Use Case Steps:
233Case A
234 C1 invokes WSA, exposed by ESB.
235 WSA is executed with the internal composition (transparent to C1) and with intermediary services
236 provided by the ESB.
237 At the end of the internal interactions, the ESB forwards the response to C1.
238Case B
239 C2 invokes WSA, exposed by ESB.
240 WSA is executed with the internal composition (transparent to C2) and with intermediary services
241 provided by the ESB.
242 At the end of the internal interactions, the ESB forwards the response to C2.
2432.2.3 Possible Gaps

244To Telecom Italias knowledge and expertise, in presence of an ESB offering intermediary services, there
245is no formal way to specify the endpoint (e.g. C1 or C2) to which the final result of a process/transaction"
246(i.e. asynch response) result should be sent.
247

2482.2.4 Editor Note: This is a place holder for possible Workaround
249This issue could be solved with the following workaround solution, which in any case is not mandatory
250but exploits some optional features of WS-Addressing.
251Note:
252This proposal does not require any persistence on any intermediary and is fully compliant with WS-
253Addressing specification.
254
255Telecom Italia asks if, apart from the proposed workaround, there is another standard reference solution
256for the highlighted problem.
257
258Should there be no other solution apart from the proposed workaround; TI proposes to extend the WS-
259Addressing specification in order that the Message Properties include a new tag (provisionally
260named Final Destination) to specify the process/transaction result.
261Moreover the proposal is to make the utilization of this new tag as Mandatory whenever it is
262necessary to specify a final destination, i.e. in presence of a non-direct requester-consumer
263situation.
264
265
266Proposed Workaround:
267
268
269CASE A:
270
271 1. C1 invokes WS-A and specifies in the replyTo section of the WS-Addressing header the EPR
272 (Endpoint Reference) where it wants to receive the async response (C1).
273 (Example: http://service1.sc.local/response).
274
275 2. The ESB invokes WSB and specifies in the replyTo section of the WS-Addressing header the EPR
276 (Endpoint Reference) where it wants to receive the async response (Example:
277 http://service1.esb.local/response). By doing so it takes the replyTo section received by C1 and
278 embeds it in the referenceParameters section of replyTo. P1 is obliged by WS-Addressing
279 specification to return the referenceParameters in the To section when sending the async response.
280
281 3. P1 returns the async response to the replyTo address (Example:
282 http://service1.esb.local/response) specified by the ESB, together with the referenceParameters
283 section.
284
285 4. The ESB invokes WSC and specifies in the replyTo section of the WS-Addressing header the EPR
286 (Endpoint Reference) where it wants to receive the async response (Example:
287 http://service2.esb.local/response). By doing so it takes the referenceParameters section received
288 by WSB and embeds it in the replyTo section. P2 is obliged by WS-Addressing specification to
289 return the referenceParameters in the To section when sending the async response.
290
291 5. P2 returns the async response to the ESB replyTo address (Example:
292 http://service2.esb.local/response) specified by the ESB, which includes the referenceParameters
293 section.
294
295 6. The ESB gets the replyTo info, embedded in the referenceParameters received from P2, to
296 address the async response to C1.
297
298CASE B:
299Same as Case 1 with C2 originator and final destination.
300
301
3022.3 Service Non Functional Properties (NFP)

303
304Editor Note: This section is a place holder for Non Functional Properties. Contributions are encouraged.
305
3062.4 Service Discovery

307Editor Note: This section is a place holder for Discovery. Contributions are encouraged.
308 To discover available services and may be other devices in a network
309 Many techniques for service discovery
310 UDDI for Web services
311 Jini for Java objects
312 Simple Service Discovery Protocol (SSDP) used for Universal plug-and-play (UPnP)
313 DNS Service Discovery (DNS-SD)
314 Bluetooth Service Discovery Protocol (SDP)
315 Service Location Protocol (SLP)
316 How about HTTP Discovery?
3172.5 Service Level Agreements (SLA)

318Editor Note: This is a place Holder for material on SLA
319 Need to differentiate between service SLA and measuring service SLA compliance
320 Services may need to have a service compliance interface (testing to verify claims against SLA)
321 Relationship to service composition
322 W-SLA, service testting and monitoring
323 Relation to Non-functional properties
3242.5.1 Composed services and their part in Web Services Service Level
325 Agreements (WSLA)
326 Need a taxonomy or ontology of service behaviors
327 Need an approach to calculating behaviors of composed services
328 o Service failure is one of many identified behaviors
329
3302.6 Telecom WS SOA Profile

331Editor Note: This is a place Holder for material on Telecom SOA Profile. The main issue here is to
332identify the minimum number of WS specifications that need to be supported by Telecom
333Providers and establishing an interoperability profile to implement them in a composed fashion.
334Contributions are encouraged. Current specifications include:
335 WS Addressing
336 WS reliable messaging
337 WS security
338 SOAP over JMS
339 General improvement of specs with guidelines to avoid proliferation of solutions
340 WS-Policy
341
3422.7 Service Orchestration (BPEL)

343Editor Note: This is a place Holder for material on BPEL. Use cases are encouraged.
344
345 BPEL originally designed for IT application space
346 Purpose: integrate long running inter-machine business processes
347 Evolution to include BPEL4People to provide human time frame interactions rather than machine
348 speed
349 Current benchmarks show 80 TPS on dual Xeon cpu
350 Baseline HLR runs 5500 TPS (Telecom One TM1 benchmark)
351 Basic SIP B2BUA is 10+ network transactions
352There is a need for speed. Do we need a real time BPEL for Telecom.

3533 Web 2.0 and Telco 2.0
354Editor Note: A possible approach for this section is to take a deep dive into APIs such as Parlay-X,
355JAIN and CCTA and provide analysis of why these approaches have not been as widely accepted
356by the developer community.
357
3583.1 Gaps Related to Parlay-X

359Editor Note: The purpose of this section is to document the Gaps that Parlay-X encountered
360during their development. Defining new Parlay-X services or modifying current ones is out of
361scope. In this regard, contributions are encouraged to illustrate the workaround techniques that
362Parlay-X had to do to enable WS passed Telecom services.
363Contributions are encouraged.
364The definition of new Parlay-X APIs is out of scope for this OASIS working group.
365If during the use case analysis process where Parlay-X APIs are used as part of this work, some
366corrective content or even a new API function is discovered then the current OMA ARC processes
367for submitting corrective content to existing Parlay-X APIs or creating new interfaces should be
368used by member companies.
369
3703.1.1 Parlay-X Part 1 Common

371The Parlay-X API Part 1 is related to the definition of common types and other constructs used by the
372other Parlay-X APIs. The web services messages are conformant to WS-I Basic Profile for the SOAP,
373XML and HTTP components. The web service security model uses the WS-I Basic Profile for HTTP over
374TLS.
375The WSDL interfaces are defined using the WSDL 1.1 specifications.
376

3774 Mobile
378Editor Note: This is a place Holder for material on mobility aspects of the telecom SOA working group.
379
380

3815 Other Stacks
382
383
384
385
386
387
388
389
390

391# Conformance
392The last numbered section in the specification must be the Conformance section. Conformance
393Statements/Clauses go here.

394A. Acknowledgements
395The following individuals have participated in the creation of this specification and are gratefully
396acknowledged:
397Participants:
398 [Participant Name, Affiliation | Individual Member]
399 [Participant Name, Affiliation | Individual Member]
400

401B. Non-Normative Text

402C. Revision History
403
Revision Date Editor Changes Made
1.0 Jan 20, 2009 Abbie Barbir Started all sections in the document
404
405


Telecom SOA Use Case and Gap v3

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Telecom SOA Use Case and Gap v3

Uploaded by

Copyright:

Available Formats

1

2Telecom SOA Use Cases and Gap

4OASIS TC Committee Draft

1[Document Identifier] 20 January 2009

4[Document Identifier] 20 January 2009

56Copyright OASIS 2009. All Rights Reserved.

7[Document Identifier] 20 January 2009

10[Document Identifier] 20 January 2009

13[Document Identifier] 20 January 2009

1611.2 Normative References

1701.3 Non-Normative References

19[Document Identifier] 20 January 2009

1832.1 Assumed standards Landscape and Architecture

22[Document Identifier] 20 January 2009

2112.2.2 Use Case

25[Document Identifier] 20 January 2009

225 Figure 1 Scenario Implementation

28[Document Identifier] 20 January 2009

2432.2.3 Possible Gaps

31[Document Identifier] 20 January 2009

3022.3 Service Non Functional Properties (NFP)

3062.4 Service Discovery

3172.5 Service Level Agreements (SLA)

3302.6 Telecom WS SOA Profile

3422.7 Service Orchestration (BPEL)

40[Document Identifier] 20 January 2009

3583.1 Gaps Related to Parlay-X

3703.1.1 Parlay-X Part 1 Common

43[Document Identifier] 20 January 2009

46[Document Identifier] 20 January 2009

49[Document Identifier] 20 January 2009

52[Document Identifier] 20 January 2009

55[Document Identifier] 20 January 2009

58[Document Identifier] 20 January 2009

61[Document Identifier] 20 January 2009

You might also like