Browse Prior Art Database

Dynamic Discovery Of Web Service Registries

IP.com Disclosure Number: IPCOM000032892D
Original Publication Date: 2004-Nov-17
Included in the Prior Art Database: 2004-Nov-17
Document File: 6 page(s) / 56K

Publishing Venue

Motorola

Related People

B. Thale: AUTHOR

Abstract

Web services registries are used by applications to discover the existence, availability, and interface requirements of services available on a network or internetwork, specifically, the World Wide Web. These registries are themselves web services. Unfortunately, the current web services specifications do not address the initial bootstrapping issue of how an application discovers its initial registry service. That is, the current specifications for the two main registry providers, the Universal Description, Discovery and Integration (UDDI) and the Electronic Business using XML (ebXML) projects, assume that the location of the registry is known to the application a priori and describe only how to use the registry to discover other services available on the network. Therefore, a mechanism is needed that will allow an application to discover the presence of any web service registries available via its current point of attachment to the network and to recognize when it is no longer appropriate to continue using a previously discovered registry.

This text was extracted from a Microsoft Word document.
This is the abbreviated version, containing approximately 14% of the total text.

{This template contains instructions as hidden text.  Whether the text is viewable or not is controlled by checking or clearing the Tools/Options/View/Hidden Text checkbox.  This setting can also be toggled using the macro button on the toolbar just to the left of the B for Bold button.  By default, these instructions will not appear when the document is printed, but that may be controlled by setting or clearing the File/Print/Options/Print/Hidden Text checkbox.  It is not necessary to delete these instructions from the document, but you may do so if you wish.

This document template is currently maintained by Bryan Thale (bryan.thale@motorola.com).  Problem reports or suggestions on how to improve this template are welcome and greatly appreciated.

The purpose of defensive publication is to disclose to the public the inventions in sufficient detail to prevent third parties from obtaining patent protection on the same but later developed invention.  In this way it preserves Motorola’s right to use.

Actual preparation of the defensive publication will be by the inventor(s), subject of approval of a supervising attorney or agent, who will review for content to ensure the publication is sufficient (i.e. “enabling”) to effect the intended legal bar.  The primary document must be in one of the following formats in order for your document to be published:

·Microsoft Word Document (*.doc)

·HTML (*.htm, *.html)

·Plain Text (*.txt)

·Rich Text Format (*.rtf)

Your primary Microsoft Word or Rich Text Format document may contain certain objects, such as pictures or fully qualified hyperlinks.  However, utilizing embedded objects (e.g. an Excel spreadsheet) for the purposes of sharing information between programs may cause your publication to fail.  For example, in Word, information inserted using the “Edit / Paste Special / Paste Link” or “Insert / Object …” commands may embed unacceptable objects.  Including images in your document (in Word, use “Insert / Picture / From File …”) is acceptable and encouraged.

Your Microsoft Word primary document may not contain multiple versions (via “File/Versions”).  If you use the Word versioning feature, please delete ALL saved versions before submitting your document.  In addition, your Word document must not contain any revisions (via “Tools/Track Changes”).  If you use Track Changes, please select “Tools/Track Changes/Accept or Reject Changes” and click on the button to “Accept All” changes and then save your document.

For publications with HTML or Plain Text primary documents, images may be included in the attachment.  The attachment may be in a variety of formats, including TIFF (recommended), JPEG, or GIF.  Alternatively, you may use ZIP or a similar utility to package several image files into a single attachment file.  Relative hyperlinks for embedding images in HTML files is discouraged.  Utilizing separate image files is also acceptable for Word and RTF...