© 2008 IBM Corporation Presentation URLs from Resource URLs Last updated Sep. 22, 2008

© 2008 IBM Corporation 2 UI Client’s Problem Clients obtain URLs to JTS data resources –Directly –Embedded as links in other data resources Clients know how to work with and present some data resources –E.g., work item GUI editor can read, manipulate, and present work items Clients have little/no knowledge of other data resources –E.g., work item GUI editor does not know anything about test cases Data resources are linked to other data resources –E.g., a work item resource is linked to a test case UI clients need ways to provide users with smooth navigation between presentations of linked resources –Web UI presentations –Desktop presentations –… Most data resources are not directly presentable to users –Represented as XML documents UI clients must be able to discover how to present other data resource –Discover suitable presentation given URL of a data resource Be able to presentation coming from resource’s home tool –Choose from what’s available –Bring up chosen presentation of data resource

© 2008 IBM Corporation 3 Two sides of coin Outside – UI clients interact with JTS to discover and bring up presentations –As long as client gets a good answer, client doesn’t care how answer is computed Inside - How does JTS come up with answers? –What are the internal mechanisms? –Matters might Both are needed Largely separable Outside is more straightforward

© 2008 IBM Corporation 4 Straw man proposal in 2 parts 1.Provider Discovery Service –General service used for various purposes –UI clients use to find presentations for a data resource –Addresses client’s needs - outside 2.Provider Registry –General registry used internally to associate information providers with a data resource –UI presentation providers associate presentations –Addresses implementation concerns – inside

© 2008 IBM Corporation 5 What do UI clients know? UI client has URL in hand UI client is interacting with a particular JTS Presumptively URL is of data resource on that JTS UI clients need not know –Whether data resource actually exists –Whether data resources is actually on a JTS –Whether data resources is actually on that particular JTS –What type of presentation are of interest (although it helps) –Content type of data resource (presumptive or actual) –Process governing the data resource That is to say – NOT MUCH

© 2008 IBM Corporation 6 What do UI clients need? UI client has URL of data resource in hand Wants to show the referenced data resource to their user…somehow Appeals to a particular JTS for recommend presentation(s) of certain type(s) JTS will answer with options –List of available presentations for data resource Which types of presentation are available Presentation provider label for displaying choice to user Information on how to call up that presentation Preferred presentation –Explain in cases where it cannot help Data resource has no known presentations Data resource is on some other JTS Data resource is not on a JTS Temporarily unable to decide (e.g., unable to “sniff” data resource) UI client chooses from available presentations –Present options to user and let them pick UI client calls up the chosen presentation for data resource –Could involve launching desktop app –Could involve directing web browser to different web page –Could involve …

© 2008 IBM Corporation 7 Straw man proposal part 1 – Provider Discovery Service Provider Discovery Service –REST-based API –Part of JFS –Useful for finding presentations (and likely much, much more) Globally available –One per JTS –Assume base URL discoverable via other JFS discovery service UI client –Discovers base URL of Provider Discovery Service –Constructs request URL by filling in URL of data resource in question 1 or more entry type IDs for presentations of interest to client: jazz.webui, jazz.richui –Make GET request –Response is list of recommended (or all available) presentations for data resource Presentation type - e.g., jazz.richui Presentation provider label - e.g., “RTC Client” Preferred: yes Presentation URL - e.g., “rtc:rtc1/u” –Chooses from available presentations –Uses presentation URL to bring up presentation

© 2008 IBM Corporation 8 Client accessing rich UI presentation RRC Client jf1 – JFSrtc1 – RTC server RTC Client GET /find-providers?types=jazz.webui,jazz.richui&url=//rtc1/u i.e., Find all presentations for //rtc1/u GET rtc:rtc1/u ( jazz.webui, “Build Web UI”, N, ) ( jazz.richui, “RTC Client”, Y, rtc:rtc1/u ) Retrieve build result /u 200 OK Build result data ? Shows data in Build Results view 5 Launches desktop app User chooses rich presentation 4

© 2008 IBM Corporation 9 Client accessing web UI presentation RRC Client jf1 – JFSrtc1 – RTC server b1 – Presentation provider GET /find-providers?types=jazz.webui,jazz.richui&url=//rtc1/u i.e., Find all presentations for //rtc1/u GET /show-build?url=//rtc1/u ( jazz.webui, “Build Web UI”, N, ) ( jazz.richui, “RTC Client”, Y, rtc:rtc1/u ) GET /u i.e., computed page presenting build result data i.e., raw build result data ? 3 User chooses web presentation 7 Shows data in browser widget

© 2008 IBM Corporation 10 Straw man proposal part 2 - Provider Registry Assume that data resource and services are fundamental –REST APIs are for ALL clients – not just for ones with UIs Presentations depend on data resources –Not the other way around –Not all data resources will even have presentations –Additional presentations can be added as easily as the first NEEDED: mechanism for associating presentations with data resources Presentations are typically geared for resource with a particular content type –E.g., RRC Client can present requirement resources Presentations are sometime geared for resources with a particular content type living in a particular repository –E.g., DOORS client presents requirement resources in a DOORS repository Express with a set of declarative selection rules –“The DOORS Client can provide a rich UI type presentation for data resources with content type X-application/oslcrequirement+xml The corresponding presentation URL is computed from the data resource URL by …” JTS maintain global set of rules in provider registry

© 2008 IBM Corporation 11 Provider registry Provider registry consists of selection rules, including ones for presentations Entry typeProvider label PrefferedPreffered Content type patternURL transformation function (input pattern -> output template) jazz.webuiJFS Web Client*X-app/oslcuser+xml -> jazz.richuiRTC Client*X-app/oslcworkitem+xml;tool=rtc -> rtc:{host}/{path} jazz.richuiRTC Client*X-app/oslcbuild+xml;tool=rtc -> rtc:{host}/{path} jazz.webuiRTC Web Client*X-app/oslcworkitem+xml;tool=rtc -> jazz.webuiBuildForge Web Client X-app/oslcbuild+xml -> jazz.webuiRQM Web ClientX-app/oslctest+xml {url} -> jazz.richuiDOORS Client*X-app/oslcrequirement+xml;tool=doors doors:{host}/{path} jazz.richuiRRC Client*X-app/oslcrequirement+xml;tool=rrc -> rrc:{host}/{path} jazz.richuiRRC ClientX-app/oslcrequirement+xml -> rrc:{host}/{path}

© 2008 IBM Corporation 12 How Provider Discovery Service is implemented 1.Input from client –Data resource URL –List of entry types of interest –Best vs All 2.Use HEAD to “sniff” data resource URL –http headers reveal Content type of resource JTS server that hosts data resource (i.e., basis of JFS Discovery) 3.Determine all applicable selection rules in provider registry –Match Entry Type :: entry types of interest (input) AND match Content Type Pattern :: data resource content type (step 2) 4.Compute one tuple for each applicable rule –(Entry Type, Provider Label, Preferred, x) where x = f(data resource URL) and f is given by URL Transformation Function 5.Sort results –Within entry type, sort by preferred, more-to-less specific –Choose best result per entry type (unless “all” specified) 6.Return to client –List of tuples

© 2008 IBM Corporation 13 Client accessing web UI presentation RRC Client jf1 – JFSrtc1 – RTC server b1 – Presentation provider GET /find-providers?types=jazz.webui,jazz.richui&url=//rtc1/u i.e., Find all presentations for //rtc1/u GET /show-build?url=//rtc1/u ( jazz.webui, “Build Web UI”, N, ) ( jazz.richui, “RTC Client”,Y, rtc:rtc1/u ) GET /u i.e., computed page presenting build result data i.e., raw build result data 1 6 3,4,5 HEAD //rtc1/u Content-Type: X-app/oslcbuild+xml X-JTS: … Other useful headers? 2 User chooses web presentation Shows data in browser widget

© 2008 IBM Corporation 14 Where does info in registry come from? Registry is exposed though system-defined resource –Discoverable through other JFS discovery services Representation is a single XML-based data resource –Selection rules are XML subelements Selection rules –Largely contributed by JTS extensions at their install time –Tweakable by system administrator Requires high administrative permissions to update

© 2008 IBM Corporation 15 URL transformation functions URL-to-string transformations are described by input pattern and output tempate –E.g., function -> input output Simplest possible things that could possibly work –Simple –Flexible –Declarative – describing novel xmf does not require adding code to server Note: Interesting information in data resource URL must be encoded (somehow) in presentation URL –Presentation provider must be able to reconstruct data resource URL given only presentation resource URL –If it cannot, presentation provider would need more expensive query to locate data resource URL

© 2008 IBM Corporation 16 Design Assumptions and Issues Information on how to call up rich and web presentations can be expressed conveniently as URL –HTTP for standard web presentations E.g., –Non-standard URL schemes for launching desktop applications (like “mailto” scheme) E.g., rtc:rtc1.eg.com/u –Is this reasonable? Tool-specific tagging of resource content type –Assuming that tools will tag their resources’ content type with tool ID –E.g., needed to ensure a requirement in a DOORS repository will be shown with a DOORS presentation Generalization –Clients asks for presentations for particular data resource – not resource type –User chooses from available presentations and indicates “Remember my choice” –Client remembers choice (client side) –Uses remember choices on subsequent occasions –Can client generalize to “similar” data resources?

© 2008 IBM Corporation 17 Mini critique Some shortcomings of straw man Monolithic registry resource –Does not scale to large numbers of rules, frequent edits, or edits by less trusted administrators Inability to select presentation based on anything buried inside representation of resource –Cannot choose a provider based on a requirements resource containing elements in a particular XML namespace Inability to select presentation based on project/process –Cannot choose a provider only for resources in a particular project/process –Potential challenge if we want to allow a customer to dictate a preferred presentation within a particular project/process

© 2008 IBM Corporation 18 Also considered HTTP content negotiation (Accept headers) –Only covers alternative representations of data resource –Cannot handle case where client must launch desktop tool Consult provider (or proxy) to help determine selection rule applicability –Each discovery request requires O(n) roundtrips where n is # of providers –Effort increases as # providers increases –Not scalable Consult provider (or proxy) to help compute URL tranformation function –Each discovery request requires O(k) roundtrips where k is # of applicable providers –Effort increases as # applicable providers increases –Not scalable