Hi Andy I should have stated '2 or more calls'.
A separate call is required for every 'linked' piece of information. If the linked data is coming from the same repository as the originating data then the optimal approach would be for the server to aggregate the linked data and return everything in a single XML. There is a performance trade-off here of course. For large returned datasets that aggregation could be fairly processor intensive for the server machine, depending on a number of factors, but will generally provide a significant net overall performance benefit to the reporting consumer. Some data providers do not do this, and of course this is not at all possible when the linked data is coming from another source. In both of these cases a separate query is required for every linked data item; so if each of the 500 returned requirements in ReqPro were linked to 3 test cases in RQM then 1500 additional queries would need to be executed to fetch all the required data (assuming each of the links were to unique test cases - in reality that may not be the case and if so caching would help reduce the number of queries required) There is also a scenario that poses an even greater challenge, and that is when the linked data is not provided as a URL, but instead as an ID, and the provider doesnt support field filtering capability in its REST interface. In that case, for every link from every requirement, the reporting consumer is forced to fetch a potentially large dataset, and then throw away everything not matching the linked ID. /Ben ----------------------------------------------------------------------------- Benjamin Williams Senior Product Manager - Rational Publishing Engine Email: [email protected] Tel: +44 20 8818 4360 Cell: +44 7710 637 067 IBM Extension: 364360 IBM ITN: 37364360 ----------------------------------------------------------------------------- From: Andrew J Berner <[email protected]> To: [email protected] Date: 02/09/2009 17:08 Subject: Re: [OSLC] Community Digest, Vol 9, Issue 2 Sent by: [email protected] Ben, What would the second call be? Suppose the first call was finer grained, say, all requirements in a module with High priority. Suppose the first call returned 500 requirements, and we want the test cases associated just with those. What would the call be, and why wouldn't I have just made that call in the first place? (unless you're thinking of concatenating the URL's of the individual requirements as part of the query??) Andy Berner Lead Architect, ISV Technical Enablement and Strategy IBM Rational Business Development 972 561-6599 [email protected] Ready for IBM Rational software partner program - http://www.ibm.com/isv/rational/readyfor.html Community Digest, Vol 9, Issue 2 community-request to: community 09/02/2009 11:00 AM Sent by: [email protected] Please respond to community Send Community mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit http://open-services.net/mailman/listinfo/community_open-services.net or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of Community digest..." Today's Topics: 1. Re: Reporting Domain (Benjamin Williams) ---------------------------------------------------------------------- Message: 1 Date: Tue, 1 Sep 2009 17:53:30 +0100 From: Benjamin Williams <[email protected]> Subject: Re: [OSLC] Reporting Domain To: Arthur Ryman <[email protected]> Cc: [email protected], [email protected] Message-ID: <of19f8333b.240a07a6-on80257624.005b9931-80257624.005cc...@uk.ibm.com> Content-Type: text/plain; charset="us-ascii" Hi Arthur Its a terminology issue for sure. Many might associate links with traceability relationships, as opposed to logically nested data (what I believe is really being referred to here) e.g. When we want to retrieve all of the requirements within a DOORS module, that is logically nested data. Linked data might be test cases associated with each requirement. In the first case, we would expect to be able to retrieve all the required data for those requirements in a single call. In the second case we would expect to need 2 calls to retrieve all of the requirements and all of the test cases. /Ben ----------------------------------------------------------------------------- Benjamin Williams Senior Product Manager - Rational Publishing Engine Email: [email protected] Tel: +44 20 8818 4360 Cell: +44 7710 637 067 IBM Extension: 364360 IBM ITN: 37364360 ----------------------------------------------------------------------------- From: Arthur Ryman <[email protected]> To: Benjamin Williams/UK/IBM@IBMGB Cc: [email protected], [email protected] Date: 01/09/2009 14:09 Subject: Re: [OSLC] Reporting Domain Ben, The intended meaning was to include properties from linked data. I don't see the ambiguity. The goal is to avoid multiple GET calls. Arthur Ryman, IBM DE Chief Architect, Rational Project and Portfolio Management Office: 905-413-3077, Cell: 416-939-5063 Assistant: Nancy Barnes, 905-413-4182 Benjamin Williams <[email protected]> Sent by: [email protected] 08/12/2009 04:28 PM To [email protected] cc Subject [OSLC] Reporting Domain Ref: http://open-services.net/bin/view/Main/ReportingHome One of the key requirements for a reporting consumer is what is being referred to as inlining. This was formerly named 'Self Contained XML' inlining - linked data should be inlined in the response to reduce the number of requests I believe that this description should be modified to avoid ambiguity and misunderstanding. I think most people will understand that definition as meaning the data from linked resources rather than its intended meaning of a full set of self contained data being returned for the initial query (vs the common OSLC model of atomic transactions) I suggest modifying this definition as below: inlining - all queried data should be returned inline in the response with no need for further HTTP GET requests Regards /Ben ----------------------------------------------------------------------------- Benjamin Williams Senior Product Manager - Rational Publishing Engine Email: [email protected] Tel: +44 20 8818 4360 Cell: +44 7710 637 067 IBM Extension: 364360 IBM ITN: 37364360 ----------------------------------------------------------------------------- Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU _______________________________________________ Community mailing list [email protected] http://open-services.net/mailman/listinfo/community_open-services.net Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: < http://open-services.net/pipermail/community_open-services.net/attachments/20090901/976a1253/attachment-0001.html > ------------------------------ _______________________________________________ Community mailing list [email protected] http://open-services.net/mailman/listinfo/community_open-services.net End of Community Digest, Vol 9, Issue 2 *************************************** _______________________________________________ Community mailing list [email protected] http://open-services.net/mailman/listinfo/community_open-services.net Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
