Re: new editor's draft of WSA available
Hugo Haas <[email protected]>
| Newsgroups | gmane.comp.web.services.ws-arch |
|---|---|
| Organization | World Wide Web Consortium (W3C) |
| Message-ID | <[email protected]> |
Content of the email, which ended up being messy: - a set of comments with an attached patch implementing them. - a request for the deletion of 3 sentences (comment that I had done a few weeks ago). * Christopher B Ferris <[email protected]> [2002-10-24 07:58-0400] > If others have also offered feedback and/or suggested changes, I would > encourage > them to identify their comments so that their feedback can be likewise > incorporated. First set of comments --------------------- I had been trying to tweak Heather's contributions in order not to imply that the architecture was registry-centric by commenting on HKsContribution.triangle.htm[1], but I obviously missed HKsContribution.discoveryagency.htm[2] in the email storm. HKsContribution.discoveryagency.htm is now section 3.3.4[3], so I will comment on this. Considering the time constraints, I will try and not start a long debate, just suggest simple, yet important for the sake of generalization, edits. First, a purely editorial comment: there are some redundancies in the text. In the 3.3.4 introduction, the end, from "The simplest, ..." until 3.3.4.1 is redundant with what is explained later, and what was said in the previous paragraph. The following is very UDDI-centric, and I think that we could add a few "such as", or "for example". 3.3.4.1.2, which lists examples, should IMO list publication on a Web site (WSDL document sitting at a URI). The following: | For service description repositories that span hosts within an | enterprise, a service provider would publish to a private UDDI | registry. suggests that UDDI is the only answer. I would change "would" by "may". In 3.3.4.2.3, I would change "WSIL, unlike UDDI, is not suited for many/most of the dynamic discovery/bind scenarios" to "Inspection, unlike registries, is not suited for many/most of the dynamic discovery/bind scenarios" to generalize concepts. I am sure that this very sentence can spark an interesting debate, but I just want to focus on editorial changes here. I would also remove the "index.html" example: index.html isn't a well known specified place. "/w3c/p3p.xml" is a better example. Attached is a patch against wd-wsa-arch.xml, revision 1.19 dated $Date: 2002/10/24 15:37:40 $, which implements my suggested changes. I apologize for any weirdness in the patch encoding: the file was in some weird Mac encoding that Emacs & diff were fighting over. [ Having just edited the document, I see that some of my comments went away when Joel's edits were incorporated. ] Second comment -------------- One last thing: I had suggested[4] to remove mentions of SOAP 1.1 in what is now section 3.3.1.2, since SOAP 1.2 is near completion, and I don't think we need to behave as historians here. I would remove "The current industry standard [..] input specification for the XML Protocol Working Group [XMLP 00]." (3 sentences) I will do a closer reading of the draft in the next few days (I just looked at the discovery section for now). Thanks. Regards, Hugo 1. http://lists.w3.org/Archives/Public/www-ws-arch/2002Sep/0223.html 2. http://lists.w3.org/Archives/Public/www-ws-arch/2002Sep/0219.html 3. http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-arch.html#IDAGCH2E 4. http://lists.w3.org/Archives/Public/www-ws-arch/2002Oct/0040.html -- Hugo Haas - W3C mailto:[email protected] - http://www.w3.org/People/Hugo/
wd-wsa-arch.diff
(text/plain, 13.3 KB)
--- wd-wsa-arch.xml Thu Oct 24 18:44:46 2002 +++ wd-wsa-arch-hh.xml Thu Oct 24 18:44:54 2002 @@ -440,28 +440,28 @@ <p>While the bottom three layers of the stack identify technologies for compliance and interoperability, the service publication and service discovery can be implemented with a range of solutions. </p> <graphic source="discovery.png" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad" alt="Discovery"/> - <p>Any action that makes a WSDL document available to a requestor, at any stage of the service requestorâs lifecycle, qualifies as service publication. The simplest, most static example is the service provider sending a WSDL document directly to a service requestor. This is called direct publication. E-mail is one vehicle for direct publish. Direct publish is useful for statically bound applications. Alternatively, the service provider may publish the WSDL document describing the service to a local WSDL registry, or to a private or public UDDI registry such as the UDDI Business Registry. The variety of service publication mechanisms is discussed in more detail in the section titled Service Publication. + <p>Any action that makes a WSDL document available to a requestor, at any stage of the service requestor-F¢s lifecycle, qualifies as service publication. The simplest, most static example is the service provider sending a WSDL document directly to a service requestor. This is called direct publication. E-mail is one vehicle for direct publish. Direct publish is useful for statically bound applications. Alternatively, the service provider may publish the WSDL document describing the service to a local WSDL registry, or to a private or public UDDI registry such as the UDDI Business Registry. The variety of service publication mechanisms is discussed in more detail in the section titled Service Publication.-A </p> - <p>Since a web service cannot be discovered if it has not been published, service discovery depends upon service publication. The variety of discovery mechanisms parallels the set of publication mechanisms. Any mechanism that allows the service requestor to gain access to the service description and make it available to the application at runtime qualifies as service discovery. The simplest, most static example of discovery is static discovery wherein the service requestor retrieves a WSDL document from a local file. This is usually the WSDL document obtained through a direct publish or the results of a previous find operation. Alternatively, the service may be discovered at design time or run time using a local WSDL registry, or a public or private UDDI registry. The variety of service discovery mechanisms is discussed in more detail in the section titled Service Discovery. + <p>Since a web service cannot be discovered if it has not been published, service discovery depends upon service publication. The variety of discovery mechanisms parallels the set of publication mechanisms. Any mechanism that allows the service requestor to gain access to the service description and make it available to the application at runtime qualifies as service discovery. The variety of service discovery mechanisms is discussed in more detail in the section titled Service Discovery. </p> <div4> <head>Service Publication</head> <div5> <head>Producing Service Descriptions</head> - <p>The service description may be generated, hand coded, or pieced together based on existing service interface definitions etc. Developers may hand code the entire service description, including the UDDI entry. Tools exist to generate parts of the WSDL and potentially parts of the UDDI entry from metadata artifacts from the programming model and the deployment of the web service executable. Parts of the service description may already exist (for example the web service may be based on an industry standard service interface definition) such that very little needs to be further generated. + <p>The service description may be generated, hand coded, or pieced together based on existing service interface definitions etc. Developers may hand code the entire service description, including a repository entry. Tools exist to generate parts of the WSDL description and potentially parts of a UDDI entry from metadata artifacts from the programming model and the deployment of the web service executable. Parts of the service description may already exist (for example the web service may be based on an industry standard service interface definition) such that very little needs to be further generated. </p> </div5> <div5> <head>Publishing Service Descriptions</head> - <p>A service description can be published using a variety of mechanisms. These various mechanisms provide different capabilities depending on how dynamic the application using the service is intended to be. The service description may be published to multiple service registries using several different mechanisms. The simplest case is a direct publish. A direct publish means the service provider sends the service description directly to the service requestor. This can be accomplished using an e-mail attachment, an FTP site, or even a CDROM distribution. Direct publish can occur after two business partners have agreed on terms of doing e-business over the web, or after fees have been paid by the service requestor for access to the service. In this case the service requestor may maintain a local copy of the service description. Slightly more dynamic publication uses WSIL. WSIL defines a simple HTTP GET mechanism to retrieve web services descriptions from a given URL. An enhanced service description repository would provide a local cache of service descriptions, but with additional search capabilities.</p> - <p>Another means of publishing service descriptions available to Web services is through a UDDI registry. There are several types of UDDI registries that may be used depending on the scope of the domain of web services published to it. + <p>A service description can be published using a variety of mechanisms. These various mechanisms provide different capabilities depending on how dynamic the application using the service is intended to be. The service description may be published to multiple service registries using several different mechanisms. The simplest case is a direct publish. A direct publish means the service provider sends the service description directly to the service requestor. This can be accomplished using an e-mail attachment, an FTP or Web site, or even a CDROM distribution. Direct publish can occur after two business partners have agreed on terms of doing e-business over the web, or after fees have been paid by the service requestor for access to the service. In this case the service requestor may maintain a local copy of the service description. Slightly more dynamic publication uses inspection. WSIL defines a simple HTTP GET mechanism to retrieve web services descriptions from a given URL. An enhanced service description repository would provide a local cache of service descriptions, but with additional search capabilities.</p> + <p>Another means of publishing service descriptions available to Web services is through a registry, such as UDDI. There are several types of UDDI registries that may be used depending on the scope of the domain of web services published to it. When publishing a Web service description to a UDDI registry, complete business context and well thought out taxonomies are essential if the service is to be found by its potential service consumers. </p> <ulist> <item> <p>Internal Enterprise Application UDDI registry: Web services for use within a company for internal enterprise applications integration should be published to a UDDI registry of this kind. The scope of this UDDI registry may be single application, departmental, or corporate. These UDDI registries sit behind the firewall and allow the service publishers more control over their service registry and its accessibility, availability, and publication requirements. </p> </item> <item> - <p>Portal UDDI registry: Web services published by a company for external partners to find and use may use a portal UDDI registry. A portal UDDI registry runs in the service providerâs environment outside the firewall or in a DMZ between firewalls. This kind of private UDDI registry contains only those service descriptions that a company wishes to provide to service requestors from external partners. This allows companies to retain control of their service descriptions, access to the UDDI registry and quality of service for the UDDI registries. Moreover, by using the Role based visibility inherent in portals, and emerging in newer drafts of the UDDI specs themselves, the enterprise may limit visibility of service descriptions to the partners authorized to see their existence.</p> + <p>Portal UDDI registry: Web services published by a company for external partners to find and use may use a portal UDDI registry. A portal UDDI registry runs in the service provider-F¢s environment outside the firewall or in a DMZ between firewalls. This kind of private UDDI registry contains only those service descriptions that a company wishes to provide to service requestors from external partners. This allows companies to retain control of their service descriptions, access to the UDDI registry and quality of service for the UDDI registries. Moreover, by using the Role based visibility inherent in portals, and emerging in newer drafts of the UDDI specs themselves, the enterprise may limit visibility of service descriptions to the partners authorized to see their existence.</p>-A </item> <item> <p>Partner Catalog UDDI registry: Web services to be used by a particular company can be published to a Partner Catalog (rolodex like) UDDI registry. A Partner Catalog UDDI registry sits behind the firewall. This kind of private UDDI registry contains only approved, tested, and valid web service descriptions from legitimate business partners. The business context and metadata for these web services can be targeted to the specific requestor. @@ -485,7 +485,7 @@ <head>Service Discovery</head> <div5> <head>Acquiring Service Descriptions</head> - <p>As with publishing Web service descriptions, acquiring Web service descriptions will vary depending on how the service description is published and how dynamic the Web service application is meant to be. Service requestors will find Web services during two different phases of an application lifecycle â design time and run time. At design time, service requestors will search for web service descriptions by the type of interface they support. At run time service requestors will search for a web service based on how they communicate or qualities of service advertised. + <p>As with publishing Web service descriptions, acquiring Web service descriptions will vary depending on how the service description is published and how dynamic the Web service application is meant to be. Service requestors will find Web services during two different phases of an application lifecycle $(O#|(B design time and run time. At design time, service requestors will search for web service descriptions by the type of interface they support. At run time service requestors will search for a web service based on how they communicate or qualities of service advertised. </p> <p>With the direct publish approach, the service requestor will cache the service description at design time for use at runtime. The service description may be statically represented in the program logic, stored in a file, or in a simple, local service description repository. </p> @@ -501,8 +501,8 @@ </div5> <div5> <head>Inspection</head> - <p>WSIL provides a de-centralized service discovery method and it can be used to discover web services at the service provider's point-of-offering. The WSIL specification defines a file that contains a list of WSDL URLs and WSIL URLs in a domain. WSIL can also reference UDDI entries/repositories and RDF documents as well. It can actually contain references to anything. The WSIL specification defines a convention for naming and placing the files so that they are easier to locate (similar to index.html and robots.txt files). WSIL, unlike UDDI, is not suited for many/most of the dynamic discovery/bind scenarios (simply because there is no searching capability). + <p>Inspection is a de-centralized service discovery method that can be used to discover web services at the service provider's point-of-offering. The WSIL specification defines a file that contains a list of WSDL URLs and WSIL URLs in a domain. WSIL can also reference UDDI entries/repositories and RDF documents as well. It can actually contain references to anything. The WSIL specification defines a convention for naming and placing the files so that they are easier to locate (similar to the /w3c/p3p.xml and /robots.txt locations). Inspection, unlike the use of registries, is not suited for many/most of the dynamic discovery/bind scenarios (simply because there is no searching capability). </p> <p>They may or may not be local to the system. WSIL documents can be used to enable a variety of discovery agent patterns: </p>