Issue 4071: Section 5.5 Service Discovery segment (tsas-ftf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: TSAS Section 5 - [Optional] Service Access Segments Most of this section is not addressed by Parlay 2.1, with the exception of the Service Discovery segment… Section 5.5 Service Discovery segment · TSAS permits the retailer (Parlay framework) to invoke discovery functions on the service provider (Parlay service supplier). Only the opposite is supported in Parlay: i.e. the service supplier may invoke discovery functions on the framework. · TSAS does not appear to support retrieval of, or selection by, Service Type. Specifically TSAS does not support the Parlay listServiceTypes and describeServiceType methods, or the Service Type parameter in the Parlay discoverService method. · The TSAS get_service_info method has no close equivalent in Parlay. · 5.5.1 ServiceDiscovery Interface, discover_services: The desired_properties parameter includes more filtering capabilities (use of Match & Which syntax) than the equivalent parameter in the Parlay discoverService method. · 5.5.1 ServiceDiscovery Interface, discover_services: The return parameter (services) is a superset of the information returned by the corresponding parameter of the Parlay method; i.e. the latter does not return a service name attribute for each "discovered" service. Resolution: Revised Text: Actions taken: November 15, 2000: received issue Discussion: End of Annotations:===== TSAS Section 5 - [Optional] Service Access Segments Most of this section is not addressed by Parlay 2.1, with the exception of the Service Discovery segment Section 5.5 Service Discovery segment 7 TSAS permits the retailer (Parlay framework) to invoke discovery functions on the service provider (Parlay service supplier). Only the opposite is supported in Parlay: i.e. the service supplier may invoke discovery functions on the framework. 7 TSAS does not appear to support retrieval of, or selection by, Service Type. Specifically TSAS does not support the Parlay listServiceTypes and describeServiceType methods, or the Service Type parameter in the Parlay discoverService method. 7 The TSAS get_service_info method has no close equivalent in Parlay. 7 5.5.1 ServiceDiscovery Interface, discover_services: The desired_properties parameter includes more filtering capabilities (use of Match & Which syntax) than the equivalent parameter in the Parlay discoverService method. 7 5.5.1 ServiceDiscovery Interface, discover_services: The return parameter (services) is a superset of the information returned by the corresponding parameter of the Parlay method; i.e. the latter does not return a service name attribute for each "discovered" service. Date: Tue, 03 Jul 2001 11:20:26 +0200 From: Linda Strick X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: tsas-ftf@omg.org Subject: proposal for issue 4071 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-UIDL: +8Sd9$<~!!";:e9!F7e9 Proposal: close with no changes Discussion this is not really an issue for TSAS but demonstrates the differences between PARLA and TSAS. Furthermore, TSAS made this as an optional segment to try to align the smallest functionality which is possible, which have been tried in the core segment. TSAS is addressing the end-user and the service provider domain. Therefore, more information is needed to provide the end-user with the necessary information, that is also that the TSAS provider can offer a bunch of own and with other providers negotiated services. Linda Date: Tue, 10 Jul 2001 18:39:10 +0200 From: "Marcel J. Mampaey" Organization: Alcatel X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Linda Strick CC: tsas-ftf@omg.org Subject: Re: proposal for issue 4071 References: <3B418E5A.AE6288F1@fokus.gmd.de> Content-Type: multipart/mixed; boundary="------------7670C6B95DAAE935413E744E" X-UIDL: b%nd9Yb-e9bO0e9;@Ee9 I agree to close issue 4071 with no change. We should remember that TSAS is about the end-user while Parlay is about the enterprise domain such that these differences are normal, not a mistake, the specs are complementary. As Linda Strick indicates it is the same situation with other issues that should also be closed with no change for the same reason, so I support to close with no change following issues: 4072 and 4092. Marcel Mampaey Linda Strick wrote: > > Proposal: close with no changes > > Discussion > > this is not really an issue for TSAS but demonstrates the differences > between PARLA and TSAS. Furthermore, TSAS made this as an optional > segment to try to align the smallest functionality which is possible, > which have been tried in the core segment. > > TSAS is addressing the end-user and the service provider domain. > Therefore, more information is needed to provide the end-user with the > necessary information, that is also that the TSAS provider can offer a > bunch of own and with other providers negotiated services. > > Linda [] Marcel.Mampaey4.vcf