[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [uddi-spec] TN idea: link tags for UDDI
Sorry, I still can't who and why would use this technology? Is there a real life use case for this? Cheers, Max ----- Original Message ----- From: "Paul Denning" <pauld@mitre.org> To: <uddi-spec@lists.oasis-open.org> Sent: Saturday, May 10, 2003 7:14 AM 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-4C 5791E102B1" > /> > > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]