1、 Access to Additional Content for ECMA TR/90, Dated: December 2005 (Click here to view the publication) This Page is not part of the original publication This page has been added by IHS as a convenience to the user in order to provide access to additional content as authorized by the Copyright holde
2、r of this document Click the link(s) below to access the content and use normal procedures for downloading or opening the files. ECMA TR/90 Extra Files Information contained in the above is the property of the Copyright holder and all Notice of Disclaimer & Limitation of Liability of the Copyright h
3、older apply. If you have any questions, or need technical assistance please contact IHS Support. IHS Additional Content Page ECMA TR/90 1stEdition / December 2005 Session Management, Event Notification, and Computing Function Services - Amendments for ECMA-348 Ecma International Rue du Rhne 114 CH-1
4、204 Geneva T/F: +41 22 849 6000/01 www.ecma-international.org PC TR-090.doc 08/12/2005 16:22:00 Session Management, Event Notification, and Computing Function Services - Amendments for ECMA-348 Technical Report ECMA TR/90 1stEdition / December 2005 . Introduction ECMA-348 provides a Web Service (WS)
5、 interface for CSTA using Web Service Description Language (WSDL) 1.1. CSTA (ECMA-269) requires applications to establish a session, which provides the context for all services and event transactions. ECMA-366 specifies Services for Web Service (WS) based session management. This Technical Report pr
6、oposes to amend ECMA-348 to use ECMA-366 for session management. WSDL 1.1 does not support concrete bindings for Notification operations. ECMA-348 uses these operations for CSTA events. This Technical Report proposes to amend ECMA-348 to establish an event channel and three event-sink types using WS
7、-Addressing and WS-Eventing. WSDL 1.1 does not define fault messages with one-way operation types that are needed for switching function services without a positive acknowledgement. ECMA-348 uses notification operations to convey the fault to those service requests. This Technical Report handles suc
8、h notifications in the same way as events. WSDL 1.1 does not support concrete bindings for Solicit-response operations. To allow proper implementation of the Computing Function Services, this Technical Report proposes to add a WSDL interface to ECMA-348 for the Computing Function in addition to the
9、Switching Function WSDL. When the WS-Addressing and WS-Eventing specifications have become stabilised, a next edition of ECMA-348 should be drafted. This Ecma Technical Report has been adopted by the General Assembly of December 2005. - i - Table of contents 1 Scope 3 2 References 3 3 Definitions 3
10、4 Acronyms and Abbreviations 3 5 Web Service Based Application Session Management 3 6 Event Sink Interface Definitions for ECMA-348 3 6.1 Loosely Coupled (generic) Event Sink Interface 3 6.2 Tightly Coupled (typed) Event Sink Interface 3 6.3 Combined (typed+generic) Event Sink Interface 3 6.4 Event
11、Sink Interface Design 3 7 WS Interface for Computing Function Services 3 8 Subscription Patterns for ECMA-348 3 8.1 Source-Sink Subscription Pattern 3 8.2 Sink-Source Subscription Pattern 3 8.3 Default Subscription 3 8.4 Life Cycle of Subscriptions 3 8.5 SOAP Subscription Messages 3 8.6 Examples of
12、SOAP Subscription Messages 3 - 1 - 1 Scope ECMA-348 2ndedition specifies a Web service interface for CSTA (ECMA-269) in Web Services Description Language (WSDL) version 1.1. It provides WSDL definitions for solicit-response and notification operations, referred in this Technical Report as outbound o
13、perations. These operations are used in ECMA-348 to convey events, some negative responses and computing function services. However, WSDL 1.1 does not specify concrete bindings for those outbound operations. In particular, WSDL 1.1 does not provide a mechanism for transmitting events, e.g. specifyin
14、g where the switching function should send CSTA events. This Technical Report proposes to amend ECMA-348 to establish an event channel and event-sink interface using WS-Addressing and WS-Eventing. This Technical Report proposes to add a Computing Function WSDL interface for proper support of the Com
15、puting Function Services of ECMA-348. CSTA also requires an application context before any services or events can be exchanged, to that end, this Technical Report proposes that the next edition of ECMA-348 uses WS-Session (ECMA-366) Services. This Technical Report describes amendments to the 2ndedit
16、ion of ECMA-348 to be effectuated when the WS-Addressing and WS-Eventing specifications become stabilised. 2 References ECMA-269 Services for Computer Supported Telecommunications Applications (CSTA) Phase III, 6th Edition (June 2004): http:/www.ecma-international.org/publications/standards/Ecma-269
17、.htm ECMA-323 XML Protocol for Computer Supported Telecommunication Applications (CSTA) Phase III, 3rd Edition (June 2004): http:/www.ecma-international.org/publications/standards/Ecma-323.htm ECMA-348 Web Services Description Language (WSDL) for CSTA Phase III, 2nd Edition (June 2004): http:/www.ec
18、ma-international.org/publications/standards/Ecma-348.htm ECMA-354 Application Session Services (June 2004): http:/www.ecma-international.org/publications/standards/Ecma-354.htm ECMA-366 WS-Session - Web Service Specification of Application Session Services (June 2005): http:/www.ecma-international.o
19、rg/publications/standards/Ecma-366.htm W3C-SOAP Simple Object Access Protocol (SOAP) 1.1, W3C Note 08 May 2000: http:/www.w3.org/TR/2000/NOTE-SOAP-20000508/ W3C-WSDL Web Services Description Language (WSDL) 1.1, W3C Note 15 March 2001: http:/www.w3.org/TR/wsdl WS-Eventing Web Service Eventing (WS-Ev
20、enting) from Oasis, August, 2004, by IBM, Microsoft, BEA, Computer Associates, TIBCO Software, and Sun Microsystems http:/ WS-Eventing-XSD WS-Eventing XSD: http:/schemas.xmlsoap.org/ws/2004/08/eventing WS-Eventing-WSDL WS-Eventing WSDL: http:/schemas.xmlsoap.org/ws/2004/08/eventing/eventing.wsdl WS-
21、Addressing Web Service Addressing (WS-Addressing) from W3C: WS-Addressing 1.0 Core: W3C Working Draft (February 15, 2005): http:/www.w3.org/TR/2005/WD-ws-addr-core-20050215 - 2 - WS-Addressing 1.0 SOAP Binding: W3C last call Working Draft (February 15, 2005): http:/www.w3.org/TR/2005/WD-ws-addr-soap
22、-20050215/ WS-Addressing 1.0 WSDL Binding: W3C Working Draft (February 15, 2005): http:/www.w3.org/TR/2005/WD-ws-addr-wsdl-20050215/ 3 Definitions Outbound operations - solicit-response and notification operations as defined in 6.4 of ECMA-348. 4 Acronyms and Abbreviations CF Computing Function as d
23、efined in ECMA-269 CF-SP Computing Function - Service Provider CF-SR Computing Function - Service Requester SF Switching Function as defined in ECMA-269 SF-SR Switching Function - Service Requester SF-SP Switching Function - Service Provider SP Service Provider as defined in ECMA-348 SR Service Requ
24、estor as defined in ECMA-348 WS Web Service as defined in W3C-WSDL WSDL Web Services Description Language as defined in W3C-WSDL 5 Web Service Based Application Session Management ECMA-269, on which ECMA-348 is based, requires a computing function (CF) to establish a session (i.e. application associ
25、ation) with the switching function (SF) before any CSTA message can be exchanged. ECMA-366 defines Web services for application session management. This Technical Report proposes to use these services in ECMA-348. 6 Event Sink Interface Definitions for ECMA-348 ECMA-348 describes four categories of
26、operations from the perspective of the switching function, in which it performs the role of service provider. The computing function receives three types of outbound operations from the service provider: 1. Event (Notification) 2. One-way fault notification with no acknowledgement (Notification) 3.
27、Request with acknowledgement (Solicit-response) This Technical Report proposes to add a computing function WSDL to ECMA-348, which leads to the situation that computing function and switching function can be both a service requester and a service provider (i.e. CF-SR, CF-SP, SF-SR, and SF-SP). The s
28、ervice requester has to specify the event sink to service provider in order to receive event notification. Two general approaches can be used to define these outbound operations for the service requester interface, namely a Loosely Coupled interface and a Tightly Coupled interface. - 3 - 6.1 Loosely
29、 Coupled (generic) Event Sink Interface Loosely coupled event sink Interfaces define operations for the categories of events they receive. The loosely coupled event sink interface is based on a “wrapped” message delivery model as defined in WS-Eventing. Events from each category are delivered to the
30、ir specific event sink interface inside category specific SOAP message. It has the advantage that the computing function interface is loosely-coupled with the switching function interface. It only needs to expose one operation per event category. The loosely coupled generic event sink defines one op
31、eration for all categories of events it receives. The loosely coupled generic event sink is defined as follows: 6.2 Tightly Coupled (typed) Event Sink Interface The tightly coupled interface defines operations that are exact reversal of the outbound operations as defined in ECMA-348. Each solicit-re
32、sponse operation in ECMA-348 is reversed into a request-response operation, and each notification operation is reversed into a one-way operation for CF service requester interface. Instead of providing a complete CF service requester side interface, we illustrate the tightly coupled event sink inter
33、face for two notifications: - 4 - This is a reversal of the following outbound operations defined in ECMA-348: Both the service requester and the service provider can perform message (type) validation. But any change to the service provider interface will require the corresponding change in the serv
34、ice requester interface. 6.3 Combined (typed+generic) Event Sink Interface The event sink can be a combination of typed and loosely coupled event interfaces. The switching function service provider should send the event notifications only to the matched typed event sink interface of the computing fu
35、nction, if existing. Otherwise, the event notification should be delivered to the loosely coupled event interface of the computing function. A combined (typed+generic) event sink interface is illustrated below in which the generic interface WSDL is imported to a typed interface WSDL. - 5 - 6.4 Event
36、 Sink Interface Design Both loosely coupled and tightly coupled event sink interfaces can be used for event notification. But they are based on two different architectures. In tightly coupled event sink interface, the event sink interface is a mirrored reversal of the service provider interface. Cha
37、nges made to the service provider interface can impact all its service requesters. On the other hand, loosely coupled event sink interface can allow the service requester and service provider to evolve separately as long as they maintain the loosely coupled event interface relation. A resource const
38、rained service requester may dispatch the service event notifications received to a more resource rich platform for processing, and it needs only a very light and stable event sink interface for the event notification to pass through. The tightly coupled event sink interface has the advantage of str
39、ict type checking by both the service provider and service requester. On the other hand, the loosely coupled event sink interface allows the service requester to do late binding with other distributed processing resources. Both tightly coupled and loosely coupled event interfaces can be applied, and
40、 in many cases, a combined (typed+generic) event sink interface is preferred. The tightly coupled event sink interface can be used for operations which are more stable and loosely coupled event sink interface can be used for operations which are more dynamic and subject to change. WS-Session Annex C
41、 specifies a default generic (loosely coupled) event sink interface for all subscribed events within the session, and the typed (tightly coupled) event interface as optional. Service providers should support the combined (typed+generic) event sink interface, and the service requester should specify
42、its event sink interface type declaratively to the service provider during the event subscription as defined in Clause 6. A use case of combined event sink interface is provided in WS-Session Annex C for ApplicationSessionTerminated service subscription, and the event sink interface type should be d
43、eclared in the event sink endpoint reference as specified in WS-Addressing. - 6 - 7 WS Interface for Computing Function Services ECMA-348 defines solicit-response operations for computing functions services such as Call Detail Report Services. WSDL 1.1 does not provide the concrete binding for these
44、 operations. In addition to the WSDL definition for the switching function in 2ndedition of ECMA-348, the computing function should also have its WSDL definition. Only those operations, which are modelled in ECMA-348 as solicit-response operations, are included in the computing function WSDL. The co
45、mputing function WSDL contains the operations, which are the reversal of the corresponding operations defined in the switching function WSDL. Reversal means that the solicit-response operation that contains an output element followed by an input element as defined in ECMA-348 must be reversed into a
46、n input element followed by an output element in the computing function WSDL. For instance, ECMA-348 defines CSTA-Call-Data-Recording-Services operation as follows: The corresponding CF operation is defined as follows, which is the reversal of the operation defined in the service provider WSDL inter
47、face of ECMA-348. - 7 - 8 Subscription Patterns for ECMA-348 CSTA switching functions can be viewed as hosting various event sources, such as WS-Session, CSTA monitors, and registrations. Event sources can be enabled using a CSTA Service Request, e.g. a MonitorStart Service Request creates a monitor
48、. Switching functions may notify computing functions of these events following subscription. The computing function may link each of these event sources to its event sink. WS-Eventing can be used to manage the many-to-many relationships between the Event sinks and sources through subscriptions as il
49、lustrated in Figure 1. Figure 1 - Subscription patterns for ECMA-348 The two subscription patterns for using CSTA with WS-Eventing, without requiring any modification to the XML Schemas of ECMA-348 or Application Session Services (WS-Session, ECMA-354) are: 1) Source-Sink: In this pattern, the computing function creates the CSTA sessions, monitors, and registrations using CSTA Service Requests before it subscribes to these entities one by one and it provides event sink for each subsc
