1 / 6

Need for “Discovery”

Need for “Discovery”. Different product servers (RQM, RTC, RRC, …) working together Each must share certain info known uniquely to it E.g., available presentations for its resource types Each must discover info known to others E.g., available presentations for other resource types

giolla
Download Presentation

Need for “Discovery”

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Need for “Discovery” • Different product servers (RQM, RTC, RRC, …) working together • Each must share certain info known uniquely to it • E.g., available presentations for its resource types • Each must discover info known to others • E.g., available presentations for other resource types • Similar needs arising on several fronts for CALM 1.0 • Presentations, link type definitions, dashboard viewlets, content types, & more • Need to provide some JF mechanisms to address needs • Propose a central registry • Pick one of the product servers in environment to host • Each product server obtains info from same place • 1-stop shopping • Avoids product servers having to connect pairwise

  2. Presentation registry resource <?xml version="1.0"?> <selectionRules xmlns="http://jazz.net/jfs/presentation/1.0" > <selectionRule> <presentationType>web</presentationType> <providerLabel>RQM Web Client</providerLabel> <mediaTypePattern> application/oslctest+xml </mediaTypePattern> <urlTransform> ... </urlTransform> </selectionRule> <selectionRule> <presentationType>web</presentationType> <providerLabel>RTC Web Client</providerLabel> <mediaTypePattern> application/oslcworkitem+xml </mediaTypePattern> <urlTransform> ... </urlTransform> </selectionRule> <selectionRule> <presentationType>desktop</presentationType> <providerLabel>RTC Eclipse Client</providerLabel> <mediaTypePattern> application/oslcworkitem+xml </mediaTypePattern> <urlTransform> ... </urlTransform> </selectionRule> <!-- others --> </selectionRules>

  3. Discovery resource <?xml version="1.0"?> <entries xmlns="http://jazz.net/jfs/discovery/1.0" > <entry key="http://jazz.net/names/registries/presentation"> http://example.com/jazz/jfs/presreg </entry> <entry key="http://jazz.net/names/registries/content-types"> http://example.com/jazz/jfs/ctreg </entry> <!-- others --> </entries> • Discovery resource is root registry • Contains only link to presentation registry resource, and other registries

  4. Implementation • Propose starting with simplest possible implementation • Read-only resources – supports GET only • Discovery resource • Presentation registry resource • Served from static content held in server configuration files • Manually editable by administrator • Each product server configured to point to same Discovery resource URL

  5. Open questions • Central registry = Single point of failure • Are we okay with this? • Security • Do we protect read access to registries? • Performance • Do we use HTTP caching proxy to reduce inter-server round-trips? • What is toleration for staleness? • Cost of reparsing XML documents?

  6. Open questions • Hot server re/configuration • Doable without taking product servers down? • NL story for display strings in registries • Registry info may serve users in many locales

More Related