[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [uddi-spec] TN idea: link tags for UDDI
Thanks for your feedback. My comments inline below. Paul At 04:54 AM 2003-04-16, Daniel Feygin wrote: >I think it is important that we devise technical solutions to support >expanded applicability of UDDI and its accessibility (service delivery) >through various meaningful channels. Paul's proposed methods would result >in users' ability to neatly weave UDDI into semi-structured Web and business >documents that could be substantially broad in nature. I believe this would >be helpful, but I think industry acceptance is something that needs to be >addressed. Even a helpful TN would not do much good unless it is broadly >implemented. I am suggesting that publishing this as a TN would lead to broader implementation than if no TN is published. >In my view this TN risks being ignored, unless we identify and >promote sufficiently powerful value that would drive its adoption (say, >Microsoft embeds this functionality in IE, which instantly makes it a >simple-to-implement competitive parity feature for other browser makers). I don't see this as something that needs to be added to a browser. I am thinking of things like bookmarklets that you use or activate from within a browser, but may result in actions outside the browser. For example, bookmarklets for RSS can pass the embedded link to amphetadesk. Amphetadesk is outside the browser. Once amphetadesk adds the link to its set of RSS files, amphetadesk would then retrieve the RSS file. I am thinking of an extension of amphetadesk (or other RSS aggregator) that, instead of simply retrieving RSS files could send SOAP inquiries to the UDDI server. The query parameters could be set up separately; amphetadesk has a settings page, which might be a place to add a link to build the query (taxonomy drill down, write find_* to an XML file). >In case of its successful adoption it would positively contribute to UDDI - >and particularly UBR - adoption. In doing <link> for UDDI similar to the way it is used with RSS, I am hoping to piggyback on or leverage the success of RSS and blog technology. >In terms of implementation, I don't think SOAP API or WSIL are relevant in >this context, because UDDI's discoveryURL feature enables businessEntity >retrieval using HTTP GET, which is all that is needed. The use cases I see that would need the SOAP API are for runtime use of UDDI by application-to-application exchanges. They would just happen to use the machine-readable <link> within the XHTML homepage. Given a hostname and port, it is easy to retrieve the homepage. DNS SRV RRs can easily provide the hostname and port, but using DNS to provide a URI is less straightforward. TXT RRs can be used, but they are too general. PTR or NAPTR (DDDS) RRs are a possibility, but it seems a little easier to use SRV RRs. I was trying to provide a way to discover UDDI servers, or rather, avoid manual configuration of applications that consume web services (and use UDDI at runtime to discover them). If example.com has a homepage with a <link> to its businessEntity in UBR, I still don't know the URL for the UBR SOAP inquiry API. I perhaps could link (from the example.com homepage) to the businessEntity for the UDDI node, then look in its bindings for the inquiry accessPoint, such as, [4][5][6][7]. So the example.com homepage would contain <head> .... <link rel="alternate" type="application/uddi-biz+xml" title="uddi-node" href="http://uddi.ibm.com/ubr/uddiget?businessKey=1B51FFEA-9101-43D0-BAB9-4C5791E102B1" /> That is, title="uddi-node" would indicate that this bizEntity is for the UDDI node to which example.com publishes its own bizEntity. If example.com publishes to UBR and other private UDDI registries, its homepage could have multiple <link ... title="uddi-node" href=... /> So if I plug my laptop into a LAN, the following sequence would bootstrap me for consuming web services: 1. DCHP gives me my IP address and my-domain, and DNS servers, 2. DNS can give me an SRV RR for _http._tcp.<my-domain> 3. HTTP GET on a homepage for the host and port indicated in the SRV RR 4. Extract the <link> info to find the bizEntity for the UDDI Node (could be a private UDDI registry within my intranet), 5. HTTP GET the bizEntity, extract the accessPoint for the UDDI SOAP inquiry API 6. send SOAP requests to the UDDI node for things my app is configured to use (e.g., certain tModelBag), 7. Optionally, look in the UDDI node for other UDDI nodes, repeat from Step 5 8. If more than one matching binding, somehow pick one that is "best" 9. Start consuming the web services identified by the UDDI node Note on Step 7, a TN is needed to make it clear how to search UDDI for other UDDI servers. I discussed this recently [8]. [4] http://uddi.ibm.com/ubr/uddiget?businessKey=1B51FFEA-9101-43D0-BAB9-4C5791E102B1 [5] http://uddi.microsoft.com/discovery?businessKey=6c068bd0-21f8-40f0-9742-94e60e68d690 [6] http://uddi.sap.com/UDDI/discovery/businessEntity/02fb553a-5be9-47b7-a0d8-dc94a1709703 [7] http://www.uddi.ne.jp/ubr/uddiget?businessKey=4C8A7E90-B9F1-11D6-9C9F-000255762291 [8] http://www.oasis-open.org/archives/uddi-spec/200305/msg00040.html >Daniel > > > -----Original Message----- > > From: Paul Denning [mailto:pauld@mitre.org] > > Sent: Wednesday, April 09, 2003 8:58 PM > > To: uddi-spec@lists.oasis-open.org > > Subject: [uddi-spec] TN idea: link tags for UDDI > > > > > > Various machine-readable links are being included in web > > pages (especially > > blogs) to enable various discovery techniques. > > > > For example, RSS Auto-discovery provides a link to an RSS > > file. > > http://diveintomark.org/archives/2002/06/02/important_change_t > > o_the_link_tag.html > > > > The addition of such link tags are very simple and provide a > > low barrier to > > entry into a more discoverable infrastructure. Many large > > organizations > > are now providing RSS feeds, and many are using the RSS > > auto-discovery > > technique referenced above. > > > > The following technique is proposed for use in an XHTML > > homepage to locate > > UDDI servers. > > (UDDI TN material?) > > > > A <link> element is placed within the <head> element as follows: > > > > <link rel="alternate" type="application/uddi-inq+xml" > > title="bizNameHere" > > href="url/to/SOAP/UDDIv2/inquiryAPI" /> > > > > The title attribute SHOULD contain the business name, which > > could be used > > in a UDDI find_business inquiry sent via SOAP to the href > > URL. Note that > > the type attribute contains a media type, which is currently > > not registered > > with IANA. This media type flags this link tag as one > > pointing to the SOAP > > UDDI v2 inquiry API. > > > > A web page may contain zero or more such links. For example, if the > > organization has published a bizEntity in both the UBR and a > > private UDDI > > registry, then two link tags would be used. Thus, agents > > (browsers and > > other web-enabled applications) that retrieve the homepage > > can examine the > > link tags to discover UDDI servers. > > > > The idea is to locate an HTTP server, for example, using DNS SRV RRs > > (_http._tcp.<domain>), then retrieve the XHTML home page > > associated with > > it. UDDI servers can be discovered using this technique. By > > providing the > > URL of the UDDI inquiry API, discovery software can be > > written to follow > > the pointers. This provides a way of bootstrapping web service > > consumers. Rather than manually configuring them with the > > SOAP inquiry > > URI, web service consumer applications would be manually > > configured only > > with, say, a tModelKey for services they need to find. Once > > they find UDDI > > servers using the technique described above, they can > > find_bindings with > > the tModelKey in the tModelBag. > > > > Note that using the link tag described above to retrieve the > > UDDI bizEntity > > for the organization is a two step process. First, do > > find_business with > > the name parameter set to the value of the title attribute (i.e., > > bizNameHere). Second, do get_businessDetail with the results > > of the first > > step. Both steps use SOAP (HTTP POST). > > > > A slightly different approach can be used to link directly to the > > associated bizEntity from the XHTML homepage using the > > following technique: > > > > <link rel="alternate" type="application/uddi-biz+xml" > > title="businessEntity" href="http-get/url/to/xml/bizEntity" /> > > > > The value of the href attribute would be the URI assigned by the UDDI > > server to the discoveryURL [1] with useType="businessEntity". > > It can be > > retrieved using HTTP GET. > > > > Using link tags would enable other things, such as > > bookmarklets [2]. For > > example, bookmarklets are available for Amphetadesk [3]. > > Perhaps tools > > like Amphetadesk will emerge that know how to grok the UDDI > > link tags to > > help discovery services in UDDI. > > > > [1] > > http://uddi.org/pubs/DataStructure-V2.03-Published-20020719.ht >m#_Toc25130759 >[2] http://www.bookmarklets.com/ >[3] http://diveintomark.org/projects/misc/autorss/amphetadesk.html > >Paul
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]