Loading ...
Sorry, an error occurred while loading the content.

Re: ANN: Distributed Registry for Web Services

Expand Messages
  • Roger L. Costello
    Hi Ranjeet, Perhaps we shouldn t have used the word registry as that word seems to have some baggage associated with it, and is automatically leading people
    Message 1 of 5 , Dec 19, 2002
    • 0 Attachment
      Hi Ranjeet,

      Perhaps we shouldn't have used the word "registry" as that word seems to
      have some baggage associated with it, and is automatically leading
      people down the wrong path. What you have nicely described is a way to
      implement a centralized registry using LDAP. This is not what we have
      in mind.

      Here's our idea: suppose that you go and create a Web service. How do I
      use your service? Perhaps you would like to create a document (or
      documents) to describe your service. There are many technologies that
      have been created to describe services - WSDL, DAML, tModels, XHTML,
      etc. We place no restriction on what you use to desribe your service.

      Next you associate a URL to your service description. Suppose that this
      is the URL to your service description:

      http://www.parts-depot.com/parts/metadata

      When a client submits this URL a description of the service will be
      returned (and the description may be customized based upon the value of
      the HTTP Accept header field in the client's request). You may ask, how
      does the description get generated and returned to the client? Answer:
      The person who created the service is also responsible for implementing
      its metadata "service". We make no restrictions on how it is
      implemented, e.g., using a servlet, cgi script, vb script, etc. This is
      standard Web technology.

      The interesting (novel) feature is that in the HTTP header of the
      description that is returned to the client is a Meta-About header. This
      contains the URL to the service that this metadata describes. For
      example:

      Meta-About: http://www.parts-depot.com/parts

      Thus, this identifies that the description is for the service at this
      URL.

      Conversely, if the client submits the service URL then a representation
      of the service is returned to the client. (Again, we make no
      restrictions on how the service is implemented - SOAP, REST, RPC, etc)
      In the HTTP header is a Meta-Location header that provides the URL to
      the description of the service. For example:

      Meta-Location: http://www.parts-depot/parts/metadata

      Do you see that EACH service implements its service and its metadata?
      And given the service you can locate its metadata description (using
      Meta-Location), or given the metadata description you can locate the
      service (using Meta-About).

      As you can see, there is no "central storage place" where all the
      service implementors store their service metadata. No. Instead, the
      service metadata is distributed across the Web, is owned and created by
      each service implementor.

      Sorry to be so long-winded. I hope that this clears things up. /Roger

      Ranjeet Sonone wrote:
      >
      > A first look at the presentation gives an impression that
      > the easiest and most natural way to build such a registry
      > is (one or more) LDAP Directory servers.
      >
      > The features required in a distributed registry are already available.
      > The features like object-oriented support(inheritance of objectclass
      > definitions)
      > replication, referral etc. are already supported
      > by major LDAP vendors (Novell LDAP server is free for 250,000 entries).
      >
      > One can define schema for UDDI defined objects,
      > provide a DSML gateway for the information that comes out,
      > so that it is all XML and then slap an API layer on top of the
      > directory (which is now the registry) to give UDDI compliant API
      > support. This is the meat of it.;-) lot of work!
      >
      > I think LDAP looks like a good candidate for such a registry.
      > What do you think?
      > -ranjeet
      >
      > -----Original Message-----
      > From: Chiusano Joseph [mailto:chiusano_joseph@...]
      > Sent: Wednesday, December 18, 2002 1:18 PM
      > To: Roger L. Costello
      > Cc: xml-dev@...; JacobsDavid B.
      > Subject: Re: [xml-dev] ANN: Distributed Registry for Web Services
      >
      > Roger,
      >
      > The v3 spec is not formally approved yet, but the following URL from the
      > open e-mail archives references a presentation that details the V3
      > enhancements (this is all public information):
      >
      > http://lists.oasis-open.org/archives/regrep/200212/msg00016.html
      >
      > Just search for the word "federated".
      >
      > Hope that helps,
      > Joe
      >
      > "Roger L. Costello" wrote:
      > >
      > > Chiusano Joseph wrote:
      > > >
      > > > Some additional information: the OASIS/ebXML Registry v3.0
      > > > enhancements will include support for distributed (known as
      > > > "federated") registries.
      > >
      > > Thanks Joe. I wasn't able to locate the info you reference. Can you
      > > provide a URL? In any case, I suspect that their federated registries
      > > are more heavyweight and relatively fewer in number than we are
      > > envisioning. Our interest is in very lightweight, massively
      > distributed
      > > registries. /Roger
      > >
      > > > "Roger L. Costello" wrote:
      > > > >
      > > > > Hi Folks,
      > > > >
      > > > > You are invited to participate in the collaborative development of
      > a
      > > > > distributed registry technology.
      > > > >
      > > > > We have created a list (distributed-registry) for discussion of
      > this
      > > > > topic. To subscribe to the list send an empty email to:
      > > > >
      > > > > distributed-registry-subscribe@yahoogroups.com
      > > > >
      > > > > Here is a description of the purpose of a distributed registry:
      > > > >
      > > > > A Web service registry provides information about what services
      > do, and
      > > > > how they are used. Today's Web service registries (e.g., UDDI and
      > ebXML)
      > > > > are implemented as centralized repositories. That is, all services
      > store
      > > > > their service descriptions within a single, or a small number of
      > > > > registries. The purpose of this effort is to develop a concrete,
      > > > > implementable architecture for a highly distributed registry. The
      > notion
      > > > > is that each Web service defines their own registry - comprised of
      > the
      > > > > collection of documents that describes the service.
      > > > >
      > > > > We have created a Web page which
      > > > > - lists the design goals for a distributed registry, and
      > > > > - proposes an architecture
      > > > >
      > > > > Here's the URL to the Web page:
      > > > >
      > > > > http://www.xfront.com/dist-reg/distributed-registry.html
      > > > >
      > > > > We invite you to participate in the development of this
      > technology.
      > > > > Thanks!
      > > > >
      > > > > Roger L. Costello and David B. Jacobs
      > > > >
      > > > > -----------------------------------------------------------------
      > > > > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
      > > > > initiative of OASIS <http://www.oasis-open.org>
      > > > >
      > > > > The list archives are at http://lists.xml.org/archives/xml-dev/
      > > > >
      > > > > To subscribe or unsubscribe from this list use the subscription
      > > > > manager: <http://lists.xml.org/ob/adm.pl>
      > >
      > > -----------------------------------------------------------------
      > > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
      > > initiative of OASIS <http://www.oasis-open.org>
      > >
      > > The list archives are at http://lists.xml.org/archives/xml-dev/
      > >
      > > To subscribe or unsubscribe from this list use the subscription
      > > manager: <http://lists.xml.org/ob/adm.pl>
    • Seairth Jacobs
      Maybe I missed this, but how does the client find the service description URL in the first place? ... Seairth Jacobs seairth@seairth.com ... From: Roger L.
      Message 2 of 5 , Dec 19, 2002
      • 0 Attachment
        Maybe I missed this, but how does the client find the service description
        URL in the first place?

        ---
        Seairth Jacobs
        seairth@...

        ----- Original Message -----
        From: "Roger L. Costello" <costello@...>
        To: "Ranjeet Sonone" <ranjeet@...>
        Cc: "Chiusano Joseph" <chiusano_joseph@...>; "JacobsDavid B."
        <djacobs@...>; <distributed-registry@yahoogroups.com>; "Costello,Roger
        L." <costello@...>
        Sent: Thursday, December 19, 2002 8:35 AM
        Subject: [distributed-registry] Re: ANN: Distributed Registry for Web
        Services


        > Hi Ranjeet,
        >
        > Perhaps we shouldn't have used the word "registry" as that word seems to
        > have some baggage associated with it, and is automatically leading
        > people down the wrong path. What you have nicely described is a way to
        > implement a centralized registry using LDAP. This is not what we have
        > in mind.
        >
        > Here's our idea: suppose that you go and create a Web service. How do I
        > use your service? Perhaps you would like to create a document (or
        > documents) to describe your service. There are many technologies that
        > have been created to describe services - WSDL, DAML, tModels, XHTML,
        > etc. We place no restriction on what you use to desribe your service.
        >
        > Next you associate a URL to your service description. Suppose that this
        > is the URL to your service description:
        >
        > http://www.parts-depot.com/parts/metadata
        >
        > When a client submits this URL a description of the service will be
        > returned (and the description may be customized based upon the value of
        > the HTTP Accept header field in the client's request). You may ask, how
        > does the description get generated and returned to the client? Answer:
        > The person who created the service is also responsible for implementing
        > its metadata "service". We make no restrictions on how it is
        > implemented, e.g., using a servlet, cgi script, vb script, etc. This is
        > standard Web technology.
        >
        > The interesting (novel) feature is that in the HTTP header of the
        > description that is returned to the client is a Meta-About header. This
        > contains the URL to the service that this metadata describes. For
        > example:
        >
        > Meta-About: http://www.parts-depot.com/parts
        >
        > Thus, this identifies that the description is for the service at this
        > URL.
        >
        > Conversely, if the client submits the service URL then a representation
        > of the service is returned to the client. (Again, we make no
        > restrictions on how the service is implemented - SOAP, REST, RPC, etc)
        > In the HTTP header is a Meta-Location header that provides the URL to
        > the description of the service. For example:
        >
        > Meta-Location: http://www.parts-depot/parts/metadata
        >
        > Do you see that EACH service implements its service and its metadata?
        > And given the service you can locate its metadata description (using
        > Meta-Location), or given the metadata description you can locate the
        > service (using Meta-About).
        >
        > As you can see, there is no "central storage place" where all the
        > service implementors store their service metadata. No. Instead, the
        > service metadata is distributed across the Web, is owned and created by
        > each service implementor.
        >
        > Sorry to be so long-winded. I hope that this clears things up. /Roger
        >
        > Ranjeet Sonone wrote:
        > >
        > > A first look at the presentation gives an impression that
        > > the easiest and most natural way to build such a registry
        > > is (one or more) LDAP Directory servers.
        > >
        > > The features required in a distributed registry are already available.
        > > The features like object-oriented support(inheritance of objectclass
        > > definitions)
        > > replication, referral etc. are already supported
        > > by major LDAP vendors (Novell LDAP server is free for 250,000 entries).
        > >
        > > One can define schema for UDDI defined objects,
        > > provide a DSML gateway for the information that comes out,
        > > so that it is all XML and then slap an API layer on top of the
        > > directory (which is now the registry) to give UDDI compliant API
        > > support. This is the meat of it.;-) lot of work!
        > >
        > > I think LDAP looks like a good candidate for such a registry.
        > > What do you think?
        > > -ranjeet
        > >
        > > -----Original Message-----
        > > From: Chiusano Joseph [mailto:chiusano_joseph@...]
        > > Sent: Wednesday, December 18, 2002 1:18 PM
        > > To: Roger L. Costello
        > > Cc: xml-dev@...; JacobsDavid B.
        > > Subject: Re: [xml-dev] ANN: Distributed Registry for Web Services
        > >
        > > Roger,
        > >
        > > The v3 spec is not formally approved yet, but the following URL from the
        > > open e-mail archives references a presentation that details the V3
        > > enhancements (this is all public information):
        > >
        > > http://lists.oasis-open.org/archives/regrep/200212/msg00016.html
        > >
        > > Just search for the word "federated".
        > >
        > > Hope that helps,
        > > Joe
        > >
        > > "Roger L. Costello" wrote:
        > > >
        > > > Chiusano Joseph wrote:
        > > > >
        > > > > Some additional information: the OASIS/ebXML Registry v3.0
        > > > > enhancements will include support for distributed (known as
        > > > > "federated") registries.
        > > >
        > > > Thanks Joe. I wasn't able to locate the info you reference. Can you
        > > > provide a URL? In any case, I suspect that their federated registries
        > > > are more heavyweight and relatively fewer in number than we are
        > > > envisioning. Our interest is in very lightweight, massively
        > > distributed
        > > > registries. /Roger
        > > >
        > > > > "Roger L. Costello" wrote:
        > > > > >
        > > > > > Hi Folks,
        > > > > >
        > > > > > You are invited to participate in the collaborative development of
        > > a
        > > > > > distributed registry technology.
        > > > > >
        > > > > > We have created a list (distributed-registry) for discussion of
        > > this
        > > > > > topic. To subscribe to the list send an empty email to:
        > > > > >
        > > > > > distributed-registry-subscribe@yahoogroups.com
        > > > > >
        > > > > > Here is a description of the purpose of a distributed registry:
        > > > > >
        > > > > > A Web service registry provides information about what services
        > > do, and
        > > > > > how they are used. Today's Web service registries (e.g., UDDI and
        > > ebXML)
        > > > > > are implemented as centralized repositories. That is, all services
        > > store
        > > > > > their service descriptions within a single, or a small number of
        > > > > > registries. The purpose of this effort is to develop a concrete,
        > > > > > implementable architecture for a highly distributed registry. The
        > > notion
        > > > > > is that each Web service defines their own registry - comprised of
        > > the
        > > > > > collection of documents that describes the service.
        > > > > >
        > > > > > We have created a Web page which
        > > > > > - lists the design goals for a distributed registry, and
        > > > > > - proposes an architecture
        > > > > >
        > > > > > Here's the URL to the Web page:
        > > > > >
        > > > > > http://www.xfront.com/dist-reg/distributed-registry.html
        > > > > >
        > > > > > We invite you to participate in the development of this
        > > technology.
        > > > > > Thanks!
        > > > > >
        > > > > > Roger L. Costello and David B. Jacobs
        > > > > >
        > > > > > -----------------------------------------------------------------
        > > > > > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
        > > > > > initiative of OASIS <http://www.oasis-open.org>
        > > > > >
        > > > > > The list archives are at http://lists.xml.org/archives/xml-dev/
        > > > > >
        > > > > > To subscribe or unsubscribe from this list use the subscription
        > > > > > manager: <http://lists.xml.org/ob/adm.pl>
        > > >
        > > > -----------------------------------------------------------------
        > > > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
        > > > initiative of OASIS <http://www.oasis-open.org>
        > > >
        > > > The list archives are at http://lists.xml.org/archives/xml-dev/
        > > >
        > > > To subscribe or unsubscribe from this list use the subscription
        > > > manager: <http://lists.xml.org/ob/adm.pl>
        >
        >
        >
        > To unsubscribe from this group, send an email to:
        > distributed-registry-unsubscribe@yahoogroups.com
        >
        >
        >
        > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
        >
        >
        >
      • David and Lisa Jacobs <dbj@yahoo.com>
        Since a browser accessing the URL should return an HTML document describing the service, we are relying on Google like services to fill this need. David ...
        Message 3 of 5 , Dec 19, 2002
        • 0 Attachment
          Since a browser accessing the URL should return an HTML document
          describing the service, we are relying on Google like services to fill
          this need.

          David

          --- In distributed-registry@yahoogroups.com, "Seairth Jacobs"
          <seairth@s...> wrote:
          > Maybe I missed this, but how does the client find the service
          description
          > URL in the first place?
          >
          > ---
          > Seairth Jacobs
          > seairth@s...
          >
          > ----- Original Message -----
          > From: "Roger L. Costello" <costello@m...>
          > To: "Ranjeet Sonone" <ranjeet@i...>
          > Cc: "Chiusano Joseph" <chiusano_joseph@b...>; "JacobsDavid B."
          > <djacobs@m...>; <distributed-registry@yahoogroups.com>; "Costello,Roger
          > L." <costello@m...>
          > Sent: Thursday, December 19, 2002 8:35 AM
          > Subject: [distributed-registry] Re: ANN: Distributed Registry for Web
          > Services
          >
          >
          > > Hi Ranjeet,
          > >
          > > Perhaps we shouldn't have used the word "registry" as that word
          seems to
          > > have some baggage associated with it, and is automatically leading
          > > people down the wrong path. What you have nicely described is a
          way to
          > > implement a centralized registry using LDAP. This is not what we have
          > > in mind.
          > >
          > > Here's our idea: suppose that you go and create a Web service.
          How do I
          > > use your service? Perhaps you would like to create a document (or
          > > documents) to describe your service. There are many technologies that
          > > have been created to describe services - WSDL, DAML, tModels, XHTML,
          > > etc. We place no restriction on what you use to desribe your service.
          > >
          > > Next you associate a URL to your service description. Suppose
          that this
          > > is the URL to your service description:
          > >
          > > http://www.parts-depot.com/parts/metadata
          > >
          > > When a client submits this URL a description of the service will be
          > > returned (and the description may be customized based upon the
          value of
          > > the HTTP Accept header field in the client's request). You may
          ask, how
          > > does the description get generated and returned to the client?
          Answer:
          > > The person who created the service is also responsible for
          implementing
          > > its metadata "service". We make no restrictions on how it is
          > > implemented, e.g., using a servlet, cgi script, vb script, etc.
          This is
          > > standard Web technology.
          > >
          > > The interesting (novel) feature is that in the HTTP header of the
          > > description that is returned to the client is a Meta-About header.
          This
          > > contains the URL to the service that this metadata describes. For
          > > example:
          > >
          > > Meta-About: http://www.parts-depot.com/parts
          > >
          > > Thus, this identifies that the description is for the service at this
          > > URL.
          > >
          > > Conversely, if the client submits the service URL then a
          representation
          > > of the service is returned to the client. (Again, we make no
          > > restrictions on how the service is implemented - SOAP, REST, RPC, etc)
          > > In the HTTP header is a Meta-Location header that provides the URL to
          > > the description of the service. For example:
          > >
          > > Meta-Location: http://www.parts-depot/parts/metadata
          > >
          > > Do you see that EACH service implements its service and its metadata?
          > > And given the service you can locate its metadata description (using
          > > Meta-Location), or given the metadata description you can locate the
          > > service (using Meta-About).
          > >
          > > As you can see, there is no "central storage place" where all the
          > > service implementors store their service metadata. No. Instead, the
          > > service metadata is distributed across the Web, is owned and
          created by
          > > each service implementor.
          > >
          > > Sorry to be so long-winded. I hope that this clears things up.
          /Roger
          > >
          > > Ranjeet Sonone wrote:
          > > >
          > > > A first look at the presentation gives an impression that
          > > > the easiest and most natural way to build such a registry
          > > > is (one or more) LDAP Directory servers.
          > > >
          > > > The features required in a distributed registry are already
          available.
          > > > The features like object-oriented support(inheritance of objectclass
          > > > definitions)
          > > > replication, referral etc. are already supported
          > > > by major LDAP vendors (Novell LDAP server is free for 250,000
          entries).
          > > >
          > > > One can define schema for UDDI defined objects,
          > > > provide a DSML gateway for the information that comes out,
          > > > so that it is all XML and then slap an API layer on top of the
          > > > directory (which is now the registry) to give UDDI compliant API
          > > > support. This is the meat of it.;-) lot of work!
          > > >
          > > > I think LDAP looks like a good candidate for such a registry.
          > > > What do you think?
          > > > -ranjeet
          > > >
          > > > -----Original Message-----
          > > > From: Chiusano Joseph [mailto:chiusano_joseph@b...]
          > > > Sent: Wednesday, December 18, 2002 1:18 PM
          > > > To: Roger L. Costello
          > > > Cc: xml-dev@l...; JacobsDavid B.
          > > > Subject: Re: [xml-dev] ANN: Distributed Registry for Web Services
          > > >
          > > > Roger,
          > > >
          > > > The v3 spec is not formally approved yet, but the following URL
          from the
          > > > open e-mail archives references a presentation that details the V3
          > > > enhancements (this is all public information):
          > > >
          > > > http://lists.oasis-open.org/archives/regrep/200212/msg00016.html
          > > >
          > > > Just search for the word "federated".
          > > >
          > > > Hope that helps,
          > > > Joe
          > > >
          > > > "Roger L. Costello" wrote:
          > > > >
          > > > > Chiusano Joseph wrote:
          > > > > >
          > > > > > Some additional information: the OASIS/ebXML Registry v3.0
          > > > > > enhancements will include support for distributed (known as
          > > > > > "federated") registries.
          > > > >
          > > > > Thanks Joe. I wasn't able to locate the info you reference.
          Can you
          > > > > provide a URL? In any case, I suspect that their federated
          registries
          > > > > are more heavyweight and relatively fewer in number than we are
          > > > > envisioning. Our interest is in very lightweight, massively
          > > > distributed
          > > > > registries. /Roger
          > > > >
          > > > > > "Roger L. Costello" wrote:
          > > > > > >
          > > > > > > Hi Folks,
          > > > > > >
          > > > > > > You are invited to participate in the collaborative
          development of
          > > > a
          > > > > > > distributed registry technology.
          > > > > > >
          > > > > > > We have created a list (distributed-registry) for
          discussion of
          > > > this
          > > > > > > topic. To subscribe to the list send an empty email to:
          > > > > > >
          > > > > > > distributed-registry-subscribe@yahoogroups.com
          > > > > > >
          > > > > > > Here is a description of the purpose of a distributed
          registry:
          > > > > > >
          > > > > > > A Web service registry provides information about what
          services
          > > > do, and
          > > > > > > how they are used. Today's Web service registries (e.g.,
          UDDI and
          > > > ebXML)
          > > > > > > are implemented as centralized repositories. That is, all
          services
          > > > store
          > > > > > > their service descriptions within a single, or a small
          number of
          > > > > > > registries. The purpose of this effort is to develop a
          concrete,
          > > > > > > implementable architecture for a highly distributed
          registry. The
          > > > notion
          > > > > > > is that each Web service defines their own registry -
          comprised of
          > > > the
          > > > > > > collection of documents that describes the service.
          > > > > > >
          > > > > > > We have created a Web page which
          > > > > > > - lists the design goals for a distributed registry, and
          > > > > > > - proposes an architecture
          > > > > > >
          > > > > > > Here's the URL to the Web page:
          > > > > > >
          > > > > > > http://www.xfront.com/dist-reg/distributed-registry.html
          > > > > > >
          > > > > > > We invite you to participate in the development of this
          > > > technology.
          > > > > > > Thanks!
          > > > > > >
          > > > > > > Roger L. Costello and David B. Jacobs
          > > > > > >
          > > > > > >
          -----------------------------------------------------------------
          > > > > > > The xml-dev list is sponsored by XML.org
          <http://www.xml.org>, an
          > > > > > > initiative of OASIS <http://www.oasis-open.org>
          > > > > > >
          > > > > > > The list archives are at
          http://lists.xml.org/archives/xml-dev/
          > > > > > >
          > > > > > > To subscribe or unsubscribe from this list use the
          subscription
          > > > > > > manager: <http://lists.xml.org/ob/adm.pl>
          > > > >
          > > > > -----------------------------------------------------------------
          > > > > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
          > > > > initiative of OASIS <http://www.oasis-open.org>
          > > > >
          > > > > The list archives are at http://lists.xml.org/archives/xml-dev/
          > > > >
          > > > > To subscribe or unsubscribe from this list use the subscription
          > > > > manager: <http://lists.xml.org/ob/adm.pl>
          > >
          > >
          > >
          > > To unsubscribe from this group, send an email to:
          > > distributed-registry-unsubscribe@yahoogroups.com
          > >
          > >
          > >
          > > Your use of Yahoo! Groups is subject to
          http://docs.yahoo.com/info/terms/
          > >
          > >
          > >
        • Roger L. Costello
          Hi Seairth, ... This is the so-called matchmaking problem, i.e., matching a client to a service. We deliberately kept the matchmaking problem separate from
          Message 4 of 5 , Dec 19, 2002
          • 0 Attachment
            Hi Seairth,

            Seairth Jacobs wrote:
            >
            > Maybe I missed this, but how does the client find the service
            > description URL in the first place?

            This is the so-called "matchmaking" problem, i.e., matching a client to
            a service. We deliberately kept the matchmaking problem separate from
            the registry problem (consequently, we make no restrictions on the
            matchmaker).

            To answer your question more specifically, there are many ways for a
            client to find a service:

            - if the client is browser-based then simply use Google to locate the
            service (resource)
            . Since the services and their metadata are simply Web sites
            the Google Web crawlers can easily index them. Contrast that
            with a centralized registry where it would be very difficult
            (impossible?) for a Web crawler to index all the services
            and descriptions stored in the registy.
            . One of the really cool things about this distributed
            registry approach is that Google will be able to
            PageRank services - based upon frequency of hits, recency of
            hits, etc.

            - if the client is an RDF or DAML engine then use a search engine that
            understand the RDF/DAML vocabulary.

            /Roger
          • Frank Wilhoit <Frank.Wilhoit@das.state.o
            Roger, The matchmaking problem is really the starting point. It is the first step of discovery. It needs to be standardized. Since we already have a
            Message 5 of 5 , Dec 20, 2002
            • 0 Attachment
              Roger,

              The matchmaking problem is really the starting point. It is the first
              step of discovery. It needs to be standardized. Since we already
              have a distributed directory that has proven extremely robust
              efficient and flexible, viz. DNS, I suggest that a new type of DNS
              entry be defined, the "WS" entry, somewhat analogous to the "MX"
              entry. The "WS" entry would specify the address within a domain to go
              to for information about that domain's Web services.

              Also I quite fail to understand your enthusiasm for page-ranking
              mechanisms, or indeed their relevance to the discovery/description
              problem--especially since they are so notoriously subject to manipulation.

              Thanks,
              FW
              .


              --- In distributed-registry@yahoogroups.com, "Roger L. Costello"
              <costello@m...> wrote:
              > Hi Seairth,
              >
              > Seairth Jacobs wrote:
              > >
              > > Maybe I missed this, but how does the client find the service
              > > description URL in the first place?
              >
              > This is the so-called "matchmaking" problem, i.e., matching a client to
              > a service. We deliberately kept the matchmaking problem separate from
              > the registry problem (consequently, we make no restrictions on the
              > matchmaker).
              >
              > To answer your question more specifically, there are many ways for a
              > client to find a service:
              >
              > - if the client is browser-based then simply use Google to locate the
              > service (resource)
              > . Since the services and their metadata are simply Web sites
              > the Google Web crawlers can easily index them. Contrast that
              > with a centralized registry where it would be very difficult
              > (impossible?) for a Web crawler to index all the services
              > and descriptions stored in the registy.
              > . One of the really cool things about this distributed
              > registry approach is that Google will be able to
              > PageRank services - based upon frequency of hits, recency of
              > hits, etc.
              >
              > - if the client is an RDF or DAML engine then use a search engine that
              > understand the RDF/DAML vocabulary.
              >
              > /Roger
            Your message has been successfully submitted and would be delivered to recipients shortly.